A few months ago we pulled up a client’s website during an audit and found a redirect that went to another redirect, which went to another redirect, which finally landed on a page that had been deleted two years earlier. Four hops just to reach a 404. Nobody built that on purpose. It happened one small decision at a time: a URL restructure in 2021, a redesign in 2023, a rebrand in 2024, and a deleted page that nobody realized was still sitting at the end of the chain the whole time.
That’s how almost every redirect chain we find gets built. Nobody sits down and designs one, they just pile up slowly as one decision stacks on top of an older decision that nobody ever goes back to check.
Before we get into how to deal with this and what fixes lie ahead, I want to clear something up, because a lot of what gets repeated about redirect chains online is outdated or flat-out wrong. You have probably read that every redirect loses a fixed percentage of its link value, or that too many redirects will automatically tank your crawl budget, or that any chain longer than one hop is quietly punishing your rankings. None of that accurately reflects how Google has actually described redirects working. The real explanation is more practical, but there are still plenty of reasons to clean these broken 301 redirects up.
TL;DR – Key Takeaways
- A redirect chain happens when one redirected URL points to another redirected URL instead of going straight to the final page
- Google says permanent redirects do not lose a fixed percentage of link value at each hop, despite what a lot of SEO advice still claims
- Chains still add latency, waste crawl requests, delay signal consolidation, and create more places for something to break
- A 301 means permanent, a 302 means temporary, and mixing them inside a chain sends a confusing signal about which URL should really be trusted
- Internal links should point straight to the current URL instead of riding through a redirect
- Screaming Frog can surface every chain, loop, and dead-end redirect on a site in one crawl
What a Redirect Chain Actually Is
A single redirect is simple enough. An old URL changes, and the server tells anyone who asks for it, “that page moved, go here instead.” One request, one instruction, one final page.
A chain is what happens when the destination has also moved too, so Page A points to Page B, and Page B points to Page C, and nobody ever went back to update Page A. The browser has to make two or three separate round trips before it ever sees real content. We’ve found redirect chains running five and six hops deep on sites that have been through several redesigns over the years, each one adding a new layer of redirects without anyone checking what was already sitting underneath it.
It reminds me of a mail forwarding order. You move once and forward your mail, no problem. You move four times over ten years and never update the order at each stop, and a letter addressed to your very first apartment ends up bouncing through three other addresses before it reaches you. It usually still arrives, but it took far longer than it should have, and there is a real chance it gets lost somewhere along the way. Google has said Googlebot will follow up to 10 redirect hops before giving up, but its own guidance still recommends sending visitors and crawlers straight to the final destination whenever you can, rather than leaning on that limit.
How Do Redirect Chains Build Up Over Time?
Nobody plans a chain, or at least they shouldn’t! For the most part, they are leftovers of ordinary website changes stacking on each other without anyone checking the layer underneath. A service might start at /services/plumbing-repair/, get renamed to /repairs/plumbing/ with a redirect in place, then get reorganized two years later into /plumbing/residential-services/. If whoever made that second change points the redirect from the second URL to the third instead of fixing the very first one, you end up with three URLs daisy-chained together instead of one clean hop.
We see this same pattern after permalink changes, full redesigns, new online store software, domain moves, and WooCommerce category name changes. None of these are mistakes on their own. The mistake is never circling back to check whether the new redirect lines up with what already existed, and since the site keeps working the whole time, these chains can sit there for years without anyone noticing.
Part of what makes them tricky to clean up is that WordPress redirects rarely live in one place. We have seen them scattered across Rank Math, Yoast, the Redirection plugin, the site’s .htaccess file, Cloudflare page rules, and the hosting company’s own control panel, sometimes all on the same website, with Page A redirecting through Rank Math, Page B via an.htaccessrule, and Page C caught by Cloudflare before WordPress ever sees the request. If you check only one redirect manager, you may be only seeing part of the picture, so adding a new rule on top without finding where the earlier redirects actually live creates an even bigger headache for the future.
The Myth That Every Redirect Loses Link Value
One of the most repeated claims about redirects is that every 301 quietly drains a percentage of its link equity, and that each extra hop bleeds off another chunk. You will still find articles insisting a redirect only passes 85 or 90 percent of its value along. That explanation is outdated. Google’s current documentation on site moves is pretty clear that permanent redirects do not cause a fixed loss in PageRank, and there is no secret percentage disappearing at each hop.
That doesn’t make chains harmless, it just means the real problem is different than advertised. Google still has to crawl and process every URL in the chain before reaching the final page, which can delay its ability to consolidate signals and recognize the preferred destination.
Problems start to happen when the chain ends at a 404, when one of the hops is blocked from crawling, when the destination has nothing to do with the original page, or when temporary and permanent redirects get mixed together without a clear reason. Personally, I’ve used a 302 redirect maybe 4 or 5 times in 25 years, usually for an event that was time- or date-sensitive. Beyond that, 301 permanent redirects are what I have relied on.
The Myth That Chains Automatically Destroy Crawl Budget
Redirect chains also get blamed for wrecking crawl budget, and there is a kernel of truth in there, but it gets overstated constantly for small sites. Crawl budget is really just the number of URLs Googlebot can and wants to crawl on your site, and every extra hop is one more request that returns no actual content. That is genuinely inefficient, and Google has said as much, but a 20-page small business site is not one redirect chain away from a crawling crisis.
Crawl efficiency starts mattering a lot more on large ecommerce sites, publishers running thousands of articles, and sites that have been through a huge migration with thousands of URLs on the move. 99% of people reading this article will never have to really care about crawl budget; your site simply isn’t large enough.
For most of the local business sites we work on, the real cost of a redirect chain is not some dramatic crawl budget problem. It is the wasted requests, the added load time, and the fact that every extra hop creates another place where something can quietly break.
Permanent and Temporary Redirects Are Not the Same Thing
Part of what makes a chain messier to untangle is that not every redirect in it is even saying the same thing. A 301 means a page has permanently moved, which is the right call when a page has been renamed or multiple pages have been merged together. Google treats that as a real signal that the new URL should become the one it trusts going forward.
A 302 says something different: this move is temporary; keep the original URL in mind. That is the right code for short-term maintenance, a temporary promotion, or a page you genuinely expect to bring back later. The trouble we see is not that temporary redirects are bad for SEO, it is that they get used out of habit and then left in place for years, at which point they are not really temporary. We have found 302s sitting untouched on client sites because of a migration that happened three or four years previously, and here they are still telling Google “don’t get too attached to this,” long after the change had clearly become permanent.
Mixed signals of both 301 and 302 instructions on the same chain can become a problem too. A URL that was permanently moved via a 301, only to hit a 302 further down the chain, is sending a mixed signal about which page actually deserves to be treated as the real one. Those mixed instructions can delay consolidation and make it less clear which URL Google should ultimately treat as the permanent destination. That’s something that needs to be addressed.
What Actually Slows Things Down?
Every redirect adds a full request and response cycle before the real page loads. On a fast server, that one extra hop is barely noticeable, but it adds up fast when the hosting is already slow, the visitor is on mobile, or the chain crosses between HTTP and HTTPS with a CDN adding its own processing on top.
The other place we clean up constantly is internal links still pointing at a redirected URL instead of the real one. Redirects exist for traffic you cannot control: an old bookmark, a backlink on another site, a brochure still floating around with the old URL printed on it. Your own internal links do not need that excuse. If a menu item, a blog post, or a product link is still pointing at Page A instead of the current Page C, update it. The redirect from Page A can keep running for outside traffic, but there is no reason for your own site to route its own visitors through it.
How to Find Redirect Chains With Screaming Frog
Screaming Frog can find all the redirect chains, loops, and dead ends in a single crawl. It is the same tool we used for the published and modified date extraction we wrote about previously. A normal Spider Mode crawl, followed by Reports -> Redirects -> Redirect Chains, shows every chain currently reachable from the live site, every hop, the status code at each step, and the final destination. Pay close attention to anything ending in a 404, a 5xx error, a noindex page, or somewhere unrelated to where the URL started.
The catch is that Spider Mode only finds URLs it can still discover by crawling the current site. If you are auditing a migration or checking old URLs that nothing currently links to, switch to List Mode, upload the historical URLs from an old sitemap, Search Console, or a client-supplied list, turn on Configuration → Spider → Advanced → Always Follow Redirects, and run the crawl from there. That is the only way to catch chains hiding on URLs the current site no longer links to at all.
Fixing Redirect Chains the Right Way
The goal is simple even when the cleanup itself takes patience. Every historical URL should point straight to the final live destination, not through whatever came before it. If Page A goes to Page B and that goes to Page C, update Page A to redirect directly to Page C, and update your internal links to point at Page C while you are at it. Do not assume Page B’s redirect is useless once Page A no longer needs it. Page B might still be catching backlinks, bookmarks, or traffic from an old email campaign, so it still deserves its own direct line to Page C rather than getting deleted outright.
It is also worth resisting the urge to redirect every dead page straight to the homepage just because a 404 feels worse. A redirect should lead somewhere that actually replaces what was there. An old plumbing service page should point to the current plumbing page, not a homepage with nothing relevant on it. When there truly is no equivalent page anymore, a proper 404 is often more honest than forcing visitors onto a page that has nothing to do with what they clicked. Some people are tempted to dump old blog posts to the main /blog/ page, but I encourage you to resist. Google has been known to treat those mismatched redirects as soft 404s anyway, which defeats the purpose of setting one up in the first place.
How Often Should You Check for Redirect Chains?
Most small business sites do not need to think about this weekly. Once or twice a year is plenty for a stable site, and it is worth doing right after a redesign, a domain change, or a hosting migration, since those are exactly the moments new chains get created. A site redesigned three or four times over a decade tends to have more of these buried underneath than one that launched last year, simply because there has been more time for old decisions to stack on top of each other.
Need Help Cleaning Up Old Redirects?
Redirect chains rarely announce themselves. The site still loads, pages still work, and nobody notices that old URLs are quietly bouncing through two or three systems before reaching the page that actually matters. If your WordPress site has been through a few redesigns, migrations, or domain changes over the years, there is a good chance some of that is still sitting under the surface right now.
This is exactly the kind of technical cleanup we handle as part of our SEO audits and ongoing SEO services. We crawl the current site, test the historical URLs, track down where each redirect actually originates, and rebuild the paths so visitors and search engines land where they are supposed to, directly.
Call us at (402) 522-6468 or contact Kim and Conor if you want a second set of eyes on your redirects.
