The usual way to look at a redirect chain is curl -sI -L against the URL, or opening DevTools' Network panel and reading the Status and Name columns row by row. Both show you the hops. Neither one tells you whether any of what you're looking at is actually wrong -- a loop, a chain that's grown too long, a downgrade back to HTTP, or a permanent move that used a temporary status code. That reading is still yours, by eye, on every URL, every time.
Checking by hand costs nothing and needs no tool beyond what's already on your machine or in your browser. curl -sI -L (or curl -sI run once per hop, without -L, to see each Location header) and DevTools' Network panel both surface the real chain. For a one-off look at a URL you already suspect is fine, that's often enough.
This checker takes the same kind of hop data -- pasted from DevTools, or fetched for you by the CLI -- and runs it against five named checks instead of leaving the reading to you: a redirect loop, a chain longer than recommended, an HTTPS-to-HTTP downgrade, a temporary status code used for what looks like a permanent move, and a chain that dead-ends in an error. It states which pattern was found and why it matters, and the CLI exits non-zero so it can fail a build instead of waiting for someone to notice.
| Question | Where to answer it |
|---|---|
| I just want to see the raw hops for one URL, right now. | Either one. curl -sI -L or DevTools is the faster path for a single ad-hoc look. |
| Does this chain loop back on itself? | This checker. A loop is easy to miss by eye once a chain runs past two or three hops. |
| Is this chain longer than the single hop search engines recommend? | This checker. Neither curl nor DevTools flags "one hop too many" -- there's no visual cue for it in either tool's output. |
| Does any hop quietly drop from HTTPS back to HTTP? | This checker names the exact hop. In a long DevTools list it's one row among many, easy to scroll past. |
| Did a same-path scheme/www move use 302/303/307 instead of 301/308? | This checker. Telling a temporary code apart from a permanent one, and knowing that distinction matters for ranking-signal consolidation, is a judgment call by-hand checking leaves entirely to you. |
| I want this checked automatically on every build, with nothing sent to a third party. | This checker's CLI -- node check.mjs <url> runs from your own machine and exits non-zero on a finding, wireable into any CI as an ordinary step. |
It shows you the hops, which is the raw material this tool also needs -- but curl -L follows the chain silently by default and prints only the final response unless you add -v or drop -L and re-run it once per hop, and DevTools' Network panel requires you to read the Status and Location value of every row yourself. Neither tool tells you whether any of what you're looking at is actually a problem; that reading is left to you, and it has to be redone by eye on every URL you check.
Five specific patterns this tool names explicitly: a redirect loop (an earlier URL in the chain reappears later in it -- easy to miss by eye once a chain is more than two or three hops), a chain longer than the recommended single hop, an HTTPS-to-HTTP downgrade buried in the middle of an otherwise-fine chain, a same-path scheme or www normalization that used a temporary 302/303/307 instead of a permanent 301/308, and a chain that ends in a 4xx/5xx error or is still redirecting when the data runs out. Curl and DevTools both show you the status codes; neither one tells you which combination of them is wrong.
A loop only shows up as a URL that was already visited reappearing later in the list -- trivial to spot in a three-hop chain, and easy to miss once you're scrolling through eight or ten DevTools rows across an old migration nobody has cleaned up. Chain length has the same problem in reverse: there is no visual cue in curl's or DevTools' output for "this is one hop more than recommended," so the judgment call is silent and easy to skip entirely.
Yes -- that's the difference a script has over a habit. node check.mjs <url> makes the same real HTTP requests curl would, from your own machine, and exits non-zero the moment a danger-severity finding is produced, a hop's request fails, or the chain runs out of hops while still redirecting. Add it as an ordinary step in your own CI and a new loop or downgrade fails the build instead of waiting for someone to notice it in a manual curl trace.