What a redirect chain actually is, and why it matters

A redirect chain is what happens when one URL points to another URL, which then points to another URL, before finally landing on the destination page. Instead of a clean A to B hop, you get A to B to C to D. Each extra step is a separate HTTP request, a separate DNS lookup if the host changes, and a separate roundtrip that the browser, the crawler, or the AI bot has to make before it sees any actual content. A redirect chain checker (sometimes called a redirect tracer) walks that path for you and shows every hop, every status code, and every header in between.

On a healthy site, you should not have chains. Every redirect should be a single 301 from the old URL to the final URL. The reality is messier. Sites get migrated, HTTPS gets enabled years after launch, www versus non-www gets sorted out by a different team than the one that handled the trailing slash policy, and over time you end up with three or four redirects stacked for URLs nobody has audited in years.

The reason this matters is not theoretical. Google has been clear in its documentation that it will follow up to ten hops in a chain, but that the practical limit for what gets indexed cleanly is closer to five. After that, crawl signals get muddier, link equity attribution gets weaker, and you start losing the ranking signal you paid for when you acquired those backlinks in the first place.

Chains versus loops: a small but important distinction

A chain goes somewhere. A loop never resolves. If A redirects to B, B redirects to C, and C redirects back to A, you have a redirect loop, and any browser or crawler will eventually stop and throw an error. Chrome shows "ERR_TOO_MANY_REDIRECTS." Googlebot logs a soft 404 or simply gives up. Either way, the page is effectively dead.

Loops usually come from configuration mistakes. The classic one is forcing HTTPS at the load balancer while a CMS plugin separately forces HTTP based on a stale environment variable, so the two fight each other forever. Another common pattern is a www to non-www rule running at the DNS level while a CDN edge worker rewrites in the opposite direction. A redirect loop checker catches both of these in the first two hops because the trace can never escape.

The fix for a loop is almost never "add another redirect." It is "find the two rules disagreeing and turn one of them off." Run the chain trace, identify the hostname or path where the bounce starts, and trace that single rule back to the layer that owns it (server config, CDN, framework, plugin).

301 versus 302 versus 307 versus 308

These are the four status codes you actually need to understand. A 301 is a permanent redirect. It tells crawlers and browsers to update their records and treat the new URL as the canonical one. A 302 is a temporary redirect: keep coming to the old URL, we are just bouncing you elsewhere for now. A 307 is also temporary, but it preserves the HTTP method (POST stays as POST instead of being rewritten to GET, which 302 sometimes does in older clients). A 308 is the permanent equivalent of 307 with method preservation guaranteed.

For SEO purposes, 301 and 308 are what you want when a URL has moved for good. They consolidate ranking signals onto the new URL. A 302 used by mistake on a permanent move is one of the most common reasons sites lose rankings after a migration; the crawler keeps treating the old URL as the real one and never fully transfers equity to the new path.

When you run a chain checker and see a 302 sitting in the middle of what should be a permanent redirect, that is a flag. It does not always tank rankings overnight, but it slows the consolidation of signals and adds friction to every crawl.

How long chains actually get on legacy sites

On a freshly built site, a chain looks clean. On a site that has been around for a decade, four to six hops is common. A typical messy chain looks like this: http://example.com/old-page returns a 301 to http://www.example.com/old-page, which 301s to https://www.example.com/old-page, which 301s to https://example.com/old-page (someone reversed the www policy two years ago), which finally 301s to https://example.com/new-page. Five hops, all 301s, and it works in the browser, so nobody noticed.

Each of those hops adds a roundtrip. On a fast network, that is maybe 80 to 150 milliseconds per hop. On mobile in a weaker signal area, it is closer to 400 ms each. Five hops can add a full two seconds to time to first byte before the browser even starts rendering. That is brutal for Core Web Vitals and for users.

The canonical pattern: HTTP to HTTPS, www, and trailing slash

There is a clean, boring pattern that every site should converge on. Pick one canonical hostname (either www or non-www, it does not matter which, just pick), force HTTPS at the edge with a single 301 from any HTTP request, and decide once whether your URLs end with a trailing slash or not. Then make every other variation 301 directly to the canonical version, in a single hop.

The trailing slash debate is older than most SEOs working today. The technically correct answer is that /page and /page/ are different URLs, and search engines treat them as different. Pick one format, stick to it across the entire site, and 301 the other format to the canonical one. Most modern frameworks default to no trailing slash for non-directory paths, which is fine.

When you get this right, every URL on your site reaches its final form in zero or one hops. Zero if the user typed the canonical version. One if they did not. Never two, never three. A redirect chain checker is the tool that confirms you actually achieved this in production.

How chains kill crawl budget and link equity

Google does not crawl forever. Every site gets a crawl budget, which is roughly the number of URLs Googlebot will fetch in a given window. Every hop in a redirect chain counts as a fetch. If you have 50,000 URLs that each go through a 4-hop chain to reach their canonical version, that is 200,000 fetches Googlebot has to perform just to discover the canonical set. The actual content pages get crawled less often because of it.

Link equity follows a similar logic. Every 301 in modern Google passes nearly all of its PageRank, but each hop is a small leak. Across a long chain, the cumulative loss is real, and it is multiplied across thousands of inbound links. Flattening to a single 301 is one of the cheapest, highest-impact technical fixes most sites can make.

AI crawler behavior and modern bots

Traditional Googlebot tolerates up to about ten redirects before giving up. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are stricter. Most stop following at three or four hops because their crawlers are tuned for speed and citation reliability rather than exhaustive discovery. If your canonical content sits behind a five-hop chain, AI search results will frequently miss it entirely.

The fix is the same as for Google: flatten every chain to a single 301 from the original URL straight to the final destination. Run the trace, identify which intermediate redirects are no longer needed, and rewrite the rules so the source goes directly to the target. Re-run the trace and confirm zero or one hop. That is the entire job, and a redirect chain checker is the tool that tells you when it is done.