Quick answer
Set an intentional Cache-Control policy for HTML responses based on how frequently the content changes and whether it is public or personalised. A missing header deserves review, but the correct directive depends on the response—not on a blanket recommendation to cache everything.
What the issue means
Cache-Control controls caching behaviour for browsers and shared caches. no-cache allows a response to be stored but requires revalidation before reuse; no-store tells caches not to store it. private restricts storage to a private cache, while public permits shared-cache storage. See RFC 9111 for the directive semantics.
Why it matters for SEO
Caching affects delivery efficiency and freshness more directly than rankings. Public pages that can be reused may benefit from caching; account pages and sensitive responses need stricter controls.
How NOTABIS detects it
The cache-policy-review rule checks whether the measured HTML response advertises a Cache-Control policy. It does not benchmark cache hit rates, CDN behaviour, or freshness correctness.
How to check it yourself
Inspect the response with browser developer tools or a GET request such as curl -sS -D - -o /dev/null https://example.com/page. Check cache headers at the origin and CDN, and test both anonymous and authenticated responses where relevant; a HEAD response may not match the GET response.
How to fix it
Choose directives per response class. Cache public, versioned or stable content for an appropriate period; use private when a response may be stored by the user’s browser but must not be shared by a CDN; use no-store when it should not be stored. Purge or revalidate content deliberately after important changes. These directives are not a substitute for access controls.
For example, an anonymous public page could use a short shared-cache lifetime, while a response containing account-specific data needs a private policy:
Cache-Control: public, max-age=3600
Cache-Control: private, no-store
These are examples, not defaults for every route. Confirm how the origin and CDN apply the policy before enabling shared caching.
When this is intentional or does not need fixing
A dynamic, personalised, authenticated, or security-sensitive response may intentionally avoid shared caching. Document that policy rather than adding a header that could leak content.
Related issues
Review response time, compression, large HTML, and security headers separately.
Run a NOTABIS audit
An audit shows the final response headers observed for affected pages so you can distinguish missing policy from an intentionally uncached response.