Redirect Chains — What Every Extra Hop Costs, and How to Monitor Them

Nobody designs a redirect chain. They accrete. The http→https redirect went in during the TLS migration; the non-www→www rule came with the CDN; the trailing-slash normalization ships with the framework; the /home→/ rewrite is left over from the old CMS. Each one is individually correct — and a user who types example.com/home now bounces through three or four full round trips before receiving a byte of your actual page.

Redirect chains are the rare problem that hurts performance, SEO, and reliability at once, while being invisible in day-to-day browsing because your own browser has cached its way past them. Let's make them visible.

How one URL becomes four requests

The classic stack, hop by hop:

http://example.com/page
  → 301 → https://example.com/page       (scheme upgrade)
  → 301 → https://www.example.com/page   (host canonicalization)
  → 301 → https://www.example.com/page/  (trailing slash)
  → 200

Three redirects, four requests, and every request is a full HTTP transaction. Worse, the hops don't share connections:

• Hop 1 → 2 switches scheme, so it's a new connection — and now with a TLS handshake.
• Hop 2 → 3 switches hostname, so it's a new DNS lookup, new TCP connection, and new TLS handshake — www.example.com is a different origin from example.com, and nothing from the previous connection is reusable.
• Hop 3 → 4 at least stays on the same origin and can reuse the connection.

On a decent connection each cross-origin hop costs roughly 100–300 ms; on mobile networks with real-world latency, it's routinely several hundred. Stack three hops and you've spent close to a second before your server starts doing any work — pure protocol overhead, experienced most by exactly the visitors arriving from old links, email campaigns, and typed-in URLs.

Trace your own chain in ten seconds

curl shows the whole story:

curl -sIL http://example.com/page | grep -iE '^(HTTP|location)'

-s silences the progress bar, -I fetches headers only, -L follows redirects. Typical output:

HTTP/1.1 301 Moved Permanently
location: https://example.com/page
HTTP/2 301
location: https://www.example.com/page
HTTP/2 301
location: https://www.example.com/page/
HTTP/2 200

Every location: line is a hop. Two useful variations: add --connect-timeout 5 -w '%{num_redirects} redirects\n' -o /dev/null for a quick count, and run the trace against the variants of your URL — http:// and https://, with and without www, with and without the trailing slash — because each entry point has its own chain.

The fix is almost always the same: redirect once, directly to the final form. Your server config should compute the canonical URL — scheme, host, path, slash — and issue a single 301 to it, rather than delegating each normalization to a separate rule that fires in sequence. In nginx, that means a dedicated catch-all server block:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # cert must cover BOTH names — see below
    return 301 https://www.example.com$request_uri;
}

…with only the canonical https://www.example.com block actually serving content. One hop from any entry point.

The certificate-on-every-hop gotcha

Here's the failure mode that turns a redirect chain into an outage: TLS is negotiated before the redirect is sent. A redirect away from a hostname doesn't excuse that hostname from needing a valid certificate.

The classic version is apex vs www. Your site lives at https://www.example.com, the cert covers www.example.com, and https://example.com redirects to it — except the browser must first complete a TLS handshake with example.com to receive that redirect. If the cert doesn't also cover the apex, every visitor who types https://example.com hits a full-screen certificate error and never sees the redirect at all. Meanwhile your monitoring, pointed dutifully at the canonical www URL, stays green.

The rules:

• Every HTTPS hostname in the chain needs a valid cert — apex, www, old domains you still redirect, regional variants, all of them.
• Cover apex and www together (a SAN listing both, or a wildcard plus the apex) even if one "only redirects."
• Redirecting domains still expire. The cert on that legacy domain you 301 to the new brand will lapse silently unless something is watching it — the redirect works right up until the handshake in front of it doesn't.

301 vs 302 discipline

The status code you return is a promise, and search engines take it literally:

• 301 (permanent) — "the resource has moved; update your records." Browsers cache it aggressively, and search engines transfer indexing signals to the target. Correct for canonicalization: http→https, apex→www, old-URL→new-URL.
• 302 (found / temporary) — "it's over there for now; keep asking me." Not cached long, and search engines keep the original URL indexed. Correct for genuinely temporary situations: maintenance pages, A/B routing, geo-redirects.

The discipline failures run both directions. A 302 doing a permanent job leaks — search engines keep crawling the old URL indefinitely, and every user pays the hop forever because browsers won't cache it. A 301 doing a temporary job is worse: browsers cache 301s so hard that "undoing" one takes weeks of stragglers stuck on the cached redirect. Check what your stack actually emits — several frameworks and hosting layers default to 302 for rules people intend as permanent.

The SEO cost of chains compounds quietly: crawlers spend budget on intermediate hops, some crawlers abandon long chains entirely (following only a handful of hops), and each hop is one more place for a signal-diluting misconfiguration. One clean 301 is both the fast answer and the search-friendly one.

Monitor the destination — and the journey

Most monitoring follows redirects to the final URL, asserts on the 200, and calls it a day. That verifies the destination while ignoring the journey — and the journey is where this whole class of failure lives. Worth watching explicitly:

• The final URL is the one you intended. A redirect that starts pointing somewhere new — staging, a parked page, an attacker's clone — still ends in a happy 200.
• The hop count. Alert when the chain grows; that new hop someone shipped on Friday costs every visitor real latency.
• Each hop's certificate, apex and www included — the gotcha above.
• The status codes themselves. A 301 that quietly becomes a 302 after a config change is invisible to users and expensive for SEO.

CompleteStatus checks redirect behavior as part of its HTTP monitoring — following chains, verifying the final destination, timing the whole journey, and watching certificates on your domains including the ones that "only redirect." Because as we covered in ping vs HTTP checks, a check that stops at "something responded" misses the failures that actually happen. Start monitoring free — and before you do, run that curl -sIL against your homepage. If you see more than one location: line, you now know what this week's small win looks like.