# Cloudflare îți pune singur analytics pe site, din oficiu

> Din 15 octombrie 2025 Cloudflare injectează implicit Web Analytics pe domeniile gratuite. Cum îl verifici cu adevărat și trei feluri de a-l opri.

Source: https://cittago.com/ro/blog/cloudflare-web-analytics-automatica-2026/  
Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011  
Published: 2026-08-18  
Language: ro

---

Din 15 octombrie 2025, Cloudflare pornește implicit propriul Web Analytics pe toate domeniile din planul gratuit. Dacă site-ul trece prin serverele lui, un script apare în paginile tale fără să-l fi pus tu. E fără cookie-uri, dar e opt-out — și pornește înaintea bannerului de consimțământ. Iată cum verifici într-un minut și cum îl oprești.

**Răspunsul scurt.** Dacă domeniul tău e pe un plan Cloudflare gratuit și traficul trece prin serverele lui (norișorul «portocaliu»), din 15 octombrie 2025 Cloudflare injectează implicit un script de analiză — static.cloudflareinsights.com/beacon.min.js, în jur de 31 KB — în pagini care înainte nu aveau niciunul. Îl adaugă la margine, înainte ca pagina să ajungă în browser. Fără cookie-uri, iar după Cloudflare fără date personale, vizitatorii din UE excluși din oficiu. Dar nu te-a întrebat.

**Cine poate închide pagina.** Dacă ai pornit tu monitorizarea de performanță și te folosești de datele alea, e în regulă: las-o așa, n-ai nimic de reparat. Problema e pentru cine nu știe ce încarcă propriul site.

**De ce ar citi restul mai departe.** Pentru că scriptul pornește *înaintea* bannerului de cookie-uri, nu trece prin tag manager și, pe un site pe care îl țineai curat, e prima linie de JavaScript pe care n-ai scris-o tu. Și e o capcană în capcană: verificarea evidentă — să cauți scriptul în codul-sursă — poate răspunde «curat» în timp ce beacon-ul se încarcă oricum. S-a întâmplat pe site-ul nostru. Îți arătăm verificarea care chiar îl prinde.

- Comanda de o linie care îți spune dacă e pe site-ul tău.
- Cum ajunge Cloudflare să pună un script într-un fișier pe care nu-l atinge pe serverul tău.
- Ce s-a schimbat pe 15 octombrie 2025 și cele trei feluri de a-l opri.
- De ce căutarea scriptului în codul-sursă nu ajunge — și verificarea care îl prinde de fiecare dată.

În pagină

1. [Ce este, și ce nu este](#ce)
2. [Cum ajunge scriptul în pagină](#cum)
3. [Cum îl verifici, și ce am găsit noi](#verific)
4. [Fără cookie-uri nu înseamnă invizibil](#consimt)
5. [Cum îl oprești, în trei feluri](#oprire)
6. [Ce nu spune articolul acesta](#nu)
7. [Unde te afli, în trei praguri](#praguri)
8. [Întrebări pe care nu ni le-a pus nimeni](#faq)

Ai un site. Poate e o singură pagină, scrisă de mână, fără niciun script de urmărire în tot codul. Într-o după-amiază muți nameserverele la Cloudflare — îți trebuia să servești un bucket de pe subdomeniul tău — și câteva ore mai târziu descoperi că în HTML-ul tău e acum un script de analiză pe care nu l-ai pus. Nu l-ai descărcat, nu l-ai lipit, n-ai bifat nimic. A apărut.

Nu e un caz rar. E comportamentul implicit, decis de Cloudflare și anunțat cu luni înainte. Pe 17 septembrie 2025, Cloudflare a publicat pe blog articolul «The RUM Diaries: enabling Web Analytics by default», unde scrie negru pe alb: *«The journey starts on October 15, 2025, when Cloudflare will enable Web Analytics for all free domains by default»*. Din ziua aceea, orice domeniu gratuit cu traficul trecut prin proxy primește scriptul — dacă nu te duci tu să-l oprești.

Povestea a revenit pe 16 august 2026, când un fir de discuție pe Hacker News — peste 600 de voturi într-o zi — a readus-o în prim-plan: un dezvoltator mutase nameserverele ca să folosească stocarea R2 și s-a trezit cu scriptul pe un site care n-avea deloc JavaScript. Formularea lui, tradusă: găsesc abordarea asta invazivă, la funcții de genul ăsta ar trebui să te înscrii, nu să te dezabonezi. Exact distincția care contează.

*Scriptul nu-l scrii tu. Apare între HTML-ul tău și browserul celui care citește, într-un loc pe care editorul tău nu-l arată.*

Definiția

## Ce este, și ce nu este

**Cloudflare Web Analytics e un instrument de monitorizare a experienței reale (RUM): înregistrează cât de repede se deschid paginile tale pentru cei care le vizitează cu adevărat, fără cookie-uri și — spune Cloudflare — fără să adune date personale sau să urmărească oamenii în timp.** Nu e Google Analytics: nu numără conversii, nu construiește un profil, nu-ți spune din ce campanie a venit un client. Măsoară Core Web Vitals și cam atât.

Pe partea de confidențialitate, Cloudflare e clară, și merită spus: în articolul oficial scrie că nu folosește *«client-side state (like cookies or localStorage) for analytics purposes»* și că nu urmărește utilizatorii *«over time by IP address, User Agent, or any other fingerprinting»*. Versiunea pornită din oficiu, în plus, *«excludes data from EU visitors»* — vizitatorii europeni sunt excluși, dacă nu alegi altfel. Deci nu vorbim despre o scurgere de date. Vorbim despre altceva: un script adăugat în paginile tale fără acordul tău.

Mecanismul

## Cum ajunge scriptul în pagina ta

Partea care surprinde e tehnică, și e aceeași care face Cloudflare comod. Când un record e trecut prin proxy — norișorul portocaliu — certificatul TLS pe care browserul îl verifică e al Cloudflare, nu al tău. Traficul se «termină» pe serverele lui, care deschid o a doua conexiune spre al tău. La mijloc, Cloudflare vede pagina în clar și o poate rescrie din mers, înainte s-o predea vizitatorului.

Acolo bagă beacon-ul. Nu atinge fișierul de pe serverul tău: modifică doar copia care iese de la margine. Scriptul injectat arată cam așa:

Două consecințe practice. Prima: dacă te uiți în fișierul de pe hostingul tău, nu-l găsești, pentru că nu e acolo — e injectat după. A doua: există o ieșire documentată. Dacă servești pagina cu antetul Cache-Control: public, no-transform, Cloudflare nu poate rescrie conținutul și beacon-ul nu se injectează. E singura condiție tehnică ce-l oprește singură, fără să treci prin panou.

Verificarea

## Cum îl verifici într-un minut

Sunt două verificări, iar diferența dintre ele e miezul poveștii. Prima e rapidă, dar te poate păcăli; a doua nu greșește.

Din terminal, o singură linie:

Dacă răspunde un număr mai mare decât zero, beacon-ul e scris în codul-sursă: sigur e acolo. Dar dacă răspunde 0 încă n-ai terminat — și aici e capcana. Cloudflare poate injecta beacon-ul *la runtime*, doar pentru browserele reale, după un test JavaScript. În cazul ăla, codul-sursă pe care îl vede curl rămâne curat, dar browserul descarcă beacon-ul oricum. Verificarea care nu greșește e din browser: deschide uneltele pentru dezvoltatori, fila *Network*, reîncarcă și filtrează după cloudflareinsights. Dacă apare o cerere către beacon.min.js, e activ — chiar dacă sursa părea curată. Iar un ad blocker precum Brave sau DuckDuckGo îl blochează deja pentru o parte dintre vizitatori, lucru pe care Cloudflare însăși îl documentează.

- **Îți trebuie:** domeniul tău, un terminal (sau uneltele pentru dezvoltatori din browser) și treizeci de secunde.
- **Unde te uiți:** codul-sursă al paginii principale și al unei pagini interne — injectarea e per pagină, nu per site.
- **Ce cauți:** șirul cloudflareinsights sau fișierul beacon.min.js.

### Pe site-ul nostru: curl zicea zero, browserul nu

cittago.com trece prin Cloudflare — antetul server: cloudflare și identificatorul cf-ray o confirmă la fiecare cerere. Cu curl, șase pagini — acasă, indexul blogului, pagina de serviciu Cloudflare în engleză și în italiană, home-ul italian și cel românesc — dădeau toate același rezultat: **zero**, niciun beacon în codul-sursă. Apoi am deschis home-ul într-un browser real, cu Lighthouse: apărea o cerere către static.cloudflareinsights.com/beacon.min.js. Nu era în sursă pentru că Cloudflare îl injectează la runtime, doar pentru browserele verificate. Web Analytics era activ pe site-ul nostru — iar verificarea pe care am fi recomandat-o prima, curl, era exact cea care ni-l ascundea. Scriptul, descărcat direct, cântărește **31.612 octeți**, în jur de 31 KB.

Treizeci și unu de kilobytes nu scufundă un site. Dar pe o pagină pe care o coborâseși sub 100 KB ca să zboare, e o treime din greutate adăugată pentru o funcție pe care n-ai cerut-o — și fiecare script în plus e muncă pe firul principal, exact lucrul pe care scorul mobil îl măsoară cel mai mult. Dacă un panou pe care nu l-ai deschis niciodată poate adăuga o linie în paginile tale, merită să știi ce face restul: e chiar munca unei [configurări Cloudflare făcute pe mână](https://cittago.com/ro/services/cloudflare/), unde fiecare setare o decizi tu, nu valoarea implicită. Pe același subiect, am explicat [ce este de fapt Cloudflare](https://cittago.com/ro/blog/cloudflare-cdn-firewall-2026/) pentru cine pornește de la zero și am măsurat [ce boți lăsa firewallul să treacă și pe care îi bloca](https://cittago.com/ro/blog/ai-crawlers-blocked-firewall-2026/) pe domeniul nostru.

Consimțământul

## Fără cookie-uri nu înseamnă invizibil

Aici e nevoie de onestitate în două direcții. Pe de o parte, Cloudflare are dreptate să spună că analiza lui e altceva decât un pixel de reclamă: fără cookie-uri, fără profilare, vizitatorii din UE excluși din oficiu. Pe de altă parte, beacon-ul pornește la margine, **înainte** ca bannerul tău de consimțământ sau tag managerul tău să fi apucat să ruleze. Nu trece prin uneltele tale, deci nu-l controlezi cu ele.

Consecința nu e «ești în afara legii»: ar fi o frază prea comodă, și nu e ce spune Cloudflare despre propria măsurătoare. Consecința e mai simplă și mai enervantă: ai o piesă în mozaicul site-ului tău pe care n-ai pus-o tu și care nu apare în registrul tău de scripturi. Pentru cine ține o evidență serioasă a ce rulează pe paginile lui, «nu l-am pus eu și nu-l controlez eu» e deja un răspuns insuficient. Nu pentru că ar fi ilegal, ci pentru că nu mai e site-ul tău cel care decide.

*Între tine și cel care te vizitează e un strat pe care îl poți configura, dar nu-l vezi. Acolo se adaugă o linie — sau se scoate.*

Soluția

## Cum îl oprești, în trei feluri

Niciunul din cele trei nu cere să pleci de la Cloudflare. În ordine, de la cel mai direct la cel mai tehnic:

1. **Din panou.** Intri în *Web Analytics*, deschizi *Manage RUM Settings* (Gestionează setările RUM) și alegi *Disable*. E metoda pe care Cloudflare însăși o indică în articolul de anunț. E valabilă pentru toată zona, adică pentru tot domeniul.
2. **Cu antetul de cache.** Dacă servești paginile cu Cache-Control: public, no-transform, Cloudflare nu rescrie conținutul și beacon-ul nu se injectează. Util dacă vrei să împiedici din principiu orice modificare din mers, nu doar analiza.
3. **Instalare manuală.** Dacă vrei totuși datele de performanță, dar în condițiile tale, poți opri injectarea automată și lipești tu fragmentul unde decizi — așa îl gestionezi ca pe orice alt tag, după consimțământ.

Orice alegi, fă-o știind că ai făcut-o. Diferența dintre un site îngrijit și unul lăsat pe valorile implicite nu e aproape niciodată o greșeală gravă: e o sumă de lucruri mici pornite din oficiu pe care nimeni nu le-a oprit.

Limitele

## Ce nu spune articolul acesta

- **Nu e o acuzație de încălcare a GDPR.** Cloudflare își descrie analiza ca fiind fără cookie-uri și fără date personale, cu vizitatorii din UE excluși din oficiu. Tema e consimțământul la gest — un script adăugat fără să te întrebe — nu o prelucrare ilegală de date.
- **Nu privește orice site.** Schimbă doar domeniile din planul gratuit cu traficul trecut prin proxy. Planurile plătite rămân manuale, iar cine servește cu no-transform nu e atins.
- **N-am măsurat tot webul.** Cifrele noastre sunt pentru cittago.com, șase pagini, 18 august 2026. Situația ta o spune doar site-ul tău, cu comanda de mai sus.
- **Nu spunem să pleci de la Cloudflare.** Îl folosim, îl configurăm pentru clienți și îi recomandăm folosirea. Critica e la o valoare implicită, nu la unealtă.

Unde te afli

## Trei praguri, nu o concluzie

Fă verificarea de un minut și așază-te:

- **Domeniu Cloudflare gratuit, setări neatinse** → aproape sigur beacon-ul e activ. Verifică-l diseară; sunt treizeci de secunde.
- **Ai un banner de cookie-uri și te simțeai acoperit** → beacon-ul pornește înaintea bannerului. Verifică ce încarcă pagina cu adevărat, nu ce promite bannerul.
- **Ai pornit tu RUM-ul și datele îți sunt de folos** → las-o. N-ai nimic de reparat: e singura jumătate a poveștii în care valoarea implicită coincide cu alegerea ta.

## Întrebări pe care nu ni le-a pus nimeni

Ultima actualizare: 18 august 2026. Data de 15 octombrie 2025 și citatele provin din articolul Cloudflare «The RUM Diaries: enabling Web Analytics by default» (17 septembrie 2025), recitit la această dată. Măsurătorile despre cittago.com sunt din 18 august 2026: cu curl, 6 pagini dădeau zero, dar Lighthouse într-un browser real arăta o cerere către static.cloudflareinsights.com/beacon.min.js (fișierul are 31.612 octeți). Cloudflare injectează beacon-ul la runtime pentru browserele verificate, deci nu apare în codul-sursă. Cârligul de actualitate e firul de pe Hacker News din 16 august 2026. Actualizăm pagina dacă Cloudflare schimbă comportamentul implicit.

## Întrebări și răspunsuri

**Cum aflu dacă e activ pe site-ul meu?**

Două verificări, nu una. Cea rapidă: curl -s https://site-ul-tau.ro/ | grep -c cloudflareinsights — dacă dă mai mult de zero, beacon-ul e în codul-sursă. Dar dacă dă 0 încă nu ești în siguranță: Cloudflare îl poate injecta la runtime, doar pentru browserele reale, și atunci curl nu-l vede. Verificarea care nu greșește e din browser: uneltele pentru dezvoltatori, fila Network, reîncarcă și caută beacon.min.js. Dacă apare cererea, e activ chiar dacă sursa părea curată.

**Cloudflare adună datele vizitatorilor mei pe la spatele meu?**

Adună metrici de performanță, nu date personale: Cloudflare declară că nu folosește cookie-uri sau localStorage și că nu urmărește utilizatorii după IP, User Agent sau alt fingerprinting, iar din oficiu exclude vizitatorii din UE. Ideea articolului nu e o colectare ascunsă de date, ci faptul că scriptul e adăugat în paginile tale fără să te întrebe.

**De când se întâmplă?**

Din 15 octombrie 2025. Cloudflare a anunțat pe 17 septembrie 2025, în articolul «The RUM Diaries», că va porni Web Analytics din oficiu pe toate domeniile gratuite din acea dată. Planurile plătite nu s-au schimbat: acolo pornirea rămâne o alegere manuală.

**Cum îl opresc fără să plec de la Cloudflare?**

Din panou: Web Analytics → Manage RUM Settings → Disable. E valabil pentru tot domeniul. Sau servești paginile cu antetul Cache-Control: public, no-transform, care împiedică Cloudflare să rescrie conținutul și, deci, să injecteze beacon-ul.

**Cât cântărește scriptul?**

L-am descărcat pe 18 august 2026: 31.612 octeți, în jur de 31 KB. Nu scufundă un site, dar pe o pagină pe care o țineai ușoară e greutate adăugată pentru o funcție pe care n-ai cerut-o, iar fiecare script ocupă firul principal, adică lucrul pe care scorul de viteză pe mobil îl penalizează cel mai tare.

**Nu-l blochează oricum ad blockerele?**

În parte, da: Cloudflare documentează că beacon-ul e blocat de Brave, de extensia DuckDuckGo și de altele. Ceea ce înseamnă două lucruri: pentru o parte dintre vizitatorii tăi datele nu ajung oricum, și nu te poți baza pe blocarea altcuiva ca să decizi ce rulează pe paginile tale. Alegerea rămâne a ta.

**L-ați găsit pe site-ul Cittago?**

Da, și ne-a surprins chiar în timp ce scriam. Cu curl, șase pagini de pe cittago.com dădeau zero: niciun beacon în codul-sursă. Apoi Lighthouse, într-un browser real, a arătat o cerere către static.cloudflareinsights.com/beacon.min.js pe home. Cloudflare îl injectează la runtime, pentru browserele verificate, deci sursa rămâne curată. E cel mai bun exemplu pe care-l puteam da: verificarea evidentă ne spunea nu, realitatea spunea da.

**Dacă îl las pornit, ce date primesc?**

Core Web Vitals reale de la vizitatorii tăi — cât de repede devine pagina utilizabilă, cât de mult «sare» în timpul încărcării — fără conversii și fără profiluri. Sunt date oneste și utile, dacă le vrei. Întrebarea nu e dacă e bun, ci dacă ai ales tu să-l ai.

**Mutarea nameserverelor pornește și altceva din oficiu?**

În cazul care a reaprins discuția, utilizatorul a observat că și proxy-ul era pornit din oficiu, nu doar analiza. Regula practică e aceeași: după ce muți un domeniu la Cloudflare, deschide setările și uită-te ce e pornit, în loc să presupui că totul e oprit până îl pornești tu.

**Site-ul meu e pe un plan plătit — sunt afectat?**

Schimbarea de pornire din oficiu e pentru domeniile din planul gratuit. Pe Pro, Business și Enterprise, Web Analytics rămâne manual. Merită totuși să rulezi verificarea de o linie, pentru că o setare pornită demult, sau pe altă zonă, te poate surprinde — comanda nu costă nimic și răspunde sigur.

---

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.