Finding and Fixing Broken Redirect Chains & Loops

Redirects are an indispensable tool in modern web engineering. They ensure visitors don't encounter dead ends when URLs are updated, consolidate non-WWW and WWW traffic, and enforce secure HTTPS connections.

However, when redirects are configured carelessly over months or years of website revisions, they easily mutate into Redirect Chains and Redirect Loops.

• A Redirect Loop (ERR_TOO_MANY_REDIRECTS) completely breaks the site, preventing anyone from viewing the page.
• A Redirect Chain forces the browser through multiple sequential HTTP 301/302 hops, adding hundreds of milliseconds of unnecessary latency and causing Googlebot to drop link equity or abort crawling altogether.

In this actionable technical guide, we explain how redirect chains form, how to trace every hop using command-line curl, and how to refactor your server rewrite rules into crisp, single-hop redirects.

1. What is a Redirect Chain?

A redirect chain occurs when there is more than one redirect step between the initial URL requested and the final destination URL.

The Classic 4-Hop Chain:

1. User clicks: http://example.com/blog (Insecure HTTP, non-WWW, no trailing slash)
2. Hop 1 (301): Redirects to https://example.com/blog (Enforcing HTTPS)
3. Hop 2 (301): Redirects to https://www.example.com/blog (Enforcing WWW)
4. Hop 3 (301): Redirects to https://www.example.com/blog/ (Enforcing trailing slash)
5. Hop 4 (301): Redirects to https://www.example.com/articles/ (Old URL rewrite rule)
6. Final Destination (200 OK): Page finally renders.

Why This Destroys Your Site:

• Mobile Latency: On cellular networks, each separate redirect requires an entire DNS lookup, TCP handshake, and TLS negotiation. A 4-hop chain can add 1.5 to 2.5 seconds of pure waiting time before the browser even receives the first byte of HTML.
• Search Engine Crawl Budget Drop: Googlebot has publicly stated that it will follow a maximum of 5 redirect hops before aborting the crawl entirely and marking the URL as an indexing error.
• Lost PageRank: Every intermediate hop introduces a slight degradation in transferred link equity.

2. What is a Redirect Loop (ERR_TOO_MANY_REDIRECTS)?

A redirect loop occurs when Page A redirects to Page B, and Page B redirects back to Page A (or via an intermediary):

URL A ──(301)──> URL B ──(301)──> URL A (Infinite Loop!)

Browsers contain a safety limit (typically 20 redirects). When that threshold is reached, Chrome displays the dreaded error: ERR_TOO_MANY_REDIRECTS.

The #1 Cause of Redirect Loops: Cloudflare "Flexible" SSL

By far the most common cause in production happens when using Cloudflare:

1. Cloudflare is set to Flexible SSL.
2. A visitor requests https://example.com.
3. Cloudflare decrypts the traffic and talks to your origin server over plain http://example.com:80.
4. Your origin server (e.g., Nginx or Apache) sees an insecure HTTP connection and has a rule saying: "Redirect all HTTP traffic to HTTPS!"
5. Your server sends a 301 back to Cloudflare pointing to https://example.com.
6. Cloudflare receives the redirect and connects back to the origin over HTTP again.
7. Result: Infinite loop.

The Fix: Go to Cloudflare Dashboard > SSL/TLS > change encryption mode from "Flexible" to Full (Strict).

3. How to Trace Redirect Chains via Command Line

Do not guess which server or rule is triggering the redirect. Use the curl command with the -IL flags to follow and display every intermediate HTTP response header:

curl -IL https://yourdomain.com/old-page

Example Output:

HTTP/2 301 
location: https://www.yourdomain.com/old-page

HTTP/2 301 
location: https://www.yourdomain.com/old-page/

HTTP/2 301 
location: https://www.yourdomain.com/new-page/

HTTP/2 200 
content-type: text/html

The location: headers reveal the exact path of the chain.

4. How to Refactor Redirects into Single-Hop Rules

All canonical redirects (HTTPS enforcement, WWW alignment, trailing slash consistency) should be consolidated into a single, unified server block that redirects in one single leap.

Clean Nginx Configuration (Single-Hop):

# 1. Catch-all for plain HTTP (redirect directly to canonical HTTPS WWW)
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# 2. Redirect non-WWW HTTPS directly to canonical HTTPS WWW
server {
    listen 443 ssl http2;
    server_name example.com;
    
    # SSL certificate definitions...
    return 301 https://www.example.com$request_uri;
}

# 3. Primary Canonical Production Server Block
server {
    listen 443 ssl http2;
    server_name www.example.com;

    # Application logic...
}

With this architecture, regardless of whether a visitor types http://example.com, http://www.example.com, or https://example.com, they arrive at https://www.example.com in exactly one single 301 hop.

5. Audit Checklist for Old Article Redirects

When retiring or reorganizing website sections:

1. Never redirect through intermediate historical URLs: If URL A was redirected to URL B in 2024, and URL B is now moved to URL C in 2026, do not leave A -> B -> C. Update URL A directly: A -> C.
2. Audit internal links: Run an automated crawler (like Screaming Frog or Sitebulb) across your own site. Update your internal navigation menus and blog post links so they point directly to final 200 OK destinations rather than triggering redirects.

Eliminating redirect chains slashes loading latency, conserves crawl budget, and ensures visitors and search crawlers reach your content instantly.