HTTP Status Code Checker Guide: Read the Number Behind Every Page Load

Every web response carries a three-digit status code, and that number is the server's verdict on the request. Visitors see a page, or an error message, but the code underneath tells the real story: whether the request succeeded, whether it was redirected, whether the client asked for something wrong, or whether the server itself failed. Learning to read these codes turns vague reports like "the page is broken" into precise ones like "the page returns 500", which is the difference between a guess and a diagnosis. The HTTP Status Code Checker interprets a code or a list of codes you paste, explaining each one in plain language and grouping it by family. It works on pasted codes: it explains what a code means, it does not fetch your live site, and it cannot by itself tell you why a server returned that code.

The codes are grouped by their first digit, and the grouping is the fastest way to read them. Codes starting with 2 mean success: 200 means the request succeeded and the resource is returned. Codes starting with 3 mean redirection: the resource has moved, and the response says where to go next, with 301 for a permanent move and 302 for a temporary one. Codes starting with 4 mean the client made an error: 400 for a bad request, 401 for unauthenticated, 403 for forbidden, and the famous 404 for not found. Codes starting with 5 mean the server failed: 500 for a general server error, 502 for a bad gateway, 503 for a service unavailable, and 504 for a gateway timeout. There are also less common codes worth knowing: 410 means gone permanently, which is stronger than 404 because it tells search engines to drop the page, and 429 means too many requests, which is a rate-limit signal rather than a fault.

Reading a code in context

A code alone rarely tells the whole story; the context around it matters. A 404 on a page you just deleted is expected, while a 404 on a page linked from your own homepage is a broken link. A 301 on an old address is healthy, while a chain of three 301s in a row is wasteful and should be shortened to a single hop. A 500 on one page after a deployment points at the new code, while a 500 on every page points at the server itself. A 403 on an admin page for an anonymous visitor is correct behaviour, while a 403 on a public page for everyone is a permissions fault. Always ask three questions: which address returned the code, who was asking, and what changed recently. The checker explains the code; those three questions explain the incident.

Worked example

Take a sample site crawl, with values clearly labelled as an illustration. The crawl checks 500 addresses and returns: 420 with 200, 50 with 301, 20 with 404, 5 with 500, and 5 with other codes. The success rate is 420 divided by 500, which is 0.84, or 84 percent. The error rate, counting 404 and 500 together, is 25 divided by 500, which is 0.05, or 5 percent. The redirect rate is 50 divided by 500, which is 0.10, or 10 percent. Now prioritise: the 5 server errors affect every visitor to those pages and indicate a server or application fault, so they come first despite being only 1 percent of the total, since 5 divided by 500 is 0.01. The 20 missing pages come next, because they break links and waste search visibility. The 50 redirects come last, unless inspection shows they form chains: if each of those 50 redirects points to another redirect, the crawl actually contains 100 hops for 50 destinations, doubling the redirect work, and shortening them to direct hops saves one round trip per affected page. The arithmetic turns a list of codes into a work order: server errors first, missing pages second, redirect hygiene third.

Mistakes to avoid

The first mistake is treating every non-200 code as a fault: redirects, authentication challenges, and rate limits are normal behaviour in the right context. The second is treating a 404 as a problem to hide by redirecting everything to the homepage, which confuses visitors and search engines alike; a proper 404 page, or a 410 for permanently removed content, is more honest and more useful. The third is ignoring 500 errors because they are intermittent: an intermittent 500 is often a real fault that appears under load, and it deserves investigation, not dismissal. The fourth is reading a code from a cached response, or from a different address than the one reported, and fixing the wrong page. The fifth is pasting a code list containing private addresses or tokens into a checker without redacting them; codes alone are enough, and private addresses should be stripped.

Putting it into practice

Keep a short reference for the codes you meet most: 200 success, 301 permanent redirect, 302 temporary redirect, 400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 410 gone, 429 too many requests, 500 server error, 502 bad gateway, 503 unavailable, 504 timeout. When a page misbehaves, note its code before anything else, then check the address, the visitor's state, and recent changes. For site maintenance, crawl the site periodically, fix 500s first, then 404s on linked pages, then redirect chains. For related checks, the HTTP Headers Checker reads the headers that carry the status line, the Htaccess Redirect Generator writes the rules that produce clean redirects, and the CORS Checker covers cross-origin failures that often surface as confusing codes. The companion guide on Fix Redirect Chains Loops explains the redirect side in depth.

Key points

• Status codes are three-digit numbers grouped by their first digit: 2xx success, 3xx redirect, 4xx client error, 5xx server error
• A 404 means the resource was not found, while a 410 means it is gone permanently
• Redirect chains waste time and signal, so old addresses should point directly at their final destination
• A checker interprets pasted codes, it does not fetch a live site or diagnose the cause of an error

In short: the first digit tells you the family, the full code tells you the verdict, and the context tells you whether it is a fault. Note the code first, fix server errors before missing pages, and shorten redirect chains to single direct hops.