Cloudflare îți pune singur analytics pe site, din oficiu
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ă.
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ă.
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:
<script defer src="https://static.cloudflareinsights.com/beacon.min.js"
data-cf-beacon='{"token":"..."}'></script>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:
curl -s https://site-ul-tau.ro/ | grep -c cloudflareinsightsDacă 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
cloudflareinsightssau fișierulbeacon.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.
Lighthouse, browser real → cerere către beacon.min.js · fișier = 31.612 octeți
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ă, unde fiecare setare o decizi tu, nu valoarea implicită. Pe același subiect, am explicat ce este de fapt Cloudflare pentru cine pornește de la zero și am măsurat ce boți lăsa firewallul să treacă și pe care îi bloca 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.
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:
- 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.
- 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. - 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-transformnu 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
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.
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.
