Redirect chains and loops: how to find and flatten them

A single redirect is harmless. The problem arises when redirects pile up: page A sends you to B, which sends you to C, which sends you to D. Every hop adds a request, a delay and a chance of error. In the worst case the chain closes on itself and becomes a loop, and the page simply does not open.

How chains form

Almost nobody creates a chain intentionally. They form by layering, one intervention after another:

1. years ago the site moves from HTTP to HTTPS: http:// → https://;
2. then someone decides to drop the www: https://www. → https://;
3. then the URL structure changes: /blog/2019/article → /articles/article;
4. finally the slug is renamed: /articles/article → /articles/new-title.

An old external link to http://www.example.com/blog/2019/article now goes through four redirects before reaching its destination. None of the four is wrong on its own; it is the sum that creates the problem.

Other frequent causes:

• normalisation rules applied in sequence rather than together (protocol, then host, then trailing slash);
• redirects configured in both the CDN and the CMS, which add up;
• plugins that automatically add a redirect on every slug change, even on pages already redirected.

Why they are a problem

For users

Every hop is a round trip to the server, and on a slow mobile connection each one can cost a noticeable amount of time. With three or four hops the delay adds up before the page has even started loading.

For crawlers

Engines follow a limited number of consecutive hops; beyond a certain threshold they stop and treat the URL as an error. Even within the limit, every hop is a request that consumes crawl resources. And the longer the chain, the longer the engine takes to consolidate signals on the final destination.

For maintenance

A chain is fragile: all it takes is for an intermediate link to be removed, perhaps on the assumption that «that old rule is no longer needed», for the whole path to break with a 404.

Loops

A loop occurs when the chain returns to a URL already visited. Typical cases:

• one rule adds the trailing slash and another removes it;
• HTTPS forced by the server while the CDN, which talks to the server over HTTP, receives a redirect and repeats it forever;
• a language-based redirect sends you to the Italian version, which in turn sends you back to the language selector.

The browser stops after a certain number of hops with an error along the lines of «too many redirects». The crawler does the same, and the page disappears from the index.

How to find them

With a crawler

A desktop crawler reports chains and loops during the crawl, showing the starting URL, intermediate hops and final destination. It is worth running it in two modes:

1. starting from the home page, to find internal links that end up in a chain;
2. loading a list of historical URLs, taken from old sitemaps, logs or webmaster tools, to check paths coming from outside.

From the command line

For a single URL, curl shows all the hops:

curl -sIL http://www.example.com/blog/2019/article | grep -i -E "^(HTTP|location)"

The output lists every status code and every Location header, in order.

How to flatten them

The goal is for every old URL to reach the final destination in a single hop.

1. Gather all the rules in a single table: source, destination, where it is configured.
2. Resolve the destinations: for each source, follow the chain to the end and write the final URL directly.
3. Unify normalisations: a single rule that brings protocol, host and trailing slash into the correct form in one go.
4. Remove duplicates between CDN, server and CMS, choosing a single layer in which to manage redirects.
5. Update internal links so that they point directly to the destination, without passing through any redirect.
6. Recheck the list of historical URLs with the crawler.

In short

• Chains arise from the sum of successive interventions, not from a single mistake.
• Every hop slows down users and crawlers and increases fragility.
• Loops make the page unreachable for browsers and engines.
• Check both internal links and historical URLs with a crawler.
• Every old URL must reach the final destination in a single hop.