How Redirect Chains Hurt SEO

Published 27 April 2026

A redirect chain is a sequence of two or more redirects in a row before reaching the final destination. They're invisible to most users — the browser silently follows each hop and lands where it was going — but they cause real, measurable damage to your site's performance and SEO. The reason chains are so common is that they accumulate over time without anyone noticing: each individual redirect was added for a sensible reason, but together they form a messy daisy-chain that nobody planned.

This guide covers what chains do to your site, why they keep appearing, how to find them, and how to flatten them.

What a Redirect Chain Looks Like

The simplest example: you renamed /old-page/ to /middle-page/ last year, then renamed it again to /new-page/ this year. The chain is:

/old-page/      → 301 → /middle-page/
/middle-page/   → 301 → /new-page/
/new-page/      → 200 OK

Two hops to reach the final page. Older bookmarks, indexed search results, and inbound links all hit the chain. Each request takes longer, and each hop is one more chance for something to go wrong.

The chains we see in real audits are usually longer:

http://example.com/Old-URL/      (typo capital O)
  → 301 → http://example.com/old-url/  (lowercase normalisation)
  → 301 → https://example.com/old-url/  (HTTPS upgrade)
  → 301 → https://www.example.com/old-url/  (canonical host)
  → 301 → https://www.example.com/new-url/  (page rename)
  → 200 OK

Five hops. Every browser, every crawler, every API client takes the entire chain. None of those redirects are individually wrong — but together they're a mess.

What Chains Cost

Latency

Each hop is a full HTTP round trip — DNS lookup (cached), TCP handshake (often skipped via keep-alive), TLS handshake (often resumed), and the actual request and response. Even with everything optimised, each hop typically adds 50–200ms. A five-hop chain easily adds half a second to first paint, before the browser has even seen the real page's HTML.

Mobile networks are worse. Latency is higher, connections are less likely to be kept alive, and TLS resumption is less reliable. We've measured chains adding over 1.5 seconds on 4G to high-latency origins.

Diluted link equity

Google has stated that link equity is preserved across 301 redirects, and recent statements suggest no per-hop loss for chains under a few hops. That said, the practical reality is messier:

• Crawlers may stop following chains after a certain depth (Googlebot follows up to 10 redirects, but treats chains over 5 as low quality).
• Other search engines have stricter limits.
• Some link-equity-aware tools (Ahrefs, Moz) attribute equity to the first non-redirect URL only.
• Even if equity flows perfectly, the indexer's confidence drops with each hop.

The safe assumption: every hop costs something, even if the cost is small. Multiply by the number of inbound links to your site, and the cost adds up.

Wasted crawl budget

Search engines allocate a finite crawl budget to each domain. Every URL in a redirect chain consumes a crawl request. If Googlebot has to follow five hops to read one page, that's five times less time spent crawling your other pages. Large sites with thousands of redirects can find themselves indexed less frequently than they otherwise would be.

Application bugs

Some HTTP clients don't follow redirects at all by default — including a lot of API libraries and webhook receivers. Others follow them but limit chain depth. A chain that "works fine" in your browser may be silently failing for integrations you don't think about often.

Why Chains Form

Most chains accumulate because each redirect was added independently:

• Layered URL normalisation. One rule lowercases, another forces HTTPS, another forces www. If they're separate rules, each one redirects separately.
• Multiple URL renames over time. Page A was renamed to B, then B to C. The A→B rule was never updated to skip B and go straight to C.
• Migrations that didn't clean up. Old domain →new domain → new structure on new domain. Three rules each added in a different migration project.
• Plugin chaos. WordPress sites often have a redirect plugin, plus rules in .htaccess, plus rules in a security plugin, plus rules at the CDN. Each layer adds its own hops.
• HTTPS upgrades not stacked. The HTTPS-forcing rule fires after a path-renaming rule, instead of before, producing two hops where one would do.

Finding Redirect Chains

The fastest check for a single URL is curl with verbose redirect tracing:

curl -sLI -w "%{redirect_url} -> %{http_code}\n" -o /dev/null https://example.com/some-url/

For a site-wide audit, you have a few options:

• Broken Link Finder — scans every link on a page and flags chains explicitly. Free, no signup.
• Screaming Frog — desktop crawler that maps every redirect on a site, including chain length.
• Server logs — if you have access, grepping for 301 and 302 status codes shows you the redirects most-followed in production. The biggest chains are usually the ones serving the most traffic.
• Google Search Console → Pages → Page with redirect — Google explicitly tells you which URLs in the index have redirects. Cross-reference with your sitemap to find URLs that shouldn't redirect at all.

Flattening a Chain

The fix is conceptually simple: every redirect should go directly to the final destination, not to another redirect.

For our earlier 5-hop example, the flattened version is:

http://example.com/Old-URL/         → 301 → https://www.example.com/new-url/
http://example.com/old-url/         → 301 → https://www.example.com/new-url/
https://example.com/old-url/        → 301 → https://www.example.com/new-url/
https://www.example.com/old-url/    → 301 → https://www.example.com/new-url/

Four redirects, but each one is a single hop. Anyone hitting any of the legacy variants reaches /new-url/ in exactly one round trip.

To flatten:

1. Build a redirect map. A spreadsheet with two columns — old URL, final destination URL. For every URL that currently redirects, the destination is the final page after following the entire chain (not the next hop).
2. Test against the map. Run every URL through curl or Broken Link Finder to confirm the actual final destination matches what you've written.
3. Replace the existing rules with single-hop rules that go directly to the final destination.
4. Re-test the entire map. Each URL should now resolve in exactly one redirect.

Stacking Normalisation Rules

The redirect rules that handle protocol and host normalisation should be stacked into a single redirect, not chained. In nginx, this typically means:

# Catch all variants in one server block
server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;

    if ($scheme != "https" || $host != "www.example.com") {
        return 301 https://www.example.com$request_uri;
    }

    # serve content from here
}

This way http://example.com/foo reaches https://www.example.com/foo in exactly one hop, regardless of which combination of wrong-protocol and wrong-host the visitor arrived with.

Updating Internal Links

Even after redirects are flattened, every chain represents an internal link or external bookmark that points to the wrong URL. The redirect handles the immediate problem, but you should also update internal links so visitors and crawlers stop hitting the redirect at all:

• Update internal links to point directly to the new URL. Skip the redirect for navigation, footers, and content links you control.
• Update sitemap.xml so it lists the canonical URL only. Search engines should never see a redirected URL in your sitemap.
• Update canonical tags so each page's <link rel="canonical"> points to itself, not to a redirected variant.
• Update structured data (Open Graph, Twitter Cards, schema.org URLs) for the same reason.
• Reach out to high-value external linkers if the link is valuable. Most won't update, but a polite request to a major site that's been linking to your old URL for years often gets the link updated to the canonical version.

The Maintenance Pattern

Chains will keep forming as long as your site keeps evolving. The maintenance pattern that works:

• Audit redirects monthly or quarterly with Broken Link Finder or a similar tool.
• Whenever you add a new redirect, check whether the destination URL itself is a redirect. If so, point the new rule at the final destination instead.
• Whenever you change a URL, search the codebase for any redirect rule whose destination is the URL being changed, and update those too.
• Use a single, authoritative redirect manager (one plugin, one config file) — fewer layers means fewer chances for layers to chain.

Done well, a site with thousands of redirects can still keep every chain at exactly one hop. That's the goal.