# Cloudflare attiva la sua analisi da sola: come te ne accorgi

> Dal 15 ottobre 2025 Cloudflare inietta la sua Web Analytics di default sui domini gratuiti. Come vederla davvero e tre modi per spegnerla.

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

---

Dal 15 ottobre 2025 Cloudflare accende la propria Web Analytics su tutti i domini del piano gratuito. Se il sito passa dai suoi server, uno script compare nelle tue pagine senza che tu l'abbia messo. È senza cookie, ma è opt-out — e parte prima del tuo banner di consenso. Ecco come verificarlo in un minuto e come spegnerlo.

**La risposta corta.** Se il tuo dominio è su un piano Cloudflare gratuito e passa dai suoi server (record «arancione»), dal 15 ottobre 2025 Cloudflare inietta di default uno script di analisi — static.cloudflareinsights.com/beacon.min.js, circa 31 KB — in pagine che prima non ne avevano nessuno. Lo fa al bordo, prima che la pagina arrivi al browser. Nessun cookie, per Cloudflare nessun dato personale, visitatori UE esclusi di default. Ma non te l'ha chiesto.

**Chi può chiudere la pagina.** Se hai attivato tu il monitoraggio delle prestazioni e quel dato ti serve, va tutto bene: lascialo così, non c'è nulla da sistemare. Il problema riguarda chi non sa cosa carica il proprio sito.

**Perché gli altri dovrebbero continuare.** Perché lo script parte *prima* del tuo banner cookie, non passa dal tuo tag manager, e su un sito che avevi tenuto pulito è la prima riga di JavaScript che non hai scritto tu. E c'è una trappola dentro la trappola: il controllo ovvio — cercare lo script nel codice sorgente — può rispondere «pulito» mentre il beacon si carica lo stesso. È successo sul nostro sito. Ti mostriamo il controllo che invece lo trova.

- Cosa fa davvero la Web Analytics di Cloudflare — dalla documentazione, non dal passaparola.
- La data esatta in cui è diventata predefinita, e cosa cambia rispetto a prima.
- Il comando di una riga per sapere se è sul tuo sito, e i tre modi per spegnerla.
- Perché cercare lo script nel codice sorgente non basta — e il controllo che invece lo trova ogni volta.

In questa pagina

1. [Cosa fa (e cosa no)](#cosa)
2. [Cosa è cambiato il 15 ottobre 2025](#quando)
3. [Come finisce lo script nella pagina](#come)
4. [Controllarlo, e cosa abbiamo trovato](#verifica)
5. [E il consenso? Senza cookie non vuol dire invisibile](#consenso)
6. [Come spegnerla, in tre modi](#spegnere)
7. [Cosa questo articolo non dice](#nonfa)
8. [Dove ti trovi, in tre soglie](#soglie)
9. [Domande che nessuno ci ha ancora fatto](#faq)

Hai un sito. Magari è una pagina sola, scritta a mano, senza uno script di tracciamento in tutto il codice. Un pomeriggio sposti i nameserver su Cloudflare — ti serviva servire un bucket dal tuo sottodominio — e qualche ora dopo scopri che nel tuo HTML, adesso, c'è uno script di analisi che tu non hai messo. Non l'hai scaricato, non l'hai incollato, non hai spuntato nulla. È comparso.

Non è un caso limite. È il comportamento predefinito, deciso da Cloudflare e annunciato con mesi di anticipo. Il 17 settembre 2025 Cloudflare ha pubblicato sul proprio blog il pezzo «The RUM Diaries: enabling Web Analytics by default», in cui scrive nero su bianco: *«The journey starts on October 15, 2025, when Cloudflare will enable Web Analytics for all free domains by default»*. Da quel giorno, ogni dominio gratuito con il traffico proxato riceve lo script — a meno che tu non vada a spegnerlo a mano.

La notizia è tornata a galla il 16 agosto 2026, quando un thread su Hacker News — oltre 600 voti in un giorno — l'ha rimessa in prima pagina: uno sviluppatore aveva spostato i nameserver per usare l'archiviazione R2 e si era ritrovato lo script su un sito che di JavaScript non ne aveva. La sua frase, tradotta: trovo questo approccio invasivo, a funzioni così ci si dovrebbe iscrivere, non doversene cancellare. È esattamente la distinzione che conta.

La definizione

## Cosa fa (e cosa no) Cloudflare Web Analytics

**La Web Analytics di Cloudflare è un sistema di misurazione delle prestazioni «lato utente» (RUM, Real User Monitoring): registra quanto velocemente le tue pagine si aprono per chi le visita davvero, senza usare cookie e — dichiara Cloudflare — senza raccogliere dati personali né seguire le persone nel tempo.** Non è Google Analytics: non conta le conversioni, non costruisce un profilo, non ti dice da quale campagna arriva un cliente. Misura Core Web Vitals e poco altro.

Sulla privacy Cloudflare è netta, e va dato atto: nel post ufficiale scrive di non usare *«any client-side state (like cookies or localStorage) for analytics purposes»* e di non tracciare gli utenti *«over time by IP address, User Agent, or any other fingerprinting»*. La versione attivata di default, inoltre, *«excludes data from EU visitors»* — i visitatori europei sono esclusi salvo tua diversa scelta. Quindi non stiamo parlando di una fuga di dati. Stiamo parlando di una cosa diversa: uno script aggiunto alle tue pagine senza il tuo sì.

*Lo script non lo scrivi tu. Compare tra il tuo HTML e il browser di chi legge, in un punto che il tuo editor non vede.*

La data

## Cosa è cambiato il 15 ottobre 2025

Fino a quella data la Web Analytics esisteva, ma la accendevi tu: opt-in. Dal 15 ottobre 2025 il verso si è invertito. Ecco la differenza, riga per riga.

Il meccanismo

## Come finisce lo script nella tua pagina

La parte che spiazza è tecnica, ed è la stessa che rende Cloudflare comodo. Quando un record è proxato — la nuvoletta arancione — il certificato TLS che il browser verifica è di Cloudflare, non tuo. Il traffico si «apre» sui suoi server, che aprono una seconda connessione verso il tuo. In mezzo, Cloudflare vede la pagina in chiaro e può riscriverla al volo prima di consegnarla al visitatore.

È lì che aggiunge il beacon. Non tocca il file sul tuo server: modifica la copia che esce dal bordo. Lo script iniettato ha più o meno questa forma:

Due conseguenze pratiche. La prima: se guardi il file sul tuo hosting non lo trovi, perché non è lì — è iniettato dopo. La seconda: esiste una via d'uscita documentata. Se servi la pagina con l'intestazione Cache-Control: public, no-transform, Cloudflare non può riscrivere il contenuto e il beacon non viene iniettato. È l'unica condizione tecnica che lo ferma da sola, senza passare dal pannello.

La verifica

## Come controllarlo in un minuto

Ci sono due controlli, e la differenza tra loro è il cuore di questa storia. Il primo è veloce ma può ingannare; il secondo non sbaglia.

Da terminale, una riga:

Se risponde un numero maggiore di zero, il beacon è scritto nel codice sorgente: c'è di sicuro. Ma se risponde 0 non hai ancora finito — e qui sta la trappola. Cloudflare può iniettare il beacon *a runtime*, solo per i browser veri, dopo un controllo JavaScript. In quel caso il codice sorgente che vede curl resta pulito, mentre il browser scarica il beacon lo stesso. Il controllo che non sbaglia è quello dal browser: apri gli strumenti per sviluppatori, scheda *Rete*, ricarica la pagina e filtra per cloudflareinsights. Se compare una richiesta a beacon.min.js, è attivo — anche se il sorgente sembrava pulito. E un ad blocker come Brave o DuckDuckGo lo blocca già per una parte dei tuoi visitatori, cosa che Cloudflare stessa documenta.

- **Ti serve:** il tuo dominio, un terminale (o gli strumenti per sviluppatori del browser) e trenta secondi.
- **Dove guardare:** il codice sorgente della home e di una pagina interna — l'iniezione è per pagina, non per sito.
- **Cosa cercare:** la stringa cloudflareinsights o il file beacon.min.js.

### Sul nostro sito: curl diceva zero, il browser no

cittago.com passa da Cloudflare — l'intestazione server: cloudflare e l'ID cf-ray lo confermano a ogni richiesta. Con curl, sei pagine — home, indice del blog, la pagina servizio Cloudflare in inglese e in italiano, la home italiana e quella rumena — davano tutte lo stesso risultato: **zero**, nessun beacon nel codice sorgente. Poi abbiamo aperto la home in un browser vero, con Lighthouse: compariva una richiesta a static.cloudflareinsights.com/beacon.min.js. Non era nel sorgente perché Cloudflare lo inietta a runtime, per i browser verificati. La Web Analytics era attiva sul nostro sito — e il controllo che avremmo consigliato per primo, curl, era proprio quello che ce la nascondeva. Lo script, scaricato direttamente, pesa **31.612 byte**, circa 31 KB.

Trentuno kilobyte non affondano un sito. Ma su una pagina che avevi portato sotto i 100 KB per farla volare, è un terzo del peso aggiunto per una funzione che non hai chiesto — e ogni script in più è lavoro sul thread principale, la cosa che il punteggio mobile misura di più. Se un pannello che non hai mai aperto può aggiungere una riga alle tue pagine, vale la pena sapere cosa fa il resto: è esattamente il lavoro di una [configurazione Cloudflare fatta a mano](https://cittago.com/it/services/cloudflare/), dove ogni impostazione la decidi tu e non l'impostazione predefinita. Sullo stesso tema, abbiamo spiegato [cos'è davvero Cloudflare](https://cittago.com/it/blog/cloudflare-cdn-firewall-2026/) per chi parte da zero, e misurato [quali bot il firewall lasciava passare e quali no](https://cittago.com/it/blog/ai-crawlers-blocked-firewall-2026/) sul nostro dominio.

Il consenso

## E il consenso? Senza cookie non vuol dire invisibile

Qui serve onestà in due direzioni. Da un lato, Cloudflare ha ragione a dire che la sua analisi è diversa da un pixel pubblicitario: niente cookie, niente profilazione, visitatori UE esclusi di default. Dall'altro, il beacon parte al bordo, **prima** che il tuo banner di consenso o il tuo tag manager abbiano avuto la possibilità di eseguire. Non passa dai tuoi strumenti, quindi non lo governi con essi.

La conseguenza non è «sei fuori legge»: sarebbe una frase troppo comoda, e non è quello che dice Cloudflare della propria misurazione. La conseguenza è più semplice e più fastidiosa: hai una tessera nel mosaico del tuo sito che non hai posato tu e che non compare nel tuo registro degli script. Per chi tiene un inventario serio di cosa gira sulle proprie pagine — e in Italia, con l'attenzione del Garante, sono in tanti — «non l'ho messo io e non lo controllo io» è già una risposta insufficiente. Non perché sia illegale, ma perché non è più il tuo sito che decide.

*Tra te e chi ti visita c'è uno strato che puoi configurare ma non vedere. È lì che una riga si aggiunge, o si toglie.*

La soluzione

## Come spegnerla, in tre modi

Nessuno dei tre richiede di lasciare Cloudflare. In ordine, dal più diretto al più tecnico:

1. **Dal pannello.** Vai in *Web Analytics*, apri *Gestisci impostazioni RUM* (Manage RUM Settings) e scegli *Disattiva*. È il metodo che Cloudflare stessa indica nel post di annuncio. Vale per l'intera zona, cioè per tutto il dominio.
2. **Con l'intestazione di cache.** Se servi le pagine con Cache-Control: public, no-transform, Cloudflare non riscrive il contenuto e il beacon non viene iniettato. Utile se vuoi impedire per principio qualsiasi modifica al volo, non solo l'analisi.
3. **Installazione manuale.** Se il dato di performance lo vuoi, ma alle tue condizioni, puoi disattivare l'iniezione automatica e incollare tu lo snippet dove decidi — così lo gestisci come qualsiasi altro tag, dopo il consenso.

Qualunque scelta tu faccia, falla sapendo che l'hai fatta. La differenza tra un sito curato e uno lasciato ai valori predefiniti non è quasi mai un errore grave: è una somma di piccole cose accese di default che nessuno ha mai spento.

I limiti

## Cosa questo articolo non dice

- **Non è un'accusa di violazione del GDPR.** Cloudflare descrive la sua analisi come priva di cookie e di dati personali, e con i visitatori UE esclusi di default. Il tema è il consenso al gesto — uno script aggiunto senza chiederti — non un trattamento illecito di dati.
- **Non riguarda ogni sito.** Cambia solo i domini del piano gratuito con traffico proxato. I piani a pagamento restano manuali, e chi serve con no-transform non è toccato.
- **Non abbiamo misurato l'intero web.** Le nostre cifre valgono per cittago.com, sei pagine, il 18 agosto 2026. La tua situazione la dice solo il tuo sito, con il comando qui sopra.
- **Non stiamo dicendo di lasciare Cloudflare.** Lo usiamo, lo configuriamo per i clienti e ne consigliamo l'uso. La critica è a un default, non allo strumento.

Dove ti trovi

## Tre soglie, non una conclusione

Fai il controllo di un minuto e collocati:

- **Dominio Cloudflare gratuito, impostazioni mai toccate** → quasi certamente il beacon è attivo. Controllalo stasera; sono trenta secondi.
- **Hai un banner cookie e ti sentivi a posto** → il beacon parte prima del banner. Verifica cosa carica davvero la pagina, non cosa promette il banner.
- **Hai attivato tu il RUM e il dato ti serve** → lascialo. Non c'è nulla da sistemare: questa è l'unica metà della storia in cui il default coincide con la tua scelta.

## Domande che nessuno ci ha ancora fatto

Ultimo aggiornamento: 18 agosto 2026. La data del 15 ottobre 2025 e le citazioni provengono dal post di Cloudflare «The RUM Diaries: enabling Web Analytics by default» (17 settembre 2025), riletto in questa data. Le misure su cittago.com sono del 18 agosto 2026: con curl, 6 pagine davano zero, ma Lighthouse su un browser vero mostrava una richiesta a static.cloudflareinsights.com/beacon.min.js (il file pesa 31.612 byte). Cloudflare inietta il beacon a runtime per i browser verificati, quindi non compare nel codice sorgente. L'aggancio di attualità è il thread di Hacker News del 16 agosto 2026. Aggiorniamo la pagina se Cloudflare cambia il comportamento predefinito.

|   | Prima del 15 ottobre 2025 | Dal 15 ottobre 2025 |
| --- | --- | --- |
| Domini free (proxati) | analisi da attivare a mano | analisi **attiva di default** |
| Chi decide | tu, con un'iscrizione | Cloudflare, con una cancellazione |
| Script nella pagina | nessuno, se non lo mettevi | beacon iniettato al bordo |
| Visitatori UE | — | esclusi di default |
| Piani Pro / Business / Enterprise | manuale | manuale (nessun cambio) |

## Domande e risposte

**Cloudflare raccoglie i dati dei miei visitatori a mia insaputa?**

Raccoglie metriche di prestazione, non dati personali: Cloudflare dichiara di non usare cookie né localStorage e di non tracciare gli utenti per IP, User Agent o altro fingerprinting. E di default esclude i visitatori UE. Il punto dell'articolo non è una raccolta occulta di dati, ma il fatto che lo script venga aggiunto alle tue pagine senza chiedertelo.

**Come faccio a sapere se è attivo sul mio sito?**

Due controlli, non uno. Il veloce: curl -s https://iltuosito.it/ | grep -c cloudflareinsights — se dà più di zero, il beacon è nel codice sorgente. Ma se dà 0 non sei ancora al sicuro: Cloudflare può iniettarlo a runtime, solo per i browser veri, e in quel caso curl non lo vede. Il controllo che non sbaglia è il browser: strumenti per sviluppatori, scheda Rete, ricarica e cerca beacon.min.js. Se compare la richiesta, è attivo anche se il sorgente sembrava pulito.

**Da quando succede?**

Dal 15 ottobre 2025. Cloudflare lo ha annunciato il 17 settembre 2025 nel post «The RUM Diaries», scrivendo che avrebbe attivato la Web Analytics di default su tutti i domini gratuiti a partire da quella data. I piani a pagamento non sono cambiati: lì l'attivazione resta manuale.

**Come la disattivo senza lasciare Cloudflare?**

Nel pannello: Web Analytics → Gestisci impostazioni RUM → Disattiva. Vale per tutto il dominio. In alternativa servi le pagine con l'intestazione Cache-Control: public, no-transform, che impedisce a Cloudflare di riscrivere il contenuto e quindi di iniettare il beacon.

**Quanto pesa lo script?**

Lo abbiamo scaricato il 18 agosto 2026: 31.612 byte, circa 31 KB. Non affonda un sito, ma su una pagina che avevi tenuto leggera è peso aggiunto per una funzione che non hai chiesto, e ogni script occupa il thread principale, cioè la cosa che il punteggio di velocità mobile misura di più.

**Devo preoccuparmi per il consenso e il Garante?**

L'analisi di Cloudflare è senza cookie e, per sua dichiarazione, senza dati personali, con i visitatori UE esclusi di default — quindi non è il caso classico da banner. Il problema pratico è un altro: lo script parte prima del tuo banner e non passa dal tuo tag manager, quindi non lo governi con i tuoi strumenti. Se tieni un inventario di cosa gira sul sito, va messo in conto o spento.

**Gli ad blocker non lo bloccano già da soli?**

In parte sì: Cloudflare documenta che il beacon è bloccato da Brave, dall'estensione di DuckDuckGo e da altri. Il che significa due cose: per una fetta dei tuoi visitatori il dato non arriva comunque, e non puoi contare sul blocco altrui per decidere cosa gira sulle tue pagine. La scelta resta tua.

**L'avete trovato sul sito di Cittago?**

Sì, e ci ha sorpresi proprio mentre scrivevamo. Con curl, sei pagine di cittago.com davano zero: nessun beacon nel codice sorgente. Poi Lighthouse, su un browser vero, ha mostrato una richiesta a static.cloudflareinsights.com/beacon.min.js sulla home. Cloudflare lo inietta a runtime, per i browser verificati, quindi il sorgente resta pulito. È l'esempio migliore che potessimo dare: il controllo ovvio ci diceva di no, la realtà diceva di sì.

**Se lo lascio attivo, che dato ottengo?**

Core Web Vitals reali dai tuoi visitatori — quanto velocemente la pagina diventa utilizzabile, quanto «salta» durante il caricamento — senza conversioni né profili. È un dato onesto e utile, se lo vuoi. La domanda non è se sia buono, ma se hai scelto tu di averlo.

**Cambiare i nameserver attiva anche altro di default?**

Nel caso che ha riacceso la discussione, l'utente ha notato che anche il proxy era attivo per impostazione predefinita, non solo l'analisi. La regola pratica è la stessa: dopo aver spostato un dominio su Cloudflare, apri le impostazioni e guarda cosa è acceso, invece di dare per scontato che sia tutto spento finché non lo accendi tu.

---

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.