Redirect chains: why they slow your site down
In your audit this appears as URLs causing a redirect chain
One URL redirects to another, which redirects to another. Instead of a single hop, the browser has to make two or three before reaching the real page.
Why it matters
Every hop is another request: the browser asks, the server says "it is somewhere else", and round it goes again. On a slow mobile connection that shows up in load time — exactly what Core Web Vitals measure.
Search engines follow redirects, but not endlessly, and they spend crawl budget on each hop. The longer the chain, the easier it is for one leg to break over time and leave the whole route ending in an error.
Where they usually come from
- Accumulated layers: first you moved from HTTP to HTTPS, then from
wwwto nowww, then you changed the URL structure. Each change added its hop. - Old migrations whose rules nobody cleaned up.
- Internal links still pointing at the old address instead of the final one.
How to fix it
- Shorten the chain: make the first URL redirect directly to the final one, in a single hop. You do not need to delete the old rules, just repoint them.
- Correct the internal links so they point at the final address already. An internal link should never need a redirect.
- Use
301when the move is permanent, which it usually is.
A redirect loop is worse: A leads to B and B leads back to A, so the page never opens at all. If you see that one, it takes priority over this.
Does your site have this problem?
Analyse your page for free and we will tell you which of these issues you have, and on which pages.
Audit a site