scalpel@labs: ~/glossary/wasted-redirect-hops.mdx5 sections

Wasted Redirect Hops

A wasted hop is any redirect in a chain that could be eliminated by pointing its source directly to the final URL. The most common forms are 301→301 chains from old migrations and http→https→www stacks that should be one rule.

extension: Scalpel Redirectsupdated: 2026-08-14read_time: 1 min
less wasted-redirect-hops.mdx

Why it matters

Every wasted hop is a full round-trip every visitor pays, every crawl wastes. On 50ms latency, one extra hop adds 50ms to page load. A thousand visitors a day? That's real time gone. The fix already exists in your config; you're just pointing at the wrong destination.

The http→https→www stack is a classic tell: the protocol and host rules were written independently. Merge them into one rule per entry variant, usually a five-minute fix with measurable TTFB gain. Successive migrations (old-slug→older-slug→new-slug) leave 301→301 chains nobody ever cleaned up.

How it works

Every entry variant needs exactly one rule pointing to your final canonical. Four variants means four rules:

  • http://example.com
  • http://www.example.com
  • https://example.com
  • https://www.example.com

Each points straight to https://www.example.com. Four requests total: three redirects, one content load. No bouncing between intermediates.

Without consolidation, http://example.com→https://example.com→https://www.example.com is three requests for nothing. The fix: one rule per entry variant, one destination each.

What does not matter

Google's promise that "redirects are handled fine" is true. Google will crawl your chains and won't penalise you. Neither fact is a reason to ship them. The cost is real: user latency, crawl budget spent on redirects instead of content, and cache misses that could have hit. "Google handles it" isn't an excuse for friction.

Code example

Before: three rules that chain.

# Rule 1: http to https
server {
  server_name example.com;
  listen 80;
  return 301 https://example.com$request_uri;
}

# Rule 2: https without www to https with www
server {
  server_name example.com;
  listen 443 ssl;
  return 301 https://www.example.com$request_uri;
}

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

After: one rule per entry variant.

# Rule 1: http://example.com → final
server {
  server_name example.com;
  listen 80;
  return 301 https://www.example.com$request_uri;
}

# Rule 2: https://example.com → final
server {
  server_name example.com;
  listen 443 ssl;
  return 301 https://www.example.com$request_uri;
}

# Rule 3: http://www.example.com → final (less common but thorough)
server {
  server_name www.example.com;
  listen 80;
  return 301 https://www.example.com$request_uri;
}

# Rule 4: Final destination
server {
  server_name www.example.com;
  listen 443 ssl;
  # Content here
}

To audit and track regressions:

# Before
curl -sIL http://example.com | grep "< HTTP"
# < HTTP/1.1 301 Moved Permanently
# < HTTP/1.1 301 Moved Permanently
# < HTTP/1.1 200 OK

# After
curl -sIL http://example.com | grep "< HTTP"
# < HTTP/1.1 301 Moved Permanently
# < HTTP/1.1 200 OK

How Scalpel shows it

Scalpel flags known collapsible patterns: "301→301 chain, collapse to one hop" or "http→https→www, configure a single redirect rule." It identifies these patterns and surfaces them immediately, so you see the fix opportunity.

Sources