1. Check a redirect chain
Get this from your browser's DevTools Network panel (the Status and Name columns, in order), or by running curl -sI against each hop by hand.
2. Hops parsed
| # | Status | URL |
|---|
Findings
Prefer a CLI, or want this as a CI gate?
The CLI walks the real chain over HTTP itself, one hop at a time — no cross-origin restriction, because it isn't a browser, and it only reads each response's headers, never the body:
node check.mjs https://example.com/old-page --json node check.mjs https://example.com/old-page --max-hops 5 node check.mjs https://example.com/old-page --recommended-max-hops 2
Get check.mjs, fetch-chain.mjs, and engine.mjs from the repo — plain Node 18+, nothing to install. It only ever talks to the URL you give it and the Location header that URL's own server sends back — nothing goes through this site. Exit code 1 when a danger-severity finding is produced or the chain could not be completed.
What's checked
| Check | What it flags | Severity |
|---|---|---|
| Redirect loop | A URL earlier in the chain is visited again later in it | Danger |
| Chain too long | More hops than recommended (default: 1) before landing | Notice |
| Protocol downgrade | A hop redirects from HTTPS back to HTTP | Danger |
| Temporary code for a permanent move | A scheme/www normalization redirect uses 302/303/307 instead of 301/308 | Notice |
| Chain ends in an error | The final hop is a 4xx or 5xx response | Danger |
| Chain incomplete | The last hop given is itself still a redirect, with nowhere further to go | Danger |
More: why redirect chains matter, and the most common ways they break. See also: how this differs from httpstatus.io's free redirect checker, and what checking a chain by hand with curl or DevTools misses.
Common questions
Why is a redirect chain longer than one hop a problem?
Google's own Search Central documentation on redirects advises keeping a redirect chain as short as possible — ideally a single hop — because search engines may not follow a very long chain at all, and every extra hop adds a full network round-trip of latency for every visitor, not just the first crawl. A chain that grows over years of site migrations without ever being cleaned up is the most common way this happens.
Why does a temporary redirect matter for a permanent site move?
A 301 or 308 tells a search engine the move is permanent, so it should consolidate ranking signal onto the new URL and eventually stop checking the old one. A 302, 303, or 307 says the opposite: "this is temporary, keep the old URL as canonical and check back later." Using a temporary code for what is actually a permanent scheme or www change (the same page, just upgraded to HTTPS or normalized to a canonical host) is one of the most common redirect mistakes and slows down exactly the ranking consolidation the move was meant to achieve.
Why can't this page follow the redirect chain itself?
A browser tab's fetch() to a different origin, by default, follows the whole chain silently and hides every intermediate hop and status code — exactly the information this tool needs. Asking for redirect: "manual" instead makes the response opaque, so JavaScript cannot read the status or the Location header of even the first hop. Either way, a page running in your browser cannot reliably inspect a cross-origin redirect chain. The zero-dependency CLI has no such restriction because it isn't a browser tab — it makes one real HTTP request per hop and reads each response directly.
Is this a full technical-SEO audit?
No. It checks specific, mechanically verifiable properties of the redirect chain you provide or the CLI fetches — loop detection, chain length, protocol downgrades, temporary-vs-permanent status codes, and the final destination's own status. It is not a crawl of your whole site and not a ranking guarantee.