Hi James,
Saw your follow-up about the banner showing across all pages now once the cache cleared — glad that one turned out to be a CDN propagation lag and not a real bug. No need to apologise: the fact that it took over an hour for your Stackcache to roll over is actually a useful data point for the second issue too (more on that below).
In the meantime I didn’t want to leave you waiting, so while you do your own investigation I went and looked at the live site from the outside to make sure my mental model of what is happening matches what your server is doing in practice. Here is what I found, kept short and concrete.
First, the good news: the cookie policy literal-JSON bug is gone. The /cookie-policy/ page rendered through 1.16.1 no longer contains the {“en”:”…”} fragments you spotted on the previous release. The fix landed exactly where I expected. The cookie inventory layout is still the flat definition-list from 1.16.0/1.16.1 on your install, but that is improving in 1.16.2 (which is already on ww.wp.xz.cn and propagating): the inventory becomes a collapsible accordion with a real table per category instead of the long flat list, and the footer disclaimer becomes admin-configurable (toggle plus optional custom text) instead of being hardcoded. So when your install picks up 1.16.2, that policy page will tighten up considerably without any action on your side beyond an update.
Now the cache miss. I confirmed it is happening on every page I tested, not just the home: the home, /cookie-policy/ and /shop/ all return identical headers. The relevant ones are:
cache-control: no-store, no-cache, must-revalidate, max-age=0
x-litespeed-cache-control: no-cache
x-stackcache-cacheable: nope
x-cdn-cache-status: MISS
So Stackcache is correctly honouring what the origin is telling it; the origin is the one deciding the page is uncacheable. That decision comes from a single function inside the plugin (send_geo_cache_headers), which fires Cache-Control no-store the moment it decides the rendered output is country-dependent. There are four conditions that can flip that switch, in this order of likelihood:
- IAB TCF v2.3 is enabled in Settings. I can rule this one out — your home page does not contain the _fazTcfConfig object, which means TCF is off on your install.
- Geo-routing is on with the default behaviour set to “do not show banner outside target regions” (Settings, Geo-routing, fallback). When that is the setting, the cached HTML of an EU visitor would silently show no banner to an outside-EU visitor (or vice versa), so the plugin marks the output uncacheable.
- Multi-banner geo-routing is configured (more than one banner, with at least one carrying a target-countries list). Here the plugin needs to serve a different banner per country, so once again it cannot let the CDN freeze one version of the page.
- A custom filter, faz_use_country_language_fallback, is turned on by the theme or another plugin. Very unlikely on a standard install.
For your stack the no-cache header is being driven by one of (2) or (3). Both are legitimate uses of the geo logic, but in your case (a UK ecommerce site targeting mostly UK and EU buyers) you may have set them up only as a safety net rather than because you genuinely want a different banner per country. If that is the case there is a clean fix to push on my side and I’d like to ship it as 1.16.3 within a few days. Two practical paths:
Path A — the minimal one. If you are running a single banner (no per-country variants) and you simply turned on geo-routing to gate the banner for EU/UK only, I add a settings flag so the plugin emits Vary: X-Country-Code plus a permissive Cache-Control header instead of the blanket no-store. Stackcache (and LiteSpeed) can then cache one HTML per country code — typically two or three variants in your case — which keeps the page near-instant for the dominant traffic segment while preserving the regulatory accuracy. Net effect: HIT for the vast majority of visitors instead of MISS for everyone.
Path B — the heavier one. If you are running multiple banners with target_countries, same idea but the Vary header logic needs to enumerate the country codes that actually have distinct banners, otherwise the CDN ends up caching 250 micro-variants of the same page. This is the same fix but a touch more careful.
To pick the right path I need a few details from you when you’ve finished your own investigation — no rush, this is patch-release work, not emergency. Roughly:
- In Settings, Geo-routing: is “Geo-routing” itself enabled, and if yes what is “default behaviour” set to (show banner, hide banner, fallback to most-protective)?
- In Cookie Banner, do you have one banner or more than one? If more than one, do any of them have a target-countries list configured?
- Are you fine with the page being cached per-country (so EU visitors share one cached variant, UK another, US another) rather than not cached at all? In most ecommerce stacks the answer is yes — it preserves performance while keeping the per-jurisdiction banner accurate.
- And one extra now that I’ve seen Stackcache react to a purge with that hour-long propagation lag: do you know whether Stackcache currently keys its cache by country (via CF-IPCountry or an equivalent header), or strictly by URL? Their support people will know — it decides whether the Vary trick can work as-is or whether they need to add a small cache key rule on their end alongside the plugin change.
If the answer to question 2 is “one banner, no target_countries”, the change becomes a one-liner on my side: I can probably ship it in a follow-up patch within a couple of days. I won’t push it speculatively because making the page cacheable for sites that DO rely on per-country banners would silently break their compliance posture, which is the worse failure mode.
A side note while I am here: the home page contains a “countryCode”:”GB” string a few times — that is WooCommerce’s own checkout state (“default country is GB”), not the plugin. Unrelated. The plugin’s own geo state isn’t exposed in the public HTML, which is the correct security posture.
