Bridge SEO
Redirect chains: how to find them and collapse them
HTTP round trip for every hop it contains. It also fails for the clients whose hop limit it exceeds, which is why a share of visitors can see an error on a site everybody else finds fine.Quick facts
| Question | Answer |
|---|---|
| What the visitor experiences | The right page, arriving later, with no error until the hops exceed a client's limit |
| Who it affects | Some clients and not others, depending where each stops following |
| What the logs show | Ordinary redirect responses, each individually correct |
| How they form | Accumulation: rules added at different times, by different people, in different layers |
| What fixes it | Pointing the first rule at the final destination, then updating the links that lead into it |
Why a chain is harder to notice than a loop
Because it works, and working faults do not generate tickets.
A loop announces itself: every visitor gets an error and somebody says so within the hour. A chain delivers the page. The visitor waits slightly longer, the extra requests appear in logs as ordinary responses, and nothing anywhere is labelled as a fault. The cost is real and paid on every visit, and the only thing missing is a complaint.
The second reason is that the fault is invisible from any single vantage point. Each rule in a chain is correct by the semantics in RFC 9110, and does exactly what its author intended. The chain exists only in the composition, and nobody composed it, which means no configuration file contains the problem and no code review would have caught it.
How chains form
Three at once, usually, and none of them a mistake at the time.
Time
A restructure moves a section. A year later the canonical form of the domain changes. A year after that a page is renamed. Each change adds a rule pointing at what was correct on the day it was written, and the rules compose into a path through the site's history.
Layers
A rule in front of your server and a rule at the origin can each add a hop while both being right. Neither author saw the other's configuration, so the composition was never anybody's decision.
Convenience addresses
A short address for a campaign points at the page, which by then already redirects somewhere else. This one is the most common source of the chains that matter most, because those addresses are printed, mailed, and linked from places you cannot edit afterwards.
Finding them across a site
Checking addresses one at a time finds the chain you already suspected. Finding the rest means starting from the lists that already exist.
Your internal links
Anything on your own site that points at an address which redirects is a chain you can end at the source rather than in the rules. This is usually the largest group and the cheapest to fix.
Your sitemap
Entries in
sitemap.xmlthat redirect are worth treating as errors rather than as chains, because a sitemap is a statement about where the content is and a redirecting entry contradicts it.What is actually requested
Your logs list the addresses clients ask for, including the historical ones you had forgotten were still in circulation. This is the list that tells you which rules are still earning their keep.
Inbound links you know about
Directories, partner sites, and anything printed. You cannot change these, which makes them the reason to keep the rules that serve them, and the reason to make sure those rules take one hop rather than four.
Follow each address and record the number of hops and the final destination. Anything above one hop is a candidate; anything above two is worth fixing this week.
Which chains actually matter
Ranked, because fixing all of them at once is rarely the best use of an afternoon.
The ones on paths people take matter most: addresses in your navigation, in your sitemap, and in whatever your busiest inbound source is. A chain on an address nobody has requested this year costs nothing, and the rule behind it is still worth keeping for the day somebody does.
The ones that are close to a client's limit matter next, because they are the chains that fail intermittently rather than uniformly. A chain of two hops is a tax; a chain long enough to approach any client's bound is an outage for a subset of visitors, arriving without a pattern anybody can reproduce.
How to collapse them
Two moves, and doing only the first leaves the work half done.
Point the first rule at the final destination
Editing the rule that starts the sequence removes every intermediate hop at once. The instinct to delete the middle rules is the wrong one and dangerous besides, which is the subject of the warning below.
Remove the need for the hop
Update your own links and your sitemap to name the final address directly. A redirect that nothing points at costs nothing, and this is the only fix that survives somebody adding a new rule later.
Before deleting any old rule, note what it is for. Rules exist for the links you do not control: inbound links, printed addresses, bookmarks, and anything already published elsewhere. Collapsing a chain should shorten the path, not remove the entrance to it. Deleting the first rule after collapsing the chain turns a slow success into a missing page for everybody who arrives the old way, and you will not hear about it from the people affected.
How to verify
Follow the hops again and count them.
Request each address you changed and record the Location header of every response in turn. One hop, or none, is the result you want. Two means an intermediate rule is still being consulted, and the address you pointed at is itself redirecting. How a trace reads each hop and its status is covered under redirect tracing, and with a trace in front of you the count is a matter of reading rather than of assembling requests by hand.
Repeating the check some weeks later pays off. Chains form by accumulation, so a site that was clean in March is not necessarily clean in June, and the cheap version of this work is periodic rather than heroic.
Chains and loops
The same mechanism at different lengths, and each is a common way to create the other.
A chain reaches its destination and costs a round trip per hop. A loop never reaches one and fails for everybody. Fixing a chain by adding a rule that points back at something earlier in it produces a loop; fixing a loop by sending one side to a third address produces a chain. Both are avoided the same way, by editing the rule that starts the sequence rather than adding another one to the end.
FAQ
How many hops is too many?
More than one is worth removing, because every hop is a round trip that produces no content. There is no safe number to aim at instead: clients stop following after a bounded count that differs between them, so a chain long enough to matter fails for some visitors and works for others with no pattern.
Why not just delete the old rules?
Because they serve the links you do not control: inbound links, bookmarks, printed addresses, and anything already published elsewhere. Collapsing a chain should shorten the path while keeping its entrance. Deleting the first rule turns a slow success into a missing page for exactly the people you cannot reach to tell.
Do chains matter if the page still loads?
Yes, in two ways. Each hop is a round trip paid on every visit and returns no content in exchange. And a chain that grows past a client's bound fails for that client while working for everybody else, which produces reports nobody else can reproduce and no logs explain.
Where should I start?
With your own links and your sitemap, because those are chains you can end at the source instead of in the rules, and because they are usually the largest group. Then the addresses your logs show are actually being requested, which tells you which rules are still doing work.
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.