A redirect chain is what happens when one redirect points to another redirect instead of pointing to the final page.
The visitor asks for URL A. A sends them to B. B sends them to C. C finally loads.
Each hop looks harmless on its own. That is exactly why chains accumulate. Nobody decides to build one. They assemble themselves out of reasonable decisions made months apart.
How chains form without anyone noticing
The most common chain on a small business site is not exotic. It is the stack of housekeeping rules that pile up over time:
- HTTP redirects to HTTPS
- the non-www version redirects to the www version
- an old page slug redirects to a renamed slug
- the renamed slug redirects again after a later restructure
Four rules. Each one was correct when it shipped. Together they mean an old link in an email newsletter or a directory listing now takes three or four hops to land.
Migrations make this worse. A site that has moved platforms twice often carries redirect logic from both moves, layered on top of each other, with nobody left who remembers why.
Cost one: every hop is a real delay
A redirect is a round trip. The browser asks for a URL, waits for the answer, gets told to go somewhere else, and starts over.
On a fast connection that might be tens of milliseconds per hop. On a phone with a weak signal, each hop can take noticeably longer, and the hops happen before any of your content starts loading.
A three-hop chain in front of your homepage means your real page load time is whatever you measured, plus the chain, for everyone arriving through an old link. Your own testing rarely catches this because you test the final URL directly.
Cost two: crawl signal gets thinner
Search crawlers follow redirects, but not with unlimited patience. Long chains slow crawling down, and very long ones can cause a crawler to give up before reaching the destination.
There is also a quieter signal problem. Redirects are how you tell search engines that one URL has permanently become another. A clean single hop says that plainly. A chain says it with a stutter. The consolidation still generally works, but you are making the crawler do reconstruction work that a direct redirect would not require.
If you are also dealing with canonical tags that disagree with the redirect destination, the chain turns a small inconsistency into genuine confusion about which URL is the real one.
Cost three: debugging gets expensive
This is the cost that surprises people.
When something breaks on a chained URL, you now have multiple places to look. Is the loop in the CDN config? The server rules? The CMS plugin? The platform-level HTTPS rule? Each layer can issue redirects, and each layer was probably configured by a different person or vendor.
A redirect loop, where the chain circles back on itself, takes a page completely offline. Visitors see a browser error, not your site. Loops are almost always born from chains, because a chain is the only structure long enough to bite its own tail.
How to find your chains
You do not need special access to start. Pick the URLs that matter and trace them:
- your homepage, over HTTP and HTTPS, with and without www
- your top service or product pages
- any URL you have printed, emailed, or listed in directories
- old URLs from before your last redesign
A command line check with curl, or any free redirect checker, will show you the hop count. What you want to see is one hop at most from any legacy URL to its final destination.
When you find a chain, the fix is usually simple: update the first redirect to point directly at the final URL. You do not need to delete the intermediate rules immediately. You need the first hop to skip past them.
Why this is a monitoring problem, not a one-time fix
Here is the honest part. You can clean every chain this week, and new ones will form.
The next plugin update, the next page rename, the next SSL configuration change, the next marketing landing page with its own vanity URL. Each one is a chance for a new hop to slip in front of an existing redirect.
A one-time audit catches the chains you have today. It says nothing about the chain that appears after the next deploy. That is the gap recurring checks exist to fill, and it is worth being clear that a monitoring pass is a narrower thing than a full audit. Monitoring asks a small set of questions on a schedule. An audit asks a much larger set once.
For redirect health, the monitoring questions are small and answerable:
- Do my key URLs still resolve in one hop?
- Did the hop count change since last week?
- Did any redirect destination change unexpectedly?
This is the kind of check Site Clinic runs as part of watching a site's live behavior over time, alongside uptime, certificate, and indexing signals. The point is not that redirects are glamorous. The point is that they drift, and drift is cheap to catch early and expensive to explain later.
What to do this week
Trace your five most important URLs. Count the hops. If anything takes more than one redirect to land, point the first redirect at the final destination.
Then write down what the correct behavior is, even if it is just a note: these URLs, one hop, these destinations.
That note is the difference between noticing drift next quarter and discovering it the day someone asks why the old brochure link stopped working.