HTTP Status Code Checker: Bulk URL Status Code Lookup and Redirect Chain Test
Paste up to six URLs and we request each one from outside your network, then follow every redirect hop by hand and report the status code, response time, server and content type at each step.
HTTP status code checker
LiveUp to 6 URLs. We follow up to 8 redirect hops each.
What an HTTP status code checker does
An HTTP status code checker sends a request to a URL and reports the three digit code the server returns, along with every hop in the redirect chain that follows. The code tells you what the server did with the request: 2xx succeeded, 3xx redirected somewhere else, 4xx means the request was wrong, and 5xx means the server failed. The value of checking from outside your own network is that you see what a visitor and a search engine crawler see, including redirect hops your browser hides from you by following them silently.
The reason a dedicated tool beats reloading the page is the chain. Browsers follow redirects silently and show you only the final result, so a URL that quietly passes through three hops looks identical to one that resolves immediately. The checker above stops at every hop and reports it, which is how you find the chains nobody meant to build.
The five classes, in one line each
- 1xx Informational. The request was received and processing continues.
- 2xx Success. The request was received, understood and accepted.
- 3xx Redirection. Further action is needed to complete the request.
- 4xx Client error. The request was malformed, unauthorized or aimed at nothing.
- 5xx Server error. The request was valid and the server failed to handle it.
| What the checker reports | What it is | Why it matters |
|---|---|---|
| Status code | The three digit code on the response status line | The primary answer. 200 is a working page, 301 and 302 are redirects, 404 is missing, 500 is a server fault. Everything else on this page is context for this number. |
| Redirect chain | Every intermediate URL between what you typed and where you landed | The part a browser hides. A URL that looks fine can be three hops deep, and each hop costs a round trip and dilutes the ranking signal passed to the destination. |
| Final URL | Where the chain actually ended | Frequently not the URL anyone expects. Trailing slash rules, www canonicalization and HTTPS upgrades all add hops that nobody deliberately configured. |
| Response time per hop | Milliseconds from request to status line for each hop | A redirect that takes 400 ms is 400 ms before the real page even starts loading. Chains turn into perceived slowness long before anything technically breaks. |
| Server header | What the responding server reports itself as | Tells you whether you reached the origin, a CDN edge or a proxy. A Cloudflare header on a 5xx moves the diagnosis somewhere entirely different. |
| Content type | The media type of the response body | A page returning application/json where you expected text/html usually means an API route is shadowing a page route. |
From Google's own documentation
What each HTTP status code means for Google indexing
Most status code tools stop at telling you the number. The question that actually decides whether a status code costs you traffic is what Google does with it, and Google documents this precisely. The table below is a plain reading of Google Search Central's own page on HTTP status codes and network errors, checked against the source in August 2026.
| Code | Meaning | Effect on indexing | What Google documents |
|---|---|---|---|
| 2xx | 200, 201, 202 | Content goes to the indexing pipeline | Google says the indexing systems may index the content, but indexing is never guaranteed by the status code alone. |
| 301, 308 | Permanent redirect | Strong canonical signal to the target | Googlebot follows the redirect and the indexing pipeline treats the target as the page that should be canonical. 308 is treated as equivalent to 301. |
| 302, 303, 307 | Temporary redirect | Weak signal, source stays indexed | Googlebot still follows it, but the redirect is only a weak signal for the target. The source URL is what continues to appear in search results. |
| 304 | Not Modified | No effect on indexing | Signals the content has not changed. The indexing pipeline may recalculate signals, but the status code itself does not change what is indexed. |
| 4xx | 400, 403, 404, 410 | Not indexed, and removed if already indexed | Google does not index URLs returning 4xx, and URLs already in the index that start returning 4xx are dropped. Newly discovered 404 pages are not processed at all. |
| 429 | Too Many Requests | Treated as a server error | Grouped with 5xx rather than 4xx, so it slows crawling instead of removing the page. |
| 5xx | 500, 502, 503, 504 | Kept for a while, then dropped | Already indexed URLs are preserved in the index but eventually dropped. Google also reduces crawl rate while the errors continue, then increases it again once 2xx responses return. |
10 hops is the documented limit
Googlebot follows up to 10 redirect hops by default. Past that the fetch fails and the URL is treated as unreachable. Almost no site hits the limit, which is why chains hurt quietly rather than loudly: they stay under the ceiling and just cost you speed and signal.
4xx removes, 5xx delays
The distinction that matters during an incident. A 404 gets a page dropped from the index. A 500 gets it preserved for a while, with crawl rate reduced until healthy responses return. If you must fail, failing with a 5xx is the recoverable option.
429 counts as a server error
Despite being a 4xx, Google groups 429 Too Many Requests with the server errors. So aggressive rate limiting slows crawling rather than deindexing pages, which is the better failure mode but still throttles how fast new content gets discovered.
Source: Google Search Central, HTTP status codes and network errors. Re-read August 2026.
301 vs 302 vs 307 vs 308
How to read a redirect chain, and which redirect code to use
The single most useful thing a status checker shows you is the part of the journey your browser hides. Type a URL into a browser and you see where you ended up. Type it into the tool above and you see how many servers it took to get there, how long each one held the request, and which code each of them returned.
| Code | Permanence | Method and body | How Google treats it | Use it for |
|---|---|---|---|---|
| 301 Moved Permanently | Permanent | May be rewritten to GET | Strong signal, target becomes canonical | Domain migrations, URL restructures, HTTP to HTTPS, www canonicalization |
| 302 Found | Temporary | Often rewritten to GET | Weak signal, source stays indexed | Genuinely temporary situations only: A/B tests, short campaigns, geo tests |
| 303 See Other | Temporary | Always becomes GET | Followed like a 302 | After a form POST, to stop a refresh resubmitting the form |
| 307 Temporary Redirect | Temporary | Preserved | Equivalent to 302 | Temporary moves where the method and body must survive, including POST |
| 308 Permanent Redirect | Permanent | Preserved | Equivalent to 301 | Permanent moves where the method and body must survive |
Why chains appear without anyone building them
Nobody sits down and designs a four hop redirect. Chains accumulate one reasonable decision at a time. Somebody adds an HTTPS upgrade rule at the load balancer. Somebody else standardizes on www at the CDN. A third person adds a trailing slash rule in the framework. A fourth migrates a section of the site and adds redirects from the old paths.
Every one of those rules is correct in isolation. Stacked, they mean a request for the old HTTP address of a moved page goes through four servers before it renders anything. The visitor waits for all of them, and the ranking signal from any link pointing at the original URL gets passed along the whole chain rather than straight to the destination.
The fix is not to remove the rules. It is to make the first redirect point at the final destination, so the chain collapses to a single hop while every rule stays in place for anything else that needs it.
What the checker flags automatically
- Chains of two or more redirects, with the hop count and the cumulative time
- Redirect loops, where a URL appears twice in its own chain and can never resolve
- An HTTP to HTTPS upgrade sent as a temporary 302 or 307 rather than a permanent 301 or 308
- A downgrade from HTTPS back to HTTP, which breaks HSTS expectations and leaks the request
- Chains that end on a 4xx, so every link pointing at the first URL leads to a dead end
- Chains that end on a 5xx, which is a server fault rather than a bad request
Status code lookup
HTTP status code list: what each code means and what to do about it
The codes below are the ones that actually turn up in production, grouped by class. The full IANA registry has more, but a list of every assigned code is less useful than knowing what to do when you see the twenty or so that appear in real logs.
2xx Success
| Code | Reason phrase | What it means in practice |
|---|---|---|
| 200 | OK | The request worked and the body is the requested resource. This is what a healthy page returns. |
| 201 | Created | A POST or PUT created a resource. Common on API endpoints, not on pages. |
| 204 | No Content | Success with an empty body. Used by APIs for deletes and by tracking beacons. |
| 206 | Partial Content | A range request succeeded. Normal for video streaming and resumable downloads. |
3xx Redirection
| Code | Reason phrase | What it means in practice |
|---|---|---|
| 301 | Moved Permanently | The resource has a new permanent home. The method may be rewritten to GET by older clients, which is why 308 exists. |
| 302 | Found | A temporary redirect. The original URL stays authoritative, so this is the wrong code for a permanent move. |
| 303 | See Other | Redirect the client to a different resource with GET, typically after a form POST. |
| 304 | Not Modified | The cached copy is still current. Sent in response to a conditional request, with no body. |
| 307 | Temporary Redirect | Like 302 but the HTTP method and body are guaranteed to be preserved. |
| 308 | Permanent Redirect | Like 301 but the method and body are guaranteed to be preserved. The modern choice for permanent moves. |
4xx Client error
| Code | Reason phrase | What it means in practice |
|---|---|---|
| 400 | Bad Request | The server could not parse the request. Malformed syntax, an oversized header or an invalid parameter. |
| 401 | Unauthorized | Authentication is required and either missing or invalid. The response should name the accepted scheme. |
| 403 | Forbidden | The server understood the request and refuses to fulfil it. Often a WAF, a bot rule or a file permission rather than a login problem. |
| 404 | Not Found | No resource at that URL. Normal for genuinely removed pages, a problem when it appears on URLs that still have links pointing at them. |
| 405 | Method Not Allowed | The URL exists but not for that verb. A HEAD request against a route that only answers GET is a common false alarm. |
| 410 | Gone | Deliberately and permanently removed. A stronger signal than 404 that the page is never coming back. |
| 429 | Too Many Requests | Rate limited. Check the Retry-After header before retrying, and expect crawlers to back off. |
| 451 | Unavailable For Legal Reasons | Blocked for legal reasons, typically geographic or takedown related. |
5xx Server error
| Code | Reason phrase | What it means in practice |
|---|---|---|
| 500 | Internal Server Error | An unhandled exception in the application. The generic catch all, so the real cause is only in the server logs. |
| 502 | Bad Gateway | A proxy got an invalid response from upstream. Usually the application process is down or crashed behind nginx. |
| 503 | Service Unavailable | Temporarily unable to handle the request. Overload or deliberate maintenance. The only 5xx that is sometimes intentional. |
| 504 | Gateway Timeout | A proxy waited for upstream and gave up. The application is running but too slow to answer in time. |
| 521 | Web Server Is Down (Cloudflare) | The origin actively refused the connection. A firewall REJECT rule or a stopped web server. |
| 522 | Connection Timed Out (Cloudflare) | The origin never answered the connection attempt at all. A DROP rule or an overloaded server. |
The Cloudflare 5xx codes are worth separating from the standard ones because they describe where the failure happened rather than what it was. A 502 bad gateway comes from your own proxy, while a 521 or 522 comes from Cloudflare failing to reach your origin at all. The difference between a refused connection and a dropped one is the difference between a firewall REJECT rule and a DROP rule.
Four methods
How to check HTTP status codes, and what each method misses
These four methods do not always agree, and the disagreement is usually the most informative part. Your browser sends your cookies and your session. A command line tool sends neither. An external checker adds a different network path and a different user agent, which is exactly what surfaces firewall rules you did not know were there.
| Method | How | What it is good for, and what it misses |
|---|---|---|
| This checker | Paste up to six URLs above | Sees the full chain from outside your network, in one pass, for several URLs at once. Shows you the hops your browser follows silently. It is still a single moment in time, and it assumes the site answers at all: if you are not sure it is even reachable, the website down checker tests DNS, the connection and the certificate first. |
| Browser DevTools | F12, Network tab, reload, untick Preserve log off | Shows the real request your browser made with every header. Reflects your cookies, your session and your extensions, so it is not what an anonymous visitor gets. |
| curl on the command line | curl -sSIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com | The most precise view and the only one that scripts cleanly. The -I flag sends HEAD, which some servers answer differently from GET. |
| Continuous monitoring | A scheduled check that alerts on the status code | The only method that catches a status code that changes at 3am. Everything above requires you to be looking at the moment it breaks. |
Print the whole chain with curl
curl -sIL -o /dev/null \
-w "%{http_code} %{url_effective}\n" \
https://example.com
The -L flag follows redirects and -w prints one line per hop, so you get the chain and the final URL without any of the response bodies. Note that -I sends HEAD, and a few servers answer HEAD differently from GET.
Check a list of URLs from a file
while read -r url; do
printf '%s ' "$url"
curl -sIL -o /dev/null -w '%{http_code}\n' "$url"
done < urls.txt
The DIY version of bulk checking. Useful in CI after a migration, where you want the build to fail if any URL from the old sitemap stops resolving to a 200.
Every method on this page assumes the server answers. When it does not, a status code checker has nothing to report, because there is no status line to read. That is a different question with a different tool: the website down checker resolves the domain against four public DNS resolvers, opens the connection, verifies the certificate and only then reads the status code, so it can tell an expired domain apart from a crashed application instead of reporting both as no response.
Symptom to cause
Six results that confuse people, and what each one actually means
A page returns 200 in the browser but 404 to the checker
You are logged in. Session cookies, preview modes and staging cookies routinely expose pages that anonymous visitors and crawlers cannot see. The checker sends no cookies, which is exactly why it disagrees with you.
A URL returns 403 only to tools
A firewall or bot rule is matching the user agent. Cloudflare, AWS WAF and most managed hosts ship rules that challenge non-browser clients. The page is fine, the rule is the problem, and it may also be blocking search crawlers.
The chain is four hops long and nobody built it that way
Chains accumulate. HTTP to HTTPS is one hop, non-www to www is another, a trailing slash rule is a third, and an old campaign redirect from two years ago is the fourth. Each was added by a different person solving a different problem.
A 302 where a 301 was intended
The default in most frameworks and load balancers is 302, so a permanent move ships as temporary unless someone changes it. Google keeps the old URL indexed and the new one does not inherit the signal.
Intermittent 502 or 504
The application process is restarting, running out of workers or hitting a slow dependency. These are the codes a one-off check almost never catches, because they are fine when you look and broken between checks.
200 with the wrong content type
An API route is shadowing a page route, or a rewrite rule is catching more than it should. The status code is healthy and the page is still broken for a visitor.
The limit of a one-off check
What a status code checker cannot tell you
The tool at the top of this page tells you what six URLs returned at one moment. That is the right shape for confirming a fix, auditing a migration or settling an argument about whether a redirect is a 301. It is the wrong shape for the failure that actually costs money.
Status codes are not stable properties of a URL. They change when a deploy goes out, when a worker pool exhausts itself, when a database connection limit is reached, or when a certificate expires at 2am on a Sunday. The 500 you care about is the one that lasted eleven minutes while nobody was looking, and every manual check you run will faithfully report 200.
The second gap is coverage. A checker tests the URLs you thought to paste in. Outages happen on the checkout endpoint, the login callback and the API route that one integration depends on, which are rarely the URLs anyone tests by hand.
What continuous checking adds
- The same request every 30 seconds from six regions, so a regional failure is visible as a regional failure
- An alert the moment the status code stops matching what you expect, rather than when a customer emails
- Keyword checks, so a page that returns 200 while rendering an error message still counts as down
- Response time recorded on every check, which is what turns a slow creep into a graph instead of a surprise
- SSL expiry, DNS, TCP port and cron heartbeat checks on the same alert path
Questions
HTTP status code questions, answered
How do I check the HTTP status code of a URL?
Paste the URL into the checker at the top of this page and it will request it and report the status code along with every redirect hop. You can also open DevTools with F12, use the Network tab and reload, or run curl -I https://example.com on the command line. Checking from outside your own browser matters because your cookies and session can change what the server returns.
What is an HTTP status code?
An HTTP status code is a three digit number a server returns on the first line of every response, telling the client what happened to the request. The first digit sets the class: 1xx is informational, 2xx succeeded, 3xx means look somewhere else, 4xx means the request was wrong, and 5xx means the server failed while handling a valid request.
How do I check status codes for multiple URLs at once?
Paste one URL per line into the box above and the checker requests up to six of them in a single pass, showing the full redirect chain for each. Bulk checking is the practical way to audit a migration or a sitemap, because the problem is almost never the one URL you thought to test.
What is a redirect chain and why is it bad?
A redirect chain is any sequence where one URL redirects to a second which redirects to a third. Each hop adds a full round trip before the visitor sees anything, and search engines pass ranking signals less efficiently through a long chain. Googlebot follows up to 10 hops by default, so a chain does not have to be broken to be costly. The fix is to point the first URL straight at the last one.
What is the difference between a 301 and a 302 redirect?
A 301 says the move is permanent and a 302 says it is temporary. Google treats a 301 as a strong signal that the target should become the canonical URL, while a 302 is only a weak signal and the original URL stays in the index. Use 301 or 308 for migrations, HTTPS upgrades and restructures, and reserve 302 for changes you genuinely intend to reverse.
How many redirects will Google follow?
Googlebot follows up to 10 redirect hops by default, according to Google Search Central. Anything beyond that is treated as a failure to fetch. That headroom is not a reason to allow long chains: every hop still costs the visitor a round trip and weakens the signal reaching the destination.
What does a 404 status code mean for SEO?
Google does not index URLs that return 404, and URLs already in the index that start returning 404 are removed from it. That is correct behavior for pages you deliberately deleted. It is a problem when a 404 appears on a URL that still has internal links or backlinks pointing at it, because the value of those links goes nowhere.
What is the difference between 404 and 410?
Both mean the resource is not there. A 404 says only that nothing was found at that URL, which leaves open the possibility that it returns. A 410 says the page was deliberately and permanently removed. Use 410 when you want to be unambiguous that a page is never coming back.
Why does my site return 403 to a checker but work in my browser?
A firewall or bot management rule is almost certainly matching on the user agent or the absence of browser fingerprints. Cloudflare, AWS WAF and most managed hosts ship rules that challenge non-browser clients by default. Worth investigating rather than ignoring, because rules broad enough to block a status checker sometimes block search crawlers too.
What is the difference between a 502 and a 504?
Both come from a proxy in front of your application. A 502 Bad Gateway means the upstream returned something invalid or nothing at all, usually because the process is down or crashed. A 504 Gateway Timeout means the upstream is alive but did not answer within the timeout, so it points at slowness rather than a crash.
Does a 5xx error remove my pages from Google?
Not immediately. Google preserves already indexed URLs returning 5xx for a while and eventually drops them if the errors persist. Google also decreases its crawl rate while the errors continue, and increases it again once 2xx responses resume. Short outages are survivable, sustained ones are not.
Is checking status codes once enough?
No, and the codes that matter most are exactly the ones a one-off check misses. A 500 that appears for eleven minutes during a deploy, a 502 while workers restart, or a certificate expiry at 2am all return a perfectly healthy 200 whenever you happen to look. Continuous checking on a fixed interval is what turns those into an alert rather than a support ticket.
Keep reading
Related tools and guides
Cron expression generator
Build a schedule, read any cron expression in plain English, and see its next run times.
SSL certificate checker
Read the live certificate on any host: expiry, issuer, covered names and chain.
Uptime calculator
Turn any SLA percentage into the downtime it allows per day, month and year.
503 service unavailable
The six real causes, and how 503 differs from 502 and 504.
The status code that costs you money is the one nobody checked
Uptimehub requests your URLs every 30 seconds from six global regions and alerts you the moment the status code changes, alongside SSL expiry, DNS and response time. From $9 a month, priced per monitor and never per seat.