Redirect Chain Tracer
Follows every hop of a redirect chain — status semantics, per-hop latency, cookies set along the way — then shows you the single redirect it should have been.
The cost of a chain
Every extra hop taxes you three ways: crawlers spend budget re-requesting, users wait (each hop is a full round trip — you’ll see the real latency per hop here), and ranking signals lose a little fidelity with every intermediate URL. Chains accumulate silently — an http→https rule, then a www rule, then a trailing-slash rule, then the CMS’s own redirect — and nobody ever sees the full sequence. This shows the full sequence.
What it flags
- Wrong status semantics — a
302 Founddoing permanent consolidation (http→https, old URL→new URL) tells crawlers “keep checking the old one.” Permanent moves want301or308. - Collapsible chains — when hop 1 could point directly at the final destination, the tool shows the ideal single redirect to configure.
- Protocol downgrades (https→http mid-chain), redirect loops, and chains that dead-end in a 404 or error.
- Invisible redirects — meta refresh and JavaScript
locationassignments on the final page. Search engines process these slowly and unreliably compared to an HTTP redirect. - Cookies set mid-chain — set on URLs the user never sees; usually wasted, occasionally a privacy-review surprise.
Redirects are followed manually from Cloudflare's edge (up to 10 hops) so every hop's status, latency, and headers are recorded. The final page is scanned for meta refresh and common JavaScript redirect patterns; those are reported but not followed. Nothing is stored.