Every time a browser loads a page, the server replies with a status line and a set of response headers before any content. Those headers are a compact status report: which server answered, how the response should be cached, whether the connection is being upgraded to HTTPS, and what security protections are in place. Reading them is one of the fastest ways to diagnose a misbehaving site.
Start with the status and the redirect chain
Before the headers, look at the status code and how you got there:
- 200, OK, the request succeeded.
- 301 / 308, permanent redirect. Good for
http -> httpsandnon-www -> www(or vice versa), as long as it lands in one hop. - 302 / 307, temporary redirect. Fine for short-lived cases, but not for canonical HTTPS/www rules.
- 4xx / 5xx, client or server error. A 502/503 points at the origin or a proxy, not DNS.
A long chain (http -> https -> www -> trailing slash) adds latency and can confuse crawlers. Aim for at most one redirect. The HTTP response header viewer shows each hop so you can spot a redirect loop or an unnecessary extra jump.
Security headers worth checking
- Strict-Transport-Security (HSTS), tells browsers to always use HTTPS for your domain. Look for a
max-ageof at least six months. Missing HSTS means a first visit can be downgraded to HTTP. - Content-Security-Policy (CSP), restricts which scripts, styles, and origins can load. A strong CSP is the single biggest defense against cross-site scripting.
- X-Content-Type-Options: nosniff, stops the browser from guessing (and mis-guessing) content types.
- X-Frame-Options / frame-ancestors, prevents your pages from being embedded in someone else's iframe (clickjacking).
- Referrer-Policy and Permissions-Policy, control how much referrer data and which browser features are exposed.
Missing security headers are not an outage, but they are easy wins that many audits flag.
Caching headers
- Cache-Control, the master switch:
no-storefor sensitive pages,public, max-age=...for static assets,no-cacheto force revalidation. - ETag / Last-Modified, let the browser ask "has this changed?" and get a cheap
304 Not Modifiedwhen it has not. - Age and X-Cache, reveal whether a CDN served the response from cache and how old that copy is.
If a change you deployed is not showing up, stale caching headers or a CDN edge cache are usual suspects.
Server and platform headers
Server, X-Powered-By, and CDN markers (CF-RAY, Via) tell you what actually answered. That is useful for debugging, though from a hardening standpoint, many teams deliberately strip version details so they do not advertise exactly what they run.
Command-line equivalents
# Headers only, following redirects and showing each hop
curl -sIL https://example.com
# Just the final status code
curl -o /dev/null -s -w "%{http_code}\n" https://example.com
FAQ
How many redirects is too many?
One is ideal, two is tolerable. Three or more adds real latency and risks redirect loops. Consolidate your http/https and www/non-www rules into a single hop.
I set a security header but it is not showing. Why?
Check that it is set on the final response, not an intermediate redirect, and that a CDN or proxy in front is not stripping or overriding it. View the full chain to see where it disappears.
Are missing security headers an emergency?
Not an outage, but a real risk-reduction opportunity. Add HSTS and a Content-Security-Policy first, they deliver the most protection per line of config.