An HTTP status code is the three-digit number a web server sends at the start of every response to say how it handled a request. Browsers, search crawlers, ad servers and API clients read it before anything else and decide from it whether to display content, follow a redirect, retry or give up. It exists because a response body is written for people and varies endlessly, while software needs a short, standard verdict. For marketers, status codes decide whether a landing page passes ad review, whether a page stays indexed and whether a bid or pixel fire has counted.
The five classes
The current definition sits in RFC 9110, the Internet Engineering Task Force (IETF) specification of HTTP semantics published in June 2022 and edited by Roy Fielding, Mark Nottingham and Julian Reschke. It describes "a three-digit integer code that describes the result of the request and the semantics of the response". Valid codes run from 100 to 599. The first digit defines the class; "the last two digits do not have any categorization role".
- 1xx Informational: an interim reply, such as 100 Continue or 103 Early Hints.
- 2xx Successful: the request was received, understood and accepted. 200 OK dominates; 204 No Content means success with nothing to return.
- 3xx Redirection: further action is needed, usually a new request to the address in the Location header. 301 and 308 are permanent, 302 and 307 temporary.
- 4xx Client Error: the request was faulty or cannot be fulfilled, as with 403 Forbidden, 404 Not Found, 410 Gone and 429 Too Many Requests.
- 5xx Server Error: the server "failed to fulfill an apparently valid request", as with 500, 502 Bad Gateway and 503 Service Unavailable.
The class rule keeps the system workable. A client "MUST understand the class of any status code" and treat an unrecognised one as the x00 code of its class, so an unknown 471 is handled as a 400.
How the code travels
In HTTP/1.1, specified in RFC 9112, the response opens with a status line: protocol version, code and an optional reason phrase, as in "HTTP/1.1 404 Not Found". The phrase is decoration. RFC 9110 calls the listed phrases "only recommendations" that can be "left out altogether without affecting the protocol".
HTTP/2 and HTTP/3 dropped the status line. Under RFC 9113, a single ":status" pseudo-header field "carries the HTTP status code field" and must appear in every response; HTTP/3, in RFC 9114, does the same. Neither carries a reason phrase, so the number is the whole message.
Codes also govern caching. RFC 9110 lists 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501 as "heuristically cacheable", meaning a cache may reuse them without explicit instructions. A 404 can therefore linger in a content delivery network (CDN) after a page is restored, while a 302 or 503 is stored only if the server says so.
The registry and unofficial codes
Official codes are listed in the HTTP Status Code Registry kept by the Internet Assigned Numbers Authority (IANA), and new entries require IETF Review. As of October 2026 the registry, last updated on September 15, 2025, holds 64 entries, two of them marked unused. One is temporary: 104 Upload Resumption Supported, tied to an IETF draft on resumable uploads, registered on November 13, 2024 and due to expire on November 13, 2026.
Vendors fill unassigned numbers on their own. Nginx logs 499 when a client closes the connection before the server answers; the code exists only in logs. Cloudflare uses 520 to 530 for failures between its edge and a customer's origin: 521 when the origin refuses connections, 522 when the connection times out, 524 when the origin answers too slowly, according to Cloudflare's documentation. None is registered, and a strict client reads each as its class's x00 code.
Origin and evolution
HTTP/0.9, which Tim Berners-Lee implemented at CERN in 1991, had no status codes: the server returned the document, and an error was simply a page of text. Numeric codes appeared in Berners-Lee's 1992 drafts and were written down in RFC 1945, which documented HTTP/1.0 in May 1996 with 15 codes across four classes.
HTTP/1.1 followed in RFC 2068 in January 1997 and RFC 2616 in June 1999, adding the 1xx class, 410 Gone and 307 Temporary Redirect, and renaming 302 "Found" because browsers had been turning POST requests into GET on redirects. RFC 7231 moved semantics into a document of its own in June 2014. RFC 9110 replaced it in June 2022, published with RFC 9114 for HTTP/3, so one semantics document now covers all three versions.
Later additions each answered an operational problem. RFC 6585 added 429 Too Many Requests for rate limiting in April 2012. RFC 7538 defined 308 Permanent Redirect, a 301 that forbids changing the request method, in April 2015. RFC 7725 created 451 Unavailable For Legal Reasons in February 2016, separating legal blocks from generic refusals; the number alludes to Ray Bradbury's Fahrenheit 451. RFC 8297 introduced 103 Early Hints in December 2017, letting servers tell browsers which resources to fetch before the final response is ready.
RFC 9110 also settled the fate of 418. The code came from RFC 2324, an April 1, 1998 joke specification for coffee pots. It had "been deployed as a joke often enough for the code to be unusable for any future use", RFC 9110 says, so 418 is reserved as "(Unused)".
Why status codes matter for marketing
Search indexing. Google's documentation, moved to its crawling site on December 18, 2025 and last updated on February 4, 2026, sets out the rules. A 200 sends content to indexing but guarantees nothing. Googlebot generally follows up to 10 redirect hops; a 301 is a strong canonical signal, a 302 a weak one. All 4xx codes except 429 lead to removal of indexed URLs and have no effect on crawl rate, which is why Google says 401 and 403 should not be used to throttle it. Codes 429 and 5xx slow crawling, and URLs that persistently return server errors are dropped. In December 2025 Google added that rendering may be skipped for non-200 status codes. Crawl capacity is covered in crawl budget.
Ad destinations. Google Ads' "Destination not working" policy cites 403, 404 and 500 as examples, and its troubleshooting table adds 4xx and 5xx responses generally, timeouts and "server redirects too often". The checks are run by Google AdsBot, so a firewall that answers AdsBot with 403 can disapprove ads on a page that works for every human. Merchant Center's "product page unavailable" error can arise with no status code at all, from crawler timeouts and DNS failures.
Programmatic plumbing. A demand-side platform (DSP) that declines an impression typically returns HTTP 204 with an empty body, which OpenRTB treats as a pass. A tracking pixel server often answers with 204 too, or with a 1x1 image and a 200. Click trackers rely on 302 redirects, and each hop adds latency and another place to lose a click.
Bots and APIs. For publishers the code is now a policy tool: 403 refuses a crawler, 429 asks it to slow down. Cloudflare began offering customisable 402 Payment Required responses to AI crawlers in 2025, reviving a code reserved since the 1990s, and said it served more than one billion 402 responses a day. Advertising APIs use 429 for exhausted quotas.
Limitations and disputes
A status code is the server's claim, and it can be wrong. The common case is the soft 404: a "not found" or empty page returned with 200. Google detects these heuristically and reports them in Search Console; other crawlers and ad systems may not.
Redirects are routinely misused. Permanent moves are served as 302s, and temporary campaign redirects as 301s that browsers then cache. Even a 301 is, in Google's words, a signal rather than an instruction.
Consumers also disagree. Google treats 403 like 404 for indexing; AdsBot records a broken destination; Bing, AI crawlers and verification vendors publish less detail. And the number says nothing about cause. A 503 can mean maintenance, overload or a bot challenge; a 403 can come from an application, a web server or an edge firewall.
What an HTTP status code is not
- HTTP method: the verb in the request, such as GET, POST or HEAD. The method asks; the code answers.
- HTTP header: a named field such as Location, Retry-After or Cache-Control that travels with the code and often completes it. A 301 without a Location header says little.
- Error page: the human-readable body sent with a 4xx or 5xx code. Served with 200, it becomes a soft 404.
- Application error codes: numbers defined inside a platform's payload. In VAST, error 303 means no ad after wrappers and 402 a media file timeout, unrelated to HTTP 303 or 402. Meta's Graph API returns codes such as 17 for request limits inside a JSON body.
Recent developments
On October 6, 2026, Google added Retry-After examples to its crawl rate guidance, confirming the header can accompany 503 and 429 responses with a delay in seconds or a date; Google said the support was not new. On September 30, 2026, Google Ads added examples to its "Destination not working" article, noting that this "does not change enforcement of the policy".
The bigger shift concerns 429. On October 16, 2026, Cloudflare said it would score Verified bots on whether they slow down after 429 responses, raising trust for crawlers that comply. The same coverage reported HasData's finding that 234 of 592 sites disallowing GPTBot still served it a live page, a 39.5% gap between robots.txt and server behaviour. The provisional 104 code reaches its expiry date on November 13, 2026.
Timeline
- 1991: HTTP/0.9 implemented at CERN, with no status line or codes
- 1992: Tim Berners-Lee's HTTP drafts introduce numeric status codes
- May 1996: RFC 1945 documents HTTP/1.0 status codes
- January 1997: RFC 2068 specifies HTTP/1.1, adding the 1xx class
- April 1, 1998: RFC 2324 defines 418 I'm a teapot as an April Fools' specification
- June 1999: RFC 2616 replaces RFC 2068 and renames 302 "Found"
- April 2012: RFC 6585 adds 428, 429, 431 and 511
- June 2014: RFC 7231 moves HTTP/1.1 semantics into a separate document
- April 2015: RFC 7538 defines 308 Permanent Redirect
- February 2016: RFC 7725 defines 451 Unavailable For Legal Reasons
- December 2017: RFC 8297 defines 103 Early Hints
- September 2018: RFC 8470 defines 425 Too Early
- June 2022: RFC 9110 consolidates semantics for HTTP/1.1, HTTP/2 and HTTP/3; 418 reserved as unused; RFC 9113 and RFC 9114 published
- November 13, 2024: 104 Upload Resumption Supported registered as a temporary code
- July 1, 2025: Cloudflare launches pay per crawl in private beta
- August 28, 2025: Cloudflare expands customisable 402 responses for AI crawlers
- September 15, 2025: IANA status code registry last updated
- December 18, 2025: Google moves its status code documentation to the crawling site and says rendering may be skipped for non-200 responses
- February 4, 2026: Google's status code page last updated
- September 30, 2026: Google Ads updates its "Destination not working" article
- October 6, 2026: Google adds Retry-After examples to its crawl rate documentation
- October 16, 2026: Cloudflare ties Verified bot trust to compliance with 429 responses
- November 13, 2026: temporary registration for 104 due to expire
Related PPC Land coverage
- Google clarifies JavaScript rendering for error pages in December documentation update - Google's December 2025 note that rendering may be skipped for 404, 301, 401 and 403 responses.
- Google updates crawling infrastructure documentation with new technical details - How 500, 503 and 429 reduce crawl rate across a hostname, and 421 for HTTP/2.
- Google Search Console crawl rate limiter tool to be deprecated - The retirement that left server responses as the main lever on Google's crawl rate.
- Google crawl rate declines affect multiple hosting platforms - The August 2025 crawl drop that Google confirmed was on its side.
- Google's secret crawl logic, finally explained in one page - Google's March 2026 crawling overview, including automatic slowdowns when sites return errors.
- 404 Errors don't hurt rankings, says Google Search Relations Team - John Mueller on 404s and on avoiding blanket redirects to the homepage.
- Google clarifies when to fix 404 errors - Gary Illyes's three categories of 404 and which ones warrant action.
- Joost de Valk's website spec: 128 rules to future-proof your site - A spec requiring correct error codes, 301 or 308 for permanent moves and no soft 404s.
- Google Merchant Center's "product page unavailable" error kills ads - here's the fix - Crawler timeouts and DNS failures behind a common Merchant Center disapproval.
- Cloudflare expands 402 payment protocol for AI crawler communication - Customisable 402 Payment Required responses for AI crawlers.
- Cloudflare launches pay per crawl to monetize AI content access - The July 2025 private beta that put 402 back into use.
- Cloudflare Verified bots face trust scores for ignoring site rules - Trust scores tied to robots.txt compliance and 429 responses, with HasData's GPTBot figures.
- Explaining OpenRTB - The bidding protocol in which an HTTP 204 response signals a pass.
- Explaining tracking pixel - How pixel servers log requests and reply with tiny images or empty responses.
- Explaining Google AdsBot - The crawler that checks ad landing pages and records their responses.
- Explaining Googlebot - Google's search crawler and how it fetches pages.
- Explaining crawl budget - How crawl capacity and demand interact, including the effect of server errors.
- Explaining VAST - The video ad template whose own error codes are often confused with HTTP codes.
Summary
- Who: Web servers, CDNs and APIs return status codes; browsers, search crawlers such as Googlebot, ad checkers such as AdsBot, DSPs and reporting tools read them. The IETF defines them and IANA keeps the registry.
- What: A three-digit number at the start of every HTTP response stating how the request was handled, grouped into five classes from 1xx informational to 5xx server error.
- When: Introduced in early HTTP drafts in 1992 and specified in RFC 1945 in May 1996; the current definition is RFC 9110 of June 2022, with the IANA registry last updated in September 2025.
- Where: In the status line of HTTP/1.1 responses and the ":status" field of HTTP/2 and HTTP/3, on every exchange between a client and a server, from page loads to bid requests and pixel fires.
- Why: Software needs a short, standard verdict to decide whether to index, display, redirect, retry or discard a response. For marketers, the code decides indexing, ad approval, bid outcomes and how crawlers and AI bots are allowed in.
Discussion