HTTP headers: inspect caching and response metadata

Read Content-Type, Cache-Control, Location and other response headers, compare like-for-like requests, and identify the next check for stale or unexpected content.

Web & TLS

Open HTTP Headers →

Capture the response before changing configuration

Run HTTP Headers against the public hostname, then keep the response status and headers together. Headers describe that particular response; they are not a complete inventory of every resource on the site. A CDN, proxy and application may each contribute fields. Repeat the same target and IP version when comparing a before-and-after deployment.

Check the content and redirect context

Content-Type describes the returned representation. If a stylesheet URL returns HTML, a browser can reject it rather than apply the page’s styling. Location identifies a destination when used in a redirect response; inspect the associated status as well. Server or proxy-identification headers can offer clues, but names can be hidden or customized and should not be treated as reliable version evidence.

Read caching directives together

Cache-Control describes caching instructions, while other fields can expose age or validation information. A cache hit does not automatically mean a response is stale; it means a stored response was used according to that cache’s behavior. Diagnose the specific symptom: old HTML, an old asset, or a path that returns the wrong content. Compare the relevant response and deployment state before purging every cache.

Choose a targeted follow-up

Use Redirect Checker for the request’s redirect path and Security Headers for browser-protection policy findings. For problems affecting only one resource, inspect that exact resource in browser developer tools or your own HTTP client; a hostname-level lookup cannot represent every path. If the browser and checker disagree, compare cookies, request method, IP family and the endpoint being served.

Worked example

Illustrative example — not a live test
Expected resource: application stylesheet
Returned Content-Type: text/html
Next step: inspect routing and asset deployment, not the font family.

What to check next

  1. Keep status, headers and the checked target together.
  2. Compare equivalent requests across repeated checks.
  3. Inspect an affected asset directly when the symptom is path-specific.

Common questions

Do these headers describe every page on the domain?

No. Applications and proxies can return different values for different paths and responses.

Does Cache-Control identify the cause of every stale page?

No. It is evidence to combine with the actual response, cache behavior and deployed files.

References

HTTP header reference: MDN

HTTP caching: RFC 9111