Learn
Cache-Control Header: max-age, no-cache, no-store and What Each Does
Two directives are routinely confused: no-cache still caches, and no-store is the one that does not. Getting that pair wrong is the most expensive caching mistake there is.
Run a fresh DomainLens audit and use the report as your priority list.
Every directive that matters
| Directive | What it does | Use on |
|---|---|---|
| max-age=N | Reusable for N seconds without asking | Fingerprinted static assets |
| no-cache | Cached, but revalidated before every reuse | HTML that changes |
| no-store | Never written to any cache at all | Personal or sensitive responses |
| public | Shared caches may store it too | Anything identical for all visitors |
| private | Only the browser may store it | Personalised pages |
| immutable | Will never change; skip revalidation | Versioned assets with a long max-age |
| s-maxage=N | Overrides max-age for shared caches only | CDN-specific lifetimes |
no-cache versus no-store
The names are backwards from how they read. no-cache does allow caching — it stores the response and then revalidates with the server before serving it again. If nothing changed, the server answers 304 and the cached copy is reused without re-downloading the body.
no-store is the absolute one. Nothing is written anywhere, and every request is a full download. It is the correct choice for genuinely sensitive responses and the wrong choice for almost everything else, because it throws away the cheap 304 that no-cache gives you.
# no-cache: stored, but checked every time.
# A 304 costs one small round trip, not the whole body.
Cache-Control: no-cache
# no-store: never stored. Every request downloads
# the full response again.
Cache-Control: no-store
# What most HTML actually wants:
Cache-Control: no-cache
ETag: "a1b2c3"
# What fingerprinted assets want:
Cache-Control: public, max-age=31536000, immutableWhich policy belongs where
The immutable pattern only works if your build genuinely changes the filename on every content change. Applying a year-long max-age to a file named style.css means visitors keep an outdated stylesheet for a year with no way to correct it. Confirm what your server actually sends with the HTTP headers checker .
- HTML — no-cache with an ETag or Last-Modified. Content changes and readers must see it, but revalidation is cheap.
- Fingerprinted CSS and JS — public, max-age=31536000, immutable. The filename changes when the content does, so the old copy can never be wrong.
- Unfingerprinted assets — a short max-age, because you have no way to bust the cache.
- Images and fonts — long max-age if versioned, moderate if not.
- Authenticated pages — private, no-store, so shared caches never hold one user's content.
What caching does and does not do for SEO
Cache-Control is not a ranking signal, and Googlebot largely ignores it — it fetches fresh rather than reusing a cached copy. So caching policy has no direct search effect at all.
The indirect effect is real but narrower than usually claimed: caching improves repeat visits, not the first one. Core Web Vitals field data is dominated by first visits from search, where nothing is cached yet. Caching is worth getting right for returning users and for origin load — just not as a route to better LCP for search traffic.
How DomainLens contributes
DomainLens reports the cache policy a URL returns as part of its audit, so a no-store on your static assets surfaces without reading headers by hand. For the transfer size itself see gzip vs brotli , and for the metric caching is often mistakenly expected to fix see what LCP measures .
- What is the difference between no-cache and no-store?
- no-cache stores the response but revalidates before reusing it, so an unchanged resource costs a small 304 instead of a full download. no-store never stores anything, so every request downloads the whole response again.
- Does Cache-Control affect rankings?
- Not directly. Googlebot does not reuse cached copies the way a browser does. The benefit is for returning visitors and for your origin, not for search.
- What max-age should HTML use?
- Either a very short one or no-cache with validation. A long max-age on HTML means returning visitors keep seeing the old page with no way for you to correct it.
- When is immutable safe?
- Only when the filename changes whenever the content does — the fingerprinting most build tools apply. On a stable filename it is a trap.