ERR_TOO_MANY_REDIRECTS after a migration means your redirects have formed a loop. A URL redirects to another that eventually points back to it, or a rule redirects a URL to itself, so the browser bounces around the loop until it stops and shows the error. The page becomes completely unreachable, for visitors and for search engines alike. The fix is to trace the chain, find the rule that closes the loop, and point each old URL straight to its final destination in a single hop. WPBuildAI builds a clean, single-hop redirect map so loops never form in the first place.
A frequent cause in 2026 is a half-finished variant setup, since Google now expects the move to be declared for every subdomain and both the www and non-www forms: when www points at the apex and the apex points back at www, the loop you are seeing is two partial rules arguing with each other.
What the error actually means
The browser is not broken and the page is not necessarily gone; the browser is protecting you from an infinite journey. When you request a URL and the server answers with a redirect, the browser follows it, and if that destination also redirects, it follows again. A loop is when that chain never ends, so after a set number of hops, around twenty in most browsers, the browser gives up and shows ERR_TOO_MANY_REDIRECTS rather than looping forever. MDN’s reference on HTTP redirections explains how chains are followed and why a cycle never terminates, which is exactly what the browser is reporting. So the error is not a mysterious server fault, it is the predictable result of two or more rules that, together, point a URL back at itself.
The usual causes after a move
Most post-migration loops come from a short list:
- Trailing slash. One rule sends /page to /page/ while another sends /page/ back to /page, so the two bounce forever.
- Protocol or www. An http-to-https rule loops with a www-to-non-www rule, or the canonical rules are configured in opposite directions in two places.
- Self-matching rules. A redirect whose source pattern also matches its own destination, so it redirects the target back to itself.
- Overlapping layers. Redirects defined both on the server and in the platform or CDN, each unaware of the other, fighting over the same URL.
These four account for the overwhelming majority of loops, and notably none of them is an exotic bug; each is a small inconsistency between two rules that individually look correct.
Why a migration is where loops appear
Loops cluster around migrations for a reason: a move is when the largest batch of new redirect rules gets added at once, often by different hands and in different places. The developer adds path redirects, the host enforces https, the platform enforces a trailing-slash convention, and a CDN adds a www rule, and no single person sees all four together. Before the migration there were few rules and little chance of conflict; after it there are hundreds, layered across the server, the platform, and the CDN. That sudden density is what turns a latent inconsistency, say, a slash convention that disagrees with a path rule, into a live loop. Recognising that the migration multiplied your rules tells you where to look: the seams between the layers that each added their own.
How to find the loop, step by step
Follow the chain for a failing URL and watch for the repeat:
- Pick a failing URL and run it through a redirect checker, or open the browser network tab with “preserve log” on and load it.
- Read the hop sequence, each entry is one redirect, with its status and destination.
- Find the repeat, the point where a URL you already saw appears again, which closes the loop.
- Identify the two rules producing those two hops; one of them is sending the URL back.
- Decide the correct final URL and rewrite the rules so the source goes there directly, removing whichever rule closes the loop.
The repeat is the whole diagnosis: it names the two URLs fighting, and from there you trace each back to the rule that produced it.
A worked example: the trailing-slash loop
Say your new platform canonicalises URLs without a trailing slash, so it redirects /guide/ to /guide. Meanwhile a leftover server rule, copied from the old WordPress config, redirects /guide to /guide/. Request either version and the two rules volley it back and forth: /guide to /guide/ to /guide to /guide/, until the browser stops at twenty hops and shows the error. Each rule is individually reasonable, one enforces “no slash,” the other enforces “slash,” but together they are a perfect loop. The fix is to delete the old server rule and let the platform’s no-slash rule stand alone, so /guide/ redirects once to /guide and stops. One of the two conventions has to win; the loop is what happens when both try to.
Why chains turn into loops
A loop is usually a chain that grew one hop too far. The 2024 Web Almanac reports how common multi-hop redirect chains are across the web, and chains are the soil loops grow in: the more hops a URL passes through, the more rules are involved, and the easier it is for one of them to point back to an earlier link. A two-hop chain that works today becomes a loop the moment someone adds a rule that redirects the final URL back toward the start. Collapsing every redirect to a single hop, old URL straight to final URL, removes the soil entirely, because a one-hop redirect has no earlier link to loop back to. So fixing the loop and shortening your chains are the same work.
Fixing it without hurting SEO
A loop is already costing you everything, the page is completely unreachable, so fixing it can only help. There is no SEO risk to weigh, because a looping URL is earning nothing: no visitor reaches it and no crawler indexes it. Google’s redirects guidance notes that a clean 301 passes ranking signals, while a broken chain passes nothing, so replacing the loop with one direct 301 to the correct final URL actively restores value that the loop was destroying. The clean version of this is a URL mapping template built as single hops, the same care that makes 301s preserve SEO. Fixing a loop is pure upside.
Why single-hop matters for speed too
Even chains that do not loop are a cost, which is the second reason to collapse them. Every extra hop is another request-and-response round trip before the visitor sees anything, and on a phone over a slow connection those add up to real delay. Portent’s study of site speed and conversion shows how directly load time affects revenue, and a redirect chain front-loads that delay onto the very visitors arriving from your old URLs, often your search traffic. So single-hop redirects are not only loop insurance; they are a speed win for everyone who follows a redirect in. Pointing each old URL straight at its final destination fixes the error and shaves the latency in one move.
The order of operations: normalize first
Loops are easiest to prevent by deciding your canonical form before you write path redirects. Settle three things first: https or http (almost always https), www or non-www, and trailing slash or not. Implement each as a single rule in one place, then write your content redirects to point at URLs already in that canonical form. The loops in the examples above all come from doing this out of order, adding path rules that produce non-canonical URLs, then bolting on normalisation rules that fight them. Normalise first and your path redirects inherit the right form, so there is no second rule to conflict with. Order of operations is the cheapest loop prevention there is, because it removes the conflict before it can exist.
Keeping redirects in one place
The “overlapping layers” cause is really an organisational problem, and the fix is organisational. When redirects live in the server config, the platform settings, and a CDN all at once, no one can see the full picture, and the layers contradict each other. Choose one authoritative place for your redirects and keep them there, so the whole map is reviewable in one spot and a new rule can be checked against the others before it ships. If a layer must handle something specific, like the host enforcing https, keep that single concern there and nothing else. Centralising the rules is what makes it possible to spot a loop in review rather than discovering it in production, and it is the standing discipline behind the migration SEO checklist.
When it is not a loop
Occasionally the same error has a cause that is not your redirect rules, and it is worth ruling these out before rewriting anything. A stale browser cache or cookie can replay an old redirect that no longer exists in your config, so test in a private window first. An HSTS policy or a CDN-level https setting can interact with a server http rule to create a loop you will not find in your own config alone. And a misconfigured canonical or login redirect, bouncing an unauthenticated user to a login page that bounces back, can loop without any migration rule involved. If your traced chain does not match any rule you wrote, widen the search to the cache, the CDN, and authentication, because the loop may be forming above your application.
Common mistakes that recreate loops
The errors that bring loops back are all variations on the causes. Adding a normalisation rule after the path rules, instead of before, reintroduces the slash or protocol conflict. Splitting redirects across the server, platform, and CDN puts them out of sight of each other again. Fixing the one failing URL you noticed while leaving the conflicting rule in place means the next URL it touches loops too. And building long chains rather than single hops leaves the soil for a future loop to grow in. Each is avoided by the same two principles: normalise first, and keep every redirect a single hop in one authoritative place, which together make loops structurally unable to form.
Key points to remember
ERR_TOO_MANY_REDIRECTS is a redirect loop, usually from trailing-slash, protocol or www, self-matching, or overlapping-layer rules that a migration introduced all at once. Find it by tracing the chain to the point it repeats, which names the two rules fighting, then remove the rule that closes the loop and point the old URL straight to its final URL in one hop. Fixing it only helps SEO, since a looping page was already unreachable, and single-hop redirects speed the site too. Prevent recurrence by normalising https, www, and slashes first, and keeping every redirect a single hop in one authoritative place. WPBuildAI builds the map as clean single hops, so loops never appear; send your site URL for a fixed quote.
Not affiliated with Google, WordPress, or Lovable.