How to Find and Fix Redirect Chains (2026 Technical SEO Guide)

A redirect chain is what happens when one URL redirects to another, which redirects to another, before a visitor or a search crawler finally lands on the real page. /old-page → /new-page → /newest-page is a two-hop chain. It usually isn't the result of a single bad decision — it's the slow accumulation of years of site moves, HTTP-to-HTTPS upgrades, www changes, trailing-slash fixes, and re-platforming, each one layered on top of the last. Individually harmless; together, a quiet drag on crawl efficiency and page speed.

The short version: chains rarely cost you rankings directly, but they waste crawl budget, add latency that hurts Core Web Vitals, and make your site harder to maintain. The fix is almost always the same — collapse every chain so each old URL points, in a single hop, straight to its final destination.

Chain vs. loop — and why loops are urgent

A redirect chain eventually reaches a working page; it's just inefficient. A redirect loop never does — /a redirects to /b, and /b redirects back to /a. Browsers stop after a few cycles and show an error (“too many redirects”), and crawlers give up entirely. A loop makes the page completely inaccessible, so if you find one, treat it as a live outage, not a tidy-up job.

Does Google actually care? What the evidence says

Here's where a lot of older SEO advice is simply out of date, so it's worth being precise.

You do not lose “link equity” through the hops

The long-standing worry was that each redirect bleeds off ranking signal. Google has said the opposite: PageRank passes through 301, 302, and other 3xx redirects without a penalty for the redirect itself. So the existence of a chain is not, on its own, silently tanking your rankings. If you've been told to panic about “equity loss” per hop, that specific fear is not supported by what Google has stated.

But Google only follows so many hops per crawl

Googlebot will follow roughly five hops in a chain per crawl attempt. If your chain is longer than that, Google may not reach the final URL on that pass — it picks up again on a later crawl, which delays how quickly the destination gets discovered and indexed. Google's own guidance is to keep chains short and, wherever possible, redirect straight to the final URL. Treat “under five hops” as a ceiling you never want to approach, not a target.

The real, measurable costs

The reasons to fix chains are practical, not mystical:

• Crawl budget waste. Every hop is a request. On a large site, thousands of chained URLs mean the crawler spends its time bouncing through redirects instead of discovering and refreshing real pages.
• Slower pages and worse Core Web Vitals. Each redirect adds a round trip before the browser gets any content. That extra latency pushes up Time to First Byte and Largest Contentful Paint — the exact metrics Google measures for page experience.
• Mobile and high-latency users feel it most. On a slow connection, three chained hops before the page even starts loading is a real, felt delay and a bounce risk.
• Maintenance debt. Chains hide broken assumptions. When you can't tell which redirect is load-bearing, every future migration gets riskier.

How to find redirect chains on your site

You can't fix what you can't see. Three practical ways to surface them, cheapest first:

1. Spot-check a single URL by hand

For one suspect URL, use any “HTTP header” or redirect-trace checker (several are free), or run a command-line request that follows and prints each hop. What you're looking for is more than one 301/302 line before a final 200 OK. One hop is fine and often correct; two or more is a chain to collapse.

2. Crawl the whole site

A site crawler (desktop crawlers and most technical-SEO platforms do this) will follow every internal link and report a “redirect chains” list: the starting URL, each hop, the number of hops, and the final status. This is the only way to find chains at scale and to catch the internal links that still point at the old URL instead of the final one.

3. Check Google Search Console

The Page Indexing report flags URLs excluded as “Page with redirect,” and the URL Inspection tool shows the redirect Google actually followed. This won't map full chains as cleanly as a crawler, but it tells you which redirected URLs Google is encountering — a useful cross-check against your crawl.

How to fix them — the one rule that covers most cases

Point every redirect directly at the final destination, in a single hop. Concretely:

1. Map each chain end-to-end. For every starting URL, identify the true final URL — the one that returns 200 OK.
2. Rewrite the first redirect to jump straight there. Change /old so it redirects once, to the final URL, skipping the intermediate hops entirely. Update the redirect rules in your server config, CDN, or platform's redirect manager.
3. Use the right status code. For a permanent move, use a 301. Reserve 302/307 for genuinely temporary redirects. Mislabeling a permanent move as temporary is a common, avoidable mistake.
4. Fix the internal links too. This is the step most people skip. If your own navigation, buttons, and body links still point at the old URL, you're forcing a redirect on every click even after the chain is collapsed. Update internal links to the final URL so no redirect is needed at all.
5. Update sitemaps and canonicals. Your XML sitemap should list only final 200 URLs, and canonical tags should reference the final URL — never an intermediate hop.
6. Re-crawl and confirm. After the change, crawl again and verify each former chain now resolves in one hop. Watch for new chains introduced by the fix itself.

One caution: don't delete the old redirects. As long as external sites and old bookmarks still point at the original URL, that first redirect has to stay — you're shortening the chain to a single hop, not removing the entry point. (For the broader picture of what a full technical review covers and the order to fix things in, see what a technical SEO audit checks and how to prioritize fixes.)

Where redirect chains quietly come from

Knowing the usual sources helps you prevent the next generation of chains:

• Protocol and host migrations layered over time: http→https, then non-www→www, each as a separate rule.
• Trailing-slash normalization added after the HTTPS rule instead of being merged into it.
• Content restructures where a page moved twice and the first redirect was never updated to skip to the newest location.
• Third-party or plugin redirects stacking on top of server-level ones, so two systems each add a hop.

The prevention is to consolidate redirect logic into one place and, whenever you add a new rule, check whether it lengthens an existing chain. (A redirect check is one line item on a broader list — here's a technical SEO checklist you can run yourself, and if your issue is pages not getting indexed at all, see how to fix “Crawled – currently not indexed.”)

Related reading: What a technical SEO audit checks and how to prioritize fixes · A technical SEO checklist you can run yourself · How to fix “Crawled – currently not indexed”