Redirect chains and the ranking they quietly eat

What a redirect chain actually is

A redirect chain is what happens when URL A redirects to URL B, which redirects to URL C, which finally lands on URL D. Nobody planned it that way. It’s the result of a site’s history: an HTTP to HTTPS move in 2019, a www to non-www swap in 2021, a URL restructure in 2023, and an affiliate link cloaking layer stacked on top for good measure. Each change added its own redirect rule, and nobody went back to check whether the old rules still pointed somewhere sane.

A single redirect, A to B, is normal and mostly harmless. A chain of three or four hops before a crawler or a visitor reaches the real page is a different problem, and it’s one I find on almost every site that’s been live for more than a few years.

Why chains build up without anyone noticing

Nobody sits down and designs a redirect chain on purpose. They accumulate because each migration is handled in isolation.

You move from HTTP to HTTPS, so every HTTP URL redirects to HTTPS. Fine. Two years later you switch from www to non-www, so every www URL redirects to non-www. Also fine, on its own. But if the HTTPS rule still targets the www version, and the www rule now points to non-www, you’ve just built a two-hop chain without touching either rule directly. Add a third change, like moving /blog/ posts to /articles/, and the old blog URLs might redirect to /blog/post-name, which then redirects to /articles/post-name. That’s three hops from an old inbound link before a crawler even sees real content.

WordPress makes this worse. Redirection plugins, SEO plugins with their own redirect managers, and hosting-level rules can all be active on the same site, each unaware of what the others are doing. I’ve opened Screaming Frog on client sites and found five separate redirect rules stacked on a single legacy URL, written by three different tools over three different years.

What each hop actually costs

I’m not going to tell you Google discounts link equity by some fixed percentage per hop, because I don’t have that number and neither does anyone claiming to. What I can tell you is what’s observable and testable on your own site.

Latency. Every redirect is a round trip. The browser or crawler requests URL A, gets a 301 response, then has to request URL B. If B redirects to C, that’s a third request. Each hop adds real time before any content loads, and that time shows up in Core Web Vitals metrics like Largest Contentful Paint if the redirect is on the critical path (for example, the canonical URL a crawler discovers through an internal link, or a URL you’re actively sending traffic to).

Crawl budget. Googlebot has a finite amount of attention for any given site, and that budget is spent on requests, not on final destinations. A crawler that has to follow three hops to reach a page has spent three times the requests to index one URL. On a small site this barely registers. On a site with tens of thousands of URLs and a crawl budget that’s already tight, redirect chains are one of the more wasteful ways to burn it.

Signal confusion. Canonicalization, internal linking, and redirect targets are all signals search engines use to figure out which URL is the real one for a page. When those signals point through multiple intermediate URLs instead of straight at the final one, you’re making the resolution process messier than it needs to be. I don’t know the exact mechanics Google uses to process that, and anyone who tells you they do is guessing. What I do know is that clean, direct signals are easier to trust than chains that require unwinding.

Broken chains. The real damage usually comes from the chain that eventually breaks. A redirect rule gets removed during a plugin update, or a hosting migration drops one hop in the middle, and now the chain 404s instead of resolving. I’ve seen this happen after routine WordPress plugin swaps, where the new redirect manager didn’t import every rule from the old one. Old backlinks and old bookmarks that were happily redirecting for years suddenly go nowhere.

Finding chains on your own site

You don’t need expensive tooling for this. A few approaches that work:

Crawl your own site with Screaming Frog (or a similar crawler) and export the redirect chains report. It will show you every hop from start to finish, which is the fastest way to see how deep the problem actually goes.

Curl from the command line. Running curl -IL against a URL shows every redirect hop with its status code. It’s slower than a full crawl but useful for spot-checking specific URLs, especially ones you suspect are chained.

Check your backlink profile against your redirect map. If you have a list of your top inbound links (from Search Console or a backlink tool), test each linked URL manually. This is where chains do the most damage, because you often can’t fix the anchor text or destination on someone else’s site. All you can control is how efficiently your own server routes that request once it arrives.

Read your server logs. If you have access to raw access logs, you can see exactly which URLs Googlebot is requesting and whether it’s hitting redirect chains during actual crawls, not just hypothetical ones.

Fixing them

The fix is almost always the same: point every redirect directly at its final destination instead of at the next link in the chain.

If A redirects to B and B redirects to C, change A to redirect straight to C. Do this for every hop you find. It sounds tedious because it is tedious, especially on a site with years of accumulated rules, but there’s no shortcut. Go rule by rule.

Update your internal links while you’re at it. If your own navigation, sitemap, or in-content links point to URL A when the real page is at URL C, fix those links to point directly at C. A crawler shouldn’t have to follow a redirect to get from your homepage to your own content.

Consolidate your redirect management into one place. If you’re running a redirect plugin, an SEO plugin with its own redirect manager, and server-level rewrite rules simultaneously, pick one system and migrate everything into it. Overlapping systems are exactly how three-hop chains get built without anyone deciding to build them.

For backlinks you don’t control, you can’t rewrite someone else’s anchor, but you can make sure your own redirect for that URL goes straight to the current page instead of through two more hops first. That’s the one lever you have.

What I won’t tell you

I’m not going to say fixing your redirect chains will move you up a set number of positions or that it’ll happen within a certain number of weeks. Redirect chains are one input among many, and their impact scales with how bad the problem is and how much of your crawl budget or backlink equity is routed through them. On a small site with a handful of chains, the practical effect might be closer to a faster page load than a ranking shift. On a large site with thousands of chained legacy URLs eating crawl budget, it can matter more.

I also won’t tell you that stacking redirects through a network of other sites, or routing link equity through a private blog network, is a safe way to consolidate signal. That’s a different risk entirely, and treating it as a shortcut around real technical cleanup is how people end up with a bigger problem than the one they started with.

The unglamorous checklist

Crawl your site and pull the redirect chains report. Fix every chain so it’s a single hop, source to final destination. Update internal links to point at final URLs, not intermediate ones. Consolidate redirect rules into one system instead of three overlapping ones. Recheck after any migration, plugin update, or URL structure change, because that’s when chains get built in the first place.

None of this is exciting work. It’s the kind of maintenance that never shows up in a screenshot, but it’s also the kind that keeps compounding if you ignore it long enough.

If you want more of this kind of unglamorous, specific technical SEO breakdown, come find us at The SEO Desk.