Caching
How may this response be reused?
Review Cache-Control, validators and cache-related fields together. The checker reads declarations; it does not simulate cache storage or reuse.
Behind the response
Understand what your server is saying.
A page response carries more than content. Inspect the headers sent along its redirect journey and make sense of caching, delivery, indexing and browser policies.
Inspect the headers
HTTP Header Checker
Check the response to a public URL.
This tool sends a server-side GET without browser cookies or custom authentication. It captures headers across up to five redirects, including headers received before an error stops the check.
02 / Understand the headers
Your header report
Enter a public URL to inspect response headers.
Plain-text report
For HTML signals, continue with the SEO Page Checker.
Put it to work
Different headers answer different questions.
Header presence is evidence to interpret. It is not a pass mark for speed, security or search visibility.
Indexing and links
What is declared outside the HTML?
X-Robots-Tag and Link can carry crawler instructions or relationships. HTML tags and robots.txt need separate inspection.
Delivery and browser policies
What did the server send with this response?
Inspect content type, redirects and browser policy headers. Their values and context matter more than a simple present-or-missing checklist.
Illustrative example
A redirect and its destination can say different things.
Illustrative responses for a moved public resource. The cache values belong to each response separately; this is not a recommended configuration to copy.
Response 1 · Redirect
HTTP 301
Location: /guides/current
Cache-Control: public, max-age=3600The redirect declares a one-hour freshness lifetime. That declaration belongs to the redirect response.
Response 2 · Destination
HTTP 200
Content-Type: text/html
Cache-Control: no-cacheThe destination asks caches to revalidate before reuse. no-cache does not mean that storage is forbidden.
The question to take to your developer: which layer owns each header—application, server or CDN—and does that response behave as intended?
Before you move on
Keep the request context with the result.
Record the exact URL and response
Keep the status and relevant headers together. A final-page policy does not describe every earlier redirect.
Compare against the real visitor request
Location, cookies, user agent and access controls may change the response. This unauthenticated request is one view of the server.
Test configuration changes in context
Changing cache or browser policies can affect real behaviour. Verify the intended result in the application and browser after implementation.
Your questions
Read the response in context.
Does no-cache mean nothing gets stored?
No. It requires validation before reuse; no-store requests that caches do not store the response. Choose policies based on the content and application requirements, not the wording alone.
Is this a security audit?
No. It displays browser-policy headers and explanations, but does not test their strength or whether the application is secure. Missing headers are not automatically failures.
Can it check a PDF or an error response?
Yes. It inspects headers rather than requiring HTML. Headers received from error responses can still be shown, even when the full redirect check cannot finish.
Will it display cookies or credentials?
Cookie and credential-like header values are redacted, and browser cookies are not forwarded. The report is a bounded diagnostic view rather than a complete raw network capture.
Need help finding the setting behind a header?
Share the URL, report and behaviour you expected. We can help trace conflicting application, hosting and CDN settings before changes are made.
Send an enquiry