Redirect chains and redirect loops

What is a redirect chain?

A redirect chain is a sequence of two or more redirects between the requested URL and the final page. Instead of going from A straight to the destination, the client is sent from A to B, from B to C and only then gets content:

http://example.com/shop
  301 → https://example.com/shop
  301 → https://www.example.com/shop
  301 → https://www.example.com/shop/
  200 OK

Each of these redirects is correct on its own. Together, they make every visitor and every crawler take three extra round trips.

A redirect loop is a chain without an end: a URL redirects, directly or through intermediate steps, back to itself.

https://example.com/
  301 → https://www.example.com/
  301 → https://example.com/
  301 → https://www.example.com/
  ...

A browser gives up after a fixed number of redirects (20 in Chrome and Firefox) and shows an error such as ERR_TOO_MANY_REDIRECTS in Chrome or "The page isn't redirecting properly" in Firefox. The page is unreachable for everyone.

Why chains hurt

• Latency: every hop is a complete HTTP request and response. If the hostname changes, the browser may also need a new DNS lookup, TCP connection and TLS handshake. On mobile networks, each hop can easily add a noticeable delay before the first byte of the real page arrives.
• Crawl budget: Googlebot has to request every intermediate URL. On large sites, crawl capacity spent on redirect hops is not spent on new or updated content.
• Hard limits: Google follows up to 10 hops. If it does not reach content within those, Search Console reports a redirect error and the URL is not indexed. Other crawlers, link preview bots and HTTP clients often give up much earlier.
• Fragility: the longer the chain, the more places where something can break. One expired certificate or one deleted rule in the middle and the whole chain fails.

What chains do not do: according to Google, permanent and temporary redirects pass PageRank, so a short chain does not "leak" link equity per hop. The problem is speed, crawling and reliability. Still, keeping every redirect to a single hop is the goal.

How chains arise

Almost nobody builds chains on purpose. They grow over time:

• Separate normalization rules: one rule for HTTP to HTTPS, one for www, one for trailing slashes, each applied in turn. The fix is shown in HTTP to HTTPS and the www redirect guide.
• Successive relaunches: in 2019, /products.html was redirected to /products/. In 2023, /products/ moved to /shop/. Nobody updated the first redirect.
• Domain migrations: the old domain redirects to the same path on the new domain, and the new domain then redirects that path again. See the domain migration checklist.
• Multiple layers: the CDN, the web server, the application and a CMS plugin each add their own redirects.
• Internal links to old URLs: navigation, sitemaps or canonical tags point to URLs that redirect, so the chain begins with your own site.
• Tracking and shortener URLs in front of an already redirected landing page.

Common causes of redirect loops and ERR_TOO_MANY_REDIRECTS

A classic example of a self-matching rule in Apache:

# Wrong: also matches /new-shop/ and redirects it again
RewriteRule shop https://example.com/new-shop/ [L,R=301]

# Right: only matches exactly /shop or /shop/
RewriteRule ^shop/?$ https://example.com/new-shop/ [L,R=301]

Platform-specific loops and their fixes are covered in the guides for Cloudflare, WordPress and .htaccess.

How to find chains and loops

1. Single URLs: enter the URL in the redirect checker. It lists every hop with status code, target and timing and flags loops. Test all variants: http://, https://, with and without www, with and without a trailing slash.
2. Lists of URLs: paste old URLs, backlink targets or your redirect map into the bulk checker and sort by the number of hops.
3. Whole sites: a desktop crawler such as Screaming Frog or a site audit tool finds internal links that point to redirects and reports chains across the site.
4. Search Console: the page indexing report lists URLs with "Redirect error". These are usually loops, chains that are too long, or redirects to invalid URLs.
5. Command line: for a quick check, curl shows each hop:

   curl -sIL http://example.com/shop | grep -iE '^(HTTP|location)'

How to fix redirect chains

1. Point every source straight to the final URL. Go through your redirect rules and replace every target that itself redirects with the final destination. In a redirect map: if B → C exists, change A → B to A → C.
2. Combine normalization rules. Protocol, host and trailing slash should be fixed in one redirect. For example in nginx:

   server {
       listen 80;
       listen [::]:80;
       server_name example.com www.example.com;
       return 301 https://www.example.com$request_uri;
   }

3. Enforce each rule in one place only. Either the CDN, the server or the application, not all three.
4. Update internal links, canonical tags and sitemaps so they point to final URLs. Your own site should never trigger a redirect.
5. Keep the old redirects. Do not delete intermediate redirects, just change their targets. External links may still point to any URL in the chain.
6. Test again with the redirect checker: each variant should need exactly one hop to reach a 200.

A single hop is the goal. For more on choosing the right status code for that hop, see 301 vs. 302.