HTTP Status Codes for SEO: 200, 301, 404 and 503

When a URL disappears, engineers often ask the SEO team, “Which status should this page return?” The answer does not live in a memorized table alone. It depends on whether an equivalent resource exists, whether the interruption is temporary or permanent, and what you need a crawler to do on its next visit.

The wrong status can create error pages that still return 200, long redirect chains, or thousands of 503 responses that reduce crawling. The right choice lets browsers, search bots, caches, monitoring systems, and maintainers understand the same state.

HTTP status is a message from the server

Whenever a browser or crawler requests a URL, the server responds with a status code. The five main classes are:

• 1xx: information while processing.
• 2xx: the request was handled successfully.
• 3xx: another address or action is required.
• 4xx: the client request cannot be fulfilled as submitted.
• 5xx: the server cannot complete a valid request.

For SEO, the status must agree with the visible content. A page that says “product not found” while returning 200 OK creates a soft 404. A complete page that responds with 500 gives crawlers an error whose body is ignored. Status and body should not tell different stories.

2xx responses: success does not guarantee indexing

200 OK

200 means the server returned a successful response. Google may send the content to subsequent processing, but indexing is not guaranteed. The page may still be excluded because of noindex, a canonical pointing elsewhere, duplication, insufficient value, or other quality signals.

Return 200 only when a URL provides real content. Do not use it to keep every address technically “alive” after a product or article has been removed.

204 No Content

204 says the request succeeded without a response body. It fits some APIs and actions that require no representation, not a landing page intended for search. An empty HTML page cannot provide a useful result simply because its status belongs to the success class.

206 Partial Content

206 is common when a client requests a range from a video or large file. It is not the normal default for an HTML document. If a CDN or proxy unexpectedly returns 206 for every page, inspect range-request and caching rules.

3xx responses: deliberate movement

301 Moved Permanently

Use 301 when an address has moved permanently and an equivalent destination exists. Typical cases include:

• Changing an article slug.
• Moving HTTP to HTTPS.
• Merging articles that serve the same intent.
• Replacing a category structure.
• Sending an old product to a genuinely equivalent successor.

The destination must match the old need. Redirecting a discontinued product to the homepage or an overly broad category frustrates visitors and may be treated like a soft 404.

302 Found

302 suits a temporary move: a short experiment, an alternate page during maintenance, limited-time routing, or a campaign that will return to the original URL. If the move has become permanent, change the response to 301 so its purpose is unambiguous to every client.

Google can process several redirect types similarly after considering broader signals. Selecting the correct status still matters to browsers, caches, other clients, and future maintainers.

303 See Other

303 often follows a POST request and sends the client to a result page using GET. A submitted form leading to a confirmation page is a common example. This is an application flow rather than the primary tool for an SEO URL migration.

307 and 308

307 Temporary Redirect and 308 Permanent Redirect preserve the HTTP method during the move. 308 is permanent and 307 is temporary. They can serve ordinary GET migrations, but engineers should understand method preservation before applying them to forms and APIs.

Redirect chains: one decision stretched across old URL generations

An article began at A, moved to B, and later moved to C. When A still redirects to B and B redirects to C, every visit needs two hops. An established site can collect chains of five or six steps that nobody designed deliberately.

The costs include:

• More latency for visitors and crawlers.
• Extra server requests.
• Harder canonical and analytics debugging.
• Greater risk of a failed hop or loop.
• Internal links that preserve an obsolete architecture.

Each old address should point directly to the current destination. Use the Redirect Chain Checker to inspect every hop, status, loop, and final URL. Then update internal links, canonicals, and sitemaps to use the final address instead of relying indefinitely on redirects.

4xx responses: address or access problems

400 Bad Request

The server cannot understand the request because of invalid syntax, headers, or parameters. If Googlebot receives 400 on a clean URL that works in a normal browser, investigate WAF policies, header limits, query-string handling, and user-agent rules.

401 Unauthorized

401 requests authentication. It is correct for signed-in areas, private APIs, and permissioned documents. Content meant to rank cannot also require a crawler to sign in. Do not use 401 as crawl-rate control; resolve server capacity and URL architecture directly.

403 Forbidden

403 says the server understood but refused the request. Overly aggressive CDN, WAF, and anti-bot settings can mistakenly return it to valid crawlers. If public pages begin leaving the index, compare logs by time, user agent, and verified IP instead of trusting a user-agent string by itself.

404 Not Found

404 is correct when a resource does not exist and has no equivalent replacement. Not every 404 is an “SEO error” that needs a redirect. A mistyped address, retired product, or removed test article may return 404 normally.

A useful 404 page should:

• Explain briefly that the resource is unavailable.
• Retain navigation and search where appropriate.
• Suggest related areas without forcing a redirect.
• Continue to return status 404, not 200.

410 Gone

410 explicitly states that the resource was deliberately removed. For Google Search, persistent 404 and 410 responses both result in the URL being removed or not indexed. Choose 410 when the application knows the resource has ended and 404 when it is simply absent. There is little value in changing thousands of valid 404 responses to 410 merely in hope of faster removal.

429 Too Many Requests

429 indicates that a client has made too many requests. Google treats it as a server-overload signal and may temporarily reduce crawling. If a rate limiter frequently returns 429 to crawlers, review quotas, caches, and verification rules. Removing every limit is not the answer; reliable capacity is.

5xx responses: the server is failing

500 Internal Server Error

500 represents an unspecified application or server failure. Occasional transient errors happen, but a high rate across many URLs points to a deployment, database, dependency, or capacity problem.

502 Bad Gateway

502 often appears when a proxy or CDN receives an invalid response from an upstream service. Check application-server health, timeouts between layers, internal DNS, and connection limits.

503 Service Unavailable

503 is appropriate for short maintenance or temporary overload. A Retry-After header can tell clients when to try again. A maintenance page should return 503, not 200; otherwise search systems may encounter the same “under maintenance” content across the site as if it were valid.

Do not leave 503 in place for days when the site has actually closed or the resource is permanently gone. Persistent server errors can eventually remove indexed URLs and reduce crawl activity across the site.

504 Gateway Timeout

504 means a gateway waited too long for its upstream. Look for slow database queries, dependent APIs, cache misses, exhausted workers, and inconsistent timeouts between CDN and origin.

A status decision table

The table is a starting point. In ecommerce, a temporarily out-of-stock product can still return 200 with product information, availability, and alternatives. A permanently retired product with a nearly equivalent successor may use 301; without a meaningful replacement, 404 or 410 is more honest.

Soft 404: successful status, failed content

Soft 404 cases often include:

• An empty product set returning 200.
• Every malformed URL rendering the homepage.
• No-result internal search pages remaining indexable.
• Deleted content leaving only a header and footer.
• Unrelated URLs redirecting to a broad category.

Inspect the Page indexing report in Search Console and sample affected URLs. Do not add a few sentences to an error template merely to avoid classification. Return the honest status or provide content that truly answers the original need.

Robots.txt cannot replace a response status

Disallowing /old-page in robots.txt does not say whether the page moved, disappeared, or requires authentication. A crawler only knows it cannot retrieve the body. A previously known URL may remain in search systems without enough information to evaluate it.

If the URL moved, redirect it. If it disappeared, return 404 or 410. If it remains available but should not be indexed, let crawlers access and read noindex. The Robots.txt Checker catches accidental blocks, but the URL lifecycle still belongs in the response.

Audit statuses by template, not a few polished pages

A homepage returning 200 says little about catalog health. Sample and aggregate by template:

1. Homepage and primary navigation.
2. Categories, pagination, and filters.
3. In-stock, temporarily unavailable, and retired products.
4. New, old, renamed, and deleted articles.
5. Parameter, case, slash, and hostname variants.
6. Sitemaps, robots.txt, key images, and important files.

Compare each status with its canonical, robots directives, sitemap membership, and internal links. A 301 URL should not remain in a sitemap. A 404 should not receive thousands of internal links. A 200 page intended for indexing should not canonicalize elsewhere.

Use the SEO Checker to inspect a representative response and its on-page signals, then run a free SEO audit to find repeated template-level defects.

Monitor before traffic falls

Create alerts for 5xx rate, response time, and status changes on critical URLs. After every deployment or migration, run a smoke test covering:

• Homepage, sign-in, and revenue pages.
• One representative URL from every template.
• Robots.txt and the sitemap index.
• Redirects from old addresses.
• One nonexistent path to confirm a real 404.

Server logs should retain status, path, duration, user agent, and request ID long enough for before-and-after comparisons. When a fault affects only a bot or region, logs usually answer the question faster than refreshing a page from one laptop.

Conclusion

An HTTP status code is a compact contract between server and client. Search systems use that contract to understand whether content exists, moved, disappeared, or is temporarily unavailable. Select the code from the real URL lifecycle, keep it consistent with the body, and clean sitemaps and internal links after every move.

Do not redirect every error to the homepage, return 200 for empty pages, or use robots.txt to conceal an undecided lifecycle. A clear status system leaves less guesswork for visitors, crawlers, and operators.

References: Google Search Central on HTTP status codes and crawling and Google's redirect guidance.