This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung
Indexing
Why should public pages be cacheable?
Because caching makes public pages faster and eases the load on the server: browsers and intermediate stations are allowed to briefly hold onto a page once loaded, instead of requesting it fresh on every visit. The Cache-Control header controls that. If it says "no-store", any caching is forbidden — a rule meant for confidential content like customer accounts, and one that's almost always a mistake on a public page. Our check reports exactly this case.
What no-store is meant for — and what it isn't
"no-store" tells everyone involved: this response must not be kept anywhere, not even in the visitor's browser. For pages with personal data, that's correct. A public content page, though, has nothing to hide — it's the same for everyone. There, the prohibition only causes downsides: every click back reloads the page completely, every intermediate station has to pass it through instead of delivering it, and the server answers requests a cache would have handled long ago. Usually the setting comes from a template or a framework default that nobody chose deliberately.
What the check exactly measures
The check reads the Cache-Control header of public pages and flags unusually restrictive values like "no-store". The finding is a flag, not a violation — there are legitimate exceptions. The question for technical support is: is this prohibition intentional here? If not, the fix is one line in the server configuration.
- Check whether "no-store" on public pages was a deliberate decision — usually it's a framework default.
- Allow public pages a short caching period; even a few minutes noticeably eases the load on the server and improves load time.
- Keep strict rules where they belong: on pages with personal or changing data.
