Redirect chains: the chain is the finding

Nobody sets out to build a redirect chain. They build up over time.

The site moves to HTTPS, so someone adds a rule. Later the www subdomain becomes canonical, so someone adds another. A redesign standardises on trailing slashes. A CMS migration brings its own redirect table. Each rule made sense on the day it was written. Put them together and an old link takes this route:

http://example.com/pricing
  → 301  https://example.com/pricing
  → 301  https://www.example.com/pricing
  → 301  https://www.example.com/pricing/
  → 200

That's three hops before the visitor gets a page. Every one of them is a full round trip.

Why chains matter

• Latency. Every hop is another request and response before the page can even start loading. On a slow mobile connection, you feel it.
• Crawlers give up. Search engine crawlers follow redirects, but not forever. A long chain risks being abandoned before the destination is reached.
• Link value leaks. A link that goes through redirects still works, but some of its value gets diluted along the way.
• They hide mistakes. A chain that ends in a 404 is a broken link that looks like it works until you follow it all the way.

A redirect loop is the extreme case: A redirects to B, and B redirects back to A. Nothing is ever served. Browsers show an error after a few hops, and search engines give up on the URL.

Why CrawlStat follows redirects by hand

This part sounds like an implementation detail, but it's the heart of the matter.

Every decent HTTP client can follow redirects for you. You ask for a URL and get back the final response. That's exactly what a browser wants. For an SEO crawler, it's useless, because the client quietly throws away the hops it went through. You learn where you ended up, but not how you got there.

For an SEO crawler, the chain is the finding. "This URL takes three hops to reach a 200" is an audit. "These two URLs redirect to each other" is an audit. So CrawlStat's HTTP client has redirect following turned off, and the engine walks the chain itself:

1. Request the URL. If the response is a 3xx with a Location header, resolve that location (relative ones are legal and common).
2. Record the hop: hop number, from, to, and status code.
3. If the next URL has already appeared in this chain, stop and mark it as a loop instead of spinning forever.
4. Otherwise, follow it and repeat. After 10 redirects, give up and report the URL as unfetchable.

Every hop gets stored in the crawl database. Each URL row then carries two status codes: status_code, the 3xx the URL itself returned, and final_status_code, what the end of the chain returned. That difference is the point. A crawler that only reports "200" for http://example.com/pricing is hiding your problem from you.

What CrawlStat reports

Three audits cover redirects:

The third one is often the most valuable. The first two tell you which redirects are bad. The third tells you which pages are sending traffic into them.

Finding them in the app

1. After a crawl, open Issues and click Redirect chain or Redirect loop. The results table filters down to the affected URLs.
2. Select a row and press Enter. The detail panel shows the redirect chain hop by hop, with the status of each one.
3. Open the Inlinks panel to see which pages link to that URL. Those are the pages you'll edit.
4. For an overview, the Response codes tab shows status, final status and the number of redirects followed side by side. Any count above two is highlighted.

How to fix them

Collapse chains to one hop

Change each redirect so it points straight at the final destination, not at the next hop. The cleanest way is to put all canonicalisation (scheme, host, trailing slash) in one rule in one place, so every URL is rewritten at most once:

# Before: three rules, applied in sequence
http://example.com/pricing    → https://example.com/pricing
https://example.com/pricing   → https://www.example.com/pricing
https://www.example.com/pricing → https://www.example.com/pricing/

# After: every variant goes straight to the canonical form
http://example.com/pricing      → https://www.example.com/pricing/
https://example.com/pricing     → https://www.example.com/pricing/
http://www.example.com/pricing  → https://www.example.com/pricing/
https://www.example.com/pricing → https://www.example.com/pricing/

When you migrate URLs, update the old redirect rules to point at the new destination. Don't add a new hop on top of them.

Then stop linking to redirects at all

A redirect should only ever serve external traffic and old bookmarks. Everything you control should name the destination directly:

• Internal links, especially in templates. A single navigation or footer link to an old URL can account for thousands of wasted requests across a site, which makes this one of the cheapest wins there is.
• Your XML sitemap. It should list final URLs that return 200, nothing else.
• Canonical tags. A canonical pointing at a redirect sends search engines a mixed signal. Point it at the URL that returns 200 directly.

Break loops at the source

Loops nearly always come from two rules that disagree. The classic is a rule that sends HTTP to HTTPS fighting a trailing slash rule, or a CMS redirect duplicating one already on the server. Find the rules that point at each other, decide which layer owns canonicalisation, and remove the duplicate.

Crawl again to confirm

Redirect rules are easy to get almost right. After you deploy a fix, crawl again and check that the chain and loop counts went to zero, and that the list of internal links to redirects got shorter.

Try it on your site

Redirect audits are part of every crawl, and CrawlStat is free and open source, with no limit on the number of URLs. Download CrawlStat, crawl your site, and open Issues. And if you'd like the full explanation for each audit, the docs for redirect chains and redirect loops have it.