Cloudflare Web Analytics: the tag you never added
7 min read
Why a Cloudflare beacon appears on your site when nobody put it there, what it does and does not collect, where the setting lives.
If Tag Explorer has shown you a Cloudflare beacon under DIRECT ON PAGE, and your first thought was that nobody at your business put it there, you are probably right. Cloudflare Web Analytics is frequently injected into the page by Cloudflare itself as the page is served, so it appears on a scan while being absent from your source code and from every tag manager container you own. Paste your page into Tag Explorer to see this tag on your own site.
It is an analytics beacon, not an advertising pixel. It counts visits and measures page performance, it does that without cookies, and it reports into a Cloudflare dashboard rather than into an ad platform. The genuine question it raises is not whether it is harmful. It is who switched it on and whether you want it.
What it actually does
The beacon is a small script, loaded from static.cloudflareinsights.com, that fires once as a page finishes loading and sends a single report back.
What goes in that report is modest: the page that was viewed, the referring site, rough device and browser information, and timing measurements the browser already collected about how fast the page rendered and became usable. That performance half is the part people overlook and it is arguably the more useful half, because it measures real visitors on real connections rather than a synthetic test.
What does not go in it is just as important. No cookie is set. No identifier is stored in the visitor’s browser. There is no profile that follows a person from your site to anyone else’s, and there is no audience that can be exported and advertised to.
The trade off is real and you should know it. Without an identifier, distinguishing a returning visitor from a new one is guesswork, so Cloudflare’s numbers will never match Google Analytics 4 exactly. That is two tools measuring differently, not one of them being wrong.
Why it has no ID in the usual sense
There is no G- code and no advertiser ID here. The beacon carries a token, a long hexadecimal string attached to the script tag, and that token identifies your site inside a Cloudflare account. It identifies nothing about the visitor.
That difference matters when you are staring at a scan result trying to work out what is sensitive. An advertising pixel ID connects your site to an ad account that builds audiences from your visitors. This token connects your site to a traffic dashboard. Nobody can do anything with it except see it in your page source, which is true of every tracking ID on every website.
Why it is there, and did you agree to it
This is the part worth understanding properly, because it is different from every other tag on your scan.
When your domain is proxied through Cloudflare, every page your visitors receive passes through Cloudflare on the way. That gives Cloudflare the opportunity to modify the HTML in flight, and automatic setup for Web Analytics does exactly that: it inserts the beacon into the response. Your files are untouched. Your container is untouched. Nothing in your codebase records that the tag exists.
So the honest answer to “did I agree to this” is that somebody with access to your Cloudflare account did, either by enabling it deliberately or by accepting a default while setting the site up. If that person is your developer, your host or a previous agency, this is a good moment to find out who holds that account, which is a more valuable discovery than the beacon itself.
The control lives in the Cloudflare dashboard on the Web Analytics page. Open Manage site for the site and you can switch the automatic injection off, or move to a manual installation where you place the snippet yourself. For a site hosted on Cloudflare Pages, the same switch sits under the project’s Metrics tab. Cloudflare documents both paths in its Web Analytics setup guide.
Keep it or turn it off
Keep it when you want a free, low weight, independent second opinion on your traffic. It is genuinely useful to have a count that is not produced by the same tool you use for everything else, particularly when ad blocking suppresses a chunk of your other analytics. The real visitor performance data is a bonus that pairs well with the technical side of an SEO review.
Turn it off when the beacon is not being looked at by anyone, when you have no access to the dashboard it reports into, or when your organisation’s policy is that every data collection on the site has to be named and owned. “Nobody reads it” is a sufficient reason on its own. Removing a script nobody uses is always the right call.
On consent: because it sets no cookie and stores no identifier, it is treated differently from advertising tags, but where consent rules apply to your traffic the decision about which tools need disclosure is one for your own legal advice, not for a scanning tool and not for us.
What this looks like in Tag Explorer
Tag Explorer draws your page as a tree. Google Tag Manager containers are branches with their tags as leaves beneath them, and anything present in the page HTML sits under DIRECT ON PAGE.
Cloudflare Web Analytics will essentially always be under DIRECT ON PAGE, never inside a container, because it is placed in the HTML rather than deployed through a tag manager. The card is colour coded as Analytics. The info icon opens a short definition plus the Learn more link that brought you here.
Because the tool reads the page as delivered, it sees the injected beacon exactly as a visitor’s browser does, which is the only reliable way to notice edge injected tags at all. Reading your own source files would never reveal it.
As with every card, a scan proves the beacon is installed, not that it fired. The browser DevTools Network tab confirms the report was actually sent.
What to do if it is missing, duplicated or dead
Missing. Nothing is broken. If you want the data, enable it from the Web Analytics page in the Cloudflare dashboard, which takes one click on a proxied site. If your site is not proxied through Cloudflare, use the manual snippet instead.
Duplicated. Two beacons on one page means the automatic injection is running and somebody has also pasted the manual snippet into the template. Page views double. Pick one: leave the automatic injection on and delete the manual snippet, or switch automatic injection off and keep the snippet you can see in your own code.
Dead or stale. The beacon does not go stale in the way an advertising pixel does, because there is no campaign behind it to end. The nearest equivalent is a token pointing at a Cloudflare account nobody can log into, which makes the data unreadable while the script still loads. In that case, remove it or regain access. There is no value in collecting into a dashboard you cannot open.
Related guides
- Google Analytics 4 explained
- Ahrefs Web Analytics explained
- Microsoft Clarity explained
- Custom HTML tags explained
- GTM containers explained
Run your site through Tag Explorer and see what else is arriving on your pages without passing through anything you control. If the answer is “more than I expected”, or nobody can name the account behind it, that is exactly the kind of loose end our hosting and care work is meant to close, so the list of things loading on your site is a list somebody owns.
Frequently asked questions
Why is Cloudflare Web Analytics on my site when I never added it?
Because for sites proxied through Cloudflare the beacon can be injected automatically into the page as it is served, rather than being added to your code or your tag manager. Somebody with access to the Cloudflare account switched it on, or it came on as part of the default setup. That is why it never appears in your source files and never appears in a container.
Does Cloudflare Web Analytics use cookies?
No. It is built to work without cookies and without storing an identifier in the visitor's browser, which is the whole point of it. That also means it cannot follow a visitor across sessions the way a cookie based analytics tool can, so its returning visitor picture is weaker by design.
Is it a tracking pixel like the advertising ones?
No. It does not build advertising audiences, it does not feed a bidding system, and it has no server side conversions companion. It reports visits and page performance back to the Cloudflare dashboard for the person who owns the account. Treating it as equivalent to an ad pixel will lead you to the wrong decision about it.
Where do I turn it off?
In the Cloudflare dashboard, on the Web Analytics page, open Manage site for the site in question. From there you can switch the automatic injection off or move to a manual installation. For a site hosted on Cloudflare Pages the equivalent control sits under the project's Metrics tab.