HTTP Status Codes Explained: The 5 Classes and 24 Codes

An HTTP status code is the 3-digit integer that opens every HTTP response and states the outcome of the request: 1xx is interim, 2xx succeeded, 3xx moved, 4xx rejected the request, 5xx admits the server failed. The first digit sets the class, so 5 classes cover every registered code and 24 of them carry a decision. UpMonitor's liveness audit captures the final status and timing, follows every hop of the redirect chain, and flags a chain over 4 hops or a missing HTTPS upgrade rule.

What Is an HTTP Status Code?

An HTTP status code is the 3-digit integer in the status line of an HTTP response that states the outcome of the request. The first digit selects 1 of 5 classes, and RFC 9110 section 15.1 defines each in a single line: 1xx received and continuing, 2xx received and accepted, 3xx further action required, 4xx bad syntax or unfulfillable, 5xx an apparently valid request the server failed. The reason phrase beside the number, Not Found next to 404, is advisory text for a human reader and carries no meaning for a client. A probe reads the status code before a single header.

How a Status Code Reaches the Browser

A status code reaches the browser as the first line of the response, and the client acts on its first digit before it recognizes the number. RFC 9110 requires a client to understand the class of any code and to treat an unrecognized one as the x00 code of that class, so a code no client library has seen still routes correctly.

The class drives 3 client behaviours:

• Follow the redirect. A 3xx sends the client to the URL in the Location header and the request repeats there.
• Serve from cache. A 304 Not Modified answers a conditional request with no body, so the client renders the copy it holds.
• Surface the failure. A 4xx or a 5xx ends the exchange, and the body that arrives is an error document.

Read the final status code of any URL, the hop count behind it and the URL it landed on, with 1 command:

curl -sS -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' -L https://example.com

The -L flag walks the redirect chain, so the first number is the status code of the last hop. Drop it to read the first hop, the number that matters when you audit a redirect rule. Confirm the chain from outside your network with the free HTTP status checker, which captures the final status and timing and follows every hop.

The 5 HTTP Status Code Classes

HTTP defines 5 status code classes and the first digit selects the class. RFC 9110 section 15.1 defines each in one line, and Google Search Central documents the crawler treatment:

The 1xx class is the one no application code sees: an interim response arrives ahead of the real one and the client library consumes it. The 2 informational codes:

• 100 Continue: the server accepts the request headers and invites the announced body.
• 101 Switching Protocols: the server agrees to the protocol in the Upgrade header, completing a WebSocket handshake.

2xx Success Codes: The 4 Responses That Mean the Request Worked

A 2xx status code means the action was successfully received, understood and accepted, so the body is the resource asked for. RFC 9110 section 15.3 registers 7 codes, and 4 carry a decision on a public website. The 4 codes:

• 200 OK: the request succeeded and the body represents the target resource. It is the only status code an indexable page should return.
• 201 Created: the request created 1 or more resources and Location names the primary one. API endpoints return it, HTML pages do not.
• 204 No Content: the request succeeded with no body to send, so the browser stays on the current page.
• 206 Partial Content: the server answers a Range request with part of the body. Video scrubbing and resumable downloads depend on it.

The trap here is a 200 on a page whose body announces the resource is gone: Google calls that a soft 404 and flags the URL in Search Console.

3xx Redirect Codes: 301 vs 302 vs 307 vs 308

Serve 301 Moved Permanently or 308 Permanent Redirect for a permanent move, and 302 Found, 303 See Other or 307 Temporary Redirect for one that ends. The split that breaks production is the method: RFC 9110 sections 15.4.8 and 15.4.9 define 307 and 308 with the same requirement, that the user agent MUST NOT change the request method if it was not GET or HEAD. 301 and 302 carry the opposite legacy, because user agents have historically rewritten a POST to a GET and discarded the body. The 6 codes on the 4 attributes that decide which to serve:

A plain-HTTP request to an HTTPS site meets a 301 to the secure variant, and a browser learns to skip it: once a host sits in the HSTS store, the browser rewrites http:// to https:// before the request leaves. The HSTS preloading guide covers the values that fill that store. Google's crawlers follow up to 10 redirect hops and UpMonitor's liveness audit flags a chain over 4 hops, because every extra hop is latency and one more rule that can be retired unnoticed.

4xx Client Errors: The 8 Codes That Blame the Request

A 4xx status code means the server rejected the request as it arrived. The cause is as often the site's own routing as a visitor's typing: a broken link, a renamed route or a stale sitemap entry each produce a 404 Not Found no visitor caused. Google does not use the content from URLs that return 4xx status codes. The 8 codes to recognize:

• 400 Bad Request: the server cannot parse the request, from malformed syntax to deceptive routing.
• 401 Unauthorized: the request lacks valid credentials, and the response carries a WWW-Authenticate header naming the scheme.
• 403 Forbidden: the server understood the request and refuses to authorize it. Credentials do not help.
• 404 Not Found: the origin server did not find a current representation for the target resource.
• 405 Method Not Allowed: the method is not supported on this target, and an Allow header lists the ones that are.
• 410 Gone: the target resource is no longer available at the origin server and that condition is likely to be permanent.
• 429 Too Many Requests: the client exceeded a rate limit in a given amount of time, and Retry-After belongs beside it.
• 431 Request Header Fields Too Large: the request header fields are too large to process, either in total or as a single field.

5xx Server Errors: The 4 Codes That Blame the Server

A 5xx status code means the request was valid and the server failed to fulfill it, so nothing the client changes will help. The fix lives in the server, the proxy or the application. The 4 codes:

• 500 Internal Server Error: the server met an unexpected condition that stopped it fulfilling the request. The cause sits in the application log.
• 502 Bad Gateway: the server, acting as a gateway or proxy, received an invalid response from an inbound server it accessed.
• 503 Service Unavailable: the server is currently unable to handle the request due to a temporary overload or scheduled maintenance. Send Retry-After with it.
• 504 Gateway Timeout: the gateway or proxy did not receive a timely response from the upstream server it needed.

Google's crawlers treat 5xx responses as a signal to temporarily slow down with crawling, and already indexed URLs are preserved in the index, but eventually dropped when the failure persists.

Which HTTP Status Codes Hurt Your Search Rankings?

3 groups cost you search visibility: temporary redirects that signal the target only weakly, 4xx codes that drop the URL, and 5xx codes plus 429 Too Many Requests that throttle the crawl. Google follows a 301 and uses it as a strong signal that the redirect target should be processed, documents 308 as equivalent to 301, and follows 302 and 307 as a weak signal only. Google does not use the content from 4xx URLs, and treats 404 Not Found and 410 Gone identically. Every sitemap URL should answer 200 OK, and the technical SEO audit guide to robots.txt and sitemaps covers the rest of that file.

How to Fix the 6 Status Code Failures That Break Sites

Fix each of the 6 failures at its source, then probe the URL again:

1. 404 Not Found on a URL that still has inbound links. The route was renamed and nothing replaced it. Serve a 301 to the closest live equivalent, then repair the internal links still pointing at the old URL. Prevention: probe every URL your sitemap advertises after a deploy, one monitor per URL.

2. A redirect chain over 4 hops. Each rule was stacked on the last: HTTP to HTTPS, www to apex, then a path rewrite. Point the first rule at the final URL and delete the rules with no source left. Prevention: the liveness audit flags a chain over 4 hops.

3. A 302 Found where the move is permanent. A framework default, or a temporary redirect nobody revisited. Change it to 301, or to 308 when the route accepts POST. Prevention: read the status code of the first hop after a routing change.

4. 429 Too Many Requests served with no Retry-After. The limiter refuses the request and says nothing about when to return, so clients retry at once and keep it saturated. Add Retry-After in seconds. Prevention: exempt your own probe by user agent.

5. 503 Service Unavailable served during a deploy with no Retry-After. A maintenance page answering 503 is correct, one with no hint is a URL Google re-requests blind. Add Retry-After. Prevention: keep the window short.

6. 502 Bad Gateway or 504 Gateway Timeout from an upstream that never answered. The proxy is healthy and the application is not: the process died, the pool is exhausted, or the read timeout is shorter than the slowest endpoint. Restart or scale the upstream, then raise that timeout. Prevention: probe the endpoint the proxy fronts, not only the proxy.

How to Monitor Status Codes on Every Deploy

A status code changes the moment a deploy changes routing, so the probe that catches it runs on a cadence and again on every release. UpMonitor's liveness audit captures the final HTTP status and timing, follows every hop in the redirect chain and flags long detours, and verifies that plain-HTTP requests get a 301 to the secure variant. The same audit runs from a pipeline:

npx @upmonitor/cli check https://upmonitor.io --ci --fail-on failure --checks http

--checks takes a comma-separated list, so naming http alone keeps the gate on routing. The CLI documentation for CI exit codes lists the 3 exit codes: 0 when all checks passed, 1 when a result matched --fail-on, and 2 on a configuration or network error. Wire it after the deploy step and ahead of the traffic switch, the way the website monitoring pipeline in CI/CD orders its stages. The status line is the first field the probe reads, so a broken route surfaces before a visitor reports it.

Frequently Asked Questions

What status code does a site that is completely down return?

None. A DNS resolution failure, a refused TCP connection and a TLS handshake failure each end the exchange before an HTTP response exists, so the probe reports a network error rather than a status line. The guide to decode SSL certificate errors covers those failures.

Should a deleted page return 404 or 410?

Use 410 Gone when the removal is deliberate and permanent, and 404 Not Found for everything else. RFC 9110 separates them on intent: 410 states the resource is no longer available at the origin server and that the condition is likely to be permanent, while 404 states only that no current representation was found. Google treats the 2 identically.

Why does my page return 200 and still get dropped from the index?

Because the body announces an error while the status line reports success. Google calls this a soft 404 and flags the URL in Search Console, and a 2xx status code does not guarantee indexing. Serve 404 or 410 instead.

What status code should a maintenance window return?

503 Service Unavailable, with a Retry-After header. RFC 9110 defines 503 as a temporary overload or scheduled maintenance which will likely be alleviated after some delay, and Google recommends an informational error page carrying 503 for a planned closure of a few days at most.

Do HTTP/2 and HTTP/3 still use status codes?

Yes, unchanged. The 3-digit code belongs to HTTP semantics, which RFC 9110 defines once for every version, so 404 means the same over HTTP/1.1, HTTP/2 and HTTP/3. RFC 9114 section 4.3.2 states HTTP/3 carries no version or reason phrase, only a :status field.