Every URL on the web returns a status code with each request. Googlebot reads those codes literally: 200 means index this, 404 means it’s gone, 301 means it moved, 503 means try again later. The codes are the protocol; misusing them produces consequences that are predictable but often unintentional.
Most developers know 200, 301, 404, and 500 by heart. Fewer have a working model of when 302 vs 301 matters for ranking, what 410 signals beyond 404, why 503 is the right code for planned maintenance, or how soft 404s differ from real ones in Google’s processing. This piece maps the status codes that matter for SEO and what each one signals.
The 2xx success codes:
The 2xx range means the request succeeded. The codes that matter for SEO:
| Code | Meaning | SEO implication |
|---|---|---|
| <strong>200 OK</strong> | Standard success | Page is indexable if other signals allow |
| <strong>201 Created</strong> | Resource created (APIs) | Rare for crawlable pages |
| <strong>204 No Content</strong> | Success with empty body | Treated as thin content; usually not indexed |
| <strong>206 Partial Content</strong> | Range request fulfilled | Used for video/audio streaming, not regular pages |
The only 2xx code that produces problems for SEO is when 200 is returned for pages that should be 404s. These are soft 404s: the URL doesn’t exist, but the server returns “page not found” content with a 200 status. Google has to crawl them to recognize the soft error, which wastes crawl budget.
The 3xx redirect codes:
The 3xx range tells the client to go somewhere else. The differences between codes are meaningful:
| Code | Meaning | When to use |
|---|---|---|
| <strong>301 Moved Permanently</strong> | Permanent redirect, signal transfer expected | URL changes, domain migrations, content consolidation |
| <strong>302 Found</strong> | Temporary redirect, no permanent signal transfer | A/B tests, geo-targeting, short-term changes |
| <strong>303 See Other</strong> | Redirect after POST (form submission) | Form post-redirect-get pattern |
| <strong>307 Temporary Redirect</strong> | Like 302, but preserves HTTP method | API redirects where method matters |
| <strong>308 Permanent Redirect</strong> | Like 301, but preserves HTTP method | Modern equivalent of 301 for non-GET requests |
For SEO purposes, 301 and 308 transfer ranking signals from the old URL to the new one. Google has stated this multiple times through John Mueller and Gary Illyes. The transfer isn’t instant, but the signal is preserved.
302 and 307 don’t transfer ranking signals in the same way. The old URL stays in Google’s index as the canonical version. If a 302 stays in place for months, Google may eventually treat it as a 301, but the official guidance is to use the correct code from the start.
The most common mistake is using 302 for permanent redirects, often because the server framework defaults to 302. The fix is configuration: set the default to 301 for permanent moves.
The 4xx client error codes:
The 4xx range means the request was wrong. The codes that matter for SEO:
| Code | Meaning | SEO implication |
|---|---|---|
| <strong>400 Bad Request</strong> | Malformed request | Rare for crawlable pages |
| <strong>401 Unauthorized</strong> | Authentication required | Page won't be crawled by Googlebot |
| <strong>403 Forbidden</strong> | Server refuses to serve | Page won't be crawled; may indicate misconfiguration |
| <strong>404 Not Found</strong> | URL doesn't exist | Standard "page is gone" signal |
| <strong>410 Gone</strong> | Resource permanently removed | Stronger "gone" signal than 404 |
| <strong>429 Too Many Requests</strong> | Rate limited | Google reduces crawl rate when it sees this |
The 404 vs 410 distinction matters more than most developers assume. Google treats them slightly differently:
- 404 tells Google the URL isn’t there right now. Google may retry the URL for some time, hoping it comes back.
- 410 tells Google the URL is permanently gone. Google removes it from the index faster.
For URLs that are definitively removed (deleted products, old promotions, decommissioned pages), 410 is the cleaner signal. For URLs that may return (temporary outages, content under construction), 404 is correct.
The 429 code is rare but useful. When Googlebot hits 429, it interprets the response as “slow down” and reduces crawl rate accordingly. Sites with crawl rate problems can use 429 strategically, though robots.txt and Search Console settings are usually better.
The 5xx server error codes:
The 5xx range means the server failed. The codes that matter for SEO:
| Code | Meaning | SEO implication |
|---|---|---|
| <strong>500 Internal Server Error</strong> | Generic server failure | Google reduces crawl rate; retries the URL later |
| <strong>502 Bad Gateway</strong> | Upstream server failed | Same as 500 for crawl purposes |
| <strong>503 Service Unavailable</strong> | Server temporarily unable to handle | The right code for planned maintenance |
| <strong>504 Gateway Timeout</strong> | Upstream server timed out | Same as 500 for crawl purposes |
503 is the code to use for planned maintenance. Combined with a Retry-After header that tells Google when to come back, 503 signals “the site is down, but it’s coming back soon.” Google reduces crawl during the outage and resumes normally afterward.
The mistake is returning 200 with maintenance page content during downtime. Google sees the 200 status and treats the maintenance content as the real page content, which can produce ranking drops. 503 prevents this.
For unplanned outages, 5xx codes are accurate but should be temporary. Sustained 5xx errors signal real problems and Google will reduce crawl rate and eventually deindex pages.
Soft 404s and why they’re different:
A soft 404 is a page that returns 200 status but contains content like “page not found” or “no results match your search.” Google detects soft 404s heuristically: empty pages, “not found” text, near-duplicate template content with no real content. When Google identifies a page as a soft 404, it treats the URL as if it returned 404, but only after spending crawl budget to discover the problem.
Common sources of soft 404s:
- Search result pages with zero results returning 200 instead of 404
- Out-of-stock products showing “currently unavailable” pages
- Category pages with no products after filters
- CMS bugs producing empty pages
The fix is making the server return 404 or 410 when the content is genuinely absent. The fix isn’t redesigning the user-facing message; users can still see a friendly “we couldn’t find what you wanted” page, but the HTTP status code below that page should reflect the real situation.
Status codes and indexing decisions:
Google’s indexing pipeline uses status codes as inputs to multiple decisions:
- Discovery: 200 means consider for indexing. 4xx and 5xx mean don’t index, or remove from index if previously indexed.
- Crawl rate: Sustained 5xx reduces crawl rate. 429 reduces crawl rate. 200 with fast response increases it.
- Canonical selection: 301 transfers canonical signals to the target. 302 keeps the original as canonical.
- Index removal: 410 removes faster than 404. Both eventually remove URLs that stay gone.
The codes interact with other signals (robots directives, canonical tags, hreflang, noindex meta tags). A page can return 200 and still be deindexed by noindex; a page can return 301 and still be deindexed if the target also returns problems. Status codes are part of the picture, not the whole picture.
Google’s documentation on these interactions was substantially expanded in 2024 with the “How Google Search treats HTTP status codes” reference page, and Martin Splitt has covered specific edge cases (the 200-with-noindex pattern, the 410-vs-404 timing distinction, the 503-with-Retry-After convention) in Search Off the Record episodes through 2025. The reference material is more comprehensive than it was a few years ago; the operational principles have stayed stable.
Diagnosis workflow:
When a page isn’t ranking, status codes are an early checkpoint. The diagnostic sequence:
- Check the URL with curl or browser dev tools. What status does it actually return?
- Check Search Console’s URL Inspection. What status did Google see most recently?
- Check the Pages report. Is the URL classified as “Crawled but not indexed,” “Discovered but not crawled,” “Soft 404,” “Redirected,” or another status?
- Check logs if available. What sequence of status codes has Googlebot seen on this URL over time?
The combination usually reveals the problem. A URL returning 200 to curl but classified as soft 404 by Google has content quality issues. A URL returning 302 instead of 301 explains why ranking signals haven’t transferred. A URL returning intermittent 503s explains crawl rate problems.
Common status code mistakes:
The patterns that recur in audits:
- 302 for permanent moves. Framework defaults set redirects to 302 when 301 was intended. Ranking signals don’t transfer cleanly.
- 200 for soft errors. Search pages, filter pages, product pages with no inventory all returning 200 with error content.
- 404 for permanently removed URLs. Slower deindexing than 410 would produce.
- Maintenance pages returning 200. Google indexes the maintenance content and may rank it instead of the real page.
- Cached 5xx responses. CDN caches a 5xx error and serves it for hours, extending what should have been a brief outage.
- Redirect chains. URL A 301 to B, B 301 to C, C 301 to D. Each hop loses time and a small amount of signal strength.
Each of these has a single-line fix once identified. The harder part is identifying them, which is why status code analysis belongs in technical SEO audits.
Monitoring status codes in production:
The diagnostic workflow above catches issues during audits, but status code problems often emerge between audits. Continuous monitoring catches them as they happen.
The monitoring infrastructure that works:
- CDN dashboards. Cloudflare, Fastly, and Akamai all show status code distribution in their analytics. Sudden spikes in 4xx or 5xx responses appear in dashboards within minutes of deployment.
- Synthetic monitoring. Tools like Pingdom, UptimeRobot, and Datadog Synthetics check key URLs on a schedule, alerting when status codes change unexpectedly. Configure synthetics for the top 50 pages by traffic and the top 20 by ranking.
- Search Console alerts. Google sends notifications when indexability changes significantly. The Coverage report shows new 4xx and 5xx errors as they appear in crawl data; the response time can be hours rather than minutes, but the alerts are free.
- Log-based alerting. For sites with log aggregation infrastructure, threshold-based alerts catch status code anomalies. A site that normally returns 0.5% 4xx responses suddenly returning 5% indicates a problem worth investigating immediately.
- Deploy-time checks. CI/CD pipelines that test critical URLs before traffic shifts to a new deployment catch status code regressions before they reach users or Googlebot. The cost is a few minutes of additional deployment time; the benefit is preventing ranking-impacting errors from going live.
The discipline: status codes deserve the same monitoring attention as performance metrics. A site that monitors LCP and INP but doesn’t monitor status code distribution misses a category of problems that affects ranking just as directly.
Status codes as protocol, not afterthought:
HTTP status codes are the protocol that connects servers to crawlers. Most of the time they work without anyone thinking about them. When they don’t, the symptoms appear as ranking problems with unclear causes, and the diagnosis comes from going back to the codes.
The teams that handle status codes well treat them as part of the deployment process: every change to URL structure, every content removal, every server configuration update gets a status code check. The teams that don’t handle them well discover the problems months later, when ranking drops force an audit.
The fundamentals are stable: 200 for indexable pages, 301 for permanent redirects, 404 for missing, 410 for permanently gone, 503 for maintenance. The principle is using the code that matches reality, not the code that’s easiest to configure.
Pick the code that tells the truth. The pages whose codes match their actual state get ranked accurately; the pages whose codes lie get ranked badly, slowly, or not at all. Most ranking surprises trace back to one or two URLs returning the wrong code for what they are, and the fix is a single configuration line away once the diagnosis is done.