Si definisce traffico bot qualsiasi richiesta al proprio sito effettuata da un software anziché da una persona davanti a uno schermo. Questa sola definizione comprende cose diverse tra loro come Googlebot che indicizza la pagina di un prodotto, un servizio di monitoraggio che interroga la home page ogni sessanta secondi, uno scraper che si porta via i prezzi e uno script di credential stuffing che lavora su un elenco di password trafugate. L'errore sta nel metterle tutte insieme. Questa guida serve a distinguerle, perché la risposta giusta a ciascuna è completamente diversa.
In sintesi
- Il traffico bot non è un fenomeno unico. Si divide in automazione utile, automazione ostile e traffico sintetico generato da noi stessi, e ciascun tipo tende ad avere un referente diverso all'interno di un'organizzazione.
- Google Analytics 4 esclude automaticamente il traffico proveniente da bot e spider noti utilizzando la IAB/MRC International Spiders and Bots List. Quel filtro esiste davvero, ma lavora su un elenco di bot noti, cioè esattamente lo strumento sbagliato per intercettare un'automazione che cerca di non farsi conoscere.
- Le stringhe User-Agent e il file
robots.txtsono dichiarazioni, non controlli. Entrambi funzionano bene con i bot ben educati e non significano nulla per tutti gli altri. - L'identità va verificata a livello di rete (DNS inverso o intervalli di IP pubblicati), non ricavata da un'intestazione che qualsiasi client può impostare.
- Nel momento in cui l'automazione prende di mira accessi, checkout, moduli o prezzi, ha smesso di essere un fastidio per i report ed è diventata una questione di sicurezza, con un percorso di escalation diverso.
Che cosa conta davvero come traffico bot?
Il confine utile è l'intento di chi lo gestisce, non la tecnologia. Un browser headless non è di per sé malevolo; la propria suite di QA probabilmente ne usa uno. Tre domande risolvono quasi tutti i casi: chi lo sta facendo girare, che cosa preleva o compie, e si è presentato? Un crawler che si identifica e rispetta le direttive di scansione è un ospite con tanto di biglietto da visita. Un insieme di IP residenziali che scorre gli URL dei prodotti a tre richieste al secondo dietro uno User-Agent Chrome di serie è un'altra cosa, anche se tecnicamente entrambi si limitano a scaricare pagine.
Le tre categorie da tenere separate
Automazione utile
Questi bot esistono perché essere visibili o osservabili porta un vantaggio. I crawler dei motori di ricerca come Googlebot e Bingbot costruiscono l'indice da cui dipende il proprio traffico organico. I servizi di monitoraggio scaricano le pagine a intervalli regolari, così un'interruzione si scopre prima che se ne accorgano i clienti. I crawler dei comparatori di prezzo e dei circuiti di affiliazione possono far parte di un canale di distribuzione che si desidera attivamente. I fetcher delle anteprime dei link generano la scheda che si vede quando un URL viene condiviso in una chat.
Una presenza più recente in questo gruppo è il crawler per l'intelligenza artificiale. OpenAI documenta GPTBot, Anthropic documenta ClaudeBot e Common Crawl gestisce da tempo CCBot. Ciascuno pubblica una documentazione che descrive l'agente e come consentirlo o vietarlo. Se accoglierli o meno è una decisione commerciale su come vengono usati i propri contenuti, non una questione di difesa tecnica. Va notato che bloccarli è una scelta autentica con un costo su entrambi i fronti, cosa che non vale per la categoria successiva.
Automazione ostile
Qui il guadagno di chi la gestisce è una perdita per il sito. Gli scraper di contenuti e prezzi copiano il catalogo, spesso a una frequenza di richieste che costa capacità di server reale. Gli script di credential stuffing riprovano coppie di nome utente e password provenienti da violazioni estranee sull'endpoint di accesso, ed è per questo che un'impennata di accessi falliti da molti IP merita attenzione nel giro di ore e non al ciclo di reportistica successivo. La frode sui clic consuma budget pubblicitario su clic che nessun essere umano ha compiuto. Lo spam nei moduli e nei commenti inquina il CRM e, cosa peggiore, i dati di conversione. I bot che accaparrano scorte mettono nel carrello merce a disponibilità limitata che non hanno alcuna intenzione di acquistare.
Il comportamento che definisce questa categoria è l'evasione. Questo traffico ruota gli indirizzi IP, imita le impronte dei browser più diffusi, si dosa al di sotto delle soglie evidenti e ignora tutto ciò che si scrive in robots.txt, perché rispettarlo ridurrebbe soltanto ciò che raccoglie.
Traffico di test sintetico
La terza categoria è l'automazione che si è commissionata: test di carico, verifiche dell'analytics, controlli di raggiungibilità configurati da noi, sessioni allestite per confermare che un evento di conversione si attivi con i parametri giusti. Non è ostile, ma non è nemmeno umana, e distorcerà qualunque report che la comprenda. La caratteristica distintiva è che se ne ha il controllo, il che significa che la si può taggare, pianificare ed escludere in modo pulito. Farlo davvero oppure no è la differenza tra un esperimento reversibile e una proprietà di analytics confusa per sempre.
| Categoria | Si identifica? | Rispetta robots.txt? | Chi dovrebbe occuparsene |
|---|---|---|---|
| Crawler di ricerca e di IA | Sì, e in modo verificabile | In genere sì | SEO / strategia dei contenuti |
| Fetcher di monitoraggio e anteprime | Di solito | Spesso esentati per progettazione | Sviluppo / operations |
| Scraper e credential stuffing | No | No | Sicurezza |
| Frode sui clic e spam nei moduli | No | Non applicabile | Media a pagamento / sicurezza |
| Il proprio traffico sintetico | Solo se lo si tagga | Sotto il proprio controllo | Referente dell'analytics |
Che cosa filtra GA4 automaticamente e che cosa gli sfugge
Google Analytics 4 esclude per impostazione predefinita il traffico proveniente da bot e spider noti. La documentazione di Google descrive questo meccanismo come basato sulla IAB/MRC International Spiders and Bots List combinata con l'identificazione interna di Google, e viene applicato automaticamente, non come un'impostazione da attivare. Per il caso più comune, cioè crawler dichiarati che visitano una pagina dotata del proprio codice di misurazione, funziona bene e silenziosamente.
Il limite discende direttamente dal meccanismo. Un filtro basato su un elenco intercetta l'automazione che compare in quell'elenco. Non è progettato per riconoscere un software che si presenta come una normale sessione Chrome da un indirizzo IP residenziale, e non ci si deve aspettare che lo faccia. Vale la pena nominare tre lacune pratiche:
- Automazione non dichiarata. Tutto ciò che imita deliberatamente un browser verrà in genere misurato come una sessione, con dispositivo, area geografica e referrer plausibili.
- Traffico che non esegue mai il proprio JavaScript. Molti bot scaricano l'HTML e si fermano lì. GA4 non li vede affatto, quindi l'analytics sottostima il carico complessivo. È la modalità di errore opposta a quella precedente, ed è il motivo per cui il solo analytics non può dire quanta automazione stia gestendo il server.
- Le proprie sessioni sintetiche. Nulla, nel filtro automatico, sa che il test di carico commissionato non era un cliente. Quell'esclusione va costruita da sé.
La lezione generale: il filtro antibot di GA4 è una funzione di igiene dei report, non un sistema di rilevamento. Va considerato come qualcosa che rimuove il rumore evidente, non come una risposta alla domanda «quanta parte di questo traffico era umana?».
Come distinguerli nei log del server
I log del server registrano ogni richiesta arrivata, comprese quelle che non hanno mai eseguito una riga di JavaScript. Questo li rende la traccia più completa e il luogo in cui la classificazione avviene davvero.
I segnali che pesano, all'incirca in ordine di affidabilità:
- Identità verificata. Google pubblica una procedura di verifica per i propri crawler: una ricerca DNS inversa sull'IP che effettua la richiesta, poi una ricerca diretta sul nome host ottenuto per confermare che riporti allo stesso indirizzo. Google pubblica inoltre gli intervalli di IP dei suoi crawler in formato JSON, e OpenAI pubblica gli intervalli di GPTBot. Bing offre uno strumento di verifica analogo. È l'unica classe di segnali che un client non può semplicemente dichiarare.
- Schema delle richieste. Intervalli perfettamente regolari, enumerazione sequenziale degli URL e richieste di HTML senza i corrispondenti caricamenti di CSS, immagini o font indicano tutti un client che non è un browser.
- Concentrazione sugli endpoint. Un traffico intenso verso
/login, verso un endpoint di ricerca o verso un template che espone prezzi, con scarso interesse per il resto, descrive uno scopo. - Origine di rete. Lo spazio di indirizzi dei datacenter è normale per i crawler dichiarati e insolito per le visite dei consumatori. Il traffico da proxy residenziali ribalta questa logica, ed è uno dei motivi per cui la sola origine non è conclusiva.
- Stringa User-Agent. Utile per raggruppare, priva di valore come prova. Non è un caso che venga per ultima.
Un ulteriore punto specifico della classificazione: il gruppo di client che compare nel proprio log di accesso ma mai nell'analytics è, quasi per definizione, automazione non basata su browser. Quel gruppo è invisibile a chiunque lavori solo sull'analytics.
Perché robots.txt e User-Agent sono segnali deboli
robots.txt è una richiesta di cooperazione volontaria. Il Robots Exclusion Protocol è stato formalizzato come RFC 9309 nel 2022, e lo standard stesso descrive il rispetto delle regole come volontario da parte del crawler. I principali motori di ricerca lo onorano; uno scraper non ha alcun motivo di farlo. C'è poi un'ulteriore trappola: pubblicare una regola Disallow per un percorso sensibile lo segnala a chiunque legga il file, che per definizione è pubblico. Va usato per gestire il comportamento di scansione e il crawl budget, mai come controllo degli accessi.
L'intestazione User-Agent ha la stessa debolezza strutturale. È una stringa scelta dal client. Chiunque può inviare Googlebot in quel campo, e chiunque può inviare al suo posto una stringa Chrome aggiornata. È proprio per questo che esiste il passaggio di verifica descritto sopra. In pratica lo User-Agent va trattato come un'etichetta per organizzare traffico già classificato con altri mezzi.
Quanta parte del web è automatizzata?
Risposta onesta: nessuno può fornire una cifra da citare con sicurezza. Le stime pubblicate provengono soprattutto da fornitori di sicurezza, in modo particolarmente visibile dal Bad Bot Report annuale di Imperva e da telemetrie analoghe di altri operatori. Sono utili come indicazione di tendenza, ma derivano dal traffico che passa attraverso la base clienti di ciascun fornitore, il che sbilancia il campione verso siti abbastanza grandi da poter acquistare soluzioni di mitigazione dei bot e verso le superfici di attacco che quei siti presentano. Fornitori diversi, metodologie diverse, numeri diversi.
Sul piano qualitativo si può affermare senza rischi che la quota automatizzata è abbastanza grande da contare su praticamente qualsiasi sito pubblico, e che varia enormemente a seconda del tipo di sito. Un servizio di massa incentrato sugli accessi, una piattaforma di biglietteria e un sito statico di documentazione non affrontano affatto lo stesso mix. Il numero che deve guidare le decisioni è quello ricavato dai propri log, non una media di settore.
Quando il traffico bot diventa un problema di sicurezza
La linea di confine è comportamentale, non quantitativa. Il traffico bot è un problema di analytics finché si limita a gonfiare i conteggi. Diventa un problema di sicurezza nel momento in cui interagisce con qualcosa che ha conseguenze.
Conviene fare escalation anziché filtrare quando si osserva una di queste situazioni: un aumento dei tentativi di accesso falliti distribuiti su molti indirizzi di origine, invii di moduli che generano eventi di conversione senza alcuna attività plausibile a valle, azioni di checkout o di carrello che non si concludono mai, enumerazione sistematica di ID utente o numeri d'ordine, oppure un volume di richieste che provoca una reale pressione sulla capacità. Ognuna di queste ha un costo che continua a maturare indipendentemente dall'esclusione del traffico da una dashboard.
La conseguenza pratica di sbagliare questo confine è che una campagna di credential stuffing viene trattata come una seccatura per i report, esclusa da una vista GA4 e lasciata attiva contro l'endpoint di accesso. Il filtro ha reso invisibile il sintomo senza toccare la causa.
Domande frequenti
Tutto il traffico bot è dannoso?
No, e trattarlo come tale provoca danni concreti. Bloccare i crawler dei motori di ricerca significa sparire dall'indice. Bloccare i fetcher delle anteprime rovina l'aspetto dei propri URL quando vengono condivisi. L'obiettivo è la classificazione e una risposta adeguata, non l'eliminazione.
GA4 rimuove tutto il traffico bot?
Rimuove automaticamente il traffico dei bot e degli spider noti presenti nell'elenco IAB/MRC. Non rimuove l'automazione che si presenta come un browser qualunque, e non vede mai i client che non eseguono il proprio codice di misurazione. Sono due punti ciechi diversi, orientati in direzioni opposte.
Posso riconoscere Googlebot dalla sola stringa User-Agent?
No. La documentazione di Google raccomanda esplicitamente di verificare con una ricerca DNS inversa seguita da una ricerca diretta, oppure confrontando con gli intervalli di IP dei crawler pubblicati da Google. Lo User-Agent è banalmente falsificabile e non dovrebbe mai essere la base per concedere un accesso.
Devo bloccare i crawler di IA come GPTBot o ClaudeBot?
È una decisione di licenza dei contenuti più che di sicurezza. Entrambi sono documentati ed entrambi possono essere vietati in robots.txt. Va soppesato il valore di comparire nelle risposte generate dall'IA rispetto alla propria posizione su come i propri contenuti vengono usati per l'addestramento. Non esiste una risposta tecnicamente corretta, solo una risposta commerciale.
Qual è la prima cosa da controllare di fronte a un'impennata di traffico inspiegata?
I log del server, non l'analytics. Bisogna guardare quali endpoint sono stati colpiti, a quale intervallo, da quali reti e se le richieste abbiano scaricato anche le risorse della pagina oppure solo l'HTML. Quelle quattro osservazioni di solito individuano la categoria in pochi minuti, e la categoria determina chi debba occuparsene.