HTTP Status Codes and SEO Impact

HTTP Status Codes and SEO Impact

HTTP status codes shape how search engines crawl and index your pages. Googlebot and other crawlers use the status code to decide whether to index the URL, follow its redirect, transfer link equity, or remove the URL from the index. Returning the wrong code creates lasting problems: a page served with 200 that should be 301 dilutes link equity across two URLs; a 404 on a page that should be 200 removes it from the index; a 302 used where a 301 is needed prevents link equity from transferring. Consequently, the status code is an SEO signal as much as it is an HTTP protocol detail.¹ This guide covers the codes that matter most for crawlability and indexing, grounded in RFC 9110² and published search engine guidance.

How search engines interpret each status class

Search engine crawlers assign distinct meaning to each status class. A 200 OK tells the crawler to index the page content. A 301 or 308 permanent redirect tells the crawler to update its index to point to the new URL and transfer link equity to it. A 302 or 307 temporary redirect tells the crawler to continue indexing the original URL and not transfer equity.³

Handling removal and maintenance

A 404 Not Found tells the crawler the page is gone, but search engines do not immediately deindex it: they return to verify the 404 over several crawl cycles before removing the URL. A 410 Gone explicitly signals permanent removal, though Google's current documentation states that it treats 410s and 404s identically for deindexing purposes.⁴ A 503 Service Unavailable with a Retry-After header tells the crawler to come back later and does not trigger deindexing, making it the correct code for planned maintenance.

Returning 200 for a maintenance page (a "soft 404") confuses crawlers into indexing the maintenance message itself.⁵ Once the holding page replaces the real content in the index, recovering the original ranking takes multiple crawl cycles even after the correct 200 response resumes, which is why soft 404s are one of the most common silent ranking killers in technical SEO audits.

Redirect chains and link equity

Link equity passes through redirects but is diluted with each hop, and the dilution compounds multiplicatively rather than additively as the chain grows longer. A direct 301 from URL A to URL B passes nearly all equity. A chain of 301s from A to B to C passes a reduced amount. Redirect chains that accumulate during site restructuring quietly degrade search rankings over time without obvious symptoms, which is why they often go undetected until a significant drop in organic traffic forces a retrospective audit.

Why chains form during site migrations

Redirect chains rarely form from a single deliberate decision. They typically emerge when multiple teams handle different parts of a migration independently: the CMS team redirects old URLs to intermediate landing pages, the SEO team then redirects those landing pages to the final URLs, and a plugin or CDN rule adds its own redirect on top without either team realising the other had already configured one. Each hop is configured with good intentions, but the cumulative effect is a chain that wastes crawl budget and dilutes link equity across three or more URLs that should have had a single clean mapping. Coordinating redirect configuration in a single routing table or redirect map prevents these accidental chains from forming in the first place.

Google's crawl budget documentation explicitly warns to "Avoid long redirect chains, which have a negative effect on crawling."⁶ The fix is to flatten chains: each URL in the chain should redirect directly to the final destination. Mixed redirect types in a chain create additional problems: a 301 followed by a 302 leaves Google unsure whether the final destination is permanent or temporary, often resulting in the original URL staying in the index. Auditing redirect chains after every site migration prevents this compounding technical SEO debt from silently degrading organic traffic over the following quarters.

301 redirect link equity is what you preserve when each URL in the chain redirects directly to the final destination instead of through intermediate hops. Audit redirect chains during site migrations and after URL restructuring projects, using a crawler tool to map the full chain from source to final destination for every redirected URL. This audit should also capture redirect types at each hop, because a chain that mixes 301 and 302 sends mixed signals to Google about whether the final destination is permanent, often resulting in the original URL remaining indexed indefinitely.

Using 503 during maintenance

Returning 503 Service Unavailable with a Retry-After header during planned maintenance is the correct SEO-safe approach. Search engines interpret 503 as a temporary condition and do not deindex the URL: they return after the Retry-After interval and index the real content. This makes 503 the only status code that protects your existing rankings while you perform scheduled work on the server, the database, or the application layer.

Returning 200 for a maintenance page causes the crawler to index the maintenance message itself, replacing the real page content in the index with a holding page.⁵ Returning 404 during maintenance causes the URL to begin the deindexing process and risks losing ranking if the maintenance window runs longer than expected. The safest pattern is to combine 503 with a Retry-After header set to a conservative estimate of the maintenance duration, so crawlers return at the right time without repeatedly hitting a still-down service.

Set the Retry-After header to the expected maintenance end time so crawlers know precisely when to return. Add Cache-Control: no-store to the 503 maintenance response to prevent CDNs from serving the maintenance page after the site recovers. Omitting Cache-Control: no-store is a common oversight that causes a recovered site to continue serving the maintenance page to some visitors until the CDN cache expires, creating a confusing mix of 200 and 503 responses that signals to search engines that the site is still unstable.

Canonical tags and status codes: handling duplicate content

Canonical tags and redirect status codes solve the same problem through different mechanisms. A canonical tag (<link rel="canonical">) tells search engines which version of a URL is the authoritative one, consolidating signals from multiple URLs to a single canonical.⁷ A 301 redirect physically moves traffic from the old URL to the new one. Choosing between them depends on whether you want the non-canonical URL to remain accessible.

Use canonical tags when the non-canonical URL must remain accessible (filtered search result pages, parameter-based sorting variants, pagination pages). Use 301 redirects when the non-canonical URL should no longer exist and all traffic should move to the canonical. Returning 200 with a canonical tag for the same content as the canonical URL is the correct pattern for faceted navigation: the filtered URLs are accessible, linked from your UI, and signal their canonical to search engines without being removed.

When canonical tags and 301 redirects conflict

A URL that both has a canonical tag pointing to another page and a 301 redirect to a third URL creates a conflicting signal. Search engines resolve this by following the 301 and processing the canonical tag on the redirect destination, which may not be the URL you intended as authoritative. Audit your canonical tag and redirect configurations together, not separately: a canonical on a URL that is also redirected usually indicates a configuration error from a previous site restructuring project.

When to use this

Use this guide when auditing a site's HTTP responses for crawlability, planning a site migration, or diagnosing unexpected changes in search rankings after a deployment or URL restructuring.

Examples