cf-cache-status on 27 homepages: four HIT, four DYNAMIC, and 13 sites that never say how old the copy is

FIELD TEST · 2026-09-01 · 27 homepages · one request each · cache status response headers

Sample and method: 30 sites requested once each on 2026-09-01 with a desktop Chrome user agent, redirects followed, no JavaScript executed, every cache-related header read off the final response. Three sites dropped out — stackoverflow.com and medium.com answered 403, reddit.com returned an 8,393-byte shell. That leaves 27.

Twenty of the 27 homepages named the layer that answered. Eight did it with cf-cache-status, split four HIT against four DYNAMIC, and another twelve used one of four other header names with no agreement on spelling. Six sites named nothing. Thirteen sent no age header, so their response gives you no way to tell how old the copy you just received is.

How we measured it

One GET per homepage on 2026-09-01, desktop Chrome user agent, redirects followed, JavaScript never executed. A homepage counts as reporting its cache status if the final response carried at least one of five header names: cf-cache-status, x-vercel-cache, x-cache, x-cache-status or x-nextjs-cache. We also recorded age and server on every response.

The exit node was in Osaka, Japan, and that belongs in the method rather than a footnote. A cache status describes one edge location at one instant. The same URL fetched from Frankfurt lands on a different node, which may be holding a different copy, and would report whatever that node had. We requested once per site, as a browser, never as Googlebot.

cf-cache-status came back four HIT and four DYNAMIC

Eight of the 27 homepages sent cf-cache-status on 2026-09-01, and the eight split down the middle. Four said HIT. Four said DYNAMIC.

The even split matters because the two values are not a scoreboard. DYNAMIC means no rule marked this response cacheable, so it went to the origin by design. A homepage that is personalised, or whose HTML is cheap to regenerate, will report DYNAMIC every time it is asked and nothing about it is broken. Treating that word as a miss to be fixed is the most common mistake this header invites.

A cache status header tells you which layer answered this request. It does not tell you the page is fast, and it does not tell you the page is stale.

Nine sites send x-cache, and no two spell it alike

The other four names carry the same idea with no shared vocabulary. x-cache is the most widespread of them and the least standardised — six different value formats across nine sites.

Those four header rows add up to 23 sightings across 20 homepages, because three sites expose two layers in one response. www.notion.com returns cf-cache-status: DYNAMIC together with x-vercel-cache: MISS and age: 0. www.wired.com returns the same DYNAMIC together with x-cache: Hit from cloudfront. linear.app pairs its DYNAMIC with x-nextjs-cache: HIT. On the last two the pair disagrees: the front layer says it did not cache, the layer behind it says it served a hit, and both statements are true about their own layer.

www.figma.com shows the stack from the other side — x-cache: Miss from cloudfront arriving alongside an x-nf-request-id, which is CloudFront sitting in front of Netlify. And one homepage falls outside both groups. www.netlify.com sends age: 15668 with no status name at all, so you can see the copy has been held somewhere for hours without being told where.

The server header is the weaker way to ask the same thing: cloudflare on 7 of the 27, Vercel on 4, nginx on 3, no server at all on 4, and nine one-offs — Google Frontend, github.com, railway-hikari, Apache, BBC-GTM, Framer, Netlify, envoy, ATS. Knowing who fronts a site is not knowing what that front did with your request.

Thirteen homepages do not say how old the copy is

Fourteen of the 27 sent an age header on 2026-09-01. The other 13 did not, and their responses therefore contain no answer to a plain question: how long has this copy been sitting in a cache before it reached me?

The largest reading is 70,780 seconds on webflow.com, roughly 19.7 hours, and the second is 38,955 seconds on www.wikipedia.org, roughly 10.8 hours. Read those for exactly what they are. An age is how long this particular copy sat in a cache before arriving in Osaka; it is not a statement about how often the site publishes, and it does not imply the content changed or failed to change in that window. The two low readings, www.notion.com at 0 and www.cloudflare.com at 1, say just as little in the other direction.

The 13 with no age are the interesting half. On those sites, a HIT tells you a cache answered and stops there — the same header would look identical whether the stored copy was minted a second ago or last week.

Googlebot keeps a cache of its own

Google's JavaScript SEO basics documentation, read 2026-09-01, is direct about this: "Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers. This may lead WRS to use outdated JavaScript or CSS resources."

Put that next to the 20 homepages above. A status value describes what an edge node did for one request from one browser. What Google's renderer used is a separate decision taken inside Google, at a separate moment — the same page notes that a headless Chromium renders the page "once Google's resources allow". The status you can observe and the copy that actually got rendered are two different facts, and only one of them is visible to you.

What this means for your site

Three checks. The first is a single request.

1. Read your own headers: curl -sI https://yourdomain/ | grep -iE 'cf-cache-status|x-cache|x-vercel-cache|^age:'. If nothing comes back, you are in the group of six, and every caching question about your site has to be answered somewhere other than the response.
2. Run the same command again thirty seconds later. MISS then HIT means the rule works and the first request found a cold node; MISS twice means the rule never matches. One reading on its own is worth very little, which is why this run of 27 homepages is a snapshot and not a ranking.
3. Decide whether your HTML is meant to be cached at all. If it is not, DYNAMIC is the right answer and the work moves to your origin's response time, measured in time to first byte on 26 homepages, and to the validators that let a crawler skip a re-download, measured in the cache control header on 27 homepages.

One more thing about the layer that answers you. The edge serving your HTML is usually the same edge deciding whether an AI crawler gets a response at all, and both rules live in one control panel — the pattern behind a CDN blocking AI crawlers. Change either one and the page still has to be re-fetched before the change counts, which is the part QueryWin covers when you are pushing the change for indexing.

What this run cannot tell you

Whether any of these 27 sites would report the same status to Googlebot. We requested with a desktop Chrome user agent, never with a crawler user agent, and we never fetched the same page twice to compare a cold node against a warm one — so for these sites we don't know whether the caching rules treat automated traffic the same way. One request, one exit in Osaka, one morning: that is the entire basis of every number above, and it is the largest limitation in this piece. A HIT here could be a MISS a minute later on a node that had just been purged, and the reverse is equally likely.

Common questions

How did you measure this?

One GET per homepage on 2026-09-01 from an exit node in Osaka, Japan, with a desktop Chrome user agent, redirects followed and no JavaScript executed, reading cf-cache-status, x-vercel-cache, x-cache, x-cache-status, x-nextjs-cache, age and server off the final response. 30 sites requested, 27 included.

What does cf-cache-status DYNAMIC mean?

The response was not eligible for the cache under the rules in force, so the request went through to the origin. Four of the eight sites carrying this header on 2026-09-01 reported that value, linear.app and www.notion.com among them, and on a personalised homepage it is the intended outcome rather than a fault.

Is a cache HIT good for SEO?

A HIT tells you an edge answered instead of your origin. That is a fact about one request, not a property of the page, and this run measured nothing about ranking, so we would not read a ranking claim into it. What a crawler experiences is the content it receives and how long it waits.

What does the age response header mean?

How many seconds the copy you received had been held in a cache. Fourteen of the 27 homepages sent one on 2026-09-01, the largest being 70,780 seconds on webflow.com. It is a fact about that copy, and it says nothing about how often the site changes.

Does Googlebot see the same cache status I see?

Unknown from this run, because we never sent a crawler user agent. Google's JavaScript SEO documentation, read 2026-09-01, does say that "WRS may ignore caching headers", so the renderer's idea of freshness and the header on your response are separate things.