Every HTTP response carries a set of headers alongside the actual page content — metadata about caching, redirects, security policy, and server behavior that never renders on screen but shapes how the page actually behaves. Most of the time nobody looks at them. When something's subtly wrong — a redirect loop, a caching bug, a missing security header — the headers are usually where the answer is.
Status codes: the first thing to check
- 200 — OK. The request succeeded and here's the content.
- 301 / 308 — permanent redirect. Search engines and browsers will remember and reuse the new location going forward.
- 302 / 307 — temporary redirect. Treated as non-permanent; the original URL should still be checked next time.
- 404 — not found. The server is reachable and working, this specific resource just doesn't exist at this URL.
- 500 / 502 / 503 — server-side error. 500 is an application error, 502/503 usually point at a proxy, load balancer, or upstream service problem rather than the application itself.
Redirect chains
A single redirect (old URL → new URL) is normal and cheap. A chain of several redirects in a row (A → B → C → D) is a common, often-overlooked performance problem: each hop costs a full round trip before the browser even starts loading the real page, and search engines generally recommend keeping chains as short as possible — ideally a single hop. Inspecting the full redirect chain is one of the fastest ways to spot this.
Headers worth actually paying attention to
- Strict-Transport-Security (HSTS) — tells browsers to only ever connect over HTTPS for this domain going forward, even if a user types
http://. Missing HSTS on an HTTPS site is a common, easy security gap. - Content-Security-Policy (CSP) — restricts what sources scripts, styles, and other resources can load from, a major defense against cross-site scripting. Absent on a large share of sites, present and well-configured on security-conscious ones.
- X-Content-Type-Options: nosniff — stops browsers from trying to “guess” a file's type differently than declared, closing off a class of content-sniffing attacks.
- X-Frame-Options / frame-ancestors — controls whether the page can be embedded in an iframe on another site, the main defense against clickjacking.
- Cache-Control — governs how long browsers and CDNs are allowed to cache the response before checking back. Misconfigured caching is a common cause of “I deployed a fix but users still see the old version.”
- Server / X-Powered-By — often reveals the underlying server software and version. Many security-conscious setups deliberately suppress these to avoid advertising exploitable version information.
Response time
Time-to-first-byte (how long the server took to start responding) is a useful, isolated signal separate from total page load time — it reflects server and backend performance specifically, before the browser has even started downloading, parsing, or rendering anything.
When to check headers
- Debugging a redirect loop or an unexpectedly long redirect chain.
- Confirming basic security headers are actually present after a server or CDN configuration change.
- Investigating a stale-content complaint — checking whether Cache-Control is set the way you expect.
- Verifying a migration or DNS cutover didn't leave the old server still answering for the domain.
If headers show an unexpected server or an old redirect target after a migration, it's often a stale DNS record pointing at the wrong place rather than a server misconfiguration — worth ruling out first.
Inspect any URL's headers with the HTTP header checker.