HTTP Status Codes — Complete List & Meanings

The server received the request headers and the client should go ahead and send the body.

When to use: Sent in reply to a request carrying Expect: 100-continue, so a client can check a large upload will be accepted before transmitting it.

The server agrees to switch to the protocol named in the client’s Upgrade header.

When to use: Used when upgrading an HTTP/1.1 connection to WebSocket (Upgrade: websocket).

WebDAV: the server has accepted the request but has not finished processing it yet.

When to use: Prevents a client from timing out during long WebDAV operations. Rarely used today.

Lets the server send Link headers (preload / preconnect) before the final response is ready.

When to use: Send while the backend is still generating the page so the browser can start fetching critical CSS, fonts or scripts early.

The request succeeded. The body contains the requested resource or the result of the action.

When to use: The default success response for GET, and for POST/PUT when you return a body.

SEO impact: The only status that lets a page be indexed with its content. Make sure “not found” pages don’t return 200 (a “soft 404”).

The request succeeded and a new resource was created.

When to use: Return after a POST (or PUT) that creates something; include a Location header pointing to the new resource.

The request was accepted for processing, but processing has not completed.

When to use: Asynchronous jobs: queue the work and return a URL where the client can poll for the result.

The response was modified by a transforming proxy and differs from the origin server’s 200 response.

When to use: Set by proxies that alter content; origin servers should not normally send it.

The request succeeded and there is intentionally no response body.

When to use: DELETE requests, autosave endpoints and CORS preflight responses where nothing needs to be returned.

The request succeeded and the client should reset the document view (for example clear a form).

When to use: Rare; tells the user agent to reset the form that submitted the request.

The server is delivering only the byte range requested with a Range header.

When to use: Video streaming, resumable downloads and download managers.

WebDAV: the body is an XML document containing separate status codes for several sub-requests.

When to use: Batch WebDAV operations where individual items can succeed or fail.

WebDAV: members of a binding were already listed earlier in the same 207 response.

When to use: Avoids listing the same resource repeatedly inside a Multi-Status response.

The server fulfilled a GET with instance manipulations (delta encoding) applied.

When to use: HTTP delta encoding (RFC 3229); almost never seen in practice.

The resource has several representations and the client (or user) should choose one.

When to use: Rare; content negotiation is usually done automatically instead.

SEO impact: Google may pick any of the options; prefer a single 301 to the canonical version.

The resource has a new permanent URL, given in the Location header.

When to use: Domain moves, HTTP → HTTPS, changed slugs, merging duplicate pages.

SEO impact: The standard way to move a page: search engines transfer ranking signals and index the new URL. Browsers may change POST to GET on a 301 — use 308 if the method must be kept.

The resource is temporarily at a different URL.

When to use: Short-lived redirects such as maintenance pages, A/B tests or login flows.

SEO impact: Google treats it as temporary and usually keeps the original URL indexed. If the move is permanent, use 301.

The client should fetch the result from another URL using GET.

When to use: The “Post/Redirect/Get” pattern: after a form POST, redirect to a confirmation page.

SEO impact: Treated like a temporary redirect.

The cached copy is still valid; no body is sent.

When to use: Reply to conditional requests (If-None-Match / If-Modified-Since) when the resource has not changed.

SEO impact: Good for crawl efficiency: Googlebot reuses its cached copy, saving crawl budget.

Deprecated. Originally told the client to access the resource through a proxy.

When to use: Do not use — browsers ignore it for security reasons.

Like 302, but the client must repeat the request with the same method and body.

When to use: Temporary redirects of POST/PUT requests; browsers also show “307 Internal Redirect” for HSTS upgrades.

SEO impact: Temporary — the original URL usually stays indexed.

Like 301, but the client must keep the same method and body.

When to use: Permanent moves of API endpoints or form targets where a POST must stay a POST.

SEO impact: Google treats 308 the same as 301 and transfers signals to the new URL.

The server cannot process the request because it is malformed (bad syntax, invalid JSON, oversized cookie…).

When to use: Validation failures you can’t express more precisely; include an error message in the body.

SEO impact: Pages returning 4xx are dropped from the index.

Authentication is required and was missing or invalid. Despite the name it means “unauthenticated”.

When to use: Missing or expired token / credentials. Must include a WWW-Authenticate header.

SEO impact: Crawlers can’t log in, so pages behind 401 are not indexed — which is what you want for private areas.

Reserved for future use; some APIs use it when a payment or quota upgrade is needed.

When to use: Non-standard billing errors (e.g. a subscription has lapsed).

The server understood the request but refuses to authorize it. Re-authenticating won’t help.

When to use: The user is logged in but lacks permission, or access is blocked by IP, WAF or file permissions.

SEO impact: Not indexed. Check that your firewall or bot protection isn’t returning 403 to Googlebot by mistake.

The server cannot find the requested resource.

When to use: The URL never existed or was removed without a replacement. Serve a helpful custom 404 page.

SEO impact: Normal and harmless for pages that really don’t exist; Google drops them over time. Redirect (301) URLs that have backlinks or a clear replacement.

The HTTP method is not supported for this URL (e.g. POST to a read-only page).

When to use: Return with an Allow header listing the supported methods.

The server can’t produce a response matching the request’s Accept headers.

When to use: Strict content negotiation; many APIs simply return their default format instead.

Like 401, but the client must authenticate with a proxy.

When to use: Sent by corporate or forward proxies with a Proxy-Authenticate header.

The server timed out waiting for the client to finish sending the request.

When to use: Idle or very slow connections; clients may retry.

The request conflicts with the current state of the resource.

When to use: Edit conflicts, duplicate unique keys, or version mismatches in optimistic locking.

The resource was permanently removed and will not come back.

When to use: Deliberately deleted content, expired listings or campaigns.

SEO impact: Google treats 410 like 404 but may drop the URL slightly faster.

The server requires a Content-Length header.

When to use: Uploads without a length when chunked encoding is not accepted.

A condition in the request headers (If-Match, If-Unmodified-Since) evaluated to false.

When to use: Optimistic concurrency: reject an update because the resource changed since the client read it.

The request body is larger than the server allows (formerly “Payload Too Large”).

When to use: File uploads above your limit — e.g. nginx’s client_max_body_size.

The URL is longer than the server will interpret.

When to use: Usually a bug: huge query strings or redirect loops that keep appending parameters.

The body’s format (Content-Type) is not supported.

When to use: An API expecting application/json receives form data or XML.

The Range header asks for bytes outside the file.

When to use: Resuming a download from beyond the end of a file that has shrunk.

The server can’t meet the requirement in the Expect header.

When to use: Rejecting Expect: 100-continue uploads.

An April Fools’ joke from RFC 2324 (Hyper Text Coffee Pot Control Protocol): the server refuses to brew coffee because it is a teapot.

When to use: Easter eggs only. Some services return it to reject automated or unwanted requests, but it carries no standard meaning.

The request reached a server that can’t produce a response for this host.

When to use: HTTP/2 connection reuse across hostnames whose certificate or config doesn’t match.

The syntax is valid, but the content fails semantic validation.

When to use: Form or API validation errors (missing required field, invalid email). Popular in Rails and Laravel APIs.

WebDAV: the resource is locked.

When to use: A file is checked out or locked by another user.

WebDAV: the request failed because a previous request it depended on failed.

When to use: Batch operations where one failure cancels the rest.

The server won’t process a request that might be replayed (TLS 1.3 early data / 0-RTT).

When to use: Protecting non-idempotent requests sent in TLS early data from replay attacks.

The client must switch to a different protocol, named in the Upgrade header.

When to use: Forcing clients onto a newer protocol version.

The server requires the request to be conditional (e.g. include If-Match).

When to use: Prevent “lost updates” by refusing unconditional PUT/PATCH requests.

The client sent too many requests in a given time (rate limiting).

When to use: API rate limits and brute-force protection. Include a Retry-After header.

SEO impact: Googlebot slows its crawl rate when it sees 429 (and 503). Persistent 429s can lead to URLs being dropped.

A header (often Cookie) or all headers together are too large.

When to use: Usually caused by accumulated cookies; clearing cookies for the site fixes it for users.

The resource is blocked for legal reasons — censorship, court orders or regional regulation. The number references Ray Bradbury’s Fahrenheit 451.

When to use: Content removed because of a takedown request or geo-restricted by law.

SEO impact: Treated like other 4xx codes: not indexed.

A generic error: the server hit an unexpected condition.

When to use: Unhandled exceptions, crashed scripts, broken .htaccess rules. Check your server logs.

SEO impact: Short outages are tolerated; if 5xx errors persist for days, Google slows crawling and eventually drops URLs.

The server doesn’t support the functionality required (often an unknown method).

When to use: A method the server doesn’t recognise at all, as opposed to 405 for a known but disallowed one.

A gateway or proxy got an invalid response from the upstream server.

When to use: Your app server (PHP-FPM, Node, Gunicorn) crashed or returned garbage behind nginx, a load balancer or a CDN.

SEO impact: Same as other 5xx: temporary is fine, persistent errors hurt crawling and indexing.

The server is temporarily unable to handle the request — overloaded or down for maintenance.

When to use: Planned maintenance or overload. Add Retry-After to say when to come back.

SEO impact: The correct code for planned downtime: Google keeps the page indexed and retries later. Don’t serve it for more than a day or two.

A gateway or proxy didn’t get a response from the upstream server in time.

When to use: Slow database queries or upstream APIs exceeding the proxy timeout.

SEO impact: Persistent timeouts reduce crawl rate and can lead to deindexing.

The server doesn’t support the HTTP version used in the request.

When to use: Very old or very new protocol versions a server can’t handle.

Server misconfiguration: the chosen variant is itself configured to negotiate, creating a loop.

When to use: A content-negotiation configuration error.

WebDAV: the server can’t store the representation needed to complete the request.

When to use: The disk or user quota is full.

WebDAV: the server detected an infinite loop while processing the request.

When to use: Some hosts (e.g. cPanel/CloudLinux) also return it when an account hits its resource limits.

Further extensions to the request are required (RFC 2774, now historic).

When to use: Practically unused.

The client must authenticate to gain network access.

When to use: Captive portals on hotel, airport or café Wi-Fi.

nginx closes the connection without sending any response.

When to use: Configured in nginx to drop malicious or unwanted requests silently.

Logged by nginx when the client closed the connection before the server answered.

When to use: You’ll see it in logs when users navigate away or a client timeout is shorter than your response time.

Cloudflare received an empty, unknown or unexpected response from the origin server.

When to use: Origin crashes, oversized headers or connection resets. Check the origin’s error logs.

SEO impact: Treated like a 5xx error.

The origin server refused Cloudflare’s connection.

When to use: The web server is stopped or a firewall blocks Cloudflare’s IP ranges.

SEO impact: Treated like a 5xx error.

Cloudflare could not complete a TCP connection to the origin.

When to use: Overloaded origin, wrong DNS record or firewall dropping packets.

SEO impact: Treated like a 5xx error.

Cloudflare connected to the origin, but it didn’t respond within 100 seconds.

When to use: Long-running requests; move them to background jobs.

SEO impact: Treated like a 5xx error.

The TLS handshake between Cloudflare and the origin failed.

When to use: Origin has no valid certificate or doesn’t support SNI/TLS versions Cloudflare uses.

SEO impact: Treated like a 5xx error.

Cloudflare (in Full Strict mode) could not validate the origin’s certificate.

When to use: Expired or self-signed origin certificate — install a valid one or a Cloudflare Origin CA certificate.

SEO impact: Treated like a 5xx error.