A single 301 redirect barely costs anything. A chain of four of them, stacked up over years of URL changes nobody cleaned up after, is a different problem entirely. Each hop adds latency, burns a fraction of your crawl budget, and dilutes the link equity passing through it. None of that shows up as an error. It shows up as a slow, unexplained decline that nobody traces back to redirects because nothing is technically broken.
Why Redirect Chains Form in the First Place
Nobody sets out to build a four-hop redirect chain. It happens incrementally. A page moves from /blog/old-post to /articles/old-post during a site restructure. Two years later, /articles/ gets renamed to /resources/ during a rebrand, so a new redirect points /articles/old-post to /resources/old-post. The original redirect from /blog/old-post never gets updated to point directly at the final destination, so now a visitor or crawler hits two redirects in sequence to reach one page.
Repeat that pattern across a few migrations, a CMS switch, and a couple of URL structure changes, and chains of three or four hops accumulate quietly across a site's oldest and often most authoritative pages, the ones with the most external links pointing at outdated URLs.
What a Chain Actually Costs You
Google's own Search Central documentation is explicit that crawlers will follow a limited number of redirect hops before giving up entirely, and every hop in between adds latency to a crawl that's already competing against every other page on your site for a finite crawl budget. A chain doesn't just slow down the one URL involved, it eats into the budget available for crawling everything else.
Link equity passes through a chain with real, measurable attenuation at each hop, not total loss but also not the free pass through multiple redirects that some outdated SEO advice still implies. A backlink pointing at a URL three redirects deep is contributing meaningfully less ranking value than the same link would if it pointed directly at the final destination.
Photo by RDNE Stock project on Pexels
Step 1: Crawl the Site to Surface Every Redirect
You can't fix chains you don't know exist, and manually clicking through a site to find them doesn't scale past a handful of pages. A crawler that specifically reports redirect chains, following each hop and flagging anything beyond a single redirect, is the only practical way to surface the full list on anything larger than a small brochure site.
Run the crawl from your sitemap URLs specifically, not just from internal links, since a chain sitting on a page nothing internally links to anymore can still be actively crawled by Google if external backlinks or old sitemap entries still reference it.
Step 2: Distinguish Necessary Redirects From Accidental Chains
Not every multi-hop sequence is a mistake. A deliberate protocol upgrade, HTTP to HTTPS, combined with a separate URL restructure can legitimately require two hops in some server configurations. The distinction that matters is whether the chain is intentional infrastructure or the accumulated residue of redirects that were never cleaned up after later changes made an earlier hop redundant.
The fix for both cases is usually the same regardless of intent: update the source to point directly at the true final destination, collapsing however many hops existed into one.
Step 3: Flatten Every Chain to a Single Hop
Once you've identified a chain, the URL at the start should redirect directly to the final live URL, not to the intermediate stop along the way. This is a mechanical fix in most CMS and server configurations, updating the target of the original redirect rule rather than leaving it pointing at a URL that itself redirects elsewhere.
Do this systematically rather than one at a time as you happen to notice a chain, since a site with dozens of accumulated chains benefits from a single cleanup pass working through the full crawl report rather than piecemeal fixes that miss most of the list.
"The pattern I see most often during a technical audit isn't one catastrophic redirect mistake, it's forty small ones stacked up over five years of nobody owning the cleanup. Flattening them in one pass is usually a bigger crawl budget win than most content changes a team makes that quarter." - Dennis Traina, 137Foundry's technical SEO team
301 vs 302, and Why the Distinction Still Matters in a Chain
The HTTP semantics specification defines a 301 as permanent and a 302 as temporary, and search engines treat that distinction as a real signal, not a formality. A chain built entirely from 301s passes link equity relatively cleanly at each hop. A chain that includes even one 302 partway through introduces ambiguity, since a temporary redirect tells a crawler the original URL might come back, which affects how confidently it consolidates signals toward the final destination.
Auditing your chains is also the right moment to check whether every hop is actually using the redirect type you intended. It's common to find a 302 left over from a quick temporary fix during a migration that quietly became permanent in practice without anyone updating the status code to match.
Tools That Make This Practical at Scale
Manually checking redirects one URL at a time works for a handful of pages and falls apart past that. A dedicated site crawler, Screaming Frog is the tool most technical SEO audits reach for, is built specifically to follow redirect chains across an entire site and report the full hop sequence for every URL it finds, rather than just confirming whether the final destination eventually loads.
For sites without an existing crawl tool in their workflow, Ahrefs and similar SEO platforms include redirect chain reporting as part of their broader site audit features, pulling from both a live crawl and historical backlink data to flag chains sitting on pages with meaningful external link equity attached.
CDN and Edge Redirect Complications
Sites running behind a CDN or edge network add another layer where chains can hide. A redirect rule configured at the origin server can be joined by a completely separate redirect rule configured at the CDN edge, Cloudflare's page rules and redirect features being a common example, and the two layers don't always show each other's configuration in one place.
This is exactly how a chain can survive a cleanup that looked complete: the origin-level redirect gets fixed, but an edge-level rule from an earlier migration is still firing first, adding a hop the person doing the origin cleanup never saw. Checking the actual live response headers with a raw request, rather than trusting either configuration panel in isolation, is the only way to confirm what's really happening across both layers together.
Step 4: Update Internal Links, Don't Just Fix the Redirect
Flattening the redirect chain fixes what happens to a crawler or visitor hitting the old URL, but it doesn't fix internal links across your own site that still point at an intermediate URL in the old chain instead of the final destination directly. Every internal link forcing a visitor through even a single redirect is a small, avoidable latency cost and a missed opportunity to pass full link equity directly.
Photo by Irina Novikova on Pexels
Step 5: Watch for Chains That Cross Domains
The most dangerous version of this problem happens during a domain migration, where an old domain gets pointed at a new one, and individual page-level redirects on top of that get layered without anyone checking whether the final destination is actually correct. A redirect chain that crosses from an old domain through an intermediate redirect to a final URL on a new domain compounds both the crawl budget cost and the link equity dilution, since cross-domain redirects already carry more scrutiny from search engines than same-domain ones.
Step 6: Re-crawl to Confirm the Fix Actually Landed
After flattening chains, re-run the same crawl and confirm each previously chained URL now resolves in a single hop. CDN caching layers and reverse proxies occasionally serve a stale version of a redirect rule even after the origin server configuration is updated, so a page that looks fixed in your CMS can still chain in production until a cache clears.
A Realistic Cleanup Cadence
Treat this as a recurring maintenance task, not a one-time project. Every URL structure change, CMS migration, or rebrand is a fresh opportunity for new chains to form, and a site that gets audited once and never again will have accumulated a new batch of chains within a year or two of the next major change.
A quarterly crawl focused specifically on redirect chains, checked against your sitemap and your highest-traffic legacy pages, catches new chains early, before they've had months to accumulate the kind of backlink and crawl history that makes cleanup more consequential to get right.
Where This Fits Into a Broader Technical Audit
Redirect chains rarely travel alone. Sites that accumulate them over multiple migrations often have related issues in the same audit: orphaned pages still in the sitemap, duplicate content from old and new URL structures both still resolving, and internal links scattered across years of content still pointing at outdated paths. 137Foundry's technical SEO work treats a redirect audit as one piece of that larger crawl health picture rather than an isolated fix, since the same migration history that produces chains usually produces these adjacent problems too.
If your site has been through more than one URL restructure, rebrand, or CMS migration without a dedicated redirect cleanup afterward, there's a good chance a chain audit today turns up more than you'd expect. It's one of the few technical SEO fixes where the effort is entirely mechanical and the crawl budget recovered is immediate, without waiting months for a ranking algorithm to notice anything changed.
For more on how site structure and crawlability decisions compound over time, visit 137Foundry's services hub or read more from 137Foundry about the technical work behind sites that actually perform the way they're supposed to.
