HTTP Status Codes and SEO: The Complete 1xx–5xx Guide

An HTTP status code is the three-digit number a server returns with every response. For SEO that number matters as much as the text on the page: it is what Google uses to decide whether to index a page, follow a redirect, come back later, or drop the URL from the index altogether.

The most common misconception is that "if the page opens in a browser, everything is fine". A page can look perfect and still be either unindexed or consolidated onto the wrong canonical URL, purely because of the code the server sent first.

What a status code is

When a browser or a search crawler requests a page, the server returns two things: a status code and the content. The code is part of the HTTP protocol (defined in RFC 9110) and reports the fate of the request: success, moved elsewhere, not found, or server failure.

Google's documentation puts it plainly: status codes "are generated by the server that's hosting the site when it responds to a request made by a client, for example a browser or a crawler".

The key idea for SEO: the code is a signal in its own right, independent of the content. Google reads the code first — and if the code says otherwise, it may never consider the content at all.

The five families at a glance

2xx — success

200 OK is what every page you want indexed should return. In Google's words, with this code "Google considers the content for processing".

But note: 200 is necessary, not sufficient. Google may still decline to index a 200 page for reasons of quality, duplication or anything else. The answer to "the page returns 200, so why isn't it indexed?" usually lies in the content, not the code — which connects to semantic SEO and the helpful content criteria.

There is also 204 No Content: a successful response with an empty body. Since there is nothing to index, such pages can in practice be treated as soft 404s.

3xx — redirection

This family is the most misunderstood part of the topic in SEO. Google's documentation states the distinction openly:

• 301 (permanent) and 308 — Google follows the redirect and uses it as a strong signal that the target should be canonical.
• 302 (temporary), 303 and 307 — Google still follows the redirect, but it is only a weak signal for the target being canonical.

So a 302 does not "pass nothing" — the signal is simply weak, and the source URL can keep appearing in results. Using a 302 for a genuinely permanent move is a classic misconfiguration.

Google also sets a limit: by default its crawlers follow up to 10 redirect hops. Longer chains are abandoned.

The full detail of this family — which method to use when, domain migrations, chains and loops — lives in its own article: the difference between 301 and 302 redirects.

This family also contains 304 Not Modified, a caching signal that the cached copy is still current. It has no direct ranking effect but supports efficient crawling on large sites.

4xx — client errors

The page cannot be served because of something on the request side: it is missing, forbidden, or closed to this client.

Two practical conclusions follow.

First: using 401/403 to slow Googlebot down does not work — those codes have no effect on crawl rate, they merely make the content invisible.

Second: a 404 is not a penalty in itself. The risk lies elsewhere — you lose that page's traffic and the links pointing at it, and at scale you waste crawl budget. Details: 404, 410 and soft 404.

5xx — server errors

The request was fine but the server could not fulfil it: 500 (internal error), 502 (bad gateway), 503 (service unavailable), 504 (gateway timeout).

The crucial SEO fact: these do not cause immediate deindexing. According to Google's documentation, 5xx and 429 errors make crawlers temporarily slow down, and the decrease in crawl rate is proportionate to the number of individual URLs returning errors. Once the server starts responding with 2xx again, Google gradually increases the crawl rate.

So a short outage is not a catastrophe. Sustained 5xx errors, however, eventually lead to content being dropped from the index.

For planned maintenance the correct code is 503 — not a broken 200 and not a redirect to a temporary page, because in the first case Google indexes the wrong content and in the second it uses the redirect for indexing.

Crawl versus index: which code affects what

Two separate questions sit behind these codes:

The only thing that breaks this model is a case where the code and the content contradict each other.

Soft 404 — the hidden trap

A soft 404 is a page that returns 200 while its content says "this does not exist": an empty result, a "product not found" message, or a phantom page produced by a misconfigured CMS.

Google detects the problem not at the code layer but at the content layer, and flags it as a soft 404 in Search Console. Google's crawl budget guide for large sites says it directly: "soft 404 pages will continue to be crawled, and waste your budget."

The usual sources: JavaScript-built sites returning 200 for routes that do not exist, empty result pages in filtered catalogues, and deleted products quietly turned into "similar products" pages.

The fix is simple: make the code match reality. If the page does not exist, return 404 (or 410) so Google can drop the URL cleanly.

How to check a status code

In the browser: DevTools → Network tab → reload the page → click the first (document) request → read the Status column.

In the terminal:

# headers only (single request)
curl -I https://example.com/page

# follow the entire redirect chain
curl -IL https://example.com/old-page

# check while presenting as Googlebot
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page

Search Console: the URL Inspection tool reports the status Google saw — the most reliable source, because what your browser sees and what Googlebot sees can differ.

Common mistakes

1. Redirecting every 404 to the home page. This creates irrelevant redirects and is frequently classified as a soft 404. Redirect when a matching page exists; otherwise return 404.

2. Returning 200 during maintenance. If the "site under maintenance" page comes back with a 200, Google indexes that content.

3. Leaving a 302 on a permanent move. The canonical signal stays weak and the old URL keeps showing up in results.

4. Long redirect chains. Chains beyond the 10-hop limit are abandoned, and every hop costs speed.

5. Trying to "manage" crawlers with 403. Crawl rate does not change; the content simply becomes invisible.