Redirect Chains and Loops: Full Diagnosis and Repair

Why redirect chains accumulate on most sites

Redirect chains are almost never created intentionally. They build up over time as sites evolve. A URL is redirected once during a redesign. Then the destination URL is redirected again during a later migration. Then that URL is redirected again when the CMS changes. Three years later you have a three-hop chain no one remembers creating.

How to fix a redirect chain

1. Run the Redirect Chain Checker on your most important URLs
2. For each chain, identify the original URL and the final destination
3. Update the original redirect to point directly to the final destination
4. Remove any intermediate redirects that are no longer needed
5. Re-run the checker to confirm the chain is resolved

The equity myth, and what a chain actually costs

The standard warning is that each hop bleeds link equity. That framing is out of date, and believing it leads people to fix the wrong things.

Google has stated that 301 and 302 redirects do not lose PageRank. The old "10–15% loss per hop" figure was a reasonable inference in 2010 and has not been true for a long time. If your only reason for fixing a two-hop chain is equity leakage, the reason is weak.

The real costs are elsewhere, and they are worse:

• Latency, paid by the user. Every hop is a full network round trip — DNS, connection, TLS, response — before a single byte of the actual page arrives. On mobile, on a poor connection, three hops can add a second or more to a page that has not started loading yet. This is a Core Web Vitals problem masquerading as a redirect problem.
• Crawlers give up. Googlebot follows a limited number of hops per crawl attempt — commonly understood to be about five before it abandons the chain. Beyond that, it may pick the trail up on a subsequent crawl, or it may simply not resolve the URL. Either way you have made discovery slower and less reliable for no benefit.
• Crawl budget. Every hop is a request. A site with thousands of chained URLs spends a large fraction of its crawl allowance on 301 responses that contain nothing.
• Chains break in ways single redirects do not. Each hop is a dependency. Remove one intermediate rule during a tidy-up and the whole trail collapses into a 404 — usually without anyone noticing, because nobody was watching a URL that had been redirecting quietly for five years.

The redirect that silently passes nothing: the soft 404

This is the mistake that actually destroys link value, and it is committed constantly — usually by someone trying to be helpful.

When you redirect a removed page to a destination that is not a genuine replacement — most often the homepage — Google treats it as a soft 404. The redirect is honoured for the user, who lands somewhere useless. But Google treats the original URL as missing, and no link value is passed at all. Every backlink pointing at that old URL is now pointing at nothing.

The bulk "redirect everything to the homepage" rule, applied during a migration to avoid a wall of 404s in Search Console, is therefore the single most expensive thing you can do with a redirect map. It looks tidy. It reports clean. It passes nothing.

The rule

• A redirect preserves value only when the destination genuinely satisfies the same intent as the original. An old product page to the current model: correct. An old article to its updated version: correct. A discontinued product to the category that contains its successors: acceptable. Anything to the homepage: not a redirect, a dead end with a 301 status code.
• Where there is no equivalent, let it 404 — or better, 410 Gone. A 410 states that the removal is deliberate and permanent. Google drops the URL faster and stops recrawling it, which is exactly what you want for content that is genuinely gone. A wall of honest 404s is not a problem; it is an accurate report.

Loops: the causes are almost always these five

A loop takes a page offline entirely — the browser gives up, Google cannot index it, and the user sees an error. The cause is rarely a single misconfigured rule; it is nearly always two rules that are individually correct and jointly contradictory.

1. HTTPS and www rules fighting each other. One rule forces HTTPS, another forces the www subdomain, and they are applied in an order that never converges: http://site → https://site → http://www.site → and round again. Fix by combining them into a single rule that goes to the final canonical host and protocol in one hop — never chain them.
2. A CDN and an origin server disagreeing. Cloudflare or similar is set to force HTTPS; the origin, unaware it is behind a proxy, sees an HTTP request and redirects to HTTPS itself. Each blames the other, forever. This is the most common loop of all, and it is invisible when testing against the origin directly.
3. A trailing-slash rule that cannot decide. One rule adds the slash, another removes it. Pick one convention and enforce it once.
4. A locale or currency redirect based on a cookie that the redirect prevents from being set. The user is redirected to choose a region; the region page redirects them back because no preference cookie exists; the cookie is never written because they never arrive.
5. An authentication redirect on a page the auth check does not recognise. Logged-out user is sent to login; login redirects back to the protected page; the session still is not established; repeat.

Choosing the right status code

The 302 trap

A 302 left in place for a year is a lie you told a search engine. It says "come back, the original will return" — so Google keeps the original URL as the indexed one, and keeps recrawling it, waiting for the page you told it would come back. Meanwhile your new destination never fully takes over.

The symptom is unmistakable: the old URL keeps appearing in search results long after you replaced it. Google is doing exactly what you asked. If the move is permanent, say so with a 301 — and check your platform's defaults, because several frameworks and hosting panels emit 302 unless explicitly told otherwise, which means the mistake is usually made once, in a config file, and then repeated a thousand times.

JavaScript and meta refresh redirects

A <meta http-equiv="refresh"> tag or a window.location assignment is not a redirect at the HTTP level. Google will generally follow both after rendering, but they arrive late, they are slower for the user, and other consumers — social scrapers, many AI crawlers, anything that parses rather than renders — will simply not follow them. Use a server-side status code. Always.

Redirects and the other signals — where the contradictions hide

A redirect is one statement among several you are making about a URL, and Google weighs them together. When they disagree, it picks — and it may not pick what you meant.

• Redirected URLs in your sitemap. The sitemap says "this is a canonical, indexable page"; the server says "this page moved". You have contradicted yourself in the two files Google trusts most. Sitemaps should contain only URLs that return 200.
• Internal links pointing at redirected URLs. Every internal link to an old URL forces a hop for every user and every crawl. After a migration, update the links in the source — the redirect is a safety net for external links you cannot control, not a substitute for fixing your own.
• A canonical pointing at a redirecting URL. You have told Google the preferred version of this page is a URL that does not exist. It will work it out, but you have made it guess.
• Redirecting a URL that is blocked in robots.txt. Google cannot fetch the URL, so it never sees the redirect and never learns the page moved. The old URL can sit in the index indefinitely.
• Redirect chains between protocol and host variants. http://site → https://site → https://www.site is two hops on every single request from anyone who typed the domain without a protocol — which is most people. Collapse it to one.

Auditing them properly

• Follow the whole chain, not the first hop. A tool reporting "301 → 200" may be reporting the last two links of a five-hop trail. Trace from the original URL, and record every intermediate.
• Start from the URLs that matter. The pages with external links, the ones in your ad campaigns, your top organic landing pages, and anything printed on physical material. A chain on an orphaned 2018 blog post is not the same problem as a chain on the URL in your paid search.
• Test as a stranger. Private window, no cookies, no session. Then test with a crawler user-agent. Loops and locale redirects are frequently invisible to a logged-in browser that has been to the site a hundred times.
• Audit after every migration, replatform, domain change and CMS upgrade — and audit again a month later, because the chains introduced by a migration usually surface once the next set of rules is layered on top.
• Keep the redirect map. A documented map of old URL → new URL, versioned alongside the code, is the only thing that prevents the next migration from adding a hop rather than replacing one. Its absence is why chains exist at all.

Frequently asked questions

What is a redirect chain?

A redirect chain is when URL A redirects to URL B, which then redirects to URL C. Each hop is a full network round trip before any page content arrives, so chains are slow for users and wasteful of crawl budget — and every hop is a dependency that can break. Google has stated that 301 and 302 redirects do not lose PageRank, so the old claim that each hop bleeds link equity is out of date. Fix chains by updating the original redirect to point directly to the final destination, eliminating the intermediate hops.

What is a redirect loop?

A redirect loop is when two or more URLs redirect to each other in a circle — URL A redirects to URL B, which redirects back to URL A. This causes an error for users and prevents Google from indexing either page. Fix by identifying which redirect is creating the circle and breaking the loop.

What is the difference between a 301 and 302 redirect?

A 301 signals a permanent move; a 302 signals a temporary one. Google has stated that both pass PageRank, so the difference is not one of link equity — it is what each tells Google to index. A 302 says the original URL will return, so Google keeps indexing the original and waits for it. Left in place on a permanent move, that is why the old URL keeps appearing in search results long after you replaced it. Use 301 for permanent URL changes, site migrations and canonicalisation. Use 302 only for genuinely temporary redirects.

Can I redirect all my removed pages to the homepage?

No — this is the most expensive mistake in a redirect map. Google treats a redirect to a destination that is not a genuine replacement as a soft 404: the redirect is honoured for the user, but the original URL is treated as missing and no link value is passed at all. It looks tidy and reports clean while passing nothing. Redirect only to a page that genuinely satisfies the same intent; where no equivalent exists, return 410 Gone.

Why does my redirect loop only affect some visitors?

Because your own browser holds the cookie, session or stored preference that the redirect logic depends on, so the page resolves normally for you. A first-time visitor — and Googlebot, which has none of those things — hits the loop. Locale redirects that depend on a preference cookie the redirect itself prevents from being set, and CDN-versus-origin HTTPS rules each redirecting on behalf of the other, are the classic causes. Always test in a private window and with a crawler user-agent.

How many redirect hops will Google follow?

A limited number per crawl attempt — commonly understood to be around five before the chain is abandoned. Beyond the crawl limit, the greater costs are latency, since each hop is a full network round trip before any page content arrives, and fragility: every hop is a dependency, and removing an intermediate rule during a tidy-up collapses the whole trail into a 404 that nobody notices.

Are JavaScript or meta refresh redirects acceptable?

Use a server-side status code instead. A meta refresh or a window.location assignment is not an HTTP-level redirect: it arrives late, it is slower for the user, and consumers that parse rather than render — social scrapers, many AI crawlers — will not follow it at all. Google will generally follow them after rendering, but there is no reason to make it work that out.

Related tools