Redirect Chains Are Silently Draining Your Crawl Budget (And Google Noticed)

I was auditing a mid-size e-commerce site last month — around 4,000 product pages — and we found something that made the team go quiet for a second. Their site had redirect chains averaging four hops deep across hundreds of URLs. Four hops. Every time Googlebot tried to crawl a product page, it was following a trail: old URL → HTTP version → www redirect → old slug → final URL. The site had been migrated twice and nobody cleaned up the old redirect rules.

Their organic traffic had dropped about 18% over the past three months. They blamed the May 2026 core update. And yeah, that might have contributed. But when we cleaned up the redirect chains, flattened everything to single 301s, and resubmitted the sitemap, traffic came back steadily over six weeks. Not all of it — but enough to make the case clearly.

Redirect chains are one of those technical SEO problems that feel minor until they're not. They're easy to accumulate, invisible to most analytics tools, and genuinely harmful in ways that stack up slowly over months. Here's everything you need to know.

What Actually Is a Redirect Chain (and Why It's Different from a Simple Redirect)

A regular 301 redirect is fine. You changed a URL, you tell browsers and bots "the new location is here," and life goes on. Google has said for years that a single 301 carries nearly full PageRank. No issue.

A redirect chain is what happens when that redirect points to another redirect, which points to another redirect. Instead of A → Z, you end up with A → B → C → D → Z. Every hop is an extra HTTP request. Every hop adds latency. Every hop is a chance for something to go wrong.

Chains usually form because:

• You migrated a site and kept old redirect rules when relaunching the next version
• You switched from HTTP to HTTPS and also changed your URL structure at the same time
• You added www/non-www normalization on top of existing redirects
• A CMS plugin auto-generates redirects when you change slugs — and you changed slugs twice
• Your CDN or hosting layer adds its own redirect before your app redirect fires

The sneaky thing about chains is that the final destination URL still loads correctly for human visitors. You don't notice anything is wrong unless you're specifically testing it. Meanwhile, Googlebot is doing extra work every single crawl, and you're slowly burning through your crawl budget on unnecessary hops.

The Crawl Budget Problem Nobody Explains Well

Crawl budget is a concept Google introduced primarily to explain how it allocates crawler resources across a site. For smaller sites (under a few hundred pages), it's almost never an issue — Google will crawl everything. But the moment you have thousands of pages, tens of thousands of products, or any kind of dynamic URL structure, crawl budget becomes real.

Here's the thing: redirect hops cost crawl budget the same way pages do. When Googlebot follows a four-hop chain to reach one page, that's four crawl requests consumed to index a single URL. On a site with 500 chained URLs averaging three extra hops each, that's 1,500 wasted crawl requests that could have gone toward indexing real content.

For e-commerce and publishing sites with high page counts, this is a silent indexation killer. New products don't get discovered because the bot spent its daily crawl budget chasing redirect trails on old URLs that should have been cleaned up two relaunch cycles ago.

PageRank Dilution Is Real — Even If Google Downplays It

Google's official line has softened over the years. They've said that a 301 redirect passes "nearly all" PageRank. But "nearly all" is doing a lot of work in that sentence. There's still some loss per hop — estimates put it somewhere between 5–15% per redirect — and that loss compounds.

If a high-authority page links to your URL via a three-hop chain, by the time that link equity reaches your final destination, you might be working with 70–80% of what was actually sent. That's not catastrophic on its own. But multiply that across every inbound link that hits a chained URL, and you're leaving meaningful authority on the table.

I've seen sites clean up redirect chains and not see dramatic ranking jumps. But I've never seen a site that cleaned up redirect chains and got worse. It's a hygiene issue — one that compounds when stacked with other technical problems.

Where Redirect Chains Like to Hide

Most redirect chains aren't obvious. If you're just checking pages you remember migrating, you'll miss the ones that crept in via other routes. Here are the most common hiding spots:

Your HTTP → HTTPS layer

If you switched to HTTPS years ago but kept old HTTP redirect rules AND later restructured your URLs, you've got chains. The HTTP URL redirects to HTTPS, which redirects to the new slug. That's already two hops, and your CDN might add a third if it handles the www redirect separately.

Blog or CMS slug changes

You changed a post's slug to be more SEO-friendly. Then six months later you changed it again because you realized the keyword was different. WordPress or your CMS dutifully stacked a new redirect on top of the old one. You now have a three-hop chain to reach what should be a single URL.

After site merges or acquisitions

This is the worst. You acquire a domain, redirect it to your main site using broadly configured rules, then your main site itself gets restructured. Everything from the old domain now hits the new domain rules on top of the old rules. Six-hop chains aren't uncommon here.

Campaign or tracking URLs

Short links, UTM parameter strippers, vanity URLs for print ads — these often add a hop or two before you reach the real page. If Googlebot follows these (and it does if they're linked internally or externally), they count against your crawl budget.

How to Find Every Redirect Chain on Your Site

There are a few ways to do this, ranging from manual to automated:

How to Actually Fix Redirect Chains (Without Breaking Everything)

The fix sounds simple: update each redirect so it points directly to the final URL, eliminating the middle hops. In practice, it requires care because you're touching redirect rules that might be relied upon in ways you don't expect.

Here's the safe approach:

• Map the full chain first — document every URL in every chain before touching anything. You need to know where everything points before you start changing rules.
• Update all intermediate redirects to point directly to the final destination — don't delete intermediate URLs, just change where they point. Old inbound links might still use those intermediate URLs.
• Fix internal links that point to non-canonical URLs — your own site shouldn't be sending traffic through redirects. Update hrefs to the final URL directly.
• Check for loops immediately after making changes — it's easy to create a loop when restructuring chains. Test everything before pushing to production.
• Update your XML sitemap — make sure your sitemap contains only final canonical URLs, not redirect intermediaries. Googlebot shouldn't have to follow a redirect just to crawl your sitemap entries.
• Monitor crawl stats in Search Console — after fixing, watch your crawl stats for a few weeks. Properly cleaned-up chains should reduce crawl errors and show more pages being successfully crawled per day.

Why This Matters More Post-May 2026 Core Update

The May 2026 Core Update finished its rollout in late May, and the pattern that emerged is consistent with what we've been seeing for years: sites with clean technical foundations held their rankings better than sites with accumulated technical debt. That's not the whole picture — content quality, E-E-A-T, and site authority all played roles — but technical SEO was clearly a differentiator in the volatility data.

Redirect chains are exactly the kind of accumulated technical debt that tips the scales. They don't sink you overnight. But they're part of the reason Site A holds its ground during a core update while Site B — equally good content, similar domain authority — loses 12% of its traffic. The difference is usually a stack of small technical problems that never got addressed, and redirect chains are always on that list.

Google has also been more aggressive about deduplicating URLs and consolidating how it handles redirects in its indexing pipeline. If your final canonical URL is being reached via a chain, Google might be less confident that it's the true canonical — and choose a different URL as its preferred version. That means your SEO work might be going to a URL you don't even consider the real destination.

How to Stop Chains From Coming Back

You can fix every existing chain on your site today and still be back to the same mess in a year if you don't change how redirects get added. A few practices that keep chains from accumulating:

Never redirect to a URL that already redirects. Before adding any redirect rule, test the destination URL first. If it returns anything other than a 200, you're about to create a chain. Always point to the final destination.

Keep a redirect map document. It sounds old-fashioned, but a spreadsheet tracking every live redirect (source → destination, date added, reason) makes chain detection trivial. When someone asks you to add a new redirect, check if the source is already a destination in your map.

Set redirect deprecation reviews into your CMS workflow. Redirects added during a campaign or site migration often outlive their usefulness by years. Every quarter, review your redirect table for rules that could be simplified or removed.

Build redirect cleanup into every site migration plan. The most common time chains are created is during migrations. Every migration plan should include an explicit step: "audit and flatten all existing redirect chains in the new setup before launch."