Redirect Chain Tracer
Follows every hop of a redirect chain, with status semantics, per-hop latency, and any cookies set along the way. Then it shows you the single redirect it should have been.
What a chain costs you
Every extra hop bills you three times. Crawlers spend budget re-requesting, users sit through another full round trip (you’ll see the real latency per hop here), and ranking signals lose a bit of fidelity at every intermediate URL. Chains build up quietly. An http to https rule, then a www rule, then a trailing-slash rule, then whatever the CMS decides to do on its own, and nobody ever looks at the whole sequence in one place.
What it flags
- Wrong status semantics. A
302 Founddoing permanent work, like http to https or an old URL to its replacement, tells crawlers to keep checking the old one. Permanent moves want a301or a308. - Collapsible chains. When hop one could point straight at the destination, you get the ideal single redirect to configure.
- Protocol downgrades mid-chain, redirect loops, and chains that dead-end in a 404 or an error.
- Invisible redirects. Meta refresh and JavaScript
locationassignments on the final page, which search engines process slowly and unreliably compared to a real HTTP redirect. - Cookies set mid-chain, on URLs the user never sees. Usually wasted, occasionally a surprise during a privacy review.
Redirects are followed manually from Cloudflare's edge, up to 10 hops, so every hop's status, latency, and headers get recorded. The final page is scanned for meta refresh and common JavaScript redirect patterns, which are reported but not followed. Nothing is stored.