No Cache-Control header
no_cache_headersShort answer
The page is served without a Cache-Control header. Browsers and CDNs then apply their own heuristics, which usually means the page is re-fetched more often than necessary. This issue affects how fast the page opens and the user experience; it has no direct effect on indexing. Set an explicit policy: a long max-age for static assets (images, CSS, JS with versioned names) and a short or no-cache policy for HTML that changes.
Why it matters
An explicit caching policy is what lets a CDN serve HTML from the edge and lets a returning visitor skip the request entirely. Without the header, intermediate caches behave inconsistently; some will cache a page you expected to be fresh, others will never cache a page that could have been.
How Glimana detects it
The rule fires when a 200 HTML response has no Cache-Control header at all. It does not judge the value; a page served with Cache-Control: no-cache is considered fine, because that is an explicit decision.
How to fix it
- Find the affected pages in Glimana. Open Issues › No Cache-Control header. 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.
Decide per resource type:
Resource Recommended header Versioned CSS/JS/fonts ( app.3f2a.js)Cache-Control: public, max-age=31536000, immutableImages Cache-Control: public, max-age=2592000HTML pages Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60(CDN caches 10 min, browser revalidates)Logged-in / personalised HTML Cache-Control: private, no-cacheCache plugins add browser-caching rules for assets. For HTML, set the header through the plugin's "cache lifespan" option or add it in the server config. If you use Cloudflare, a Cache Rule with "Edge TTL" also covers it.
Shopify sets cache headers itself; this rule should not fire on a store served directly by Shopify. If it does, the page is going through a custom proxy.
Set the header in middleware (Laravel
SetCacheHeaders, Expressres.set) or at the web server withexpires/add_header Cache-Control. Use filename hashing for assets so long max-age is safe. -
Publish and clear caches. Apply the server or CDN change (reload Nginx/Apache, save the Cloudflare rule), purge the cache, then check the live response with
curl -sI https://your-domain/page— the status line and headers you see there are exactly what Glimana and Googlebot get. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the HTML response carries a
Cache-Controlheader. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the HTML response carries a Cache-Control header.