DNS & Routing

Following the Redirect Chain

Type example.com into a browser and you rarely land in one hop. A typical site bounces you http → https → www → /home before the page even renders — four redirects, each one a place where SEO link equity, HTTPS security, or a few hundred milliseconds of load time can quietly leak away.

~6 min read Intermediate DNS & Routing

TL;DR

A redirect is an HTTP 3xx status code plus a Location header pointing to the next URL. 301/308 are permanent (cached, pass SEO value); 302/307 are temporary. Keep chains short, never lose HTTPS partway through, and pick exactly one canonical host (www or apex) so every variant lands there in a single hop.

Anatomy of a redirect

A redirect is just an HTTP response whose status code is in the 300s and which carries a Location header. The browser reads the status, sees the Location, and immediately makes a new request to that URL. Repeat until it gets a 200 OK (or an error). That sequence of hops is the redirect chain.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

The four codes that matter

Code	Meaning	Method & caching behaviour
`301`	Moved Permanently	Cached by browsers/CDNs. Passes SEO value to the target. Historically may switch the request to GET.
`302`	Found (temporary)	Not cached long-term. SEO value stays with the original URL. May switch to GET.
`307`	Temporary Redirect	Like 302 but preserves the method (a POST stays a POST).
`308`	Permanent Redirect	Like 301 but preserves the method. The modern, unambiguous “permanent.”

The permanent/temporary distinction isn't cosmetic. A 301/308 tells search engines “the target is the real home of this content — move the ranking there,” and tells browsers “you can remember this and skip the hop next time.” A 302 says “this is a detour, keep crediting the original.” Use a temporary redirect for a permanent move and you bleed SEO value; use a permanent one for a temporary A/B test and browsers will stubbornly cache it long after you stop.

The canonical chain

Every site needs to decide on one canonical hostname — either the bare apex (example.com) or the www subdomain — and funnel every other variant to it. There are four front-door URLs that all need to converge:

Both chains end in the same place, but the top one does it in two secure hops. The bottom one adds latency and spends an extra hop on insecure HTTP.

Where chains go wrong

Redirect loops. A → B → A. The browser gives up with “too many redirects” and the page never loads. Usually a misconfigured www/apex rule or a CDN and origin disagreeing about who redirects.
Chains that are too long. Every hop is a full round-trip — DNS, TCP, TLS, request, response — before the real page even starts. On mobile networks a four-hop chain can add a noticeable delay. Aim for one hop, two at most.
Losing HTTPS in the middle. If the chain dips back to http:// partway through (e.g. https://example.com → http://www.example.com → https://www.example.com), there's a window where the request is in the clear. Always redirect to HTTPS as early as possible and never downgrade.
Mixing 301 and 302 in one chain. Search engines get an ambiguous signal about which URL is canonical. Keep the permanent hops permanent.
Fake redirects. A <meta http-equiv="refresh"> tag or a JavaScript location.href assignment looks like a redirect to a user but isn't an HTTP redirect. Search engines treat them far more weakly, and they only fire after the page has already loaded. Use a real 3xx whenever you can.

HSTS removes the first hop entirely. Once a browser has seen a valid Strict-Transport-Security header from your site, it rewrites http:// to https:// internally on every future visit — the insecure first request never even leaves the machine. That's one fewer hop and one fewer interception window. (See the security headers article.)

What FatDig shows you

FatDig follows the chain for you and reports every hop with its status code, so you can see at a glance whether a domain reaches its canonical home in one clean step or wanders through four. The Advanced Dig summarises the first and final status and the final URL; the standalone Redirect Check tool lays out the full hop-by-hop sequence. Watch for chains longer than two hops, any http:// hop sitting in the middle, and a final status that isn't a clean 200.

Try it on FatDig: run your own domain through the Redirect Check and count the hops from http:// (no www) to where you land. More than two, or an insecure hop in the middle? That's a quick web-server rule away from being fixed.