HTTP Status Codes Explained for SEO and Web Performance

The short answer is simple: return 200 for a page that exists, a permanent redirect for a page that has moved permanently, 404 or 410 for content that is gone, and temporary server errors only when the failure is genuinely temporary. Do not return 200 for an error page, and do not use redirects to hide an outage.

That distinction matters to both search engines and people. Google says a 2xx response can be considered for indexing, but does not guarantee indexing. It ignores content returned with a 4xx or 5xx response, and persistent server errors can eventually remove URLs from the index. The same response also determines whether a browser, CDN, crawler, or monitoring system treats the request as successful, cacheable, retryable, or broken.

What each status class means

HTTP groups response codes by their first digit. The class is useful, but the exact code carries the operational meaning.

• 2xx success: The request succeeded. 200 OK is the normal response for an indexable HTML page. 204 No Content is appropriate for an endpoint that intentionally returns no body, not for a page that failed to render. A page that displays "not found" while returning 200 is a soft 404 and can be excluded from Search.
• 3xx redirection: The requested resource is somewhere else or the client can reuse its cached representation. 301 and 308 communicate a permanent move. 302 and 307 communicate a temporary move. Google treats the permanent forms as stronger canonicalization signals, while the temporary forms generally preserve the source URL.
• 4xx client error: The server cannot serve the requested resource as requested. 404 Not Found is the normal answer for an unknown URL. 410 Gone is useful when content has been deliberately and permanently removed. 401 and 403 describe access control, not a recommended way to slow crawlers. 429 Too Many Requests is special: Google treats it like a server error because it can indicate overload.
• 5xx server error: The server or a gateway could not complete an otherwise valid request. 500 is a generic application failure, 502 usually indicates a bad upstream response, 503 indicates temporary unavailability, and 504 indicates an upstream timeout.

A practical audit sequence

1. Inventory URLs by intent

Start with a representative URL list: important landing pages, templates, product and category pages, APIs, assets, feeds, robots.txt, and XML sitemaps. Include URLs from server logs, Search Console, analytics, internal links, and the CDN. A status dashboard that only checks the home page will miss failures in a localized path, an API route, or a cache variant.

For each URL, record the response from the public edge and, where possible, the origin. Compare status, final URL, response time, content type, cache status, Location, Cache-Control, canonical, and robots directives. A CDN can return a different code or body than the origin, so test both layers when investigating.

2. Classify every non-200 response

For a moved page, map the old URL directly to the closest equivalent destination with one server-side 301 or 308. Avoid chains such as old URL to an intermediate URL to the final URL. Update internal links, canonical URLs, and sitemaps to point directly to the destination.

For a deleted page, use 404 or 410 when no relevant replacement exists. Do not redirect every deleted URL to the home page: that creates a poor user experience and can be interpreted as a soft 404. A useful custom error page is fine, but the HTTP response must still be an error.

For an outage, return an appropriate temporary server error and recover quickly. A 503 can include Retry-After when a useful retry estimate is known. Ensure that an error body is not accidentally cached for a long time at the browser or CDN.

3. Check the response path, not only application code

Test from several networks and regions with a request that follows redirects and one that does not. Confirm that HTTPS, host normalization, trailing-slash rules, language routing, authentication, and origin failover all produce the intended result. Check HEAD only as a supplement: many real visitors and crawlers use GET, and a server can mishandle the two methods differently.

The following generic check makes redirect hops visible:

request https://www.example.test/old-page
inspect status, Location, cache headers, and final URL
repeat from a second region and with a crawler user agent

For SEO-specific work, Technical SEO/GEO connects response reliability with crawl behaviour and log analysis. For delivery work, a managed CDN can make edge and origin responses easier to compare, while Multi CDN adds another failure path that must be observed independently.

4. Monitor rates and transitions

Track status counts by hostname, path pattern, method, region, user agent, cache status, and release version. Alert on changes in the rate of 5xx, 429, redirect loops, redirect chains, soft 404s, and unexpected 200 responses from known error routes. Pair the rate with latency and origin saturation: a rising 504 rate may be a timeout problem, while a rising 502 rate may be an upstream protocol or connection problem.

Keep an error budget for search visibility as well as availability. Inspect crawl logs and Search Console after routing or application changes. Google recommends using its Crawl Stats and URL Inspection tools to investigate availability and rendering issues, and notes that crawling can recover gradually after the site is healthy again.

5. Define rollback before changing codes

Deploy status-code changes behind a reversible configuration or release. Keep the previous routing rules, application version, and cache policy available. If a new redirect map increases errors, restore the last known-good map and purge only the affected responses. If a new error handler causes a spike in 5xx, route to the previous application version. Do not solve a bad deployment by returning 200 for every request; that hides the incident and creates indexing noise.

Common mistakes

• Returning 200 with an error template, empty search result, or failed API payload.
• Using 302 for a permanent URL migration, or 301 for a temporary maintenance page.
• Leaving multiple redirect hops in place after a site or host change.
• Treating 403 or 401 as a crawl-rate control. Google documents 429, and temporarily 503, for overload situations instead.
• Caching a 404 or 503 response for longer than the recovery plan allows.
• Checking only the origin while the CDN serves an old body, different status, or stale error.
• Forgetting that a 2xx response is only an eligibility signal. Indexing still depends on the returned content and other search systems.

Read the CDN migration guide before changing the layer that generates or caches your responses, and use the web performance budget guide to connect response time with measurable delivery limits.

There are only two hard things in Computer Science: cache invalidation and naming things.