# Cloudflare adds its own analytics to your site by default > Since 15 October 2025 Cloudflare injects its Web Analytics by default on free domains. How to really check, and three ways to turn it off. Source: https://cittago.com/blog/cloudflare-web-analytics-automatica-2026/ Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011 Published: 2026-08-18 Language: en --- One line: curl -s https://yoursite.com/ | grep -c cloudflareinsights. If it returns anything but zero, Cloudflare has injected a tracking script you never wrote — the default on every free-plan domain since 15 October 2025. It is cookieless, but it is opt-out, and it loads before your consent banner. Here is how it gets there and how to switch it off. **The short answer.** If your domain is on a free Cloudflare plan and its traffic is proxied (the «orange cloud»), Cloudflare has, since 15 October 2025, injected a performance-analytics script by default — static.cloudflareinsights.com/beacon.min.js, about 31 KB — into pages that previously carried none. It rewrites the page at the edge, before it reaches the browser. No cookies, and per Cloudflare no personal data; EU visitors excluded by default. But it never asked you. **Who can close the tab.** If you turned the performance monitoring on yourself and you use that data, nothing here is a problem — leave it. This is about people who don't know what their own site loads. **Why the rest should read on.** Because the script runs *before* your cookie banner, never passes through your tag manager, and on a site you'd kept clean it is the first line of JavaScript you didn't write. There is a trap inside the trap: the obvious check — searching the page source for the script — can say «clean» while the beacon loads anyway. That happened on our own site. Below is the check that actually catches it. - The exact one-line command that tells you whether it is on your site. - How Cloudflare gets a script into a file it never touches on your server. - What changed on 15 October 2025, and the three ways to turn it off. - Why searching the page source is not enough — and the check that catches the beacon every time. On this page 1. [What it is, and what it is not](#what) 2. [How the script gets into your page](#inject) 3. [What changed on 15 October 2025](#when) 4. [Cookieless is not the same as invisible](#consent) 5. [How to switch it off, three ways](#off) 6. [What this article does not claim](#not) 7. [Where you stand, in three thresholds](#thresholds) 8. [Questions nobody has actually asked us](#faq) Start with the fast check, because it takes ten seconds. Open a terminal and run curl -s https://yoursite.com/ | grep -c cloudflareinsights. Anything above zero means Cloudflare has written its analytics beacon into your page source — a script you did not add. But zero is not the all-clear it looks like, and that is the trap this article is really about. We ran it on our own domain first, so we would not be writing about someone else's site. cittago.com is behind Cloudflare — the server: cloudflare header and the cf-ray ID say so on every request. Across six pages — home, the blog index, the Cloudflare service page in English and Italian, and the Italian and Romanian homepages — curl came back **zero every time**: no beacon in the source. Then we opened the home page in a real browser, with Lighthouse, and there it was — a request to static.cloudflareinsights.com/beacon.min.js. It was not in the source because Cloudflare injects it at runtime, for verified browsers only. Web Analytics was active on our own site all along — and the check we would have recommended first, curl, was exactly the one hiding it. Pulled directly, the script weighs 31,612 bytes, about 31 KB. This is not an obscure edge case. It is the default, decided by Cloudflare and announced months ahead. On 17 September 2025 Cloudflare published «The RUM Diaries: enabling Web Analytics by default», which states plainly: *«The journey starts on October 15, 2025, when Cloudflare will enable Web Analytics for all free domains by default»*. The story resurfaced on 16 August 2026 through a Hacker News thread — over 600 votes in a day — from a developer who had switched nameservers to use R2 storage and found the beacon on a site with no JavaScript of its own. *You don't write this script. It appears between your HTML and the reader's browser, at a layer your editor never shows you.* The definition ## What it is, and what it is not **Cloudflare Web Analytics is a Real User Monitoring (RUM) tool: it records how fast your pages load for actual visitors, without cookies and — Cloudflare says — without collecting personal data or tracking people over time.** It is not Google Analytics. It counts no conversions, builds no profile, and cannot tell you which campaign a customer came from. It measures Core Web Vitals and little else. On privacy Cloudflare is blunt, and fairly so: the official post says it uses no *«client-side state (like cookies or localStorage) for analytics purposes»* and does not track users *«over time by IP address, User Agent, or any other fingerprinting»*. The default version also *«excludes data from EU visitors»*. So this is not a data leak. It is something narrower and stranger: a script added to your pages without your yes. The mechanism ## How the script gets into your page The part that surprises people is the same thing that makes Cloudflare convenient. When a record is proxied — the orange cloud — the TLS certificate the browser validates is Cloudflare's, not yours. Traffic terminates on its servers, which open a second connection to yours. In the middle, Cloudflare sees the page in the clear and can rewrite it on the way out, before it reaches the visitor. That is where the beacon goes in. It never touches the file on your server; it edits the copy leaving the edge. The injected script looks close to this: Two practical consequences. First, if you look at the file on your hosting you won't find it — it isn't there; it is injected afterwards. Second, there is a documented way out: if you serve the page with Cache-Control: public, no-transform, Cloudflare cannot rewrite the payload and the beacon is not injected. That header is the one technical condition that stops it on its own, without opening any dashboard. - **You need:** your domain, a terminal (or the browser dev tools), and thirty seconds. - **Where to look:** the source of your home page and one inner page — injection is per page, not per site. - **What to search for:** the string cloudflareinsights or the file beacon.min.js. The Network tab in dev tools, filtered to cloudflareinsights, is the check that matters: it shows the request even when the page source is clean, because Cloudflare can inject the beacon at runtime for real browsers only. The date ## What changed on 15 October 2025 Until that date Web Analytics existed, but you switched it on: opt-in. From 15 October 2025 the direction reversed. Here is the difference, line by line. The consent question ## Cookieless is not the same as invisible This needs honesty in two directions. On one side, Cloudflare is right that its analytics differs from an ad pixel: no cookies, no profiling, EU visitors excluded by default. On the other, the beacon fires at the edge, **before** your consent banner or tag manager has had a chance to run. It doesn't pass through your tools, so you don't govern it with them. The consequence isn't «you're breaking the law» — that would be a convenient line, and it isn't what Cloudflare says of its own measurement. The consequence is simpler and more irritating: there is a tile in your site's mosaic that you didn't lay and that doesn't appear in your own register of scripts. For anyone who keeps a serious inventory of what runs on their pages, «I didn't add it and I don't control it» is already an unsatisfying answer — not because it is illegal, but because your site no longer decides. *Between you and your visitor sits a layer you can configure but not see. That is where a line gets added — or removed.* The fix ## How to switch it off, three ways None of the three means leaving Cloudflare. In order, from most direct to most technical: 1. **From the dashboard.** Go to *Web Analytics*, open *Manage RUM Settings*, and choose *Disable*. This is the method Cloudflare itself points to in the announcement. It applies to the whole zone — your entire domain. 2. **With a cache header.** Serve your pages with Cache-Control: public, no-transform and Cloudflare cannot rewrite the payload, so the beacon is never injected. Useful if you want to block any on-the-fly change on principle, not just analytics. 3. **Manual install.** If you do want the performance data, but on your terms, disable automatic injection and paste the snippet yourself — then it behaves like any other tag, loading after consent. Whatever you choose, choose it knowingly. If a panel you never opened can add a line to your pages, it is worth knowing what the rest of the configuration does — which is exactly the work of a [hand-configured Cloudflare setup](https://cittago.com/services/cloudflare/), where every setting is one you decided rather than a default. For the ground floor, we've explained [what Cloudflare actually is](https://cittago.com/blog/cloudflare-cdn-firewall-2026/), and measured [which bots our firewall let through and which it blocked](https://cittago.com/blog/ai-crawlers-blocked-firewall-2026/) on our own domain. The limits ## What this article does not claim - **It is not a GDPR-breach accusation.** Cloudflare describes its analytics as cookieless and free of personal data, with EU visitors excluded by default. The issue is consent to the act — a script added without asking — not unlawful data processing. - **It does not affect every site.** It changes only free-plan domains with proxied traffic. Paid plans stay manual, and anyone serving with no-transform is untouched. - **We did not measure the whole web.** Our figures are cittago.com, six pages, 18 August 2026. Only your own site tells you your answer — with the command above. - **We are not telling you to leave Cloudflare.** We use it, configure it for clients, and recommend it. The criticism is of a default, not of the tool. Where you stand ## Three thresholds, not a conclusion Run the ten-second check and place yourself: - **Free Cloudflare domain, settings never touched** → the beacon is almost certainly on. Check it tonight; it's thirty seconds. - **You have a cookie banner and felt covered** → the beacon fires before the banner. Verify what the page actually loads, not what the banner promises. - **You enabled RUM yourself and use the data** → leave it. Nothing to fix: this is the one half of the story where the default matches your choice. ## Questions nobody has actually asked us Last updated: 18 August 2026. The 15 October 2025 date and the quotations come from Cloudflare's post «The RUM Diaries: enabling Web Analytics by default» (17 September 2025), re-read on this date. The cittago.com measurements are from 18 August 2026: curl returned zero on 6 pages, but Lighthouse in a real browser showed a request to static.cloudflareinsights.com/beacon.min.js (the file is 31,612 bytes). Cloudflare injects the beacon at runtime for verified browsers, so it does not appear in the page source. The news hook is the Hacker News thread of 16 August 2026. We update this page if Cloudflare changes the default behaviour. | | Before 15 October 2025 | From 15 October 2025 | | --- | --- | --- | | Free (proxied) domains | analytics off until you enabled it | analytics **on by default** | | Who decides | you, by opting in | Cloudflare, until you opt out | | Script in the page | none, unless you added it | beacon injected at the edge | | EU visitors | — | excluded by default | | Pro / Business / Enterprise | manual | manual (no change) | ## Questions and answers **How do I tell whether it is on my site?** Two checks, not one. The fast one: curl -s https://yoursite.com/ | grep -c cloudflareinsights — anything above zero means the beacon is in your source. But zero is not the all-clear: Cloudflare can inject it at runtime, for real browsers only, and then curl never sees it. The check that does not miss is the browser: dev tools, Network tab, reload, and search for beacon.min.js. If the request appears, it is active even when the source looked clean. **Is Cloudflare collecting my visitors' data behind my back?** It collects performance metrics, not personal data: Cloudflare states it uses no cookies or localStorage and does not track users by IP, User Agent or any fingerprinting, and it excludes EU visitors by default. The point of this article is not covert data collection — it is that the script is added to your pages without asking. **Since when has this happened?** Since 15 October 2025. Cloudflare announced it on 17 September 2025 in the post «The RUM Diaries», saying it would enable Web Analytics by default on all free domains from that date. Paid plans did not change: there, enabling it stays a manual choice. **How do I turn it off without leaving Cloudflare?** In the dashboard: Web Analytics → Manage RUM Settings → Disable. It applies to the whole domain. Alternatively, serve your pages with the header Cache-Control: public, no-transform, which prevents Cloudflare from rewriting the payload and therefore from injecting the beacon. **How much does the script weigh?** We downloaded it on 18 August 2026: 31,612 bytes, about 31 KB. It won't sink a site, but on a page you'd kept light it is added weight for a feature you didn't ask for, and every script occupies the main thread — the thing the mobile speed score penalises most. **Won't ad blockers block it anyway?** Partly: Cloudflare documents that the beacon is blocked by Brave, the DuckDuckGo extension and others. That means two things — for a slice of your visitors the data never arrives anyway, and you can't rely on someone else's blocker to decide what runs on your pages. The choice stays yours. **Did you find it on Cittago's own site?** Yes — and it surprised us while we were writing this. With curl, six pages of cittago.com returned zero: no beacon in the source. Then Lighthouse, in a real browser, showed a request to static.cloudflareinsights.com/beacon.min.js on the home page. Cloudflare injects it at runtime, for verified browsers, so the source stays clean. It is the best example we could give: the obvious check told us no, reality said yes. **If I leave it on, what do I actually get?** Real Core Web Vitals from your visitors — how quickly the page becomes usable, how much it shifts while loading — with no conversions and no profiles. It is honest, useful data if you want it. The question isn't whether it is good; it is whether you chose to have it. **Does switching nameservers turn on anything else by default?** In the case that reignited the discussion, the user noticed the proxy itself was on by default too, not just analytics. The practical rule is the same: after moving a domain to Cloudflare, open the settings and look at what is on, instead of assuming everything is off until you switch it on. **My site is on a paid plan — am I affected?** The default-on change is for free-plan domains. On Pro, Business and Enterprise, Web Analytics stays manual. Still worth running the one-line check, because a setting enabled long ago, or on another zone, can surprise you — the command costs nothing and answers it for certain. --- Cittago · https://cittago.com · digital marketing, SEO, AI search, Google Ads and web development for small and medium companies in Romania, Italy and the EU.