Skip to main content
Start free

Free · no signup

Redirect Chain Tracer

Follow every redirect hop between a URL and the page that finally answers — status semantics, latency, TLS and cookies — and see what the chain costs.

What a redirect chain costs — and why yours keeps growing

A redirect chain is what happens between the URL someone requests and the page that finally answers: hop one says "moved", hop two says "moved again", and only hop three serves content. Nobody designs a chain on purpose — they accumulate. The http-to-https rule was added one year, the www canonicalisation another, a trailing-slash rewrite came with a framework upgrade, a campaign shortener sits in front of everything, and a platform migration stacked its own "moved permanently" on top of URLs that were already redirects. Each rule is individually correct; together they form a chain no single person ever decided to build.

Every hop costs a full network round trip before a single byte of content arrives — and when a hop lands on a new host, that means fresh DNS, a new TCP connection and a TLS handshake on top, typically 100–300 ms per hop on mobile networks. Three hops can quietly burn most of a second, which is exactly the kind of invisible latency we dig into in why is my website slow. One hop deserves special alarm: a redirect from https back to plain http. Cookies and headers that were encrypted a moment earlier are re-sent in cleartext where any network in the path can read or rewrite them — this tracer flags that downgrade in red for a reason.

The status codes carry meaning, too. 301 and 308 are permanent: browsers and search engines cache them and treat the destination as canonical. 302 and 307 are temporary — nothing is cached, nothing is consolidated. And the pairs differ on the method: 301/302 typically turn a POST into a GET, while 307/308 preserve the method and body exactly, which matters for form submissions and APIs. A "moved" page behind a 302 is one of the most common quiet misconfigurations this tool surfaces.

The fix is almost always the same: collapse the chain by pointing every legacy URL directly at the final destination. Old paths, http, non-www — each should jump to the canonical https URL in a single hop, and internal links should skip the redirects entirely. We wrote up the full method, with server configs and the SEO details, in our guide to what redirect chains cost and how to monitor them.

And because chains grow back — one migration, one marketing tool, one rewrite rule at a time — a one-off trace only tells you about today. A CompleteStatus uptime monitor follows your key URLs’ redirects on every check and alerts you when the destination stops answering or slows down; re-run this trace after a migration to catch a new hop — start monitoring free.

Frequently asked questions

A redirect chain is a sequence of HTTP redirects between the URL a visitor requests and the page that finally answers — for example http://example.com → https://example.com → https://www.example.com/. Each link in the chain is a full extra round trip to a server before any content loads, so chains quietly add latency to every single visit.

301 and 308 are permanent — browsers and search engines cache them and treat the new URL as canonical; 302 and 307 are temporary. The other difference is the method: after a 301 or 302 a POST is typically replayed as GET, while 307 and 308 preserve the method and body exactly. 303 explicitly means "fetch the result with GET". For a moved page you almost always want 301 (or 308 if the URL receives POSTs).

One redirect is normal — https and www canonicalisation are everywhere. Two is worth a look; three or more is a chain worth fixing. Each hop costs a full round trip, and on a new host that includes DNS, TCP and TLS setup — typically 100–300 ms per hop on mobile networks. Browsers cap chains at around 20 redirects before showing an error, but users give up long before that.

Mostly indirectly: chains slow the page down, and speed is a ranking factor. Google follows redirects and consolidates link equity to the final URL — a 301 does not "leak" ranking the way old folklore claims — but every extra hop wastes crawl budget on large sites, adds another point of failure, and very long chains can make crawlers give up before reaching the content. There is no upside to a chain: collapsing it loses nothing and speeds everything up.

Point every legacy URL directly at the final destination instead of at another redirect. Update the rules in your server config or CMS so http, non-www and old paths each jump straight to the canonical https URL in a single hop, then update internal links so they point at the final URL and hit no redirect at all. Re-trace afterwards to confirm at most one hop remains.