How much link equity is lost in a redirect chain?

Google's official position is that 301 redirects pass full PageRank — no loss per hop. In practice, longer chains crawl slower, take longer to be discovered, and may stop being followed entirely after 5+ hops (Google's documented limit). The real cost isn't equity loss per hop, it's crawl-budget waste and delayed indexing of the final destination.

What's an acceptable number of hops in a redirect chain?

One. The target is always a single 301 from old URL to final destination. Two hops is tolerable temporarily during migration windows. Three or more is a sign your redirect system has grown organically without consolidation; clean up. Google will follow up to 5 hops before giving up, but you should never be near that limit.

My redirects work but the Site Crawler still flags a chain — why?

Two common causes: (1) the crawler is comparing against an edge layer (Cloudflare) that handles part of the chain, while your origin still has remnants of the old rules — both fire in sequence; (2) HTTP-to-HTTPS plus www-to-non-www plus trailing-slash redirects compose into a chain even when each individual rule is correct. Combine them into a single rule that handles all three transitions in one hop.

How do I find redirect loops without breaking my site?

Test from outside the server with curl -ILs --max-redirs 10 https://yourdomain.com/path. The --max-redirs flag stops curl from infinite-looping if there's a loop, and the output shows the full hop sequence. If you see the same URL appear twice, you have a loop. Common causes: rule that redirects HTTPS->HTTP under some condition while another rule redirects HTTP->HTTPS, or a canonical-tag pointing at a URL that 301s back.

How to Fix Redirect Chains and Loops

A redirect chain is when URL A redirects to URL B, which redirects to URL C, which redirects to URL D. Each hop is a wasted request. Google follows up to 5 hops then gives up; users wait longer; crawl budget is wasted. A redirect loop is worse — the chain returns to a previous URL and never resolves. Both are common on long-lived sites where redirects accumulate without cleanup. This guide walks through diagnosis, collapsing chains to single 301s, fixing loops, and the edge-vs-origin conflict that hides chains from naive audits.

1. Build the chain list

The Site Crawler reports every internal URL that requires more than one hop to resolve.

Step 1

Run the crawler

Run the Site Crawler with the option Report redirect chains enabled (it usually is by default). Export the chains CSV. Columns: starting URL, hop 1, hop 2, ..., final URL, final status.

Step 2

Verify each chain with curl

The crawler shows what it found during the scan. Server state may differ now. Spot-check the worst offenders with:

curl -ILs --max-redirs 10 https://yourdomain.com/old-path/ 2>&1 | grep -iE "^(http|location)"

Expected good output: one HTTP/2 301, one location: https://..., one HTTP/2 200. Anything more is a chain.

2. Collapse each chain to a single 301

For each chain A → B → C → D, write a new direct rule A → D. Remove the intermediate rules.

WordPress (Redirection plugin)

Step 1

Audit existing redirects

WP Admin → Tools → Redirection → Redirects. Sort by source URL. Find the redirects that chain together. For chain /old-A/ → /old-B/ → /final/: edit the first rule to point directly at /final/, then delete the middle rule.

nginx (server config)

Step 1

Audit rewrite and return rules

In your vhost config:

# BEFORE (chain)
rewrite ^/old-a$ /old-b permanent;
rewrite ^/old-b$ /final permanent;

# AFTER (single hop)
rewrite ^/old-a$ /final permanent;
rewrite ^/old-b$ /final permanent;

Keep the rule for /old-b in case external links exist. Reload nginx:

nginx -t && nginx -s reload

Apache (.htaccess)

Step 1

Refactor Redirect chains

# BEFORE (chain)
Redirect 301 /old-a /old-b
Redirect 301 /old-b /final

# AFTER (single hop)
Redirect 301 /old-a /final
Redirect 301 /old-b /final

Save the .htaccess file. Changes apply immediately.

Cloudflare (Bulk Redirects or Rules)

Step 1

Audit existing redirect rules

Cloudflare Dashboard → Rules → Redirect Rules (or Bulk Redirects). Find chained rules and edit them to point at the final destination.

3. The edge-vs-origin chain trap

If you use Cloudflare or another CDN/edge layer, redirects can exist in TWO places that fire in sequence.

⚠️ Common pattern: Cloudflare redirects www.yourdomain.com → yourdomain.com. Then origin server redirects yourdomain.com/old/ → yourdomain.com/new/. Result: 2-hop chain even though each rule is correct. The fix: consolidate at one layer.

Step 1

Identify which layer owns which redirects

Run curl with verbose output to see where the redirect comes from:

curl -ILs https://www.yourdomain.com/old/ 2>&1 | grep -iE "^(http|server|location|cf-ray)"

The cf-ray header confirms Cloudflare was involved. server: cloudflare on the 301 response means Cloudflare did it. server: nginx means origin did it.

Step 2

Consolidate at edge layer (recommended)

Move ALL content-related redirects to Cloudflare Redirect Rules. Remove them from origin .htaccess/nginx config. Origin then only handles application requests; redirects fire once at the edge.

4. Fix redirect loops

A loop is a chain that never resolves — Google gives up, users see a browser error.

Step 1

Find the loop

curl -ILs --max-redirs 10 https://yourdomain.com/path/ 2>&1 | grep -i "^location"

If the same URL appears twice in the location list, you have a loop. Common cause: HTTP-to-HTTPS rule plus a non-HTTPS canonical somewhere.

Step 2

Trace and remove the offending rule

Look at all redirect rules that touch the looping URL pattern. One of them sends traffic back. Remove or fix.

5. Update internal links

After collapsing chains, internal links that still point at the chain start now hit the 301. Better to update the links directly so visits go straight to the final URL with no redirect at all.

Use the bulk-fix techniques from the broken links guide: WordPress Better Search Replace, Shopify theme code search, headless CMS API scripts.

💡 You don't need to update every legacy link. Focus on links from your most-trafficked pages — they're the ones causing measurable redirect overhead on real users.

6. Re-run the audit

After collapsing chains and updating internal links, re-run the Site Crawler. Chain count should be at or near zero.

🕷 Re-run the Site Crawler

Verify all chains are collapsed to single hops.

Run Site Crawler →