Bulk HTTP Status Checker: 25 URLs, Every Redirect Hop

Every page you load arrives with a second, invisible document attached to it: the response headers. They are not part of the HTML, they never appear on screen, and they carry decisions that override almost everything the markup says.

A page can be perfectly written, correctly linked and beautifully rendered, and still be excluded from search because a single header said so. It can be served with the wrong content type and displayed as raw source. It can be cached by an intermediary for a month after you fixed it. It can quietly redirect somewhere you never intended. In all four cases the HTML looks healthy, which is exactly why these problems survive so long — the evidence is somewhere nobody thought to look.

Checking headers is how you separate a content problem from a plumbing problem. It usually takes about a second, and it is the first thing worth doing when a page behaves in a way its source code does not explain.

Why the chain is followed by hand

Your browser follows redirects automatically. So does most tooling. That is the correct default for browsing and the wrong default for diagnosis, because automatic following destroys the thing you came to inspect: you end up looking at the 200 OK at the end of the chain, with no indication that a 302 you never authorised sat in front of it.

This checker switches automatic following off and then walks the chain deliberately, one request at a time. Each hop is recorded before the next one goes out, so a URL that travels 301 → 302 → 200 shows all three in order, each with its own status, its own Location target, its own timing and its own full set of response headers. Nothing collapses into a single final answer.

Before you read a single header, read the number. It tells you which category of problem you have.

Two distinctions inside those ranges do real damage when they are wrong.

301 versus 302. A permanent redirect tells search engines to transfer the old URL's signals to the new one and update their index. A temporary redirect tells them to keep the old URL and treat the new location as a detour. Teams routinely ship a 302 for a permanent move because the framework default happened to be 302, and then wonder why the new URL never inherits anything.

404 versus 410. Both mean the page is not there. 410 Gone states that the absence is deliberate and permanent, and crawlers act on it faster. If you have retired a section on purpose, 410 is the more honest answer.

403 deserves special mention. Some servers reject any client they do not recognise. That is why this tool sends a standard desktop Chrome User-Agent by default rather than announcing itself — an unfamiliar agent gets a 403 on a fair number of hosts, and a 403 that only exists because of who asked is a misleading diagnosis. It is also why the User-Agent is selectable: a 403 that appears only when you ask as Googlebot is not noise, it is the finding.

What crawlers actually get back

Across the sites we monitor for crawler traffic, the share of bot requests answered with a 2xx fell below half in 2026 — around 47% in January and 46.7% by July — while roughly a third of all crawler requests were rejected outright with a 4xx (about 36% across the same period). Redirects made up a rising slice: 13.9% of crawler responses in January 2026, 15.0% by July.

That upward drift is worth sitting with. Every redirect served to a crawler is a request that fetched no content. A handful is unavoidable. A pattern of them, especially on URLs you actively want indexed, is a slow tax on how much of your site gets seen.

A redirect chain is what happens when a redirect points at another redirect. http://example.com sends you to https://example.com, which sends you to https://www.example.com, which sends you to https://www.example.com/. Four requests to serve one page.

Across the sites we audit, chains of two or more hops appear on 24.3% of them (H1 2026) — it is the tenth most common failure our audit engine finds, and the defining issue in the Redirects category, which fails on 24.3% of audited sites overall.

Almost none of these were built on purpose. They accumulate:

• A site adds HTTPS. Rule one: http → https.
• Later it standardises on www. Rule two: non-www → www.
• Later still it normalises trailing slashes. Rule three.
• A migration moves /blog/post to /resources/post. Rule four.

Each rule was correct in isolation, and nobody ever re-tested the combination. The cost is real but undramatic, which is why it persists: every hop is an extra round trip for users, an extra request against crawl budget, and — depending on which search engine and which day you ask — a possible attenuation of the link equity being passed along.

How to find them with this tool

Check the entry URLs, not the destinations. Paste the versions people actually link to — the http:// one, the non-www one, the one with the trailing slash — and let the tool walk each chain for you. The Redirects column is the one to read first: any row above 1 is a chain, and the status badges show you the exact sequence that produced it.

For a list of any size, filter to Redirected and sort your attention by that column. In a typical migration sheet the chains cluster — the same misordered rule set produces the same extra hop across a whole section of the site, so fixing one rule usually clears twenty rows at once.

Security headers are instructions to the browser about how much to trust the connection and the content. They cost a line or two of server configuration and they are, collectively, the most neglected part of the response.

Missing Strict-Transport-Security is the fifth most common individual failure our audit engine finds: 38.6% of audited sites (H1 2026). The Security category as a whole fails on 44.1% of sites.

Why HSTS matters more than it looks

Without HSTS, a visitor who types your domain without a scheme makes their first request over plain HTTP. Your 301 to HTTPS fixes it immediately — but only after that first unencrypted request has already been sent. HSTS closes that window: after the first successful visit, the browser upgrades the URL itself before anything leaves the machine.

The reason it goes missing is mundane. It is not a code change, it lives in server or CDN configuration, and it belongs to nobody in particular. Check for it here, and if it is absent, it is usually a one-line fix that stays fixed.

A missing header cannot be seen — it simply does not appear in the table. It is worth knowing which headers you expect before you look, or you will read a clean-looking result as a passing grade.

This is the category that costs the most traffic per incident, because the symptom is total and the cause is invisible.

X-Robots-Tag

X-Robots-Tag does everything the <meta name="robots"> tag does, but from the header, where no amount of reading the page source will reveal it:

X-Robots-Tag: noindex, nofollow

A page carrying that will be dropped from the index while its HTML remains flawless. The classic origin is a staging or pre-production configuration that shipped to production with everything else. If a URL has disappeared from search and the content looks fine, check this header before you change a word.

Unlike the meta tag, it also applies to non-HTML files — PDFs, images, feeds — which is the only way to control indexing for those at all.

Link: rel="canonical"

Canonicals can be declared in the header as well as in the HTML:

Link: <https://example.com/page>; rel="canonical"

If both exist and disagree, you have a conflict that search engines resolve at their discretion rather than yours. Worth checking whenever a canonical is not behaving as expected.

Content-Type

Wrong content types break rendering in ways that look like content bugs. A page sent as text/plain is displayed as source rather than rendered. A missing charset produces mangled characters in some locales and not others. Neither is visible in the markup, because the markup is fine.

Three headers govern whether a client — browser, CDN or crawler — needs to fetch your page again at all.

• Cache-Control sets the caching rules: max-age in seconds, no-store to forbid caching entirely, private to limit it to the end user's browser. It is the header most likely to be silently rewritten by a CDN placed in front of your origin, which is why it is worth re-checking after any change to that layer.
• ETag is a fingerprint of the response body. If it has not changed, neither has the content.
• Last-Modified states when the resource last changed. Crawlers pair it with If-Modified-Since and skip the download when the answer is "not since then".

The common failure here is Last-Modified that updates on every request — typically because it is generated from the current time rather than the content's actual edit date. Every conditional request then returns a full 200 with the whole body instead of a cheap 304 Not Modified. Nothing breaks, and you spend crawl budget re-downloading pages that never changed.

The results table has one row per URL and three columns worth reading in order.

Status codes shows the whole chain as a sequence of badges, left to right, in the order the requests actually happened. Green is 2xx, blue is 3xx, orange is 4xx, red is 5xx. A single green badge is a clean direct hit. Three badges ending in green is a working page that costs three round trips to reach. Anything ending in orange or red is a URL that does not resolve.

Redirects is the hop count. Sort your attention by it. Zero is ideal, one is normal and correct, two or more is the 24.3% problem above.

Expanding a row gives you the chain in detail: a summary table with each hop's scheme (with an open padlock on any http:// step, which is worth noticing), host, path and timing, followed by the complete response headers from every single hop. Two things to know about how those render:

• Set-Cookie values are redacted. You will see the cookie's name and [redacted] in place of its contents. The tool will not reflect a session token back through a page.
• Nothing is filtered. Custom and vendor headers your stack adds appear alongside the standard ones, because those are frequently the interesting ones when something is misbehaving.

The two limits worth knowing

A crawler User-Agent is a claim, not an identity. When you select Googlebot, we send Googlebot's User-Agent string — from our own infrastructure. Any site that verifies crawlers by reverse DNS lookup will correctly conclude we are not Google, and may answer accordingly. So a difference between the Chrome run and the Googlebot run is a strong signal that something is treating crawlers specially, and worth chasing; it is not proof of what Googlebot receives.

Twenty-five URLs is a spot check. It is the right size for a migration sample, a template sweep or a post-deploy sanity check. It is not a site crawl. When the question is "every URL on the site", that is the free SEO audit.

Two methods worth knowing, because you will not always have a browser tab free.

curl is the fastest route on any machine with a terminal. -I sends a HEAD request and prints only the headers:

curl -I https://example.com

Add -L to follow redirects and print every hop in sequence, which is the closest single-URL equivalent to what this tool does:

curl -sIL https://example.com | grep -E "HTTP/|location:"

Add -A to ask as somebody else — the terminal version of the User-Agent picker:

curl -sIL -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com

Chrome DevTools works without leaving the page. Open DevTools, select the Network tab, reload, click the top request, and read the Response Headers panel. The catch is the one described earlier: the browser follows redirects for you, so on a redirected URL you land on the final response and have to hunt back through the request list for the 301 that started it. Ticking "Preserve log" before you reload makes that hunt considerably easier.

Both are excellent, and both are one URL at a time. This tool exists for the case where you have a list rather than a URL, where you want every hop laid out side by side without writing a loop, and where you want to hand somebody a result they can read.

A status check answers a narrow question very well. When the answer points at something larger:

• Tracing a single redirect chain in isolation → redirect checker
• Identifying the server, CDN or host behind the headers → hosting checker
• Checking what your robots.txt actually allows → robots.txt tester
• Running all 251 rules — headers, redirects, security, performance and the rest — across the whole site → free SEO audit