---
title: "HTTP Status Codes Explained for SEO and Web Performance"
description: "A practical guide to 2xx, 3xx, 4xx, and 5xx responses: how status codes affect crawling, indexing, redirects, caching, and web performance."
canonical_url: https://optimi.com/en/guides/http-status-codes-seo
md_url: https://optimi.com/en/guides/http-status-codes-seo.md
last_updated: 2026-07-14
---

# HTTP Status Codes Explained for SEO and Web Performance

The response code is part of your content. Choose it deliberately, verify it at the edge and origin, and make failures visible before crawlers or customers find them.

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.

**Choose the response code by URL intent**

![Decision flow showing an existing page returning 200, a permanently moved page returning 301 or 308, removed content returning 404 or 410, and a temporary outage returning 503.](/diagrams/http-status-codes-seo/response-by-url-intent.svg)

*The right response code communicates whether content can be processed, has moved, is gone, or should be retried later.*

## 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 status code is not an SEO score**
>
> A correct `200` makes content eligible for processing; it does not make the content useful, fast, or guaranteed to rank. Status codes are part of technical reliability, not a shortcut around relevance and quality.

## 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:

```text
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](/en/visibility/technical-seo-geo) connects response reliability with crawl behaviour and log analysis. For delivery work, a [managed CDN](/en/performance/cdn) can make edge and origin responses easier to compare, while [Multi CDN](/en/performance/multicdn) 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](/en/guides/cdn-migration) before changing the layer that generates or caches your responses, and use the [web performance budget guide](/en/guides/web-performance-budgets) to connect response time with measurable delivery limits.

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

[Contact Optimi](/en/contact): Make every response intentional — Talk to our team about status-code audits, crawl visibility, and resilient edge delivery.