How to find and fix redirect chains slowing down your site

// published 2026-04-17

A redirect chain is when one URL bounces to another, which bounces to a third, before serving the actual page. Each hop adds 100-400ms of latency, blows your TTFB budget, and (worst case) loses link equity in the SEO sense. They're easy to introduce and easy to miss.

The four chains you'll find on a real site

1. HTTP → HTTPS → www → trailing slash

http://example.com/page    → 301 → https://example.com/page
https://example.com/page  → 301 → https://www.example.com/page
https://www.example.com/page → 301 → https://www.example.com/page/

Three hops, two of them avoidable. Each rule was added independently — by an SRE setting up HTTPS, then a marketer wanting www, then a CMS deciding it prefers trailing slashes. Nobody collapsed them.

2. Marketing redirect through a CDN tracker

Shortened links often redirect through a tracker (Bitly, Linktree, internal click tracker), which then redirects to the destination. If the destination then has its own canonical redirect, you get 3+ hops on every campaign click.

3. Geo / language redirect

"User from DE → /de", but they typed /en/page. Some sites do /en/page → / → /de/page, two hops just to ignore the user's choice. Or worse: /en/page → /de/page → /de/page/ with three.

4. Old → new path mappings via lookup

After a CMS migration, every old URL gets a 301 to its new equivalent. Six months later, you change the URL structure again. Now you have a chain: /old → /new → /newer. The first redirect was never updated.

How to flatten them

Audit first. Run the Redirect Chain Checker on every important URL: home page, top landing pages, top product pages, key marketing campaigns. Aim for ≤1 hop per URL.

Then collapse:

1. Multiple normalization rules? Combine them. nginx example:

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

   becomes:

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

   One rule, one hop.
2. Old → new chains? Walk the chain and replace each redirect target with the final URL. Bonus: when the chain breaks (e.g. final URL is a 404), you find the dead old URLs.
3. Tracker hops? Either drop the tracker (use UTM params on the destination URL) or accept the hop — but never chain two trackers.

Why it matters more than you think

• Mobile latency penalty: on a 3G/LTE connection, each redirect costs a full TCP+TLS handshake (200-400ms). Three hops = 1 second before any content loads.
• Crawler waste: Googlebot has a per-domain crawl budget. Every redirect uses one fetch. Chains burn the budget without indexing pages.
• Analytics drift: some referrer chains drop the original referrer header. Your "direct traffic" inflates while organic decreases — entirely a measurement artifact.

Edge cases

307/308 vs 301/302: 307/308 preserve method (good for POST), 301/302 don't. If your chain mixes them, you might be silently converting POSTs into GETs partway through. Audit the status codes, not just the count.

Mixed protocol chains: if any hop in the chain is HTTP, the entire chain becomes vulnerable to MITM downgrade — even if the final URL is HTTPS. Browsers don't always warn. Fix: never let an HTTPS request redirect to HTTP, ever.

Run the Redirect Chain Checker on your top URLs now and flatten anything over 1 hop.