Redirect Chains and Loops: What They Are, How to Fix Them

A redirect chain happens when a URL takes more than one move to reach its final destination, bouncing through one or more intermediate URLs first (A → B → C → final). Every hop adds latency, costs a crawl request, and gives ranking signals one more chance to get lost. Chains build up quietly across years of migrations, plugin swaps and forgotten rules, and they are one of the cheapest technical wins in most audits: flatten them and you get faster pages and cleaner signal transfer for the cost of a config edit. A redirect loop is the broken cousin, a chain that circles back on itself and never resolves.

Redirect Chain

A redirect chain is a sequence of two or more consecutive HTTP redirects in which the original URL points to an intermediate URL that itself redirects, repeating until the request finally resolves to a live page.

How redirect chains form

Nobody builds a chain on purpose. They emerge as redirect rules pile up and nobody reconciles the old ones. The most common origins:

• Stacked migrations. You moved /blog/post → /articles/post last year, then moved /articles/ → /learn/ this year. Now /blog/post → /articles/post → /learn/post is a two-hop chain, because nobody updated the first rule to point at the final target.
• HTTP-to-HTTPS plus www normalization. http://example.com → https://example.com → https://www.example.com is three states resolved in two hops. Collapse it into one rule and you save every visitor and bot a round trip.
• Trailing-slash and case rules layered on top of content redirects.
• CMS plugins fighting server config. A WordPress redirect plugin and an Nginx rule can both fire on the same request, producing a hop you cannot see from either tool alone.
• CDN or reverse-proxy rules added at the edge, unaware of origin redirects.
• Tracking and affiliate wrappers that bounce through one or more measurement domains before the real landing page.

The pattern is always the same: a redirect points at a URL that is itself a redirect. Fixing the chain means rewriting the source rule so it points straight at the final page that returns 200 OK.

Why redirect chains hurt SEO

A single, clean 301 is harmless; it is the standard way to tell search engines a page has moved for good. The damage comes from stacking them.

Crawl budget. Each hop is a separate request a crawler has to make and follow. On a large site, thousands of multi-hop chains mean Googlebot spends its crawl budget chasing redirects while real content waits to be discovered and refreshed. Google’s crawlers follow up to 10 hops; past that, the URL shows up as a redirect error in Search Console’s Page indexing report and the page does not get indexed.

Link equity. Google has said 30x redirects pass PageRank without loss, and that holds for a redirect that resolves cleanly. Long chains raise the odds that something breaks along the way (a hop times out, a temporary code slips in, one hop lands on an error), and any of those can stop signals flowing through. The safe engineering stance is to minimize hops so there is nothing to leak.

Speed and Core Web Vitals. Every hop is another round trip before the browser starts loading the real page, plus a new DNS lookup and TLS handshake whenever the hop changes host. On mobile networks that is a visible stall, the kind of latency that drags on real-user metrics. See how site speed influences SEO.

Indexing ambiguity. Long or inconsistent chains make it harder for Google to settle on the canonical URL. If a chain ever lands on a 404 or soft 404, the signals dead-end entirely.

Analytics decay. Referral and campaign parameters can get dropped or rewritten across hops when a rule fails to carry the query string, corrupting attribution.

Redirect status codes, decoded

Knowing which code to use is half the battle:

The two rules that prevent most chains: use 301 (or 308) for anything permanent, and never use a temporary code (302/307) for a permanent move. Google treats a 301 as a strong signal that the target is the URL to index and a 302 as a weak one, so a misused 302 can keep the old URL in the index and invites the layered confusion that breeds chains.

How to find redirect chains

Detection runs from a quick spot-check to a full inventory:

1. Single-URL header trace. Run curl -sIL https://example.com/old-page and read the sequence of HTTP/... status lines and Location: headers. Each 3xx before the final 200 is a hop.
2. Full-site crawl. Screaming Frog, Sitebulb and Ahrefs Site Audit all report redirect chains. Crawl, filter for any chain with more than one hop, and export it.
3. Server logs. Grep access logs for sequences of 3xx responses to spot chains real users and bots are hitting in the wild.
4. Google Search Console. URL Inspection shows where a URL ends up, and the Page indexing report lists “Page with redirect” and “Redirect error” at scale.
5. Automated monitoring. For sites where redirects change often, alert whenever any path exceeds one hop, so chains never accumulate again.

How to fix redirect chains

The fix is simple in concept (repoint every source URL directly at its final destination). The discipline is doing it completely, so you do not recreate the chain next quarter.

1. Inventory every rule. Export redirects from your CMS, .htaccess or Nginx config, CDN and any plugins. Chains usually hide between layers, so you need all of them in one place.
2. Map source to final. Build a sheet: original URL, every intermediate hop, and the true final destination (the page that returns 200).
3. Flatten to one hop. Rewrite A → B → C as A → C and B → C, both as 301 for permanent moves.
4. Consolidate the source of truth. Pick one layer (usually server config) to own redirects and remove duplicate or conflicting rules elsewhere.
5. Fix internal links first. This is the highest-leverage step most people skip: update internal links, XML sitemaps, canonical tags and hreflang to point at the final URL, so your own pages stop generating redirects. Clean website architecture means your pages never link through a redirect. Pair this with sane URL optimization so new URLs stay stable.
6. Chase high-value external links. Where a strong referring domain points at an old URL, ask them to update it, a natural extension of any link building program.
7. Retest and monitor. Re-crawl and re-trace headers to confirm single-hop 301s, then schedule periodic checks. Roll the same pass into broken-link cleanup with find and fix broken links.

Redirect chains vs. redirect loops, and how to fix a loop

A redirect loop is a chain that circles back on itself (A → B → A) and never resolves, so the browser stops with ERR_TOO_MANY_REDIRECTS. A chain taxes the page; a loop takes it offline for users and crawlers alike.

Loops almost always come from two rules that disagree:

• HTTPS fighting the CDN. The origin forces HTTPS while the CDN talks to it over HTTP (Cloudflare’s “Flexible” SSL mode is the classic case), so every HTTPS request comes back as HTTP and is redirected again. Set the CDN to connect over HTTPS.
• Trailing slash or www rules in two places, one adding what the other removes.
• CMS address settings that disagree with the server, such as a WordPress site URL set to http:// behind a rule forcing https://.
• Redirect maps that point back at their own source, often after a second migration reused old paths.

To fix one, trace it with curl -sIL until you see the URL repeat, find the two rules responsible, and delete or rewrite one of them so a single layer owns that decision.

When redirect chains become a business problem

On a site with a few hundred URLs and one clean migration behind it, a free crawler and an afternoon fix every chain you have.

Chains start costing money after the second or third migration. Old backlinks pass through four hops, a temporary 302 left from launch week still sits in the middle, the sitemap lists URLs that redirect, and nobody knows which layer owns which rule. That is also the moment teams plan the next move, and carrying the debt into it multiplies it.

Our website migration work starts with a complete URL map: every old URL, including ones from earlier platforms, pointed in one hop at its final page and checked on launch day. On Prawomat, the build failed if any of the 1,125 migrated URLs went missing; the release as a whole, which also rewrote content and pruned URLs, took daily Google clicks up 2.9x in 19 days.

Frequently Asked Questions

How many redirects is too many?

More than one. A clean setup resolves every URL in a single hop, one 301 straight to the final destination. Two or more consecutive redirects form a chain worth flattening. Google’s crawlers stop following after 10 hops and Chrome gives up after 20, but speed and crawl efficiency degrade long before either limit, so treat anything past one hop as debt.

Do redirect chains hurt SEO?

Indirectly, yes. Chains slow page loads, waste crawl requests, and raise the risk that link equity or canonical signals get lost across hops. A single clean 301 passes PageRank fine; the problem is stacking them. Flattening chains to one hop protects speed, crawl efficiency and ranking signals at once.

How do I fix redirect chains?

Export every redirect rule from your CMS, server config and CDN, map each source URL to its final 200 page, and rewrite every rule so it points there in one 301. Then update internal links, sitemaps and canonical tags to the final URLs, and re-crawl to confirm no chain is left.

What’s the difference between a redirect chain and a redirect loop?

A redirect chain eventually resolves to a real page after multiple hops (A → B → C → final). A redirect loop never resolves: the URLs point back at each other in a cycle (A → B → A), so the browser throws a “too many redirects” error and the page is inaccessible to users and bots.

How do I check a redirect chain for a single URL?

Run curl -sIL https://example.com/your-url in a terminal and read the output. Each HTTP/1.1 3xx line with a Location: header is one hop; the chain ends at the first 200 OK. Browser DevTools shows the same sequence in the Network tab with “Preserve log” turned on.

Should I use a 301 or 302 to fix a chain?

Use a 301 (or 308 if you must preserve the request method) for any permanent move, which is what a flattened chain almost always is. Google reads a 302 as only a weak signal that the target should replace the original, which can keep stale URLs indexed and invites new chains. Keep 302 and 307 for genuinely temporary redirects.