Many HTML pages are sent with Cache-Control: no-store
html_no_storeShort answer
At least 20% of the HTML pages Glimana crawled send a Cache-Control header containing no-store. That tells browsers not to keep the page at all. It is right for private pages such as account, cart and checkout, but on public content it keeps the browser from using its back/forward cache, so going back reloads the page.
Why it matters
Chrome and other browsers have long excluded no-store pages from the back/forward cache, so every Back press on these pages costs a full load. A blanket no-store usually comes from a plugin, framework or server default rather than a decision about each page. This rule is separate from No Cache-Control header, which lists pages that send no header at all.
How Glimana detects it
During each crawl Glimana stores the Cache-Control response header of every page. The rule looks at the live HTML pages that return 200 (at least 10) and fires once for the site when 20% or more of them contain no-store. The evidence shows how many pages send it and example URLs.
How to fix it
- Find the affected pages in Glimana. Open Issues › Many HTML pages are sent with Cache-Control: no-store. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Find what adds
no-store(application code, a plugin, the web server or the CDN) and limit it to pages that show private data. For public pages sendCache-Control: no-cache(the browser revalidates before reuse) or a shortmax-age.Security, membership and cache plugins sometimes send
no-storeon every page, and WordPress itself sends it for logged-in users (which a crawler is not). Check the plugin settings and the server configuration (.htaccess, nginxadd_header).Shopify sets its own caching headers for storefront pages;
no-storeon public pages usually comes from a proxy or CDN in front of the store. Check that layer’s cache rules.Look for a global middleware or framework default that sets
no-store(session handling often does). Apply it only to authenticated or personalised routes, and sendno-cacheor a shortmax-ageelsewhere. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The next crawl reads the headers again, and the task closes when fewer than 20% of HTML pages send no-store.
How the fix is verified
The next crawl reads the Cache-Control headers again; the issue closes when fewer than 20% of the HTML pages send no-store.