HTTP Status Code Explainer
Type any HTTP status code to see its family, what it does to browsers and crawlers, and the SEO angle, with a reference table and a live URL check.
This HTTP status code explainer tells you what a code actually means, not the dry spec wording, but what it does to a browser, a crawler and your SEO. Type 200, 301, 304, 404, 429, 503 or any of more than thirty built-in codes and read the family it belongs to, the typical use, the client behavior, the cache reading and the fix checklist, all in plain English. Quick buttons jump to the codes that bite most often. Drop in a live URL and the live check follows the real response path: it pulls the final status, the first-response headers and every redirect hop, then surfaces the code you are genuinely dealing with, because the first hit and the final answer often disagree. A practical reference table covers the whole 1xx to 5xx range so you can stop guessing and copy a clean status report.
100% in your browser. Nothing you type ever leaves this page.
HTTP code reference with live URL context
Type in a status code. I'll tell you what it actually means. Not the dry spec wording, but what it actually does to a browser or a crawler. And to your weekend, when it surfaces in a log at the wrong moment. You get the family it belongs to and the SEO angle. Hand me a live URL on top of that and I'll chase the real response path, then pull out the code you're genuinely dealing with.
The live check grabs the final status, the first-response headers and every redirect hop on the way there. The code is never the whole story though. Your method, your cache rules, auth, bot filtering, whatever the app was trying to do, any of it can flip the diagnosis. Read it with that in mind.
Why HTTP status codes matter
An HTTP status code is the three-digit number a server returns first, and it decides everything that happens next. The browser reads it and then paints the page, or follows a redirect, or pulls a copy out of cache. Maybe it throws up a login box, maybe an error. Or it just sits there waiting for the service to come back. And browsers are only the start of it. Crawlers, your API clients, the uptime monitor that texts you at three in the morning, every log line you will ever grep, they all hang on that first number.
Where people go wrong is treating the code as the verdict. It is not. A 404 is exactly right for a URL that never existed. It is a small disaster when your own menu still links to it. A 301 is great for a genuine permanent move. Leave every internal link pointing at the old address, though, and it turns into dead weight that sends everyone the long way round. A 503 tells the truth about maintenance far better than some cheerful 200 page that is secretly broken. But throw 5xx over and over and you are not asking a status-code question anymore. That is an emergency. So start with the code, sure. Then ask what this URL was even supposed to do.
The families are the first map
Here is the trick worth leaning on. Do not memorize the whole registry. Just learn the first digit. The 1xx codes are protocol small talk between client and server, and honestly you can mostly forget they exist. 2xx means the request landed in some shape or form. 3xx is the server saying not here, go look over there, whether that is another address or the copy you already have in cache. 4xx is the server telling you the request was wrong, or that you were not allowed. And 5xx is the server admitting it understood you fine and then fell over on its own. Once that first digit clicks, the rest stops being scary.
- 2xx does not prove the page is any good. It just means it is the family content is even allowed to show up in.
- 3xx is all about intent: a real permanent move, temporary routing, a cache check, some path you set up on purpose.
- 4xx usually points back at the URL itself: access, login, the wrong method, a quota, a malformed request.
- 5xx drags your attention straight to reliability: upstreams, app logs, and the big question of whether the thing recovers on its own.
Status codes in SEO and site operations
This is the spot where the SEO crowd and the server crowd end up arguing, and the status code usually settles it. Your money pages want a clean public response, with signals that actually agree with each other. Redirect an old URL only when there is something real to send people to. Otherwise leave it. Content that is genuinely gone is allowed to stay gone, and saying so honestly beats pretending. A temporary outage should read as a temporary outage, not get papered over with a smiling 200. And your internal links and sitemaps should point straight at the destination you actually want, not condemn crawlers to rediscover the same pointless redirect every single time they come by. On WordPress specifically, re-check status codes after anything that touches the plumbing: permalink edits, migrations, a new cache plugin, security rules, a CDN swap, password protection, maintenance mode, sitemap changes, the lot.
The routine to run every time
- Start with the exact URL someone flagged, the one from the visitor, the log, the crawler or the monitor, not the one you think they meant.
- Pull apart the first response and the final one after redirects. They lie to you separately.
- Read the family first, then the specific code, then ask what job the page had in the first place.
- Wherever the response disagrees with the intent, go fix it: internal links, sitemap rows, redirect rules, or the reliability problem underneath. Then hit the URL again to confirm.
Frequently asked questions
Is a 200 status code always good for SEO?
No. All a 200 tells you is that the request went through. The page behind it can still be a duplicate, thin as paper, sitting under a noindex, canonicalized off to somewhere else, or just plain useless to whoever landed on it. A green light on the request says nothing about the content behind it.
Is a 404 status code always bad?
Not at all. A URL that is genuinely missing should return 404. That is the honest answer. It only turns into a problem when important links, or your sitemap, or a path people actually follow still march them straight into it.
What is the difference between a 301 and a 302 redirect?
A 301 says this moved for good, and search engines treat it that way, so ranking signals flow over to the new URL. A 302 says just for now, so the original keeps its value and nothing gets handed across. Pick the wrong one during a migration and, weeks on, you will be staring at a traffic chart wondering where your rankings went.
What is the difference between a 401 and a 403 response?
A 401 means the server does not know who you are yet, so go log in. A 403 means it knows exactly who you are and still will not let you in. Logging in fixes the first. It does nothing for the second.
Is a 304 Not Modified response an error?
No. A 304 Not Modified is a success. It is the server telling the browser the cached copy is still good, which saves a whole download. The client already has a good copy stored, asks whether it is still current, and the server says yes, nothing changed, use what you have got.