Redirect chains and loops: what they are and how to fix them

What's a redirect chain?

It's a redirect that leads to another redirect. A visitor asks for page A. A sends them to B. B sends them on to C. Each stop adds an extra request, so the page takes longer to show.

Google's advice is plain. Avoid chaining redirects, and redirect to the final destination directly.¹ It says chains add latency (waiting time) for users, and not all browsers and other clients support long ones.¹

Why is one jump better than three?

Because every extra jump is a delay, and a chance for something to go wrong. Google says its own crawler can follow up to 10 hops in a chain, but it still advises going straight to the end.¹ If a chain can't be avoided, Google asks you to keep it short, ideally no more than 3 and fewer than 5.¹

There's also a tidy reason to prefer direct rules. Google's crawler notes say content from the redirecting address is ignored and the final target's content is what gets processed.² The middle stops add nothing.

How do chains build up by accident?

Most come from changes made at different times. You moved a page last year, and now you're moving it again. The first redirect still points at the middle address.

The fix is to edit the old rule, not stack a new one on top. If A once went to B, and B now goes to C, change A so it goes straight to C. Keep the B rule too, in case someone uses it.

Your own links matter as well. MDN's view is that you should try to avoid internal redirects. Where correcting a link on your own site removes the need for one, fix the link.³

What's a redirect loop?

A loop is a chain with no end. MDN defines redirection loops as ones that happen when additional redirections follow the one that has already been followed.³ Address A sends visitors to B, and B sends them back to A, so no page is ever shown.

Why does my browser say "too many redirects"?

Because it spotted a loop and gave up. MDN says that if a server can't detect a loop, browsers will detect it and display an error message.³ Firefox's wording is that it has detected the server is redirecting the request for this address in a way that will never terminate.³ Other browsers use their own wording.

The same page says that if a server does detect the problem, it may send a 500 Internal Server Error. Seeing that soon after you changed a server configuration is a likely sign of a loop.³

MDN adds that the visitor can't do much about it, unless something is wrong on their side, such as a mismatch of cache or cookies.³ Most of the time, it's yours to fix.

How do I fix a loop?

Work backwards from the change you made last.

• List every rule that touches the address in question. Check the server file, any plugin or platform setting, and any redirect set by a host's control panel.
• Look for two rules that point at each other, or a rule whose new address matches its own old address.
• Remove or edit the rule you added most recently, then test again.
• If your platform or host runs its own redirects, check that your rule doesn't undo theirs.

The command line tool curl gives you a handy way to watch a loop without a browser. It sets a limit on how many redirects to follow, and by default that limit is 50.⁴ There's a walk-through of that command on the page about checking redirects.