A redirect chain is what happens between the URL someone typed, clicked, or a search engine indexed, and the page that finally loads. When that path is one hop — a single 301 straight to the current URL — it is invisible and free. Every hop past the first one is a cost somebody is paying without necessarily knowing it.
Nobody sits down and designs a four-hop redirect chain. It accumulates one migration at a time:
a site moves from http to https, then a year later from
www to the bare domain, then a URL structure change moves an old path to a new one
— each change reasonable on its own, and each old redirect left pointing at the previous
target instead of updated to point straight at the current one. The fix each time is simple —
point every existing redirect at the final destination, not the last one — but it requires
remembering every old redirect exists, which is exactly what nobody does three migrations later.
Latency, first: each hop is a full network round trip before the browser even starts loading the real page, and that tax applies to every visitor who follows an old link or bookmark, not just a one-time crawl. Crawl behavior, second: Google's own Search Central documentation on redirects advises keeping a chain as short as possible — ideally a single hop — because search engines may not follow a very long one at all the way a browser will. A page several hops deep in an old migration can simply stop being indexed under its current URL, with nothing in your analytics obviously pointing at "the redirect chain" as the cause.
The most common cause is two independent redirect rules that each assume the other has already run — an HTTPS-enforcement rule and a www-normalization rule configured in the wrong order, or split across two systems (a CDN in front of an origin server) that each redirect the exact case the other one just produced. It is easy to miss in ordinary browsing: a browser that has cached an earlier successful load, or that gives up and shows its own "too many redirects" error after an internal limit, may never show you the loop the way a fresh crawler or a strict HTTP client hits it immediately.
A 301 (or 308, which additionally preserves the original request method) tells a search engine the move is permanent — consolidate ranking signal onto the new URL and stop treating the old one as canonical. A 302, 303, or 307 says the opposite: this is temporary, keep checking the old URL. Using a temporary code for what is actually a permanent scheme or host normalization — the single most common shape this produces — delays exactly the ranking consolidation the move was meant to achieve, sometimes for months.
All four of the above — chain length, protocol downgrade, wrong status code for a permanent move, and an outright loop — are mechanically checkable from the chain itself, with no judgment call. Redirect Chain Checker runs those checks: paste a hop list you captured from your browser's Network panel, or run the CLI to walk the real chain over HTTP and get the same report automatically, wireable into CI as a regression gate.
One site migration at a time. A site moves from http to https (hop 1), then from www to non-www a year later (hop 2), then a URL structure change moves /old-path to /new-path (hop 3) — each individually reasonable, and each one left in place rather than updated to point straight at the current URL. Nobody adds three hops on purpose; it accumulates because updating every old redirect target every time something moves again is easy to forget.
Two costs, and they are different. First, latency: every hop is a full network round trip before the browser even starts loading the real page, and that delay applies to every single visitor, not just a search engine crawling it once. Second, crawl behavior: Google's own Search Central documentation on redirects advises keeping a chain as short as possible because search engines may not follow a very long one at all — so pages several hops deep in an old migration may simply stop being indexed under their current URL.
The most common cause is two independent redirect rules that each assume the other has already run — an HTTPS-enforcement rule and a www-normalization rule configured in the wrong order, or on two different systems (a CDN and the origin server) that each redirect the case the other one just produced. It is easy to miss because a person testing in a browser that has cached an earlier successful load, or that stops following redirects after its own internal limit, may never see the loop that a fresh crawler or a strict HTTP client hits immediately.
No — if the move really is permanent, 301 (or 308, which preserves the request method) is the correct code by definition, and using 302 for it is the mistake this tool flags. A 302 is correct for something genuinely temporary: an A/B test, a maintenance page, a seasonal redirect that will be reverted. The distinction search engines actually act on is exactly the one in the status code's own name, and using the wrong one for a permanent change is what delays ranking signal moving to the new URL.