HTTP status codes (also called HTTP response codes) are three-digit numbers a web server sends back every time a browser or crawler requests a page. A response code tells both search engines and users the webpage’s current condition and what content to expect.

The server returns the same status code to browsers and crawlers. People rarely see the number, but crawlers use it to decide whether to index a URL, follow it somewhere new, or come back and try again later.

This guide provides a practical playbook for checking status codes, understanding what common codes mean, and knowing when to act. Getting these responses right is a core part of technical SEO, as they shape how search engines crawl and index every URL on your site.

How to check a page’s HTTP status code

Different ways to find and check the HTTP status code of a web page.

Browser extensions

Using a browser extension can show the response code for every page you load, including each hop in a redirect.

The best browser extension I’ve found for identifying status codes is ‘Redirect Path’. This extension displays the page’s status code, and you can select it to view the path users and bots were directed through.

For example, if you were directed through a redirect chain of multiple pages, you can break down which pages you visited before reaching the final destination.

If you see chains like this across a site relaunch or an HTTPS move, treat them as a migration quality assurance (QA) item, not a one-off browser quirk. At SALT, redirect mapping and chain clean-up are non-negotiable migration QA. Our SEO website migrations start with the reality that most migrations fail to recover traffic quickly if redirects are left messy. 

A common false alarm: If a site uses HSTS (HTTP Strict Transport Security), Chrome upgrades HTTP requests to HTTPS itself and reports a “307 Internal Redirect”. That 307 comes from the browser, not your server. Confirm the real response with a crawler or a command-line request (for example, curl -I) before reporting it as a problem.

Chrome DevTools

The manual way to view the status code of a page involves using Chrome DevTools. To access these tools, you need to right-click a webpage and click ‘Inspect’.

Once you have developer tools open, go to the ‘Network’ tab and look for the response with the page URL slug (this is often highlighted) and look at the value in the ‘Status’ column as this will contain the response code of the page.

Tip: Tick ‘Preserve log’ before you load the page, as otherwise DevTools clears the Network tab each time the page navigates. That means JavaScript and meta refresh redirects may vanish from the log before you see them.

Command line

Run curl -I followed by the URL to see the raw response headers, including the status code, exactly as the server sends them. Add -L to follow each redirect and print every hop. This can quickly rule out browser behaviour, such as cached redirects or the HSTS upgrade.

Bulk check HTTP status codes

To identify any site-wide problems, check status codes in bulk. Crawl the site with a tool such as Screaming Frog SEO Spider. This lists every URL’s response code with a dedicated redirect chains report. Filter for 3XX, 4XX, and 5XX responses and fix any priority pages with problems first.

Compare what your crawler and Google saw. In Google Search Console, the Crawl stats report (under Settings) breaks Googlebot’s requests down by response code, and the URL Inspection tool shows how Google fetched a single URL. Google’s documentation notes that its inspection tools don’t follow redirects, so inspect the final destination URL too.

Then check your server logs for an accurate picture. They record the status code returned to every request, including errors that only appear under load. Verify that requests really come from Googlebot with our beginner’s guide to log file analysis. 

Status code classes

The first digit of each response code represents the class of the response. There are five classes of response code, as shown below:

1XX – Informational – These codes are temporary responses until a final server response has been provided. They indicate that the server has received the request and is currently processing a response.

2XX – Success – The server has received the request from the browser, processed the request and accepted it. With 2XX codes, no actions are required by users or search engine bots, as everything has been carried out successfully.

3XX – Redirection – Redirect status codes mean there are additional actions to be completed by the client (a browser or crawler) before the final page can be reached. These codes are most commonly used to direct users and search engine bots to a new page.

4XX – Client Error – These codes indicate there was an issue with processing the request that was not a result of the server, and it is not able to deliver what the user is requesting.

5XX – Server Error – These codes are a result of a request not being completed due to an issue on the server’s side. 

Common status codes and how to handle them

Every class includes several response codes, each with its own purpose. These are the common response codes and how website owners and webmasters should treat each one.

HTTP status codes quick reference

Use this table for a brief overview of common codes, with more detail about each one below.

Code What it means What to do for SEO
200 OK Request succeeded No action, but check it isn’t a soft 404
301 Moved Permanently Permanent move Point straight at the final URL, one hop
302 Found Temporary move Use only when the old URL will return
304 Not Modified Unchanged since last request Return it accurately to save crawl resources
307 / 308 Temporary/permanent, method kept Use when a POST or other method must be kept
404 Not Found Page doesn’t exist Fix internal links; redirect only to a real replacement
410 Gone Removed on purpose Use for deliberate, permanent removals
429 Too Many Requests Rate limited Check CDN and firewall rules aren’t throttling Googlebot
500 Internal Server Error Generic server failure Check logs; Google slows crawling
503 Service Unavailable Temporarily unavailable Use for maintenance with Retry-After; keep it short
504 Gateway Timeout Upstream server too slow Find the slow layer and check proxy timeouts

2XX success codes

200 – OK – This is the generic response for when the request has been processed by the server and delivered successfully to the client (user).

No action is required for pages with a 200 status code. A 200 http status code tells Google the content can move on to indexing. However, Google’s status code documentation makes it clear that it doesn’t guarantee the page will be indexed.

If the page is a soft 404, you can either add appropriate content, implement a redirect to a relevant page or remove the page completely. Find soft 404s in the Page indexing report in Google Search Console, where they’re listed as a reason pages aren’t indexed.

3XX redirect codes

301 – Permanent redirect – This code is used when a permanent redirect has been implemented, resulting in users and bots being directed to another location.

In the past, Google indicated that some PageRank was lost when a link passed through a redirect.

That changed in July 2016, when Google’s Gary Illyes confirmed that 30x redirects no longer lose PageRank. Today, Google’s redirects documentation describes a permanent redirect as a strong signal that the target should be canonical, and in practice link signals generally consolidate to the destination.

Use clean, single-hop 301s to the best replacement URL and avoid chains.

Redirects cost crawl capacity, and Google’s crawl budget guidance warns that long redirect chains negatively affect crawling. Googlebot follows a maximum of 10 hops before reporting a redirect error. Keep redirects to the ones you need, one hop where possible, and retire chains after launches.

How to fix a redirect chain: Update the first redirect to point it straight at the final URL. Next, update internal links, canonical tags, and XML sitemaps to use the final URL directly. This should mean most users and crawlers won’t hit a redirect.

302 – Found – This code acts the same as a 301 redirect, but is used to tell search engine crawlers that the redirect is only temporary.

Temporary redirects aren’t used as consistently as permanent redirects these days, but due to how easy it is to implement 302 redirects, many site owners use the incorrect redirect code.

Because of this, search engines (Google in particular) have become smarter at recognising which redirect code is most suitable for the given scenario.

Google may sometimes treat a long-lived 302 like a permanent move, but don’t rely on it to rewrite your meaning. Pick the code that matches your intent – 301 or 308 for permanent moves, 302 or 307 for temporary ones.

How to choose: If the old URL won’t return, use a 301 (or a 308 when the request method must be kept, such as a form POST). If it will return (possibly due to a short promotion, planned maintenance, or a product that’s coming back into stock), use a 302 (or a 307 to keep the method).

A quick test: Do you want the new URL to appear in search results? If yes, it’s permanent. Ensure every redirect points straight at the final destination, not at another redirect.

303 – See Other – A 303 response informs users and bots that the requested page can be found at another location and that a GET method is required to reach the destination URL.

304 – Not Modified – This response means the resource/page has not been modified since the user/bot’s last visit meaning the page doesn’t need to be requested from the server and can be retrieved from the user’s cache. According to Google’s crawler documentation, its crawlers support HTTP caching, so returning accurate 304s for unchanged pages can save crawl resources on large sites.

307 – Temporary Redirect – This status code works like a 302, with one difference: the client must repeat the request with the same HTTP method. It suits temporary, method-sensitive redirects. For sitewide HTTP to HTTPS moves, use a permanent redirect (301 or 308) instead.

308 – Permanent Redirect – The permanent counterpart to 307. Google treats it like a 301, as a strong signal that the target should be canonical. However, the client must keep the original request method, which matters for forms and APIs.

4XX client error codes

400 – Bad Request – The server was not able to understand and complete the request from the client. 

401 – Unauthorized – This status code is used for pages that require a username and password to be entered before the destination page can be accessed.  

403 – Forbidden – You guessed it, the page is forbidden, and can’t be accessed by users or search engine bots.

If pages you want indexed return a 403 to Googlebot, review your bot protection or firewall. Over-zealous rules can block crawlers while the page loads normally in a browser, so check the response with the URL Inspection tool to see if this is an issue.

404 – Not Found – The most common 4XX response code. This code informs users and bots that the server can’t find the page that is being requested.

Broken internal links and soft 404s hurt discovery and user experience. First, fix internal links at the source; don’t just redirect around them.

If a relevant replacement exists, 301 redirect to it. When the content has intentionally gone, use a 404 or 410 – don’t redirect everything to the homepage by default. If the page isn’t linked to, then no action is required as it will eventually fall out of the search engine’s index. 

Read our 404 handling guide for more information and advice about handling these well.

410 – Gone – The page that is being requested is no longer available at the location requested.

A 410 tells search engine bots and users that a page has been intentionally removed and won’t come back.

They should be used for URLs that are no longer relevant to the website (for example, products which the website no longer offers). URLs which return a 410 code but have a new URL location should be appropriately redirected.

404 or 410? For Google, the difference is small. Its status code documentation says all 4xx errors (except 429) are handled the same way, and previously indexed URLs that return them are removed from the index. 

  • Use 410 when you want to state clearly that removal is deliberate, such as a discontinued product range
  • Use 404 for everything else.

429 – Too Many Requests – The client has sent too many requests in a given time. 

Google treats a 429 as a sign the server is overloaded and slows its crawling. Rate limits set too tightly on a CDN or bot-protection layer can throttle Googlebot.

To fix it, review the rate-limit rules on your CDN or web application firewall. Allow verified Googlebot traffic instead of raising limits for everyone. Google publishes its crawler IP ranges, so you can verify requests before allowing them.

5XX server error codes

500 – Internal Server Error – This code means the server has encountered an issue and doesn’t know what action to take as a result. 

A 500 code is used when the server can’t find a more suitable 5XX code to use and can sometimes be difficult to identify the cause.

Once you identify the problem causing the 500 code, we recommend you store a log of the issue for future reference so it can be resolved faster if it happens again.

Server errors also change how Google crawls. Google slows its crawl rate in proportion to the number of URLs returning 5xx errors. Indexed URLs are kept for a time, but persistent errors may see them dropped from the index.

501 – Not Implemented – The request sent to the server cannot be handled as the method used can’t be understood or supported.

501 means the server doesn’t support the functionality the request needs, usually an HTTP method it doesn’t implement. The HTTP specification (RFC 9110) requires every general-purpose server to support GET and HEAD; other methods, such as POST and PUT, are optional and widely supported. 

Return 501 only when a method genuinely isn’t implemented. If the server knows the method but doesn’t allow it for that URL, the correct response is 405 (Method Not Allowed).

502 – Bad Gateway – This response code means the server (which acts as a gateway to gather the resource) received an invalid response while trying to complete the request. Common causes include the upstream server crashing or restarting mid-request, or returning a malformed response. If the upstream server is too slow, you’ll usually see a 504.

503 – Service Unavailable – Server isn’t able to handle the request. This is commonly caused by maintenance or an overloaded server. For planned maintenance, return a 503 with a Retry-After header so crawlers know the outage is temporary.

Unplanned 503s usually mean the server has run out of capacity. Check for:

  • Traffic spikes or bot surges
  • A load balancer pulling servers out of rotation after failed health checks
  • Deployments with too few instances running
  • Maintenance mode left switched on after an update.

Watch your robots.txt as, according to Google’s robots.txt documentation, if robots.txt returns a 5xx error, Google stops crawling the whole site for the first 12 hours. For up to 30 days, it falls back to the last cached copy. A misconfigured 503 on that one file can pause crawling of every URL you have.

504 – Gateway Timeout – A 504 response code appears when a server acting as a gateway or proxy doesn’t get a timely response from the upstream server it needs to complete the request.

This code implies that your web servers aren’t communicating successfully; you can try to resolve this code by identifying the cause of the communication issue. Identify the layer that generated the 504: a CDN, load balancer, or reverse proxy. The error page usually shows which.

Then work through the likely causes: 

  • How long the origin takes to respond to that URL
  • Slow database queries or third-party API calls holding it up
  • A proxy timeout set shorter than your slowest legitimate response
  • Recent DNS changes
  • Firewall rules blocking the proxy from the origin.

Your log files will show which requests are timing out.

505 – HTTP version not supported – The server will not support the HTTP protocol version used in the request and will therefore not complete the request.

With a 505 response, you should receive a message indicating why the server has rejected the HTTP protocol used.

H3: Other common status codes used

201 – Created – This code indicates that the request has been completed and a new resource has been produced. 

202 – Accepted – The request has been accepted and will be processed by the server.

305 – Use Proxy – Now deprecated in the HTTP specification. It originally meant the requested page needs to be accessed through the proxy that is included in the ‘location’ header.

408 – Request Timeout – The server wasn’t able to complete the request due to how long the request was taking. 

521 – Web server is down – This is a Cloudflare-specific status code that occurs when the web server refuses a connection to Cloudflare.

524 – A timeout occurred – Another Cloudflare-specific code. Cloudflare connected to your origin server, but it didn’t send an HTTP response in time (100 seconds by default). Treat it like a 504 and look for slow requests at the origin.

HTTP status codes: FAQs

What’s the difference between a 301 and a 302 redirect?

A 301 and 302 redirect differ based on the page’s status:

  • A 301 redirect says a page has moved permanently. Google treats it as a strong signal to show the new URL in search results. 
  • A 302 says the move is temporary and the page will return. Google is more likely to keep showing the original URL. 

Choose based on intent. If the old URL won’t return, use a 301 redirect.

Should I use a 404 or a 410 for a removed page?

Either a 404 or 410 works for Google, which handles all 4xx errors the same way, except 429. Use 410 when you want to say clearly that removal is deliberate, such as a discontinued product range. If a relevant replacement page exists, a 301 redirect to it is better.

Do 5xx errors affect SEO?

Yes, when Googlebot encounters 5xx errors, it slows its crawl rate in proportion to how many URLs are failing. Indexed URLs stay indexed for a time, but persistent errors can cause them to be dropped. For planned maintenance, return a 503 with a Retry-After header.

What causes a 504 gateway timeout?

A 504 gateway timeout happens when a server acting as a gateway or proxy, like a CDN or load balancer, doesn’t get a response from the upstream server in time. Common causes include slow database queries, overloaded origin servers, slow third-party API calls, and overly short proxy timeouts.

Is a 503 service unavailable error bad for SEO?

Not if it’s short. A 503 tells Google the outage is temporary, so it slows crawling and keeps your pages indexed for a time. Problems start when 503s last for days, or when robots.txt returns one, which pauses crawling of the whole site. Add a Retry-After header for planned maintenance.

Keep your status codes healthy

Status codes rarely break all at once, but they can drift. For example, a campaign redirect never comes down, a product range is removed without a plan, or a CDN rule starts throttling bots. Regular site crawls, checked against the Crawl stats and Page indexing reports in Google Search Console and your server logs, surface most HTTP status code issues before they cost you traffic.

If you’re planning a relaunch or a domain move, build redirect mapping in from the start. Talk to our team about getting it right the first time.