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.
FAQ
Do we risk visitors seeing outdated content with caching?
Not to any noteworthy degree with short caching periods: a rule of a few minutes means changes reach everyone within that period at the latest. For pages that rarely change, that's a very good trade for the speed gained.
Does the Cache-Control header directly influence ranking?
Not as a ranking factor of its own. The effect is indirect: caching makes pages faster (load time is a factor), and lets crawlers work more efficiently — both benefit visibility.
Where is this setting changed?
In the web server configuration, the hosting panel, or the settings of the system in use, or a caching plugin. The report provides the measured current value as a starting point for technical support.