A header name is not a cache-status report. Investigate who issued the policy and whether the response is safe to reuse.
Start with the actual document response
Open a logged-out public article in the Network panel and select the HTML document, not its stylesheet. Record Cache-Control, Age, status, and any provider cache-status header. Repeat with a normal reload and a new browser session. Keep the address, time, and cookie state beside each result. A screenshot of a cache plugin setting cannot show what the browser ultimately received.
Read the policy before changing it
No-cache allows storage but asks for validation before reuse; no-store tells caches not to store the response. Private concerns shared caches, while browser storage may still be permitted. These directives do not by themselves tell you whether an upstream managed cache served a hit. Use the provider’s documented status signal and compare it with the response body rather than guessing from one header.
Find the component that owns the header
Compare the same document before and after one reversible staging change. Check the host’s HTML cache, CDN response rules, and application configuration separately. If two components add conflicting policies, document both owners and resolve the conflict at its source. Do not simply strip restrictive headers at the edge: an account page could become reusable across visitors even though a public article appears faster.
Test a public and a private journey
Use two separate test sessions. Visit a public post in both, then sign into a test account in one session and open account-specific content. The second session must not receive the first session’s identity or saved data. Also check a form submission and its resulting page. A higher hit rate is not an acceptable outcome when customer-specific responses are exposed.
Choose a bounded correction
Define which route or response class needs a policy change and who will maintain it. Apply the change on staging, purge only the affected managed entries, then repeat the document tests. If privacy or freshness checks fail, restore the earlier rule and capture the conflicting headers for the host or plugin vendor. Keep public caching and customer data handling as separate acceptance criteria.
Symptom-to-cause worksheet
| What you observe | What to investigate | Next check |
|---|---|---|
| HTML has no-cache | Validation may still reuse stored content | Inspect repeat request status and validators |
| Public HTML changes policy between requests | Multiple owners or different session states | Compare cookies and header rules |
| Account HTML receives shared hits | Personalized-response exclusion may be missing | Stop the shared rule and test two accounts |
Illustrative example
Illustrative response policies; these are not universal server settings.
Public article: Cache-Control: public, max-age=60
Private response: Cache-Control: private, no-storeWorked investigation scenario
This is an illustrative case, not a measured Velonic result. A hypothetical public article validates on every reload but still displays current content. The first response includes a validator and the second returns 304. Rather than treating no-cache as a broken cache, record the saved transfer and check the managed-cache status separately. Keep the account-page policy untouched. The investigation ends when the public freshness requirement and the private-session isolation requirement both pass, not when every response says HIT.
Put it into practice
- Capture the HTML headers, not only asset headers.
- Identify the owner of every caching rule.
- Verify private responses with independent sessions.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.