Redirect Chain: What It Is, What It Costs, and How to Collapse It

## Why it matters

Chains accumulate silently. An http to https rule from one year, a www rule from another, a CMS slug change from last week. Nobody designs a four-hop chain; it grows. The costs are concrete: a round trip per hop, crawl-budget spend, and Googlebot abandoning very long chains. The common fear is off-target: chains are not a penalty. They are friction: every extra hop is latency the user pays, bandwidth a crawler spends, and cache misses the CDN experiences.

Measuring the cost is straightforward. Each hop adds one full network round trip. On a 50ms latency connection, a three-hop chain costs 150ms of pure redirect overhead before the page even begins to load. Users experience this as slower pages; crawlers experience this as less content crawled per budget.

## How it works

Redirect chains form when layered rules each add one hop. The browser requests http://example.com, gets a 301 to https://example.com, follows it, gets a 302 to https://www.example.com, follows it, and finally gets 200 with content. Each rule was written independently and correctly; together they compound.

Googlebot follows redirects up to a documented limit. Once it hits that limit, it stops and treats the final response, even if still 3xx, as the end of the chain. The exact limit varies and is subject to change, but shorter chains are always safer. More importantly, users pay for every hop in latency, so the practical rule is simple: point every entry URL directly at the final target.

## What does not matter

Chains are not a manual-action risk or a ranking penalty. A well-formed chain that ends in 200 with indexable content does not incur a ranking hit. The reason to collapse it is performance and crawl efficiency, not fear of punishment.

The "maximum of 5 redirects" rule is folklore. Googlebot follows up to 10 hops before giving up, but the real cost is latency to users, not a search rank threshold. Every hop matters to performance; no hop count is magical.

## Code example

Before: a three-hop chain that could be one rule.

# Server 1: CDN or proxy
server {
  server_name example.com;
  return 301 https://example.com$request_uri;
}

# Server 2: Origin expecting https
server {
  server_name example.com;
  listen 443 ssl;
  return 301 https://www.example.com$request_uri;
}

# Server 3: Final destination
server {
  server_name www.example.com;
  listen 443 ssl;
  # Content here
}
Copy

After: one rule per entry variant.

# One rule per combination of scheme and host
server {
  server_name example.com www.example.com;
  listen 80;
  return 301 https://www.example.com$request_uri;
}

server {
  server_name example.com;
  listen 443 ssl;
  return 301 https://www.example.com$request_uri;
}

server {
  server_name www.example.com;
  listen 443 ssl;
  # Content here
}
Copy

To audit chains and track regressions, run this:

curl -sIL http://example.com | grep "< HTTP"
# Output shows each hop's status and full count
Copy

## How Scalpel shows it

Scalpel Redirects renders the chain view as its centrepiece: one card per hop with status chips and connectors, client-redirect tails linked in, and the verdict line summing up the chain. Every hop's status, cache state, and hints are visible at once. Export the chain as JSON or CSV to diff before and after a migration, catching regressions in CI.