HTTP Status Codes for SEO

Short definition

An HTTP status code is a three-digit response sent by a server after a client requests a resource. A browser, crawler, monitoring service, or API sees that response before it can do anything useful with the body.

For SEO, the code answers an immediate question: did the crawler receive content, reach a new location, request something that is not available, or encounter a server problem? It does not answer every indexing question. A page can return 200 OK and still be non-indexable, duplicated, empty, or unsuitable for a search result.

The five response classes

HTTP divides status codes into five classes:

The class is only the starting point. 404 and 429 both begin with 4, yet Google handles them very differently. The exact code and the reason behind it matter.

2xx: a successful request is not an indexing promise

200 OK is the normal response for a working HTML page. It allows Google to pass the received content to its indexing systems. Google explicitly says that a 2xx response does not guarantee indexing.

A technically successful page can still have a problem:

• it contains an error message or almost no main content;
• it carries a `noindex` directive;
• its canonical points to another URL;
• essential content failed to render;
• it serves the wrong language, market, or user state;
• the URL is a duplicate and another version is selected as canonical.

204 No Content is also successful at the protocol level, but there is no content for a search engine to process. It is useful for some APIs and actions, not for a normal landing page that should appear in search.

304 Not Modified belongs to the 3xx class but is not a redirect. It tells a conditional client that the stored representation is still current. Google's indexing systems keep the version they already have and may recalculate signals for the URL; otherwise the code has no effect on indexing. It also saves transfer and server work.

3xx: say whether the move is permanent

Redirects are appropriate when a resource has moved, several URL variants should converge on one address, or content has been consolidated into a genuine replacement.

The most relevant server-side redirects are:

• 301 Moved Permanently and 308 Permanent Redirect for a move that should not be reversed;
• 302 Found and 307 Temporary Redirect for a temporary change;
• 303 See Other for specific request flows where the client should retrieve another resource.

Google follows the common redirects. It treats 301 and 308 as a strong signal that the target should become canonical, and 302 and 307 as a weak one. With a temporary redirect, the source URL may therefore remain the URL shown in search.

For ordinary GET requests, the visible result of 301 and 308 often looks identical. At protocol level, 307 and 308 preserve the request method and body, whereas older clients may change the method after 301 or 302. That distinction matters for forms and APIs even when it rarely changes a content migration.

A redirect becomes an SEO problem when it:

• points to an unrelated destination;
• ends at another redirect, an error, or a blocked page;
• creates a loop;
• leaves internal links and sitemaps on the old URL;
• is marked temporary even though the move is permanent;
• sends many removed pages to a generic homepage that does not satisfy their intent.

By default, Google's crawlers follow up to 10 redirect hops. That is a ceiling, not a design target. A direct redirect is easier for users, crawlers, analytics, and future maintenance. For protocol and host moves, HTTP and HTTPS basics for SEO shows how to collapse every variant onto one secure address.

4xx: missing, unauthorized, or forbidden

An ordinary 4xx response tells Google that the response body should not be used as page content. Previously indexed URLs that keep returning a 4xx response are removed over time. Google treats the common 4xx codes alike for this purpose, with one important exception: 429 Too Many Requests is handled as a server-overload signal.

Common cases include:

• 400 Bad Request: the server considers the request malformed;
• 401 Unauthorized: valid authentication is missing;
• 403 Forbidden: the server understood the request but refuses access;
• 404 Not Found: no current resource was found at this URL;
• 410 Gone: the resource is known to have been removed permanently.

A public page returning 401 or 403 deserves investigation. Authentication, a firewall, bot protection, a CDN rule, geo restrictions, or an origin configuration may be blocking crawlers unintentionally. These codes should not be used to control Google's crawl rate.

404 and 410 are not automatically mistakes

If content is gone and there is no close replacement, 404 or 410 is an honest response. You do not improve a site by redirecting every old address to the homepage.

A missing URL becomes actionable when the surrounding system still treats it as live. Look for:

• internal links to the missing URL;
• inclusion in an XML sitemap;
• meaningful external links or continuing visits;
• a product, article, or category that should still exist;
• a relevant replacement that serves essentially the same need.

The decision may be to restore the page, correct the link, remove the sitemap entry, or redirect to a close successor. The status code alone cannot choose among those options.

Google's documentation does not promise a ranking advantage for choosing 410 over 404. Both communicate that content is unavailable. Choose 410 when the permanent removal is known and intentional, not as a trick to force faster results.

Soft 404: when the code and the page disagree

A soft 404 is not an HTTP status code. It is Google's diagnosis of a URL that returns a successful response but looks like an error page, an empty page, or a page with no meaningful main content.

Typical examples are:

• a deleted product showing "Product not found" with 200 OK;
• an empty internal search page that looks like a missing result;
• a client-side router displaying a 404 view while the server still returns 200;
• a broken render that leaves only navigation and an error message.

If the resource is genuinely gone, return 404 or 410. If it moved, use a permanent redirect to a close replacement. If the content still exists, debug what Googlebot actually received and rendered. Search Console's URL Inspection and Page Indexing reports can help with that distinction.

429 and 5xx: temporary overload and server failure

429 Too Many Requests says that the client has exceeded a rate limit. Google treats it like a server error, not like an ordinary missing-page response.

The main 5xx responses are:

• 500 Internal Server Error: an unspecified application or server failure;
• 502 Bad Gateway: a gateway or proxy received an invalid upstream response;
• 503 Service Unavailable: the service is temporarily unavailable or overloaded;
• 504 Gateway Timeout: a gateway did not receive an upstream response in time.

Repeated 5xx and 429 responses prompt Google's crawlers to slow down. Indexed URLs can initially remain in the index, but persistent failures may eventually cause them to be dropped. Once stable successful responses return, crawl activity rises gradually rather than instantly.

For short planned maintenance or genuine overload, 503 is more truthful than returning a branded error page with 200. HTTP also allows a Retry-After header with 503 to tell compatible clients when to try again. Keep the outage brief and test the whole delivery path, including CDN, proxy, application, database, and origin.

For emergencies in which Googlebot overwhelms a server, Google's crawl-rate guidance allows temporary 500, 503, or 429 responses instead of 200. It also advises against keeping this up for longer than one or two days, because URLs that return these codes for several days may be dropped from the index. That is an emergency brake, not a standing crawl-management technique.

How to audit status codes without fixing the wrong thing

A useful audit groups evidence by cause, template, and business relevance. Start with these questions:

1. Which indexable, internally linked URLs end in 4xx or 5xx?
2. Which sitemap URLs redirect or fail?
3. Which internal links still point through redirects?
4. Which redirect chains end at an irrelevant, non-indexable, or broken target?
5. Which successful pages look empty or display an error state?
6. Are failures isolated, tied to one template, or spread across the host?
7. Do server logs show that search crawlers encountered the same response?
8. Which URLs still receive visits, impressions, or valuable external links?

Then assign an intentional outcome to each group:

The objective is not to turn every URL green. It is to make the server response match the decision the site has actually made about that resource.

What Crawl Foundry can verify

Crawl Foundry's Site Audit crawls the site with its own crawler and records the status code and redirects for every crawled URL. Redirect chains that pass through several hops appear as their own issue, together with the affected URLs. The same crawl keeps canonical and robots directives, indexability, and internal links, each link with its source, target, anchor text, and position. Comparing two runs shows whether a fix actually changed the responses.

That turns a generic "we found errors" list into affected URLs and reproducible evidence. It does not prove how Googlebot behaved historically, read your private server logs, or replace Search Console. It also does not decide whether a missing page deserves restoration, removal, or a redirect. Those decisions still need content context and editorial ownership.

FAQ

Which HTTP status codes matter most for SEO?

The codes you encounter most often are 200, 301, 302, 404, 410, 429, 500, 502, 503, and 504. Add 401 and 403 when public content is unexpectedly protected. The important question is whether the response matches the URL's intended state.

Is every 404 bad for SEO?

No. A real 404 is correct for a missing resource with no close replacement. Broken internal links, stale sitemap entries, valuable backlinks, and accidentally removed pages are the problems to investigate.

Is a soft 404 worse than a real 404?

It is a different failure. A real 404 communicates the missing state clearly. A soft 404 sends a successful status while showing missing or empty content, so the technical response and the page disagree. Either can be costly if an important page was removed by mistake.

Should a permanent redirect use 301 or 308?

Both are permanent signals for Google. Use the code your stack supports correctly. Choose 308 when preserving the original request method and body is important. For ordinary page migrations, a correctly implemented 301 remains common and appropriate.

Can Crawl Foundry detect every status-code problem?

No crawler sees every layer. Crawl Foundry shows the responses and redirects its own crawl received. Intermittent failures, user-agent differences, edge-location issues, and historical Googlebot responses may require repeated tests, monitoring, Search Console, and server logs.

Related terms

• Crawling
• Indexing
• Redirects
• Canonical Tag
• Advanced Technical SEO
• HTTP and HTTPS basics
• Googlebot

Sources and further reading

• Google: How HTTP status codes affect Google's crawlers
• Google Search Central: Redirects and Google Search
• Google Search Central: Troubleshoot crawling errors and soft 404s
• MDN: HTTP response status codes
• RFC 9110: HTTP Semantics

Conclusion

Status codes work when they tell the truth. A live page should return useful content with a successful response. A permanent move should point directly to its successor. A removed page may correctly return 404. A temporary outage should not masquerade as a healthy page.

Good technical SEO therefore does more than count errors. It compares the response with the intended page state, the links that lead there, the content users receive, and the evidence search engines expose. That is how a status-code report becomes a repair plan instead of another dashboard.