Redirect chains: how to find and fix them

Nobody sets out to build a chain. Each redirect was sensible when it was added, and they stack:

• http:// redirects to https://, which redirects example.com to www.example.com, which adds a trailing slash.
• A page moved twice. The first redirect still points at the second address, which now redirects to the third.
• A CMS adds its own redirect when a slug changes, on top of a rule in the server config.
• Internal links still use old URLs, so every click starts at the top of the chain.

Time, first. Each hop is a new request, often on a new connection, before the browser even starts on the real page. On mobile networks two or three extra hops are noticeable.

Crawl requests, second. Google's crawlers follow up to 10 redirect hops by default, and every hop spends a crawl request on a URL with no content. Other crawlers and link preview bots may follow fewer.

Google has said that redirects themselves no longer lose PageRank, so the old argument that each hop leaks link value is weaker than it was. The case for fixing chains rests on speed, crawl efficiency and reliability, which is enough.

For each chain, note the final URL and change the first redirect to point straight at it. Then update every internal link, canonical and sitemap entry that uses an old URL, so nothing on your own site starts a chain in the first place.

Where the chain comes from protocol and host rules, combine them: one rule that sends any http or non-www request directly to the final https://www. URL, with the trailing slash already right.

Keep the old redirects in place for links from other sites. The aim is one hop, not zero.

The free SEO checker follows the redirects from one URL and lists every hop, which is the quickest way to confirm a fix. The site audit finds every chain across the crawl.