HTTP Status Codes: A Complete Guide to Every Response Code

Every HTTP response starts with a three-digit number, and that number is the server telling you, in the shortest possible form, what happened to your request. Most of the time you never see it: the page loads and the browser moves on. The number only becomes visible when something is wrong, which is exactly when you need to know what it means.

Status codes are not just diagnostics, though. They are instructions. A 301 tells a search engine to move its index entry permanently; a 429 tells a client exactly how to back off; a 503 tells a crawler to come back later instead of dropping your page. Returning the wrong code is one of the quietest ways to lose traffic, because nothing visibly breaks. This guide walks through every class, the codes you will actually meet, and how to check what a URL really returns.

Why Status Codes Matter

Four audiences read your status codes, and each one acts on them differently:

• Browsers. They decide whether to follow a redirect, whether to re-use a cached copy, and whether to re-submit a form body.
• Search engines. A code decides whether a URL is indexed, merged with another, retried later, or dropped. Serving a friendly "not found" page with a 200 is the classic mistake here: the crawler is told the page exists and keeps it in the index.
• API clients. Well-written clients branch on the code. A 429 or 503 is worth retrying; a 400 never is, because retrying a malformed request just produces the same error.
• Your own monitoring. Error rates and alerts are almost always built on status codes, so a service that returns 200 with an error in the body is invisible to its own dashboards.

The Five Classes

The first digit tells you who is responsible and what to do next. If you remember nothing else, remember this table.

The 4xx and 5xx split is the one that matters most in practice, because it answers the only question that counts during an incident: is this mine to fix, or theirs?

The Codes You Will Actually Meet

There are dozens of registered codes, but a working day involves maybe fifteen. The success codes are the simplest. 200 OK is the ordinary answer. 201 Created is the correct reply to a POST that made something, and it should carry a Location header pointing at the new resource. 204 No Content says the request succeeded and there is deliberately nothing to send back, which is the right answer to a DELETE. 206 Partial Content is what makes video seeking and resumable downloads work.

Redirects: 301, 302, 307 and 308

Redirects cause more SEO damage than any other class, almost always because the permanent and temporary forms get swapped.

• 301 Moved Permanently — the URL has changed for good. Search engines transfer ranking signals to the new address and eventually replace the old one in their index. Use it for domain migrations, HTTP to HTTPS, and removing or adding www.
• 302 Found — temporary. The old URL stays indexed because you have said it is coming back. Use it for A/B tests, short maintenance windows and geo-routing you intend to reverse.
• 307 Temporary Redirect — like 302, but the method and body are guaranteed to be preserved. A POST redirected with 307 arrives as a POST; historically some clients turned a redirected POST into a GET.
• 308 Permanent Redirect — the permanent counterpart of 307: same caching semantics as 301, with the method preserved.
• 304 Not Modified — not really a redirect. It answers a conditional request and means "your cached copy is still good", which is why a well-configured site transfers far less data than its page weight suggests.

Two rules: never chain redirects where one hop would do, because each hop costs latency and crawl budget, and never redirect every missing page to your homepage. That second one looks tidy and tells both users and crawlers something false.

Client Errors: 400, 401, 403, 404 and 429

The 4xx family says the request itself was the problem. The distinctions are worth getting right, because clients behave differently on each.

• 400 Bad Request — malformed syntax: broken JSON, a missing required field, a parameter that cannot be parsed. Never retryable as sent.
• 401 Unauthorized — misnamed; it means unauthenticated. No credentials, or credentials the server could not verify. It should include a WWW-Authenticate header.
• 403 Forbidden — the server knows who you are and you still may not do this. Re-authenticating will not help.
• 404 Not Found — nothing exists at this URL. The server does not say whether it ever did.
• 405 Method Not Allowed — the URL exists but not for this verb. Include an Allow header listing the ones that work.
• 409 Conflict — the request collides with the current state, such as a duplicate key or a stale version.
• 410 Gone — the resource existed and was deliberately removed. Search engines drop a 410 faster than a 404, so it is the better choice when you have retired content on purpose.
• 422 Unprocessable Content — the syntax parsed but the values fail validation. Useful when you want to separate "I cannot read this" from "I read it and it is wrong".
• 429 Too Many Requests — you have exceeded a rate limit. Always pair it with a Retry-After header; without one, clients retry immediately and make the overload worse.

Server Errors: 500, 502, 503 and 504

A 5xx means your request was reasonable and the server failed anyway. The four common ones point at different layers, which makes them genuinely useful during an incident.

• 500 Internal Server Error — an unhandled exception in the application. The generic catch-all, and the one to look for in your logs first.
• 502 Bad Gateway — a proxy or load balancer got an invalid or empty response from upstream. Usually the application behind the proxy crashed or was not listening.
• 503 Service Unavailable — the server is overloaded or in maintenance. This is the one code in the family you should return deliberately, with a Retry-After header, during planned downtime: crawlers keep the page and come back.
• 504 Gateway Timeout — the proxy waited for upstream and gave up. Points at a slow dependency rather than a crash.

During an outage, the difference between 502 and 504 tells you whether your application died or merely got slow, which is often the fastest clue available.

Status Codes and SEO

Search engines treat the status code as the authoritative statement about a URL, and they trust it over anything in the page body. Four consequences follow:

1. Soft 404s waste crawl budget. A "page not found" message served with 200 keeps a dead URL indexed and competing with your real pages. Return a real 404 or 410.
2. Use 301 for permanent moves. A 302 on a genuine move leaves the old URL indexed and splits signals between two addresses.
3. Keep redirect chains short. Every hop adds latency and crawlers follow only a limited number before giving up. Point the old URL directly at the final destination.
4. Return 503 during maintenance. A 503 with Retry-After tells a crawler to come back. A timeout or a 500 looks like a broken site.

Redirects also interact with HTTPS. If your http:// to https:// redirect is in place but the certificate is invalid or expired, visitors get a browser warning before the redirect matters, so it is worth confirming the certificate with the SSL Certificate Checker at the same time.

How to Check a Status Code

Your browser hides the code on a successful load, so you have to ask for it explicitly. Three reliable ways:

1. The browser's network panel. Open developer tools, reload, and read the Status column. This shows the full redirect chain, which a single number cannot.
2. curl -I https://example.com. A HEAD request prints the status line and headers without downloading the body. Add -L to follow redirects and see each hop.
3. A reference you can search. When you have the number and need the meaning, obligations and typical causes, our HTTP Status Codes reference lists every code with what to do about it.

Two things to check beyond the number itself. First, test the exact URL a user would hit, including or excluding the trailing slash, since those frequently resolve differently. Second, if the response is a 429, read the Retry-After value and work out whether your client's backoff actually respects it; the Rate Limit Calculator turns a limit into concrete request intervals.

Common Mistakes to Avoid

• Returning 200 with an error in the body. Monitoring, caches, crawlers and clients all read the code, not your JSON. This is the single most consequential mistake in the list.
• Using 302 for a permanent move. Ranking signals stay on the old URL, sometimes for months.
• Redirecting all 404s to the homepage. It hides broken links from you and produces soft 404s for crawlers.
• 403 where 401 belongs. A client that gets 403 will not try to authenticate, because 403 says authentication is not the issue.
• 429 with no Retry-After. Clients then guess, usually by retrying at once, which is precisely the behaviour the limit exists to prevent.
• Letting maintenance return a timeout. Return 503 with Retry-After so you keep your index entries.
• Long redirect chains after a migration. Each migration adds a hop; collapse them to one when you next touch the rules.

Check Your Own Status Codes

Status codes are the cheapest diagnostic on the web: one number, no authentication, and an unambiguous answer about whether a URL works, moved, or failed. Start by checking what your own important pages return, confirm that your redirects are permanent where they should be and temporary where they should be, and make sure every error path returns a code that matches what actually happened.

Related tools and guides:

• HTTP Status Codes - searchable reference for every response code.
• Rate Limit Calculator - turn a limit into safe request intervals and a Retry-After.
• DNS Lookup - confirm a domain resolves before you debug its responses.
• SSL Certificate Checker - verify the certificate behind your HTTPS redirect.
• 301 vs 302 Redirects: Which to Use and What SEO Sees - which redirect to use and what each one does to your rankings.
• 404 vs 410: What Each One Tells Google About a Dead Page - what each code tells Google about a page you have deleted.

Frequently Asked Questions