Redirect Chains and Loops: How to Detect and Fix Them
Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.
Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.
Redirect chains and redirect loops produce the same symptoms, so they get misdiagnosed frequently. They aren't the same problem, though, and the fix for one can make the other worse.
A chain quietly degrades performance and SEO without breaking anything. A loop breaks the page outright.
Confuse the two and before you know it, you're burning hours debugging the wrong thing, usually by adding another redirect rule, which is exactly what created the problem in the first place.
This article covers what each one is, why they happen, how to detect them, and how to fix them at the source.
For broader context on how redirect types and implementation methods fit together, see our URL Redirects Complete Guide.
Key Takeaways
- A redirect chain is a sequence of redirects where each one forwards to another redirect before reaching the final destination
- A redirect loop is a cycle where two or more redirects forward to each other endlessly, causing the page to fail entirely
- Both waste crawl budget and dilute link equity, but loops also break the user experience completely
- Google can follow up to 10 redirect hops but advises keeping a chain to no more than three, and under five at most
- DNS-level redirects eliminate chains by design because the edge resolves the final destination in a single hop
What is a redirect chain?
A redirect chain is a sequence of two or more redirects that fire in order before a request reaches the final URL. When a user types oldsite.com, the server returns a 301 to www.oldsite.com, which returns another 301 to https://www.oldsite.com, which returns one more to https://www.newsite.com. Three hops before the destination loads.
Each step in the chain is called a hop. A clean redirect has one hop: source to destination. A chain has two or more. Most chains start innocently and accumulate over time as teams add new redirect rules on top of old ones without cleaning up what came before.
That's why chains often go unnoticed until someone runs an SEO audit or notices their Core Web Vitals slipping.
What is a redirect loop?
A redirect loop is a cycle where redirect rules send traffic back and forth between URLs without ever reaching a final destination. URL A redirects to URL B, and URL B redirects back to URL A. The browser eventually gives up and shows an error like ERR_TOO_MANY_REDIRECTS (Chrome) or The page isn't redirecting properly (Firefox).
Loops break the page immediately. Users see the error message and bounce. Search engines abandon the crawl. There is no graceful degradation, no partial success, no slow page that eventually renders. The request just dies.
Loops can also be longer cycles: A redirects to B, B redirects to C, C redirects back to A. The principle is the same. Somewhere in the rule set, the path circles back instead of terminating at a final URL.
Why redirect chains and loops happen
Both problems share the same root cause: redirect rules layered on top of each other without anyone seeing the full picture. From my experience, these are the patterns that come up most often:
Slug changes that stack. A team renames /blog/old-name to /blog/new-name in 2024 and adds a 301. In 2026, they restructured to /resources/articles/new-name and added another 301. The original 2024 redirect still fires first, then the 2026 one runs. Two hops where one would do.
HTTP-to-HTTPS layered on existing rules. A site has a working www redirect from years ago. Then HTTPS gets enabled and a new rule forces HTTP to HTTPS. The non-www HTTP visitor now hits the www redirect first, then the HTTPS upgrade. Two hops, often unnoticed.
Conflicting www and non-www rules. This is the classic loop. One rule forces example.com to www.example.com. Another rule (maybe in a CDN, maybe in a CMS, maybe in .htaccess) forces www.example.com back to example.com. They cancel each other out and the browser bounces between them.
HTTPS rules clashing with hosting redirects. Your DNS provider redirects HTTP traffic to HTTPS. Your hosting also redirects HTTP to HTTPS. If one of them resolves the destination as HTTP, the other catches it and redirects again, and so on.
CMS-level redirects on top of CDN-level redirects. WordPress redirect plugins, Cloudflare Page Rules, and origin server redirects can all fire on the same request. Each layer is unaware of the others. Chains build up quickly when three systems each add their own hop.
The common thread: nobody designed these chains or loops. They accumulated. Most redirect problems come from layers of old rules nobody cleaned up, not from a bad initial setup.
The SEO impact: crawl budget, link equity, indexation
Redirect chains hurt SEO in three measurable ways.
Crawl budget gets wasted. Every hop is a separate HTTP request the crawler has to follow. Google's site-move documentation is explicit: Googlebot can follow up to 10 hops in a chain of redirects. The same documentation advises keeping a chain short anyway, ideally no more than three and under five. That's because long chains add latency and not every client follows them reliably. Past that ceiling, Google stops following and the final URL may not get crawled in that attempt.
Link equity dilutes. Google has confirmed that 301 redirects pass full ranking signals, but each additional hop introduces risk. A broken hop somewhere in the chain breaks everything downstream. And the more hops a crawler has to traverse, the higher the chance of timeouts or errors that prevent the final URL from being indexed at all.
Indexation slows down. Even when Google does follow the full chain, the latency adds up. On large sites with many migrated URLs, slow chain resolution means slower indexation of the new URLs and longer periods of unstable rankings during migration.
Redirect loops have a different SEO profile. They do not dilute equity, they destroy it. The crawler hits the loop, fails to reach a final URL, and may de-index the affected pages entirely if the problem persists.
The performance impact: latency per hop
Each redirect hop adds latency to page load. The exact amount depends on server architecture, geographic distance, DNS resolution, and TLS handshake costs, but real-world measurements consistently fall in a 50 to 300 millisecond range per hop. Independent testing has clocked anywhere from around 60 milliseconds per hop on a fast local setup to 280 milliseconds or more in production.
Chrome's performance documentation flags redirects as a Time to First Byte (TTFB) problem: each redirect forces the browser to make another request at the new location, and that extra trip across the network delays everything that follows.
This compounds. A three-hop chain at 200ms per hop adds 600ms of latency before the page even starts loading. On mobile networks or for users far from the origin server, the impact is worse. Core Web Vitals metrics like Largest Contentful Paint take a direct hit, because nothing useful is happening until the chain resolves.
Loops have no latency cost in the traditional sense, because they never resolve. The browser times out after roughly 20 redirects (the exact threshold varies by browser) and shows an error. The latency cost is the entire page load, plus a frustrated user.
How to detect redirect chains and loops
You cannot fix what you cannot see. These are the methods that actually work.
Browser DevTools. Open browser DevTools (right-click the page and choose Inspect, or use the keyboard shortcut for your browser), go to the Network tab, enable "Preserve log," and load the URL. Every hop appears as a separate row with its status code and destination. A chain shows multiple 301 or 302 rows. A loop shows the same URLs repeating until the browser gives up.
curl with the -L flag. The fastest command-line check. Running curl -IL https://example.com prints every hop in the chain with status code, response headers, and final destination. If you see the same URL appearing twice in the output, you have a loop.
redirect.pizza's free tester. Drop any URL into our redirect tester and see the full redirect path with status codes and response times per hop. Chains and loops are immediately visible. No signup, no install.
Screaming Frog SEO Spider. For auditing an entire site, Screaming Frog's list mode handles bulk URL checks. After crawling, filter to status code 3xx and sort by "Redirect Chain" length. Anything over one hop is a candidate for cleanup. Export to CSV for the audit workflow described below.
Online checkers. Tools like httpstatus.io or redirect-checker.org work for ad hoc checks of individual URLs. They show hop counts and final destinations but lack the depth of dedicated SEO tools for bulk work.
For most teams, the workflow is: use curl or the redirect tester for individual URLs while debugging, use Screaming Frog for periodic site-wide audits, and rely on DevTools when something breaks in production.
How to fix redirect chains
The fix sounds simple: rewrite every redirect rule to point directly to the final destination. In practice, this requires a methodical audit because chain components are often spread across multiple systems.
- 1
Export every redirect rule
Pull rules from your CDN configuration, .htaccess, nginx config, CMS redirect plugin, and any cloud provider page rules. Put them all in one spreadsheet.
- 2
Trace each chain to its endpoint
For each source URL, follow the redirects to the final destination. Record the final URL alongside the original rule. This is where curl -IL or a bulk tool like Screaming Frog earns its keep.
- 3
Rewrite rules to point to the final destination
Update every rule so its target is the final URL, not an intermediate. The two-hop chain A → B → C becomes the single hop A → C and B → C. Keep the original rules in place, just point them at the endpoint directly.
- 4
Do not delete intermediate redirects
External sites might still link to URL B. Removing the redirect from B breaks those external links. Keep the rule, just update its target.
- 5
Verify
Re-run the audit after deployment. Every source URL should now resolve in a single hop.
For sites with hundreds or thousands of redirects, this is where bulk import tools matter. Exporting current rules, editing in bulk, and reimporting via CSV is far faster than editing rules one by one in a UI. See our article on bulk domain redirects for the workflow.
How to fix redirect loops
Loops require a different approach because the problem is conflict, not accumulation. Two rules are fighting. You need to find them and pick a winner.
- 1
Identify the conflicting URLs
Use DevTools or curl to see which URLs are bouncing. The loop will be obvious: A goes to B, B goes back to A.
- 2
Check every system that touches the request
This is the hard part. A loop often involves rules in two different systems that are unaware of each other. Common pairs are a DNS-level redirect plus an origin server redirect, a CDN page rule plus a CMS redirect plugin, or an HTTPS upgrade rule plus an existing www-to-non-www rule (or vice versa).
- 3
Decide the canonical version
Pick one canonical URL pattern and stick to it. If you want https://www.example.com, every other variant (HTTP, non-www, both) must redirect to that final form, and nothing should redirect away from it.
- 4
Remove or rewrite the conflicting rule
Once you have decided on the canonical version, the fix is to delete or rewrite whichever rule contradicts it. If your DNS-level service is the source of truth, disable the equivalent rule in your CMS or CDN. If your CMS is authoritative, remove the conflicting DNS rule.
- 5
Retest from every entry point
Test the loop fix by visiting all four variants: http://example.com, http://www.example.com, https://example.com, and https://www.example.com. They should all end on the same canonical URL in a single hop.
If the conflict involves a www/non-www boundary, see redirecting non-www to www for the cleanest way to set this up.
Why DNS-level redirects eliminate chains by design
Most chains accumulate because there is a layer to stack on. .htaccess rules sit on top of nginx rules sit on top of CDN rules sit on top of CMS rules. Each system can add its own hop, and over time, they do.
DNS-level redirects work differently. The edge resolves the final destination directly. There is no application layer to add a second rule, no CDN page rule to bolt on, no plugin to override. A request hits the edge, the edge knows the final destination, the edge sends the user there. One hop.
This isn't a marketing claim, but how the mechanism works. When you set up a redirect with redirect.pizza, you define one source and one destination. The edge stores that mapping. When a request arrives, the edge resolves it and responds with a single 301 (or whatever status code you chose). There is no second rule to fire because there is no second layer where rules can live.
The single-hop guarantee applies to the part of the path that lives at the edge. If your destination URL itself does another redirect (an HTTPS upgrade, a www-to-non-www rule, a path rewrite on the receiving server), those additional hops are outside the platform's control. The DNS-level layer doesn't generate chains, but it also cannot prevent chains that exist on the destination side.
The result: chains cannot accumulate the way they do in server-side architectures. You can still create a chain manually if you point redirect.pizza at another redirect (don't do that), but the architecture itself doesn't generate them as a side effect of adding new rules.
For the rare cases where chains do develop within the platform itself (for example, /contact redirecting to /contact-us, which later gets redirected to support.example.com after a help-center migration), redirect.pizza offers Redirect Flattening on Pro plans and up. The feature collapses any chain that flows through the platform into a single response. End users and Googlebot see one hop instead of two or three, even when the underlying business logic involves multiple rules.
For more on the trade-offs between DNS-level and server-side approaches, see DNS-level vs server-side redirects.
The instinct on a slow redirect is to add caching or move to a faster server. That solves a symptom, not the cause. If the chain is three hops long, no amount of edge caching beats a one-hop redirect. The fix is in the redirect chain itself, not the hardware around it.
– Michel Bardelmeijer, Tech Lead at redirect.pizza
Frequently Asked Questions
A redirect loop means two or more redirect rules are sending traffic back and forth without reaching a final destination. The browser tries to follow the chain, hits the same URLs repeatedly, and eventually gives up with an error like ERR_TOO_MANY_REDIRECTS. Loops are almost always caused by conflicting rules in two different systems, most often a www-to-non-www rule fighting a non-www-to-www rule, or an HTTP-to-HTTPS rule clashing with an existing redirect. Unlike a chain, which slows things down quietly, a loop breaks the page entirely.
The fix depends on which one you have. For chains, rewrite every redirect rule so it points directly to the final destination instead of another redirect. Audit your rules across every system that handles requests (DNS, CDN, server config, CMS), trace each chain to its endpoint, and update the source rules to skip the intermediates. For loops, find the two conflicting rules that are bouncing the request between URLs and remove or rewrite one of them so the request resolves in a single hop. The hard part of loop debugging is usually finding where the second rule lives, because it is often in a system different from the first.
For individual URLs, use a redirect chain checker like our free redirect tester or run curl -IL https://example.com from the command line. Both show every hop and the final destination. For site-wide audits, Screaming Frog SEO Spider in list mode handles bulk checks and reports chain length per URL, which you can export to CSV. Browser DevTools (Network tab, Preserve log enabled) works for ad hoc debugging in production. The choice depends on scale. For one URL at a time, use curl or the tester. For hundreds or thousands of URLs, use Screaming Frog.
WordPress loops almost always trace back to one of three places. The first is a mismatch between the WordPress Address and Site Address under Settings, General, where one uses http or non-www and the other uses https or www. The second is an SSL plugin forcing HTTPS while the host or CDN already does the same, so each one bounces the request to the other. The third is a rule in a redirect plugin conflicting with a rule in .htaccess. Fix it by making the two address settings identical, then removing whichever duplicate HTTPS or www rule is fighting the other, so the request resolves in a single hop.
One is ideal. A single hop from source to final destination passes ranking signals cleanly and adds the least latency. Two is acceptable when a temporary situation forces it. Three or more should be consolidated. Google can follow up to 10 hops but advises keeping a chain to no more than three and under five, because each hop adds latency and raises the chance that a crawler or browser gives up before reaching the final URL. The practical rule: if a source needs more than one hop to reach its destination, point it directly at the endpoint.
ERR_TOO_MANY_REDIRECTS means the browser followed redirects back and forth until it hit its limit, which is a redirect loop. Clear the site's cookies for that domain and reload, since a stale cookie can sometimes trigger it. If the error stays, the cause is a conflicting rule. Use curl -IL or browser DevTools to see which two URLs are bouncing, then check every system that touches the request, DNS, CDN, server config, CMS, and any SSL plugin, for two rules that contradict each other. Pick one canonical URL, keep the rule that points to it, and remove or rewrite the one that points away. Retest the http, https, www, and non-www variants until each resolves in a single hop.
Related Reads
- DNS-Level vs Server-Side Redirects: When to Use Each
- Are Redirects Bad for SEO?
- 5 Common Redirect Problems You Can Fix in Under 10 Minutes
- URL Redirects Complete Guide
Test any URL for redirect chains and loops
Drop a URL into our free redirect tester and see every hop, status code, and the final destination in seconds. No signup required. Run the redirect tester.
