HTTP header inspector
Every header a site sends back, the redirects it passed through on the way, and which security headers are missing. Requested from our servers, so you see what the site sends a stranger rather than what it sends you.
The short answer: Headers explain behaviour that the page itself cannot. A cache that will not clear, a redirect loop, a download that opens in the browser instead of saving - All of it is decided here, before a single byte of the page is rendered.
What headers explain that a page cannot
A page that will not update
Almost always Cache-Control or Expires. If a response says it is good for a week, your browser will not ask again for a week however many times you reload. A hard refresh bypasses it once; everyone else still sees the old copy until the header changes.
A redirect loop
Two rules disagreeing - Typically one forcing HTTPS and another forcing a bare domain, each undoing the other. The chain above makes it obvious in a way the browser’s error never does. The error code guides cover the codes you will see when it gives up.
Mixed content and blocked resources
A Content-Security-Policy decides what the page is allowed to load. When a widget silently fails to appear, this header is usually why, and nothing in the page source will say so.
Which server actually answered
Server, Via and CDN-specific headers show whether you reached the origin or an edge cache. That matters during an outage: An edge serving stale content while the origin is down looks identical to a healthy site until you read the headers.