What a redirect chain is
A redirect chain is two or more redirects in a row before the requested URL reaches a page, such as A to B to C. Each hop is a separate request and response. The fix is to make every old URL redirect straight to its final destination, and to update links so most visitors need no redirect at all.
A redirect loop is a chain that never ends because a later hop points back to an earlier URL. Browsers give up after a limit and show an error such as ERR_TOO_MANY_REDIRECTS.
How chains build up
Chains are rarely designed. They build up as rules are added over the years, each correct on its own. The rules then run one after another in the CDN, the web server and the application.
Suppose a site moves to HTTPS, then standardizes on www, then a redesign moves /blog/ to /articles/, and the framework adds a trailing slash. An old link to http://example.com/blog/post now takes four hops:
$ curl -sIL http://example.com/blog/post | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/blog/post
HTTP/2 301
location: https://www.example.com/blog/post
HTTP/2 301
location: https://www.example.com/articles/post
HTTP/2 301
location: https://www.example.com/articles/post/
HTTP/2 200What chains cost
Every hop is another round trip before the page starts loading, and a hop to a different host can add a DNS lookup, TCP connection and TLS handshake. Visitors on slow mobile connections feel this most.
Crawlers spend a request on every hop. Google's crawlers follow up to 10 hops, and Google's site-move guidance says to redirect to the final destination directly. Where that isn't possible, it suggests keeping chains to 3 hops or fewer.
Long chains are also fragile. Each hop is one more rule that can later break, start returning 404 or drop the query string along with its campaign tags.
Redirect loops and their usual causes
A loop happens when two layers disagree about the right URL, so each keeps sending the client to its own version. Tracing the loop with curl shows which layer sends each hop, because headers such as Server or Via often name the CDN, web server or application. The usual causes:
- A CDN or load balancer ends the HTTPS connection and connects to the origin over plain HTTP, while the origin redirects every HTTP request to HTTPS. The origin needs to trust the proxy's X-Forwarded-Proto header or receive HTTPS itself.
- The CDN redirects www to the bare domain while the web server redirects the bare domain to www.
- One rule adds a trailing slash and another removes it.
- A login page sends the visitor to a protected page, which sends them back to log in because the session cookie is blocked or never set.
How to find chains in bulk
Chains hide in links you no longer look at, so test URLs in bulk. Good sources are your XML sitemaps, where every URL should return 200 directly, and a crawl of internal links. Add old URLs from past migrations and the pages with the most external links or search traffic.
Run the list through a checker that records every hop, then sort by hop count. Anything over one hop is worth fixing, and loops and chains that end in 4xx come first. The loop below does this with curl; a loop shows up as 10 hops ending in a 3xx code.
With a free account, URL Intelligence Platform does the same for a pasted list. It records the status code, location and timing of each hop, can filter for chains longer than 3 hops, and exports CSV or JSON. A loop is marked as a redirect loop and gets its own filter.
In Chrome's developer tools, a 307 Internal Redirect from http to https means the browser upgraded the URL itself because of HSTS. No request reached your server for that hop.
# Hops, final status, final URL and starting URL for each line in urls.txt
while read -r url; do
curl -s -o /dev/null -L --max-redirs 10 \
-w "%{num_redirects}\t%{http_code}\t%{url_effective}\t$url\n" "$url"
done < urls.txt | sort -rnHow to flatten chains at the source
Flattening means changing each rule so it sends the client straight to the final URL, then removing the need for a redirect wherever you control the link.
- Point old redirects at the final URL. If /blog/post redirects to /articles/post, which now redirects to /articles/post/, change the first rule to go straight to https://www.example.com/articles/post/.
- Combine the protocol and host rules, so http://example.com/page goes to https://www.example.com/page in one hop.
- Make every redirect target a complete final URL, with the right scheme, host and trailing slash, so later rules have nothing left to fix.
- Update internal links, canonical tags, hreflang tags and sitemaps to final URLs, so most requests never meet a redirect.
- Keep the old redirects after flattening them, because external links and bookmarks still use the old URLs.
- One two-hop chain is expected if you plan to submit the domain to the HSTS preload list. The list requires plain HTTP to redirect to HTTPS on the same host first, so http://example.com goes to https://example.com before https://www.example.com.