How to Fix Redirect Chains and Reclaim Lost Link Equity

A redirect chain is what happens when URL A redirects to URL B, which redirects to URL C. Each hop adds latency, consumes crawl budget, and bleeds PageRank. At scale — a migrated e-commerce site, a blog that's been live for a decade — chains quietly erode rankings for months before anyone notices.

This guide covers how to find chains, how to measure the actual SEO cost, and how to flatten them across the stacks you're most likely to be running. For related issues, the technical SEO guides hub has the full cluster.

Chains vs. Loops: Quick Distinction

Before going further: a redirect chain is a linear sequence — A→B→C→D. A redirect loop is circular — A→B→A, or A→B→C→A. Loops cause browsers to show an error and kill the request entirely. Both waste crawl budget, but loops are immediately fatal; chains are quietly damaging.

Loop detection and fixes are covered in how to fix redirect loops. This guide focuses on chains.

The SEO Cost Per Hop

The oft-cited figure is ~10–15% PageRank loss per redirect, based on older guidance from Google engineers. Google has since said that 301 and 302 redirects pass "full" PageRank in most cases. The reality in 2025 is more nuanced:

1. Link equity loss is real but uncertain. Google's official position and observed ranking behavior don't always match. Conservative SEOs still treat each hop as a small leak. Flatten chains regardless.

2. Crawl budget cost is measurable and definite. Each URL in a chain is a separate HTTP request. Googlebot follows them sequentially. On a site with 50,000 URLs and 30% of them in chains, you're burning a meaningful fraction of your crawl budget on intermediate hops that provide zero value.

3. Page speed degrades for users. Even after first-crawl caching, real users hitting old bookmarks or links traverse the full chain. 3 hops at 100ms each = 300ms extra before the page even starts loading.

4. Reporting becomes unreliable. Analytics tools attribute traffic to the final URL, but broken or misconfigured chain setups can cause referrer/source data to get dropped at each hop.

How to Find Redirect Chains

Method 1: curl -IL (fast, single URL)

curl -IL https://yoursite.com/old-page

The -I flag requests headers only; -L follows redirects. The output shows each hop:

HTTP/1.1 301 Moved Permanently
Location: https://yoursite.com/intermediate/

HTTP/1.1 301 Moved Permanently
Location: https://yoursite.com/final-page

HTTP/1.1 200 OK

Three status codes = two redirects = a chain. You want to see one 301 and one 200, or just a 200.

Method 2: Screaming Frog (free tier, up to 500 URLs)

1. Open Screaming Frog, enter your domain, crawl.
2. Go to Reports → Redirect Chains.
3. Export the CSV — every URL in a chain is listed with hop count and final destination.

The free tier is enough for most small sites. If your site is larger, you'll need the paid version or a server-log approach.

Method 3: Server logs

Server logs are the ground truth. Every request Googlebot makes is in there — including whether it followed a chain. Use a log analyzer (GoAccess, AWStats, or even grep + awk) to find requests where the response code is 301/302 and the destination is also getting 301/302 responses.

grep " 301 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

This gives you the most-crawled redirect sources. Cross-reference those destinations to see if they also redirect.

Method 4: Google Search Console

GSC doesn't directly report chains, but the Coverage report will flag pages it couldn't fully process. "Redirect error" and "excluded by redirect" reports often indicate chain or loop issues.

How to Fix Redirect Chains

The fix is always the same: update the redirect so it points directly to the final destination, skipping all intermediate hops.

WordPress: Redirection Plugin

The Redirection plugin is the most common redirect manager on WordPress. Priority of redirect resolution in WordPress:

1. Redirection plugin rules (first match wins)
2. .htaccess rules (for Apache hosts)
3. WordPress core redirects (for moved slugs)
4. Server-level rules (Nginx config, Cloudflare)

Chains often form because a URL gets redirected at multiple layers — say, a slug change creates a WordPress core redirect, and then someone adds another Redirection plugin rule to the same URL for a domain migration.

Fix in Redirection plugin:

1. Go to Tools → Redirection → Redirects.
2. Find the chain source URL.
3. Update the "Target URL" to the final destination directly.
4. Delete any intermediate-hop rules that are no longer needed.
5. Check if WordPress's built-in redirect (from the old slug) is conflicting — you may need to set the old slug back, then change it again after removing the rule.

Audit all your redirects for chains before clearing them. Export the full Redirection plugin list and trace each chain manually, or run a find-and-replace on target URLs.

Apache: .htaccess

Apache processes .htaccess rules top-to-bottom, last-match-wins by default. Chains in .htaccess happen when multiple rules match the same URL and each one sends a new redirect.

Example of a chain-causing .htaccess:

# Rule 1: old blog path
Redirect 301 /blog/old-post /blog/intermediate-post

# Rule 2: post was moved again
Redirect 301 /blog/intermediate-post /blog/final-post

A request to /blog/old-post hits Rule 1, gets a 301 to /blog/intermediate-post, then a new request hits Rule 2 and gets another 301. That's a 2-hop chain.

Fix: consolidate to one rule.

# Single rule to final destination
Redirect 301 /blog/old-post /blog/final-post

Delete the intermediate rule entirely. If you have dozens of these, export all rules, identify chains (any Redirect target that also appears as a Redirect source), and update them all in one pass.

For RewriteRule chains, the same principle applies — audit for rules whose destination is also the source of another rule.

Nginx

Nginx processes location blocks with priority rules (exact match > prefix > regex). Chains happen when multiple location blocks match a URL sequentially.

# Creates a chain:
location /old-path/ {
    return 301 /intermediate-path/;
}
location /intermediate-path/ {
    return 301 /final-path/;
}

Fix:

location /old-path/ {
    return 301 /final-path/;
}

Remove the intermediate location block if nothing else links to /intermediate-path/, or keep it if it handles direct traffic.

Cloudflare: Page Rules / Redirect Rules

Cloudflare's Page Rules and the newer Redirect Rules can both create chains if they hand off to origin server redirects.

Common pattern: Cloudflare redirects http:// → https:// and www → non-www, but the origin server also has an HTTP → HTTPS redirect configured. That's a 3-hop chain for an HTTP+www request:

1. Cloudflare: http://www.site.com → https://www.site.com (301)
2. Origin: https://www.site.com → https://site.com (301)
3. Final: https://site.com (200)

Fix: let Cloudflare own the entire canonical URL redirect, remove it from origin.

In Cloudflare, create one Redirect Rule:

http://www.site.com/* → https://site.com/$1 (301)

Then remove the HTTP → HTTPS redirect from your .htaccess or Nginx config, since Cloudflare is handling it before requests reach origin. Result: one hop.

Preventing Chains from Reforming

1. Redirect to final destination, always. When creating a new redirect, trace the existing chain for that URL first. Use curl -IL before adding any new rule.

2. Audit on every migration. Domain moves, HTTPS upgrades, URL restructures — all create chains. Run a full Screaming Frog crawl after every migration.

3. Remove intermediate rules immediately. When URL B is the final destination of a redirect from A, and you later decide to redirect B to C — update A→C and B→C. Don't leave A→B→C.

4. Monitor with canonical checks. A page appearing in search results at an intermediate URL is a sign of a chain. Check your canonical tags to confirm they point to the final URL.

Related Issues

Redirect chains and loops often coexist on the same site. If your crawl shows circular patterns — a URL that eventually redirects back to itself — see how to fix redirect loops for the diagnosis and fix process.

For XML sitemap hygiene: make sure your sitemap only lists final destination URLs. A sitemap pointing to URLs that redirect is wasted crawl budget. See XML sitemap lastmod explained for sitemap best practices.

Summary

• Every redirect hop adds latency, wastes crawl budget, and potentially leaks PageRank.
• Find chains with curl -IL (single URL), Screaming Frog (site-wide), or server logs.
• Fix by updating the source redirect to point directly to the final destination.
• In WordPress, check multiple layers: Redirection plugin, .htaccess, and WordPress core redirects.
• In Cloudflare, consolidate www/HTTP redirects into one Redirect Rule at the edge and remove duplicates at origin.
• Always redirect to final destination. Never to an intermediate URL.