HTTP Status Codes

HTTP status codes are three-digit numbers servers send in response to a request. They tell the browser (or crawler) what happened: whether the request succeeded, where to find the resource, or what went wrong. Understanding them is essential for diagnosing crawl and indexing problems.

2xx: Success

The request was received and processed.

200 OK

The standard success response. The page was found and returned correctly. All crawlable, indexable pages should return 200.

204 No Content

The request succeeded but there is no body to return. Rarely relevant for HTML pages; more common in APIs.

3xx: Redirects

The resource has moved. The browser or crawler should follow to the new location.

What separates the redirect types, in Google’s own description of them, is how strongly it reads the redirect as a statement about which URL should be canonical.¹ What does not separate them is PageRank: no 30x redirect loses any. Gary Illyes stated the position in July 2016: “30x redirects don’t lose PageRank anymore.”²

301 Moved Permanently

The resource has moved permanently to a new URL. The correct redirect for site migrations, URL changes, and consolidating duplicate content. Google follows it and “uses the redirect as a strong signal that the redirect target should be canonical”.¹ Use for permanent moves.

302 Found (Temporary Redirect)

The resource has temporarily moved. Google follows it, but uses it as a “weak signal that the redirect target should be canonical”,¹ so the original URL is more likely to stay the indexed one. Use only for genuinely temporary redirects: A/B tests, maintenance pages, geo-based routing. Using 302 when you mean 301 is a common mistake, though the cost is a slower or unresolved canonical decision rather than lost link equity.

307 Temporary Redirect

Preserves the HTTP method (GET stays GET, POST stays POST). Google treats it as “equivalent to 302”.¹

308 Permanent Redirect

Method-preserving equivalent of 301. Google treats it as “equivalent to 301”.¹

Because Google treats 301/308 and 302/307 identically, pick on HTTP semantics rather than SEO. Google’s own advice: “Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.”¹

304 Not Modified

The resource has not changed since the version specified in the request headers. Used for conditional GET requests: the browser or crawler sends an If-Modified-Since or If-None-Match header, and the server returns 304 with no body if the content is unchanged. Crawlers use this to avoid downloading pages that have not changed, improving crawl efficiency. If a server incorrectly returns 304 for a page that has been updated, Googlebot will not pick up the changes. Check cache headers if fresh content is not being indexed.

Redirect chains

A redirect chain is when URL A redirects to B, which redirects to C. “Googlebot follows up to 10 redirect hops. If the crawler doesn’t receive content within 10 hops, Search Console will show a redirect error”, and the limit varies by crawler: “The number of hops Googlebot follows is user agent dependent; for example, Googlebot Smartphone may have a different value than Googlebot Image.”¹

Chains are worth collapsing, but for the right reason. They do not bleed PageRank at each hop.² They cost crawl efficiency, add latency for real users, and risk tipping over the hop limit as chains accumulate over successive migrations. Two or three hops is untidy; a chain long enough to approach ten is a live indexing risk. Audit with Screaming Frog or Ahrefs Site Audit.

Redirect loops

URL A redirects to B, which redirects back to A. Results in a crawl error. Browsers show “too many redirects.” Fix the chain logic.

4xx: Client errors

The request could not be completed because of a problem with the request itself.

For indexing purposes Google draws far fewer distinctions here than the codes themselves suggest: “All 4xx errors, except 429, are treated the same: Googlebot signals the indexing pipeline that the content doesn’t exist. The indexing pipeline removes the URL from the index if it was previously indexed.”¹ The codes still differ for browsers, APIs and other clients, so return the accurate one, but do not expect Google to act differently on them.

400 Bad Request

The server cannot process the request because of a malformed syntax: typically a URL with invalid characters, broken query parameters, or encoding errors. Appears in Google Search Console as a crawl error. Common on sites with faceted navigation or URL parameters that generate invalid combinations. Audit with a crawl tool and fix or noindex the offending URL patterns.

404 Not Found

The requested URL does not exist on this server. Google will eventually drop 404 pages from its index. Links pointing to 404 pages pass no value. Fix broken internal links; redirect externally-linked 404s to the most relevant live page.

410 Gone

The resource has been permanently removed and will not return. It is the semantically accurate code for deliberate removal, and worth using for that reason. It is not, however, a faster route to deindexing: Google’s documentation gives 410 the same treatment text as 404, under the blanket rule that all 4xx except 429 are handled identically.¹ The long-standing practitioner belief that 410 drops pages measurably quicker is not supported by Google’s current documentation.

401 Unauthorised

The request requires authentication. Crawlers cannot access pages behind login walls unless explicitly granted access. Correct for paywalled content you do not want indexed.

403 Forbidden

The server understood the request but refuses to authorise it. Often caused by misconfigured server rules blocking Googlebot. Confirm the right pages are not accidentally blocked.

Neither code is a throttle. Google is explicit: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.”¹

429 Too Many Requests

Rate limiting. The server is throttling requests. This is the one 4xx code Google handles differently: “Googlebot treats the 429 status code as a signal that the server is overloaded, and it’s considered a server error”,¹ so it slows crawling rather than treating the content as missing, and already-indexed URLs survive for a while before being dropped. Googlebot manages its own crawl rate automatically; the manual crawl rate setting in Search Console was removed in January 2024. Persistent 429s to Googlebot point to a server or rate-limiting misconfiguration to investigate.

5xx: Server errors

The server encountered an error and could not complete the request.

500 Internal Server Error

A generic server-side error. Googlebot will retry. Sustained 500s cause pages to drop from the index. Investigate server logs immediately.

503 Service Unavailable

The server is temporarily unavailable: maintenance, overload, or deployment in progress. Google treats 503 as temporary and will retry. Use during planned downtime with a Retry-After header to signal when to return. Do not return 503 for extended periods.

504 Gateway Timeout

The server acting as a gateway did not receive a timely response from an upstream server. Usually an infrastructure or load issue.

Soft 404s

A soft 404 is a page that returns a 200 status code but contains no meaningful content: “page not found” messages, empty search results, thin auto-generated pages. Google identifies these algorithmically and may deindex them. Google Search Console flags them in the Page Indexing report.

Fix by returning the correct status code (404 or 410) for pages with no real content, or by improving the content so the page earns its 200.

Less common codes

418 I’m a Teapot

Originally an April Fools RFC (RFC 2324, 1998), 418 was preserved in the HTTP spec when there were proposals to remove it. The community voted to keep it. Some servers use it to reject requests that are clearly not HTTP (bots trying HTTP endpoints with non-HTTP protocols), and it appears occasionally as a deliberate refusal signal. It has no SEO implications, and Google names it directly as an example of the “more exotic status codes” its documentation does not cover.¹

422 Unprocessable Content

The server understood the request and the content type is valid, but the body contains semantic errors. These are commonly returned by APIs when form submissions or JSON payloads fail validation. Rarely encountered for HTML pages; more relevant when crawling form-heavy or API-driven sites.

425 Too Early

Indicates the server is unwilling to process a request sent with early data (0-RTT in TLS 1.3) due to replay attack risk. An edge case in SEO crawling; Googlebot does not use 0-RTT, so this will not appear in normal crawls.

426 Upgrade Required

The server refuses to process the request using the current protocol and requires an upgrade (typically to HTTPS or a newer HTTP version). Correctly configured servers should redirect to HTTPS via 301 rather than returning 426.

431 Request Header Fields Too Large

The server refuses the request because one or more request header fields are too large. Can occur when crawlers or browsers send an excessive number of cookies or very long URLs. On large e-commerce sites with aggressive cookie use, this can occasionally block crawlers.

451 Unavailable For Legal Reasons

The resource is unavailable due to a legal demand: a court order, DMCA takedown, or government restriction. Named after the Ray Bradbury novel. If content is removed for legal reasons, 451 is the accurate code and communicates the reason to users and other clients. Do not expect Google to treat it as a special case, though: 451 does not appear in Google’s status code documentation at all, and the blanket rule covering 4xx responses is that everything except 429 is handled the same way.¹

511 Network Authentication Required

The client must authenticate to gain network access. This is typical of captive portal pages (hotel Wi-Fi login screens). Not relevant for public web pages but may appear in crawl logs if a crawler encounters a network with a captive portal.

SEO implications at a glance

The PageRank column is uniform across redirect types by design: no 30x redirect loses PageRank.² What differs between 301 and 302 is the strength of the canonical signal, not the equity that survives the hop.

---

For a complete list of all HTTP status codes including rarely encountered ones, see the Wikipedia HTTP status codes list or http.dev/status.

Footnotes

1. How HTTP status codes, and network and DNS errors affect Google Search — Google Search Central. Covers the top 20 status codes Googlebot encounters; more exotic codes are explicitly out of scope. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³

2. Google: There is no PageRank dilution when using 301, 302, or 30x redirects anymore — Search Engine Land, 26 July 2016. Gary Illyes: “30x redirects don’t lose PageRank anymore.” ↩ ↩² ↩³