A hand-built, deliberately tracking-free website picked up a JavaScript analytics beacon it never asked for, the moment its owner pointed the domain's nameservers at Cloudflare. No install step. No checkbox. No email saying "we turned this on for you." The owner found it by accident, scrolling the dashboard for something else, and had to add the site to Cloudflare's Analytics product just to reach the setting that would turn it back off.

That's not a misconfiguration. It's the default.

Cloudflare Says So Itself

Cloudflare's own documentation confirms it. When a domain is proxied through Cloudflare (what they call "orange-clouded," meaning traffic routes through their edge before hitting your server), automatic setup for Web Analytics injects the beacon script into every page under that zone, with no manual embed required. Per Cloudflare's own FAQ documentation, the only thing that blocks the script is a Cache-Control: public, no-transform header, which stops Cloudflare's proxy from touching your HTML at all. Skip that header, and if you're routing through Cloudflare, you're very likely already serving the beacon.

The rollout has a date attached to it. Cloudflare's post on the change, "The RUM Diaries: enabling Web Analytics by default," says free-tier domains started seeing Web Analytics switched on automatically as of October 15, 2025, joining paid plans that already had it. Set up a Cloudflare-proxied site any time in the last ten months, and there's a real chance analytics has been running the whole time without a moment where anyone said yes.

The Tracking Itself Is Actually Fine

This isn't a shady tracker. Cloudflare Web Analytics is cookieless, so it skips the kind of persistent identifier that GDPR and most state privacy laws treat as requiring a consent banner. You can exclude EU visitor data from the dashboard entirely. The data reports back to your own domain's /cdn-cgi/rum endpoint instead of a third-party pixel. Set next to Google Analytics and its cookie-based session tracking, this is a lighter, more privacy-conscious build.

"Designed responsibly" and "turned on without asking" are two different claims, and only one of them is true here.

Most people running a website through an agency, a freelancer, or their own two hands are not reading Cloudflare's changelog. They picked Cloudflare for DNS, the free SSL certificate, the DDoS protection, or because someone told them to. Nobody sat down and decided "yes, I want a beacon collecting page-load data from every visitor." Cloudflare made that call for them. Reversibly, but for them. If your privacy policy promises consent-based analytics, or promises no third-party analytics at all, it's worth checking that promise against what's actually loading in your <head>.

The Pattern Underneath This

Vendors change behavior without a memo, and your name is the one on the privacy policy. A CDN, a form tool, a chat widget, a payment processor: any one of them can ship an update that changes what leaves your site, and the release notes live on their blog, not yours. We wrote about a related version of this with what your CRM actually owns versus what it just displays. The infrastructure running your site isn't a thing you configure once and forget. It keeps moving on someone else's schedule.

How To Check In Two Minutes

Open the Cloudflare dashboard for the site in question. Go to Analytics, then look for the Web Analytics tab. If it's showing traffic, it's collecting. From there, you have three real options: leave it running (it's a genuinely useful, lightweight replacement for heavier tools if you want the data), restrict it to exclude EU visitors, or switch it off entirely from Manage Site. None of those three are wrong. Not knowing which one you're currently getting is the only wrong answer.

If a developer or agency manages a Cloudflare-proxied site for you, ask them directly: is Web Analytics on, and was that a decision or a default? Most won't know off the top of their head either, and that's the actual problem. A vendor flipping a switch quietly is normal. Nobody on your side noticing for ten months is the part worth fixing.

At Pixelworx, this kind of vendor-behavior check is part of ongoing maintenance and support, not a one-time setup task, because the tools underneath a site keep shipping changes on their own timeline, long after launch day. It also sits squarely inside third-party integrations work: knowing what every connected service actually does with visitor data today, not just what it was supposed to do the day it got turned on.

Cloudflare documented the change, built an off switch, and kept the tracking about as clean as tracking gets. Nothing here is a scandal. The lesson outlasts this one vendor: the infrastructure under your site is not static, and the two-minute check for what's actually running today is worth repeating more than once.