Kinsta ha analizzato oltre 10 miliardi di richieste HTTP sulla propria infrastruttura di hosting e ha scoperto che i bot hanno colpito gli URL “add-to-cart” sui siti WordPress 7,67 milioni di volte in sole 24 ore. Un solo crawler ha generato 550 milioni di richieste in 30 giorni prima che una regola lo bloccasse.
Nessuna di quelle richieste ha portato a una conversione. Nessuna ha reindirizzato un visitatore al sito. Continuavano semplicemente ad arrivare, colpendo pagine del carrello, URL di prodotti filtrati, query di ricerca ed endpoint AJAX, costringendo ogni volta il server a eseguire codice PHP, lanciare una query sul database e gestire una sessione per un traffico che non si sarebbe mai trasformato in un cliente.
I siti che assorbivano questo carico non erano in crash. Le pagine si caricavano. Il checkout funzionava. Secondo ogni parametro convenzionale, sembravano perfettamente funzionanti. È proprio questo il problema di cui parla questo articolo.
Il traffico bot non è più solo rumore di fondo
Nel 2025, i bot rappresentavano il 53% di tutto il traffico web, segnando la prima volta in cui il traffico automatizzato ha superato quello umano in un anno solare. A giugno 2026, Cloudflare Radar ha stimato quella cifra al 57,5%, un punto di svolta che, secondo lo stesso CEO di Cloudflare, è arrivato anni prima delle sue previsioni.
Per chi gestisce siti WordPress, il cambiamento concreto va oltre la semplice percentuale. Il traffico dei bot di oggi non è solo costituito da crawler di ricerca che fanno il loro lavoro. Include crawler per l’addestramento dell’AI, strumenti di scraping, bot per l’audit SEO, monitor di uptime, user agent falsi e strumenti di AI agentica che seguono i link in modo molto più aggressivo di quanto il crawling tradizionale possa mai fare.
Alcuni indicizzano i contenuti. Altri li estraggono. Altri ancora testano gli endpoint. Altri trattano ogni combinazione di parametri URL come una pagina distinta e la scansionano singolarmente.
Quest’ultimo comportamento è particolarmente oneroso per WordPress. Una pagina di prodotto con filtri per colore, taglia, ordinamento, impaginazione e disponibilità di magazzino appare come un’unica pagina a un visitatore umano. Un bot può vedere centinaia di URL unici e eseguire il crawling su ognuno di essi.
Il traffico dei bot basati sull’AI è aumentato del 300% in un anno. Entro la fine del 2025, i bot basati sull’AI rappresentavano 1 visita su 31 sulla rete di TollBit, in aumento rispetto a 1 su 200 all’inizio dell’anno. La tendenza è chiara. Ciò che viene ancora sottovalutato è quanto costa effettivamente quel traffico.
La larghezza di banda è il costo più ovvio
La larghezza di banda è la quantità di dati che il tuo sito trasferisce quando qualcuno richiede una pagina, un’immagine, uno script, un file o altre risorse. I visitatori umani la usano. Anche i bot la usano, ma poi non comprano nulla.
Un crawler che visita un post del blog una sola volta non è un problema. Un bot che scansiona ripetutamente archivi, pagine di tag, immagini, feed, script e URL filtrati può consumare larghezza di banda reale senza generare alcun valore commerciale.
Secondo i dati di Cloudflare del 2025, citati nel report su traffico AI e bot di Kinsta, l’80% dell’attività di scansione dell’AI è destinata all’addestramento dei modelli piuttosto che alla ricerca o a query innescate dagli utenti, e non genera traffico di riferimento verso il sito. Per i siti WordPress ricchi di contenuti, questa dinamica trasforma le pagine di alto valore in risorse ad alto costo.
La cosa insidiosa è che lo spreco di larghezza di banda spesso si accumula senza causare un problema visibile alle prestazioni. Il sito continua a caricarsi. Il server continua a rispondere. Ma l’utilizzo continua a salire perché il traffico automatizzato continua a richiedere pagine e risorse di cui nessun visitatore umano ha bisogno.
Quando il costo della larghezza di banda diventa evidente, il sito potrebbe aver già speso giorni o settimane a gestire traffico che non ha mai aiutato l’azienda.
Il carico sul backend è il costo più difficile da individuare
Non tutte le richieste hanno lo stesso costo di elaborazione. Un post del blog memorizzato nella cache è relativamente economico, poiché il server restituisce una versione salvata e passa oltre. Le richieste dinamiche funzionano in modo diverso.
Quando un bot effettua un’azione nel carrello di WooCommerce, visita una pagina prodotto filtrata, un URL di ricerca, una pagina di login o un endpoint AJAX, il server non può attingere dalla cache. Deve elaborare la richiesta ogni volta:
- Esecuzione PHP — viene riservato un thread per tutta la durata della richiesta
- Query al database — la pagina interroga il database a ogni caricamento, senza cache che ne assorba il carico
- Gestione delle sessioni — le pagine del carrello e del checkout creano o convalidano una sessione per ogni richiesta, anche per i bot che non completeranno mai un acquisto
- Logica dei plugin — qualsiasi plugin collegato a queste richieste esegue il proprio codice a ogni accesso
- Bypass della cache — la richiesta non entra mai nella cache, quindi le future richieste identiche comportano di nuovo lo stesso costo
È qui che il traffico dei bot diventa più costoso di quanto sembri. Il problema non è solo la quantità di dati che un bot scarica, ma quanto lavoro deve svolgere l’infrastruttura prima di restituire quei dati.
I dati sull’infrastruttura di Kinsta rendono concreta la portata del fenomeno: i bot hanno effettuato 7,67 milioni di accessi agli URL “aggiungi al carrello” in un solo periodo di 24 ore, incluse 3,75 milioni di richieste provenienti dal solo ClaudeBot. Ognuna è stata trattata come una nuova richiesta lato server. Ognuna ha attivato l’esecuzione di PHP e una query al database. Nessuna serviva a un cliente.
Come ha detto il CTO di Kinsta, Daniel Pataki, al momento del lancio: «La maggior parte dei consigli sulla gestione dei bot si riduce a “blocca tutto” o “ignorali”. Nessuno dei due funziona su larga scala».
Perché dire “non abbiamo avuto tempi di inattività” non coglie il punto
Il tempo di attività significa che il sito rimane online. Non significa che il sito funzioni in modo efficiente.
Un sito WordPress può assorbire una quantità significativa di traffico inutile prima che i visitatori si accorgano che qualcosa non va. Le pagine continuano a caricarsi. Il checkout funziona ancora. Le schermate di amministrazione rispondono ancora. Ma l’infrastruttura continua a elaborare ogni richiesta dei bot che colpisce un endpoint dinamico, e quell’elaborazione comporta un costo reale, anche quando il sito sembra stabile.
Quel costo si manifesta in modi più impercettibili rispetto a un’interruzione:
- Un maggiore utilizzo della larghezza di banda che si avvicina ai limiti del piano
- Maggiore pressione sui worker PHP e sulle connessioni al database
- Meno margine di manovra quando i picchi di traffico reale richiedono quelle stesse risorse
- Analisi distorte che confondono le sessioni dei bot con il coinvolgimento degli utenti reali
- Risultati dei test A/B e tassi di conversione distorti dal traffico che non aveva mai intenzione di convertire
- Decisioni sull’infrastruttura prese sulla base di dati che non riflettono il comportamento effettivo del pubblico
- Risoluzione dei problemi più difficile quando il rumore dell’attività dei bot oscura il segnale dei veri problemi di prestazioni
Ecco perché l’assenza di downtime può dare ai team un falso senso di sicurezza. Il sito sembra stabile perché l’infrastruttura assorbe il carico extra. Assorbire gli sprechi ha comunque un costo; semplicemente non si nota.
Perché le agenzie dovrebbero affrontare questo problema prima che i clienti se ne accorgano
Di solito le agenzie vengono a sapere del traffico bot solo dopo che ha già creato un problema visibile. Un cliente nota un aumento dell’utilizzo dell’hosting, schermate di amministrazione più lente, rallentamenti al momento del checkout, modelli di traffico insoliti o analisi che non corrispondono più ai risultati aziendali. A quel punto, la conversazione è reattiva. L’agenzia deve spiegare cosa è successo, perché è importante e quali cambiamenti sono necessari.
Il traffico dei bot offre invece alle agenzie l’opportunità di una conversazione proattiva.
Non serve usare toni allarmistici. Puoi rimanere sul pratico:
- “Il tuo sito potrebbe funzionare bene, ma parte di quel traffico potrebbe non provenire da visitatori reali.”
- “Alcune attività dei bot sono utili, come i crawler di ricerca o gli strumenti di monitoraggio, ma altre consumano solo risorse.”
- “Possiamo ridurre gli sprechi senza intaccare il traffico che conta davvero.”
- “Gestire bene questo aspetto protegge il margine di prestazioni e aiuta a mantenere prevedibile l’utilizzo.”
Questo collega la gestione dei bot alle preoccupazioni che i clienti già comprendono: costi, efficienza, affidabilità. Inoltre, riposiziona l’agenzia da semplice risolutore di problemi reattivo a consulente proattivo per l’infrastruttura, il che crea una relazione più duratura.
L’obiettivo non è bloccare tutti i bot
È importante notare che non tutto il traffico dei bot è dannoso. I crawler di ricerca aiutano le pagine ad apparire nei risultati di ricerca. Gli strumenti di monitoraggio controllano il tempo di attività. Le piattaforme SEO verificano le pagine. Anche i fornitori di servizi di pagamento, le integrazioni, le API e le automazioni di WordPress potrebbero aver bisogno di accedere al sito per svolgere un lavoro legittimo.
I crawler basati AI sono più complicati. Alcuni proprietari di siti potrebbero voler essere visibili nelle esperienze basate sull’AI. Altri potrebbero decidere che il crawling AI genera più costi che valore, specialmente quando estrae dati da grandi librerie di contenuti senza restituire in cambio traffico di riferimento significativo.
Ecco perché l’obiettivo non è bloccare ogni richiesta automatizzata. Un blocco eccessivo può creare problemi SEO, compromettere le integrazioni, interrompere il monitoraggio o interferire con i normali flussi di lavoro di WordPress.
Un approccio migliore è il controllo selettivo:
- Consenti il traffico utile
- Blocca l’automazione chiaramente inutile
- Verifica il traffico sospetto
- Proteggi i percorsi ad alto costo
- Monitora i risultati
Questo offre ai team un maggiore controllo senza trattare tutti i bot allo stesso modo. L’obiettivo è ridurre gli sprechi preservando al contempo il traffico, gli strumenti e i flussi di lavoro che continuano a supportare l’attività.
Come funziona in pratica Protezione bot di Kinsta
Quando il traffico dei bot diventa un problema per l’infrastruttura, la risposta deve adattarsi alla situazione reale del sito.
Protezione bot in MyKinsta è pensata proprio per gestire questa variabilità. È inclusa in tutti i piani senza costi aggiuntivi, funziona a livello di ambiente e entra in vigore immediatamente quando cambi le impostazioni.
Livelli di protezione
Vai su Siti > nome del sito > Protezione bot > Modifica per scegliere tra quattro livelli predefiniti, ciascuno applicato in modo indipendente per ogni ambiente, così che staging, sviluppo e produzione possano utilizzare impostazioni diverse.
- Blocca traffico dannoso: l’impostazione predefinita su ogni sito. Gestisce la mitigazione degli attacchi DDoS e blocca gli IP e gli endpoint collegati a modelli di attacco noti. È già attiva su tutti i siti Kinsta.
- Blocca automazioni: il punto di partenza consigliato per la maggior parte dei siti che subiscono un carico di bot. Blocca il traffico automatizzato e dannoso confermato, lasciando passare i bot verificati e i visitatori reali. Efficace per i siti che registrano accessi ripetitivi su URL dinamici senza voler mettere alla prova il traffico umano.
- Verifica bot: aggiunge una fase di verifica per i probabili bot e il traffico non classificato. Un visitatore che supera la verifica non verrà sottoposto nuovamente a verifica per dieci giorni dallo stesso browser e IP. Utile durante i picchi di traffico, gli eventi di saldi o i periodi di scraping attivo, in cui l’equilibrio tra blocco e attrito richiede maggiore precisione.
- Verifica tutti: l’impostazione più rigorosa, pensata per un uso a breve termine durante un attacco in corso o un abuso prolungato. Tutto il traffico non verificato viene sottoposto a verifica, compresi i potenziali utenti umani. Non è una configurazione permanente.
Prima di alzare il livello oltre Blocca traffico dannoso, controlla che le tue integrazioni critiche per l’azienda compaiano nella directory dei bot verificati di Cloudflare. A partire da Verifica bot o livelli superiori, qualsiasi strumento che si connetta al tuo sito in modo programmatico e che non sia verificato verrà sottoposto a verifica o bloccato.
Blocca crawler AI
L’opzione Blocca crawler AI è un controllo separato dal livello di protezione. Si rivolge specificatamente ai crawler AI, compresi quelli verificati come GPTBot, senza influire su Googlebot e Bingbot. L’indicizzazione per la ricerca continua normalmente.
Per i siti ricchi di contenuti, gli editori, le librerie di documentazione e gli hub di contenuti premium in cui i crawler AI visitano ripetutamente pagine di articoli, pagine di archivio e risorse non memorizzate nella cache in grandi quantità, questo pulsante elimina quel carico senza influire sulla visibilità nei motori di ricerca.
Il compromesso è reale e vale la pena menzionarlo: bloccare i crawler AI riduce la frequenza con cui i tuoi contenuti compaiono nelle risposte e nei riassunti generati dall’AI. Per i siti in cui la visibilità sull’AI è una priorità strategica, potrebbe essere più indicato optare per Blocca automazioni o Verifica bot, poiché filtrano i comportamenti più dannosi pur rimanendo indicizzabili. Per i siti in cui il costo delle risorse del server e l’utilizzo del piano contano più della visibilità sull’AI, il blocco è la scelta più chiara.
Consenti automazioni tipiche di WordPress
Quando aumenti il livello di protezione oltre quello predefinito, attiva contemporaneamente l’opzione Consenti automazioni tipiche di WordPress.
Questo attiva una allowlist gestita di percorsi e servizi comuni di WordPress, come le richieste REST API, i percorsi WooCommerce, le attività in background, i lavori pianificati e le integrazioni dei plugin, in modo che un filtraggio più rigoroso dei bot non interrompa silenziosamente i flussi di lavoro da cui dipende il sito.
Attivalo ogni volta che passi al livello Blocca automazioni o superiore. L’obiettivo è ridurre il traffico superfluo, non interrompere le operazioni legittime.
Consenti sempre
Alcuni servizi non dovrebbero mai essere bloccati, indipendentemente dal livello di protezione. La sezione Consenti sempre permette di aggiungere fino a 50 eccezioni personalizzate in base all’indirizzo IP, al percorso URL o allo user agent.
Usala per:
- Webhook dei fornitori di servizi di pagamento (Stripe, PayPal)
- Servizi di monitoraggio affidabili (UptimeRobot, Pingdom)
- Integrazioni con partner noti o utenti delle API
- Intervalli di IP degli sviluppatori o dell’ufficio
- Percorsi specifici di WordPress come /wp-json/* o /wp-admin/admin-ajax.php, se non sono già coperti dalla lista bianca delle automazioni di WordPress
Analisi delle richieste e risultati della protezione dai bot
È difficile ottimizzare il traffico dei bot quando i team non riescono a capire come vengono classificate o gestite le richieste.
Prima di modificare qualsiasi impostazione, controlla prima la schermata della protezione dai bot. Il grafico della suddivisione delle richieste mostra tutte le richieste effettuate al tuo sito nelle ultime 24 ore, classificate in sette categorie: Probabilmente persone, Bot verificati, Probabilmente bot, Crawler AI, Crawler AI a frequenza eccessiva, Traffico non classificato e Traffico automatizzato.
La domanda è cambiata
L’hosting è sempre stato valutato in base a una breve lista di risultati visibili: il sito è online? Si carica velocemente? I visitatori riescono a fare quello che sono venuti a fare?
Queste domande sono ancora importanti. Ma non raccontano più tutta la storia.
Un sito può rimanere online pur sprecando larghezza di banda. Può caricarsi velocemente mentre i bot consumano i thread PHP e le connessioni al database di cui hanno bisogno i visitatori reali. Può superare un test di velocità un martedì pomeriggio e poi andare in crisi sotto il carico del lancio di una campagna il giovedì, perché il margine di capacità che avrebbe dovuto essere disponibile era già stato consumato per elaborare traffico che non ha mai aiutato l’azienda.
La domanda non è più solo “Il sito riesce a gestire il carico?”, ma “Quanto di questo carico dovrebbe gestire il sito, in realtà?”.
Il traffico bot non ha bisogno di mandare offline un sito per costare qualcosa. Basta che continui a colpire i percorsi che richiedono un’elaborazione reale, e che lo faccia con un volume che, in ogni dashboard, sembri un’attività normale.
Ottenere visibilità su quel traffico e avere gli strumenti per agire in base a ciò che vedi è ciò che cambia la situazione. Non puoi gestire ciò che non vedi, e non puoi agire su ciò che vedi se le tue uniche opzioni sono bloccare o consentire l’accesso a tutto.
Per i team WordPress che gestiscono siti ricchi di contenuti, negozi WooCommerce o grandi portafogli clienti, l’hosting WordPress gestito di Kinsta mette questi controlli a disposizione in MyKinsta, senza costi aggiuntivi, regolabili per ogni ambiente senza bisogno di aprire un ticket di assistenza. Inizia dando un occhiata al rapporto sul traffico AI e bot per avere un quadro completo di ciò che sta gravando sull’infrastruttura WordPress e di quanto costa.
