What a redirect chain is
What is a redirect chain? A redirect chain is when a URL redirects to a second URL that then redirects to a third (or more) before finally reaching the destination — A points to B, B points to C, and only C serves the real page. Instead of one clean hop from the requested URL to the final one, the browser and crawler are bounced through a series of intermediate stops. Each stop is a separate HTTP redirect (usually a 301 or 302), and the whole sequence is the chain.
A single redirect is normal and healthy — you use one every time you move a page, switch to HTTPS, or consolidate duplicate URLs. The problem is not redirecting; it is redirecting *through* intermediate URLs that could have been skipped. example.com/old → example.com/new is a direct redirect and totally fine. example.com/old → www.example.com/old → https://www.example.com/old → https://www.example.com/new is a four-hop chain that should have been a single jump straight to the final HTTPS URL.
Chains rarely get built on purpose. They accumulate over time as small, reasonable redirects stack on top of each other: someone adds an HTTP-to-HTTPS rule, later someone adds a non-www-to-www rule, then a page is renamed, then the site migrates platforms — and each rule fires in sequence because nobody went back to collapse them. The result is a site full of two-, three-, and four-hop chains that every crawler has to walk through. Redirects are a core part of technical SEO, and keeping them direct is one of the easiest wins available.
Why redirect chains hurt SEO
Redirect chains hurt SEO in four concrete ways, all stemming from the extra hops. First, they waste crawl budget. Every redirect is a request a crawler must make and follow. A three-hop chain turns one URL into three round-trips before any content is fetched, so search engines process fewer of your real pages per crawl. On large sites this directly reduces how much gets discovered and refreshed — see what is crawl budget for the full mechanics.
Second, they slow the page down for users. Each hop is a full network round-trip — DNS, connection, response — before the browser even starts loading the destination. On mobile connections that latency stacks up quickly, hurting your Core Web Vitals and the experience of anyone who clicks an old link.
Third, they dilute link equity. A backlink pointing at the first URL passes its ranking value along the chain, but each redirect can shed a little of that authority. The more hops between the linked URL and the final page, the more diluted — and the less reliably it consolidates — the equity becomes.
Fourth, and most dangerous, each hop is a point of failure. If any URL in the chain later breaks, returns a 404 error, or starts a loop, the whole path dies and users and crawlers never reach the destination. A direct redirect has one link that can break; a four-hop chain has four. Google also gives up after roughly five hops in a single chain, so long chains can leave the final page uncrawled entirely.
Redirect chain vs redirect loop vs direct redirect
It helps to see the three redirect patterns side by side, because they are easy to confuse and have very different consequences. A direct redirect is the healthy case: one hop from the old URL straight to the final destination. A redirect chain is two or more hops in sequence that still eventually resolve — inefficient but functional. A redirect loop is the broken case: URLs that redirect back to each other (A → B → A) so the destination is *never* reached and the browser eventually shows a "too many redirects" error.
| Pattern | Path | Reaches destination? | SEO impact | Urgency to fix |
|---|---|---|---|---|
| Direct redirect | A to final (1 hop) | Yes | Minimal — the healthy default | None — this is the goal |
| Redirect chain | A to B to C to final (2+ hops) | Yes, but slowly | Wastes crawl budget, slows load, dilutes link equity | Medium — an optimization |
| Redirect loop | A to B to A (never ends) | No — 'too many redirects' error | Page is completely inaccessible to users and crawlers | High — fix immediately |
The key distinction: a chain wastes resources but still works, while a loop is completely broken and blocks access to the page. A loop is effectively a self-inflicted outage — neither users nor crawlers can load anything — so loops are an emergency to fix immediately, whereas chains are an optimization you should fix but that will not take a page fully offline. Both are worth catching, and both come down to the same root cause: redirect rules that reference intermediate URLs instead of the final one.
The type of redirect matters too. Chains built from 301 (permanent) redirects are the least harmful because 301s consolidate signals, while 302 (temporary) redirects in a chain add uncertainty about which URL should be indexed. If you are unsure which to use, read 301 vs 302 redirects before touching your rules.
How to find redirect chains
You cannot fix redirect chains you cannot see, and chains are invisible in a browser — it silently follows every hop and shows only the final page, hiding the detour. To find them you have to inspect the actual HTTP responses. There are three practical methods.
Use a site crawler. Tools that crawl your whole site (Screaming Frog, Sitebulb, and similar) produce a redirect report listing every URL, each hop it passes through, and the final status code. This is the most thorough approach because it catches chains across your entire URL set at once, including ones buried in old internal links. Sort by number of hops to prioritize the worst offenders.
Check individual URLs with a redirect checker. For a specific page — say, an important landing page or a URL with valuable backlinks — a redirect-path checker or a quick command shows the exact sequence. On the command line, curl -IL https://example.com/old prints every hop and status code in order, so you can read the chain directly.
Run an audit that flags them automatically. Run a free SEO + GEO audit on any URL and it follows the redirects for you and reports the full hop-by-hop path, so you can see a chain — and whether it ends in a 200, a 404, or a loop — without installing anything. While you are checking redirects, it is worth catching broken internal links in the same pass, since old links are what feed chains in the first place.
How to fix redirect chains
Fixing a redirect chain comes down to one rule: point every redirect directly at the final destination URL. Once you know the chain (A → B → C → D), edit the redirect rules so that A, B, and C each go straight to D in a single hop. Collapse the sequence so no redirect ever targets another URL that also redirects. This usually happens in your server config (.htaccess, Nginx rewrite), your CDN or edge rules, or a redirect plugin — wherever the rules live, update the target of each rule to the final URL.
Follow this in order to fix a chain cleanly:
- Map the full chain first so you know the true final destination — the URL that returns a 200, not just the next hop.
- Update every intermediate rule to point straight to that final URL, using a 301 for permanent moves so signals consolidate.
- Fix internal links at the source. If your own navigation, sitemap, or content links to the old A URL, change those links to point at D directly — that removes the redirect entirely for internal traffic, which is even better than a clean single redirect.
- Re-test after the change to confirm each old URL now resolves in one hop to a 200, with no leftover intermediate stops and no loop.
The goal is not zero redirects — you will always need some. The goal is that no redirect ever points at another redirect.
One caution: when you consolidate, make sure the final destination is genuinely correct and live. Repointing a chain at a URL that itself 404s or redirects again just creates a new, subtler problem. Verify the endpoint returns HTTP 200, then move on. Done right, collapsing chains recovers wasted crawl budget, speeds up every affected page, and consolidates the link equity your old URLs have been quietly leaking.