A redirect chain is a sequence of two or more redirects between the URL someone requests and the page they finally reach: page A redirects to B, which redirects to C. Each step is called a hop, and every hop adds a delay and another chance for something to go wrong.
How a redirect chain works
Each redirect is an instruction from the server: “this page has moved, go here instead”. The browser or crawler requests the new address, and if that address also redirects, it follows again. A visitor sees only the final page, perhaps after a pause, so chains are easy to miss without a crawler.
Chains usually build up over time rather than being created on purpose. A typical UK small business site might have gone through these changes:
- Moved from http to https, so http://example.co.uk/services redirects to https://example.co.uk/services.
- Standardised on the www version, adding another hop to https://www.example.co.uk/services.
- Added trailing slashes, adding /services/.
- Restructured during a redesign, adding /our-services/.
An old link to the first address now takes four hops. Google’s documentation says Googlebot follows up to ten redirect hops; beyond that it stops and Search Console reports a redirect error for the URL. Other crawlers and some tools give up sooner. Each 301 redirect passes signals onward, yet every extra hop is an extra request and an extra risk.
Why it matters
Chains slow pages down, especially on mobile connections, because each hop is a separate round trip to the server before anything loads. They waste crawl budget on larger sites, as Google spends requests on intermediate URLs. They also make sites fragile: if any URL in the middle breaks, every link that relied on the chain lands on an error or a redirect loop.
The bigger risk is in a site migration. Redirecting old pages to URLs that already redirect elsewhere is one of the most common ways a rebuild loses visibility that took years to earn.
Common mistakes
- Adding new redirects without updating old ones. Every new rule should point existing redirects straight at the final URL.
- Splitting protocol, www and slash rules. Three separate rules create three hops. One combined rule can do it in one.
- Internal links pointing at redirecting URLs. Your own menus and body links should never need a redirect at all.
- Mixing redirect types. Chains that include a 302 or a JavaScript step send mixed signals about which URL is permanent.
- Testing only the final page. A page that loads fine can still sit at the end of a slow chain.
How to act on it
Crawl the site with a tool such as Screaming Frog and use its redirect chain report, or check individual URLs with a header checker or browser developer tools. List every chain, then rewrite each rule so the original URL goes directly to the final destination in one hop. Combine protocol, hostname and trailing slash handling into a single rule at server level where possible. Then update internal links, canonical tags and XML sitemaps to use final URLs only.
Before any redesign, pull a list of every old URL and run it through the redirect map builder, which flags chains and loops before the rules go live. Finding and flattening chains across a whole site is routine work within technical SEO.