The fix, in one snippet
Cache-Control: public, max-age=0, must-revalidate
ETag: "a4f2c1"Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We read the Cache-Control header of each HTML response and report pages that send none, or that send no-store. This is reported as information rather than a failure, because the right policy depends on what the page is: a bank statement and a blog post have opposite requirements.
Only the HTML document is examined. Static assets usually have their own, much longer, policy and are not part of this check.
Why it matters
With no directive, caches fall back to heuristics, and the result is inconsistent between browsers and proxies. With no-store, caching is forbidden entirely, including the back-forward cache, so returning to a page re-runs the whole request.
For genuinely personalised pages that is correct and necessary. For an article, a product listing or a marketing page it is a straightforward waste: the same bytes travel again for a document that has not changed.
A short cache with revalidation gives most of the benefit with none of the staleness risk, because the browser still asks whether the page changed; it just gets a cheap 304 when it has not.
How to fix it
Decide per page type. For public HTML that changes occasionally:
Cache-Control: public, max-age=0, must-revalidate
ETag: "a4f2c1"The browser revalidates on every visit but transfers nothing when the ETag matches. For pages that can be a little stale, add s-maxage so a CDN can serve them without touching the origin. For signed-in pages, keep no-store: that is the case it exists for.
Static assets are the opposite case: fingerprint the filename and cache for a year with immutable.
Where this fits
No cache policy on HTML is check 7 of 7 that the seo & site health audit runs under technical seo and speed, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Language attribute missing (low), where the lang attribute on <html> tells screen readers which pronunciation to use and search engines which language to file the page under. An attacker who has that does not need this, so it is the better use of the same hour.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: No cache policy on HTML (info severity)
Scanner check id: seo-cachingThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.