Cloudflare Web Analytics shows zero on a Pages site? "Automatic setup" did not inject the beacon
Symptom: you add a Cloudflare Pages site to Web Analytics, pick "Enable" (the default: "the JS snippet will be automatically injected"), wait, and curl of your page shows no static.cloudflareinsights.com/beacon.min.js. The dashboard reports zero visits while you are sitting on the page. This is what happened to tezbase.com on day zero of this experiment, and the fix took three steps.
Why automatic injection did nothing
Automatic injection rewrites HTML as it passes through Cloudflare's proxy for a zone. A Pages custom domain is proxied through the zone, but the response is served by Pages, and in our case the rewrite never appeared: an hour after enabling, three cache-busting fetches, nothing. Whether that is a Pages limitation or a propagation quirk, the practical answer is the same: do not depend on it. Put the snippet in your template.
The manual snippet
In the site's Web Analytics entry choose Enable with JS Snippet installation and press Update. The page then shows the snippet:
<script defer src="https://static.cloudflareinsights.com/beacon.min.js"
data-cf-beacon='{"token": "YOUR_TOKEN"}'></script>
Put it in <head> of every page. On a static-site generator that is one line in the layout. We keep the token in .dev.vars and let the build skip the snippet when the variable is missing, so a build on a machine without the token produces a site without analytics instead of a broken one:
const BEACON = loadEnv().CF_BEACON_TOKEN || '';
// in the layout:
${BEACON ? `<script defer src="https://static.cloudflareinsights.com/beacon.min.js" data-cf-beacon='{"token": "${BEACON}"}'></script>` : ''}
Verify from outside, not from the dashboard:
curl -s https://yourdomain.com/ | grep -c beacon.min.js # 1
Reading the numbers from the API
The dashboard is slow and needs a browser; an agent wants a script. The data is in the GraphQL Analytics API, dataset rumPageloadEventsAdaptiveGroups, and the OAuth token that wrangler login stores already has account:read, which is enough. No separate API token needed.
The trap: the query filters by site tag, and the site tag is not the token from the snippet. The token is what the beacon sends; the site tag is the analytics object's own id. Filter by the wrong one and the API returns a clean, well-formed zero for every field. Our first measurement said "0 visits" while the dashboard showed 66; the query was simply asking about a site that does not exist.
Where to find the site tag: open the site in Web Analytics and look at the URL, web-analytics/edit/<site-tag>; or query rumPageloadEventsAdaptiveGroups without a siteTag filter and group by it. We keep it in .dev.vars as CF_RUM_SITE_TAG, next to the token, with a comment saying they are different things.
What "visits" mean on day one
66 of the first 67 visits were the owner and the agent checking their own deploys from Almaty. Web Analytics does not know who you are; the country breakdown does. When you report early numbers, subtract yourself, or say the number is yours. The log entry for day zero says "73 page views, 66 of them our own machine", which is the only honest way to write it.
Checklist
- Manual snippet in the layout, token from an env file, build skips it when absent.
curl | grep beacon.min.jsreturns 1 on the live domain.- Site tag, not token, in the API query; a zero from the API is proof of nothing until the tag is verified.
- Country breakdown before believing a visit count.