HTTP status codes: the full list, and who sends each one

02HTTP status codes list: meaning, sender and caching

The table covers the codes you will meet in practice. "Usually sent by" is the layer that most often writes the code on a typical site with a CDN or WAF, a reverse proxy and an application; any layer can technically send any code. "Cacheable by default" follows RFC 9110 and RFC 9111: those codes may be stored and reused without explicit freshness headers, while every other code needs Cache-Control or Expires before a cache may keep it.

03How do you tell who generated a status code?

Find the author before debugging, because the same number means different things at different layers. A 403 from a web application firewall is a blocked request; a 403 from the application is a permission check. The Server header usually names the software that wrote the response, proxies add a Via header, CDNs add their own (Cloudflare adds CF-Ray, for example), and an Age header shows the response came out of a cache.

Then compare two requests: one through the public hostname, one straight to the origin with the same hostname and TLS server name. If only the first fails, the edge, or something between it and the origin, wrote the error.

The browser can produce a status too. A 301 it cached earlier is replayed without contacting the server, and on a site that uses HSTS the browser rewrites http:// to https:// before sending anything, which Chrome's developer tools show as a 307 Internal Redirect. Some failures carry no status code at all because no HTTP response arrived: this site can't be reached means DNS or the connection failed, ERR_SSL_PROTOCOL_ERROR means the TLS handshake failed, and ERR_TOO_MANY_REDIRECTS means a redirect loop.

Logs also show unregistered codes: nginx uses 444 to close a connection without a response and logs 499 when the client hung up first, and several CDNs define their own 5xx codes, such as the Cloudflare error codes 520 to 530.

# through the CDN or proxy: the status line and the headers that name the author
curl -s -o /dev/null -D - https://example.com/page | grep -iE '^(HTTP|server|via|age|x-cache|cf-ray)'

# straight to the origin, with the same Host header and TLS server name
curl -s -o /dev/null -D - --resolve example.com:443:203.0.113.10 https://example.com/page | grep -iE '^(HTTP|server|via|age)'

04Which HTTP status codes can be cached?

A shared cache such as a CDN may store a response only when permitted. RFC 9111 allows it when the response carries explicit freshness (Cache-Control with max-age or s-maxage, or an Expires header), a public directive, or a status code defined as heuristically cacheable. In RFC 9110 those codes are 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501. Everything else, including 302, 307, 401, 403, 500 and 503, is stored only when headers explicitly allow it.

Heuristic freshness is a guess, and RFC 9111 suggests 10% of the time since Last-Modified as a typical setting. Worked example: a page last modified 10 days ago and sent with no Cache-Control may be treated as fresh for about a day, because 10% of 240 hours is 24 hours. That is how a 404 or 301 sent without cache headers can keep being served after you have fixed the page.

Four codes are never stored: RFC 6585 says responses with 428, 429, 431 and 511 must not be stored by a cache. And a shared cache must not reuse a response to a request that carried an Authorization header unless the response explicitly allows it, which matters for 401 errors behind a proxy.

052xx success codes: 200, 201, 202 and 204

200 OK is the ordinary success response; its body depends on the method.

201 Created means the request created at least one new resource, typically after a POST or PUT to an API. RFC 9110 identifies the new resource by the Location header or, if that is missing, by the request URL, so an API that answers 201 should send something like Location: /orders/1234 instead of leaving the client to guess.

202 Accepted means the request was queued but not yet processed, and it may still fail later. It suits slow work such as exports or video encoding: the server answers at once, and the body should describe the job and point to a status URL the client can poll. HTTP has no way to deliver the final status of a 202 afterwards, so that URL is the only channel.

204 No Content is success with a deliberately empty body, common for DELETE requests. 206 Partial Content answers a Range request, which is how video players fetch a file in pieces.

063xx redirects in brief

Five codes do most redirecting. 301 and 308 are permanent and cacheable by default; 302 and 307 are temporary; 303 sends the client to a different resource with GET, the usual answer after a form submission. 307 and 308 forbid the client from changing the request method, whereas for historical reasons a browser may turn a POST into a GET after a 301 or 302. Choosing between all five deserves its own comparison, and a redirect that points back at itself ends in too many redirects.

304 Not Modified is formally a redirect too, to the copy the client already holds: the client asked conditionally, with If-None-Match or If-Modified-Since, and the server confirms that its stored version is still valid.

07Which status codes should an API return?

Clients branch on the status code before they read the body, so choose the code that tells them what to do next.

For the body, RFC 9457 defines Problem Details, a standard JSON shape served as application/problem+json. Its members type, title, status, detail and instance give every error one format, and an API may add fields of its own.

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://example.com/problems/invalid-email",
  "title": "The email address is not valid",
  "status": 422,
  "detail": "'bob@' has no domain part",
  "instance": "/signups/7c1e"
}

08How do status codes affect search engines?

Google documents that its crawlers treat every 4xx code except 429 the same way, as content that does not exist, and that those codes have no effect on crawl rate. 5xx codes and 429 make the crawlers slow down for a while, and URLs that keep returning server errors are eventually dropped from the index. A 401 or 403 therefore cannot slow Googlebot down.

So an HTTP flood that exhausts the origin is a search problem too: crawlers see the 5xx responses it causes.