Bridge SEO
Redirect loops: finding the rule that fights itself
Quick facts
| Question | Answer |
|---|---|
| What the visitor sees | An error naming too many redirects, such as ERR_TOO_MANY_REDIRECTS, with wording that differs per browser |
| Who it affects | Everybody, deterministically, unlike a long chain |
| What the server logs show | A normal-looking run of redirect responses, each one individually correct |
| Where the cause usually is | Two rules or two layers disagreeing about the canonical form |
| What fixes it | Deciding which single place owns canonicalisation, not adding a rule |
What a loop actually is
Not a broken redirect. A redirect that works exactly as written, pointing at an address whose own rule points back.
Every hop in a loop is a valid response. The server names a new location, the client asks for it, and the next rule does the same thing in the other direction. Nothing in HTTP forbids this, and nothing in either rule is wrong in isolation, which is why reading the rules one at a time so often fails to find the fault. RFC 9110 leaves the safeguard to the client: it follows a bounded number of hops and then reports a failure, and where that bound sits differs between clients.
The useful consequence is that a loop is honest. It fails the same way for every visitor, every time, which makes it far easier to work on than a chain that fails only for the clients whose limit it happens to exceed.
How to see it
Follow the hops instead of reading the error.
Ask for the address and record the Location header of each response in turn, without stopping at the first. An address that appears twice in that list is the loop, and the pair of hops on either side of the repeat names the two rules involved. That list is the whole diagnosis, and it takes seconds.
Two details decide whether you see the fault at all:
Check every form of the address
With and without the trailing slash, with and without
www, and on both schemes. Loops caused by canonicalisation frequently appear on one form and not on the three others, so testing the form you happen to have bookmarked can produce a clean result on a site that is failing.Check with a client that has no memory
A browser that already stored a permanent redirect will loop where a fresh client does not, and a colleague who never visited the old address will see a working site while you do not. That difference is not a mystery about their machine; it is the cached answer, and it also means a loop can survive being fixed at the server for anybody who reached it earlier.
The four ways loops form
Every loop worth the name comes from one of these, and all four are disagreements rather than mistakes.
Two canonicalisation rules pointing opposite ways
One rule adds the trailing slash, another strips it. One forces the prefixed form of the domain, another the bare one. Each was added by somebody solving a real problem, and neither is aware of the other.
Two layers each canonicalising correctly
A rule at the origin and a rule in front of it can hold opposite opinions while both being right about their own configuration. This is the version that survives longest, because reading either configuration alone shows nothing wrong.
A rule whose pattern matches its own destination
The condition is written broadly enough that the address it redirects to also satisfies it, so the rule fires against its own output. This is the one case that needs no second rule at all.
An application redirect meeting a server rule
The application sends somebody to a sign-in address; a rule elsewhere sends that address back for its own reasons. Neither component knows the other exists, and the loop appears only for the visitors who trigger the application's condition.
How to fix it
Two steps, and the second is the one that keeps it fixed.
First, establish which layer issued each hop. Ask the origin directly, bypassing whatever sits in front of it, and compare that answer with what the public address returns. If a hop disappears when you go directly, it was added in front; if it survives, it is the origin's own. That comparison identifies the owner of each rule faster than reading any configuration.
Second, decide where canonicalisation lives, and let exactly one place do it. The durable fix is not a third rule that patches the disagreement but the removal of one side of it. Two components both trying to normalise addresses will find a new way to disagree the next time either changes, and the patch will be forgotten long before the rules are.
Before you change a canonicalisation rule, note that it applies to every address on the site at once. A pattern that matches more than you intended does not produce a partial fault; it produces this one, everywhere. Test the changed rule against a handful of addresses, including the awkward ones, and keep a note of the previous rule.
How to verify
The check is the same one that found the fault.
Request the address after the change and follow the hops again, on all four forms and from a client with no stored redirect. The result you want is one hop, or none. Anything that still shows the same address twice means the disagreement moved rather than ended. How a trace reports each hop and its status is covered under redirect tracing, so the list is read rather than assembled by hand.
Loops and chains
The same fault at different lengths, and worth separating.
A chain reaches its destination after several hops, so it works while costing a round trip for each one. It fails only for clients whose hop limit it exceeds, which is why a chain can sit in place for years and be reported only now and then. A loop never reaches a destination and therefore fails for everybody at once.
They also convert into each other: the fix for one, applied carelessly, produces the other, and editing the rule that starts the sequence avoids both. How that happens, and how to find chains across a site, is covered under redirect chains.
FAQ
Why does the site work for my colleague but not for me?
Almost always a stored permanent redirect. Their client never saw the old answer and follows the current rules; yours remembers the earlier one and enters the loop before reaching them. Testing from a client with no history tells you which of you is seeing the site as it is now.
Which rule do I remove?
Neither, until you know which layer issued each hop. Compare what the origin returns directly with what the public address returns: hops that vanish when you ask the origin were added in front of it. Then keep the canonicalisation in one place and remove the other side of the disagreement.
Can a loop hurt how my pages are treated by search engines?
A looping address serves no content to anybody, so nothing is there to be read, and that consequence needs no engine-specific claim to be obvious. What each engine does about it afterwards is its own documented behaviour and changes without notice, so check the engine's own documentation.
Is there a safe way to change canonicalisation?
Change one thing at a time, test the four forms of the address before the rule applies everywhere, and write down what the previous rule was. Most loops introduced during a canonicalisation change come from a pattern that matched more addresses than the person writing it expected.
Redirects, hop by hop
Status codes, chains and loops: this section follows a request until something answers it. The platform these pages describe is Bridge CDN, where an account is created.