HTTP Status Codes

Used with the Expect: 100-continue request header so a client can check that the server will accept a large upload (authentication, size limits) before sending the body.

The reply to an Upgrade header — most often when a browser opens a WebSocket connection. After the 101, the connection speaks the new protocol.

Introduced by WebDAV to stop clients timing out during long operations. It was left out of the later WebDAV specification and is rarely used today.

A server or CDN sends Link: rel=preload or rel=preconnect headers while the page is still being generated, so CSS, fonts and scripts start downloading sooner. Supported by Chromium browsers and several CDNs.

For GET the body contains the requested resource; for POST it describes the result of the action. It is the normal answer for a working page or API call.

SEO impact: Pages returning 200 can be indexed. Make sure error and “not found” pages do not return 200 — search engines call those soft 404s.

The usual reply to a POST or PUT that creates a record in an API. Include a Location header pointing to the new resource.

Used for asynchronous work such as exports, video encoding or queued emails. The action may still fail, so a good API also returns a URL where the client can check progress.

The origin answered 200, and an intermediary modified the content or headers on the way (for example, recompressing images). Rare in practice.

Common for DELETE requests, saves with PUT or PATCH, and analytics beacons. A browser stays on the current page when a form submission returns 204.

Asks the user agent to clear the inputs that triggered the request, for example after a data-entry form is saved. Rarely used.

This is what makes resumable downloads and video seeking work. The response carries a Content-Range header such as bytes 0-1023/146515.

Returned by WebDAV operations that touch many files at once, such as PROPFIND; an XML body lists a status for each item.

Used inside a 207 response so that a resource bound into a collection several times is not listed over and over.

From the HTTP delta-encoding extension: the client asked with an A-IM header for changes only, and the server sent a delta of the current resource. Almost never seen on the public web.

For example, different formats or languages. There is no standard way to pick automatically, so it is rarely used.

Use it when a page moves for good: a domain change, HTTP to HTTPS, or a new URL structure. Browsers cache it. Clients may turn a POST into a GET when following a 301, so APIs that must keep the method should use 308.

SEO impact: Passes ranking signals to the new URL, and search engines index the target instead. Redirect each old URL to its closest new equivalent and avoid chains of redirects.

The original URL remains the real one. Common after logins, for geo or language routing and for A/B tests. Clients may switch POST to GET when following it; use 307 if the method must be kept.

SEO impact: Search engines keep the original URL indexed. A 302 left in place for a long time may eventually be treated like a 301 by Google.

The classic reply after a form POST (the Post/Redirect/Get pattern), so refreshing the result page does not submit the form again.

The answer to a conditional request with If-None-Match (ETag) or If-Modified-Since. The browser reuses its cached copy, saving bandwidth.

SEO impact: Good for crawling: Googlebot supports conditional requests, and 304s save crawl budget on large sites.

Deprecated for security reasons, and browsers ignore it.

It once meant “Switch Proxy”. The code is reserved and must not be sent.

Like 302, but a POST stays a POST. Browsers also show an internal 307 when HSTS upgrades an http:// link to https:// — that redirect never reaches the server.

SEO impact: Treated like a 302: the original URL stays in the index.

The method-preserving version of 301, first defined in RFC 7538. Ideal for APIs and for permanent moves where POST must not turn into GET.

SEO impact: Search engines treat it like a 301, so ranking signals pass to the new URL.

A catch-all for requests the server cannot understand.

Common causes

• Invalid JSON or form data, or a missing required field in an API call
• A malformed URL or unencoded characters in the query string
• Corrupted or oversized cookies (some servers answer 400 instead of 431)

How to fix it

• Validate the request body against the API documentation
• Percent-encode special characters with the URL encoder
• Clear the site’s cookies and try again

Despite the name, it means “unauthenticated”. The response must include a WWW-Authenticate header describing how to log in.

Common causes

• A missing or expired token, API key or session cookie
• Wrong username or password for HTTP Basic authentication
• Clock skew that makes a JWT look expired or not yet valid

How to fix it

• Log in again or refresh the access token
• Send credentials in the expected header, e.g. Authorization: Bearer …
• Inspect the token’s exp and nbf claims with the JWT decoder

SEO impact: Pages behind a login are not indexed, which is expected.

Never standardised for general use. Some APIs and SaaS platforms return it when a subscription has lapsed or a paid quota is used up.

Unlike 401, logging in again will not help — the client is known (or anonymous) but lacks permission.

Common causes

• File or folder permissions on the server are too strict, e.g. a folder without execute permission
• A folder has no index file and directory listing is disabled
• An IP block, firewall/WAF rule, bot protection or hotlink protection
• The signed-in user lacks the required role

How to fix it

• Set files to 644 and folders to 755 — see the chmod calculator
• Add an index.html or index.php to the folder
• Check firewall or CDN security logs for the blocked request
• Grant the user the role or scope they need

SEO impact: If Googlebot receives 403 on public pages they drop out of the index — make sure bot protection lets verified crawlers through.

The most common error on the web. It does not say whether the absence is temporary or permanent.

Common causes

• A typo in the URL or a broken link
• The page was deleted or moved without a redirect
• Wrong file name or letter case — Linux servers are case-sensitive
• Rewrite rules or single-page-app routing that the server does not know about

How to fix it

• 301-redirect moved pages to their new URL (the .htaccess redirect generator helps)
• Fix internal links that point to the missing page
• Serve a helpful custom 404 page with search and links — but keep the 404 status
• For single-page apps, make the server fall back to index.html for app routes

SEO impact: A few 404s are normal and do not hurt a site’s rankings overall, but the missing URL drops out of the index and links to it lose their value. Never answer 200 for a missing page (a soft 404).

For example a POST to a read-only page. The response must include an Allow header listing the methods that work.

Common causes

• A form or API call using the wrong method (POST vs PUT vs GET)
• Static hosting that does not accept POST
• No backend route defined for that method

How to fix it

• Check the Allow header and the API documentation
• Point forms at an endpoint that accepts POST

Content negotiation failed — for example the client accepts only XML and the API only produces JSON. Some security modules also send 406 for blocked requests.

Common on corporate networks. The proxy sends a Proxy-Authenticate header explaining how to sign in.

Usually a slow or interrupted connection, or an idle keep-alive connection being closed. Clients can safely retry.

For example editing a record someone else just changed, or creating a user that already exists. The body should explain how to resolve the conflict.

A stronger, explicitly permanent version of 404.

SEO impact: Search engines may drop a 410 URL slightly faster than a 404. Use it for content you deleted deliberately and will not replace.

Sent when a request with a body has no Content-Length and the server will not accept chunked uploads.

Used with If-Match or If-Unmodified-Since for optimistic locking: the resource changed since the client last read it, so the update is refused.

Formerly named “Payload Too Large”. Typical when uploading big files.

Common causes

• The upload exceeds a server limit — nginx’s client_max_body_size defaults to 1 MB, and PHP has upload_max_filesize and post_max_size

How to fix it

• Raise the limit on the server and on any proxy in front of it
• Shrink the file first — for photos, try the image compressor

Often caused by huge query strings, redirect loops that keep appending parameters, or data sent with GET that belongs in a POST body.

For example sending form data to an endpoint that expects application/json, or leaving out the Content-Type header.

Happens when resuming a download of a file that has since changed or shrunk. The response includes Content-Range: bytes */length.

Usually the server or a proxy does not support Expect: 100-continue; retry without that header.

Defined in RFC 2324, the Hyper Text Coffee Pot Control Protocol (1998). RFC 9110 reserves the number so it cannot be reused, and some sites return it playfully to turn away unwanted requests.

Appears when a form is submitted after the session expired, or the form lacks a CSRF token.

How to fix it

• Reload the page and submit the form again
• Developers: include @csrf in forms and check session settings

You may still meet it in old code samples and libraries.

Seen with HTTP/2 and HTTP/3 connection reuse, when a connection opened for one host name is reused for another the server is not configured for. Clients should retry on a new connection.

Formerly “Unprocessable Entity”. Widely used by APIs and frameworks such as Rails and Laravel for validation errors — valid JSON containing, say, an invalid email address.

A WebDAV file is locked by another user or process.

Used by WebDAV when one action in a batch fails and the others cannot proceed.

Relates to TLS 1.3 early data (0-RTT): the server refuses to act on a request sent before the handshake finished, because an attacker could replay it. The client retries after the handshake.

The server sends an Upgrade header naming the protocol the client must use.

Forces clients to send If-Match so they cannot overwrite changes made by someone else (the lost-update problem).

The server may include a Retry-After header saying how long to wait.

Common causes

• An API rate limit or quota has been reached
• A script or crawler requesting too fast
• A shared IP address (office, VPN, mobile carrier) with heavy traffic
• Brute-force protection on a login page

How to fix it

• Respect Retry-After and back off exponentially between retries
• Cache responses and batch requests
• Ask for a higher quota or use authenticated access

SEO impact: Googlebot slows down when it receives 429 or 503 responses; if they continue, URLs can start dropping from the index.

The server refuses to process a request whose headers, or one header, are too large.

Common causes

• Too many or very large cookies on the domain
• An extremely long Referer or Authorization header

How to fix it

• Clear the site’s cookies
• Store less data in cookies on the server side

Configured with return 444; to drop unwanted or malicious requests. Clients see an empty reply; the code only appears in nginx logs.

For example a court order, government censorship or a copyright takedown. The number is a nod to Ray Bradbury’s Fahrenheit 451, and the response may name the blocking party in a Link header.

Logged when a visitor navigates away or a client times out first — often a sign of slow upstream responses.

The server hit an unexpected condition and has no more specific code to report.

Common causes

• An unhandled exception or bug in the application
• A syntax error in .htaccess or another server config file
• Wrong permissions on a PHP or CGI script
• Memory exhausted or a failed database query

How to fix it

• Read the server or application error log — the real cause is recorded there
• Roll back the most recent deploy or configuration change
• Validate .htaccess and config syntax
• Show a friendly error page and alert developers automatically

SEO impact: An occasional 500 is harmless, but persistent 5xx errors make search engines crawl less and eventually drop pages.

Usually the server does not recognise the request method at all.

Something between you and the application — nginx, a load balancer or a CDN — could not get a valid answer from the server behind it.

Common causes

• The application server (PHP-FPM, Node.js, Gunicorn…) crashed or is not running
• The upstream closed the connection or sent malformed headers
• Wrong upstream address or port in the proxy configuration
• A firewall blocks the proxy from reaching the origin

How to fix it

• Restart the application server and check its logs
• Confirm the proxy_pass or upstream address and port
• Increase proxy buffer sizes if responses have very large headers
• As a visitor: wait a minute and reload

SEO impact: Short outages are fine; repeated 502s reduce crawling like other 5xx errors.

Overload or planned maintenance. Include a Retry-After header to say when to come back.

Common causes

• Maintenance mode is switched on
• A traffic spike beyond capacity
• Worker processes or connection pools are exhausted
• A required dependency is down

How to fix it

• Scale up, add caching or rate-limit expensive endpoints
• During maintenance answer 503 with Retry-After — not 200 or 404
• Check health checks and auto-scaling rules

SEO impact: The right code for planned downtime: search engines come back later instead of dropping pages. If it lasts more than a couple of days, URLs can start to fall out of the index.

The proxy reached the server behind it, but the answer took longer than the proxy was willing to wait.

Common causes

• Slow database queries or long-running requests
• The upstream server is overloaded or unreachable
• A proxy timeout shorter than the work needs — nginx’s proxy_read_timeout defaults to 60 seconds
• DNS or network trouble between the proxy and the origin

How to fix it

• Speed up the slow request, or move it to a background job and return 202
• Raise the proxy timeout only if the work genuinely takes longer
• Check the origin server’s health and resources

Rare today; modern servers accept HTTP/1.1 and usually HTTP/2.

The variant chosen during transparent content negotiation is itself set up to negotiate, creating a loop.

Typically a full disk or an exhausted storage quota on a WebDAV server.

Defined for WebDAV bindings. Some shared-hosting platforms also use 508 when an account exceeds its resource limits.

From the HTTP Extension Framework, an experiment that never caught on — you are unlikely to meet it.

Sent by captive portals on hotel, airport and café Wi-Fi to show that the network — not the website — needs you to log in.

Check the origin’s error logs, crash reports and response header sizes.

Make sure the web server is running and that its firewall allows Cloudflare’s IP ranges.

The origin is overloaded, offline or blocking Cloudflare at the network level.

Often caused by wrong DNS records pointing at an old or incorrect IP address.

Cloudflare waits 100 seconds by default for an HTTP response; move long jobs to background processing.

Check that the origin has a valid certificate installed and supports modern TLS versions and ciphers.

In Full (strict) mode the origin needs a valid, unexpired certificate for the host name — a publicly trusted one or a Cloudflare Origin CA certificate.