Anche sulla nostra infrastruttura abbiamo riscontrato casi estremi. Nel nostro rapporto sul traffico generato da AI e bot<\/a>, un crawler ha generato 3,75 milioni di richieste verso URL di “aggiungi al carrello” in 24 ore. Un altro modello di loop ripetitivo ha generato centinaia di milioni di richieste prima che introducessimo una regola per bloccarlo.<\/p>\n Questi casi sono reali, ma non rappresentano tutti i siti web.<\/p>\n Nella nostra ultima analisi<\/a> su oltre 5.000 siti WordPress, i bot AI rappresentavano solo l\u20191,57% della larghezza di banda nel sito mediano, rispetto al 17,8% al 90\u00b0 percentile e al 90,3% al 99\u00b0, mentre pi\u00f9 di 1.000 siti non hanno registrato alcuna larghezza di banda dovuta ai bot AI<\/p>\n \u00c8 proprio questa variazione a spiegare perch\u00e9 individuare il traffico dei bot AI e diagnosticare un problema legato a questi bot sono due cose diverse.<\/p>\n Le decisioni che prenderai in seguito possono influire sulle prestazioni del sito, sulle integrazioni, sulla visibilit\u00e0 nei motori di ricerca e sulla capacit\u00e0 degli strumenti AI di trovare i tuoi contenuti. Prima di cambiare qualsiasi cosa, devi sapere cosa stanno effettivamente facendo i bot.<\/p>\n Ecco alcuni errori che vediamo commettere da chi gestisce siti quando saltano questo passaggio.<\/p>\n Se i crawler basati sull\u2019AI rappresentano il 20% delle richieste del sito, quel numero da solo non ti dice se c\u2019\u00e8 un problema.<\/p>\n Una quota elevata di richieste verso articoli in cache potrebbe esercitare una pressione relativamente bassa sull\u2019applicazione, mentre un numero minore di richieste che colpiscono ripetutamente i risultati di ricerca, le pagine dei prodotti filtrate o gli URL del carrello pu\u00f2 creare molto pi\u00f9 lavoro.<\/p>\n Questo \u00e8 uno dei motivi per cui le statistiche sui bot a livello di rete richiedono una certa cautela quando vengono applicate a un singolo sito.<\/p>\n La nostra ultima ricerca<\/a> ha rilevato che il numero medio di richieste dei bot basati sull\u2019intelligenza artificiale per sito variava da 667 a 928 al giorno su quattro misurazioni, rispetto a una mediana di sole 33-67 richieste, mentre circa il 20%-27% dei siti non ha ricevuto alcuna richiesta da bot AI nel giorno in cui \u00e8 stata effettuata la misurazione.<\/p>\n In altre parole, un piccolo gruppo di siti sottoposti a intense attivit\u00e0 di crawling fa salire la media.<\/p>\n Quindi, se leggi che i bot costituiscono pi\u00f9 della met\u00e0 del traffico web, o vedi un altro proprietario di sito che segnala un traffico da bot pari al 99%, non usare quel numero per decidere di cosa ha bisogno il tuo sito.<\/p>\n Parti dal tuo traffico.<\/p>\n Per i clienti Kinsta, la sezione Protezione bot<\/a>\u00a0in MyKinsta mostra come vengono classificate le richieste, inclusi utenti probabilmente umani, bot verificati, bot probabili, crawler AI, crawler AI con frequenza eccessiva, traffico automatizzato e traffico dannoso.<\/p>\n Puoi poi usare la schermata Traffico principale<\/strong>\u00a0per vedere i percorsi, gli user agent, i paesi e gli indirizzi IP dietro a un tipo specifico di traffico.<\/p>\n Prima di agire, dovresti essere in grado di rispondere ad alcune domande di base:<\/p>\n Il nostro ultimo rapporto inquadra la questione analizzando la posizione, il modello e il profilo<\/strong> del traffico. Un sito che riceve pochissimo traffico generato dall\u2019AI con un comportamento di richiesta normale potrebbe non richiedere alcun intervento, mentre uno che registra un traffico costante di crawler su URL dinamici costosi merita un\u2019analisi molto pi\u00f9 approfondita.<\/p>\n Il termine “bot AI” ora copre diversi tipi di traffico. Alcuni crawler raccolgono contenuti pubblici per l\u2019addestramento dei modelli o la ricerca AI, mentre altri recuperano pagine in risposta alla richiesta di un utente.<\/p>\n Queste differenze sono importanti quando decidi cosa consentire. OpenAI, ad esempio, usa GPTBot per i contenuti che potrebbero servire a migliorare i suoi modelli, mentre OAI-SearchBot aiuta a rendere i siti web reperibili nella ricerca di ChatGPT. Bloccare OAI-SearchBot pu\u00f2 quindi influire sulla visibilit\u00e0 dei tuoi contenuti nei risultati di ricerca di ChatGPT.<\/p>\n Anche Anthropic fa una distinzione simile. ClaudeBot raccoglie contenuti web che possono contribuire all\u2019addestramento dei modelli, Claude-SearchBot viene utilizzato per la ricerca, mentre Claude-User pu\u00f2 recuperare un sito web quando qualcuno che usa Claude lo richiede.<\/p>\n Perplexity riferisce che PerplexityBot viene utilizzato per il proprio indice di ricerca e Perplexity-User per le richieste effettuate in risposta alle domande degli utenti.<\/p>\n Google offre agli editori un\u2019impostazione separata Mettere tutti questi sistemi in un unico calderone chiamato \u201cAI\u201d significa sprecare informazioni che potresti utilizzare.<\/p>\n Se preferisci non impiegare le risorse del sito per l\u2019addestramento dei modelli, puoi scegliere di limitare l\u2019accesso ai crawler di addestramento, lasciando il sito accessibile ai sistemi di ricerca e recupero. Se il tuo problema \u00e8 un agente AI che colpisce ripetutamente un endpoint dinamico, cambiare la politica relativa ai crawler di addestramento potrebbe non risolverlo.<\/p>\n C\u2019\u00e8 anche una questione commerciale da considerare. La nostra ricerca sui consumatori ha rilevato che il 44,7% degli intervistati ha dichiarato di visitare sempre o quasi sempre il sito web di un\u2019azienda dopo aver ricevuto un consiglio dall\u2019AI. Questo non significa che l\u2019accesso dei crawler AI<\/strong> generi automaticamente traffico di provenienza da referral, ma significa che vale la pena considerare la scoperta tramite AI prima di prendere una decisione generica sulla visibilit\u00e0.<\/p>\n Su Kinsta, il controllo Blocca crawler di AI<\/strong> permette ai clienti di bloccare i crawler AI, compresi quelli verificati, senza bloccare i crawler dei motori di ricerca tradizionali come Googlebot e Bing.<\/p>\n Avvertiamo inoltre i clienti che bloccare i crawler AI pu\u00f2 ridurre la visibilit\u00e0 nei risultati di ricerca, nei riassunti o nei consigli basati sull\u2019intelligenza artificiale.<\/p>\n I bot possono creare problemi di sicurezza tramite tentativi di forza bruta, attacchi DDoS, attacchi alle credenziali e altre forme di automazione abusiva, ma un crawler AI verificato che invia troppe richieste legittime \u00e8 un problema di altro tipo.<\/p>\n Durante il nostro evento live sul traffico bot<\/a>, il CTO di Kinsta Daniel Pataki ha spiegato perch\u00e9 lo preoccupa il modo in cui chi gestisce siti reagisce quando queste due cose vengono confuse:<\/p>\n “In questo caso temo una reazione eccessiva pi\u00f9 di quanto temo una reazione insufficiente, perch\u00e9 non si tratta di un problema di sicurezza.”<\/em><\/p>\n Si riferiva al problema pi\u00f9 ampio dei crawler AI, dove gran parte del traffico fastidioso che vediamo proviene da sistemi legittimi che eseguono il crawling in modo inefficiente, piuttosto che da un hacker che cerca di compromettere il sito.<\/p>\n La risposta cambia quando il sito \u00e8 gi\u00e0 in difficolt\u00e0. Se i bot stanno occupando le risorse del server, rallentando le pagine o impedendo ai clienti reali di usare il sito, la priorit\u00e0 \u00e8 stabilizzare il sito. Daniel ha consigliato di bloccare temporaneamente il traffico dei bot quando causa un problema concreto, per poi indagare una volta che il sito \u00e8 sotto controllo.<\/p>\n L\u2019errore \u00e8 trasformare quella misura di emergenza in una politica permanente senza capire cosa sia successo.<\/p>\n Protezione bot di Kinsta<\/a> offre diversi livelli di controllo, dalla protezione di base contro il traffico dannoso al blocco delle automazioni o alla verifica dei bot sospetti quando serve una protezione pi\u00f9 rigorosa. Anche i crawler AI con frequenza eccessiva possono essere sottoposti a verifica ai livelli di protezione appropriati.<\/p>\n Un improvviso incidente di prestazioni potrebbe giustificare controlli pi\u00f9 severi oggi. Una volta superato l\u2019incidente, verifica cosa stava colpendo il sito e se quei controlli pi\u00f9 severi abbiano ancora senso.<\/p>\n I dati della nostra infrastruttura rendono questa differenza facile da notare. Una richiesta per un post del blog memorizzato nella cache e una per una pagina di ricerca WooCommerce non memorizzata nella cache contano entrambe come una singola richiesta, anche se la seconda pu\u00f2 richiedere molto pi\u00f9 lavoro al server.<\/p>\n Ecco un’illustrazione tratta dall\u2019evento live “Tutta la verit\u00e0 sul traffico bot”<\/a>:<\/p>\n Quando \u00e8 disponibile una pagina memorizzata nella cache, WordPress pu\u00f2 gestire gran parte della richiesta senza rigenerare la pagina.<\/p>\n Una richiesta dinamica potrebbe richiedere un thread PHP (detto anche “worker”), query al database, la generazione della pagina e, a volte, la gestione della sessione prima che WordPress possa restituire un risultato. Le attivit\u00e0 relative al carrello e al checkout possono aggiungere ulteriore carico di lavoro.<\/p>\n Ora ripeti quel processo migliaia di volte.<\/p>\n In base a tre misurazioni del nostro ultimo studio<\/a>, tra il 76,9% e il 90,5% delle richieste dei crawler basati sull\u2019IA riguardavano contenuti dinamici. Il traffico umano \u00e8 rimasto tra il 18,3% e il 18,9%.<\/p>\n Questa differenza ti dice molto di pi\u00f9 sul potenziale carico sull\u2019infrastruttura rispetto al semplice conteggio delle richieste.<\/p>\n Pensa all\u2019incidente relativo all\u2019aggiunta al carrello che abbiamo riscontrato nella nostra ricerca sul traffico bot AI<\/a>. Un crawler ha generato 3,75 milioni di richieste in 24 ore, circa una richiesta ogni 23 millisecondi. Ogni richiesta poteva costringere WordPress a lavorare per un \u201cvisitatore\u201d che non avrebbe mai comprato nulla.<\/p>\n Ecco perch\u00e9 anche due siti con la stessa percentuale di traffico generato dall\u2019AI possono comportarsi in modo molto diverso.<\/p>\n Un sito di contenuti in cui i crawler richiedono principalmente articoli memorizzati nella cache pu\u00f2 gestire un volume elevato senza troppi problemi, mentre un negozio WooCommerce pu\u00f2 risentirne molto prima se anche un numero minore di richieste colpisce ripetutamente la ricerca, i filtri, le azioni nel carrello, le pagine dell\u2019account o altre pagine non memorizzate nella cache.<\/p>\n Una volta individuato un picco, non fermarti allo user agent.<\/p>\n In MyKinsta, puoi filtrare il traffico principale<\/strong> in base ai crawler AI<\/strong> e controllare i percorsi che richiedono pi\u00f9 spesso.<\/p>\n Poi puoi confrontare questi dati con le informazioni sulla cache, la larghezza di banda del server e i dati sulle prestazioni per capire se quelle richieste stanno raggiungendo l\u2019applicazione e creando carico di lavoro.<\/p>\n Vedere A volte il bot non fa altro che mettere in luce un problema gi\u00e0 presente nella tua struttura degli URL.<\/p>\n I siti WordPress possono generare un sacco di URL da parametri di query, pagine di ricerca, archivi filtrati, impaginazione, calendari, varianti di prodotto e azioni di e-commerce.<\/p>\n Una persona potrebbe rendersi conto che due URL leggermente diversi portano essenzialmente alla stessa pagina, mentre un crawler vede semplicemente pi\u00f9 link da seguire.<\/p>\n Se ogni pagina genera un\u2019altra serie di URL che sembrano nuovi, il crawler pu\u00f2 continuare a seguirli. \u00c8 cos\u00ec che ti ritrovi con schemi che sembrano molto pi\u00f9 aggressivi di quanto chiunque avesse previsto.<\/p>\n L\u2019abbiamo visto nella nostra precedente ricerca sull\u2019infrastruttura<\/a>. Un modello ricorrente \u00e8 diventato cos\u00ec esteso che una singola regola progettata per individuarlo ha filtrato 550 milioni di richieste in 30 giorni.<\/p>\n Bloccare il crawler pu\u00f2 fermare il carico immediato, ma non elimina il modello di URL che ha portato il crawler a trovare nuove pagine.<\/p>\n Quando un determinato percorso domina improvvisamente il traffico del crawler AI, controlla il percorso stesso:<\/p>\n Potresti comunque decidere di bloccare o contrastare il crawler, ma prima cerca di capire cosa lo ha spinto a tornare.<\/p>\n Questo \u00e8 particolarmente importante per le agenzie. Se diversi siti dei clienti utilizzano lo stesso plugin, la stessa configurazione di WooCommerce, lo stesso tema o lo stesso schema di URL, un crawler aggressivo pu\u00f2 far emergere lo stesso problema su pi\u00f9 di un sito. Risolvere il problema pu\u00f2 essere pi\u00f9 utile che mantenere un elenco sempre pi\u00f9 lungo di nomi di bot.<\/p>\n Una modifica al file Abbiamo approfondito questa distinzione nella nostra guida ai crawler AI<\/a>. Questo \u00e8 importante quando scopri un problema di prestazioni, perch\u00e9 limitarti a modificare un file pu\u00f2 farti pensare che il problema sia stato risolto.<\/p>\n Controlla i tuoi log o le analisi dei bot. Se le richieste del crawler diminuiscono dopo aver modificato il tuo file Lo stesso vale quando il problema \u00e8 la frequenza delle richieste piuttosto che l\u2019accesso in s\u00e9. Un crawler potrebbe essere autorizzato a leggere i tuoi contenuti, ma continuare a richiederli a una frequenza che il tuo sito non riesce a gestire comodamente.<\/p>\n L\u2019esempio di PatronView<\/a> \u00e8 utile perch\u00e9 la risposta del sito si basava sui propri dati.<\/p>\n Il suo pubblico \u00e8 prevalentemente nordamericano, quindi il proprietario blocca il traffico proveniente da altri continenti. Ha controllato i dati reali sui visitatori prima di bloccare gli utenti con versioni obsolete del browser. Inoltre, monitora quanti visitatori bloccati completano effettivamente la procedura di verifica. In un determinato periodo, solo lo 0,24% di oltre 100.000 verifiche \u00e8 stato superato.<\/p>\n Questi numeri rendono pi\u00f9 facile giustificare le regole per quel sito, ma applicare la stessa configurazione a un negozio di e-commerce internazionale potrebbe finire per bloccare clienti legittimi. Lo stesso rischio si presenta quando i team accumulano diversi strumenti di sicurezza perch\u00e9 ognuno sembra utile di per s\u00e9.<\/p>\n Un sito WordPress potrebbe avere una protezione anti-bot a livello di hosting, regole Cloudflare, un plugin di sicurezza, limitazioni di velocit\u00e0, blocchi per paese e regole WAF personalizzate, tutte cose che prendono decisioni sulla stessa richiesta. Individuare un falso positivo diventa molto pi\u00f9 difficile quando non sai quale livello abbia preso la decisione.<\/p>\n Ai clienti Kinsta sconsigliamo espressamente di combinare Protezione bot di Kinsta con ulteriori livelli personalizzati di protezione dai bot<\/a>. Classificazioni contrastanti possono causare il blocco di visitatori legittimi o di integrazioni.<\/p>\n Livelli di protezione pi\u00f9 elevati possono inoltre influire sulle automazioni legittime come API, strumenti di monitoraggio, webhook e integrazioni WordPress. MyKinsta include quindi l\u2019opzione Consenti le automazioni tipiche di WordPress<\/strong> ed eccezioni di tipo \u201cconsenti sempre\u201d per indirizzi IP, percorsi e user agent affidabili.<\/p>\n Se gestisci un\u2019agenzia, un processo standard \u00e8 pi\u00f9 utile di un insieme di regole standard. Puoi applicare lo stesso processo a 20 siti dei tuoi clienti identificando il traffico, analizzandone i percorsi, verificandone le prestazioni, scegliendo un controllo, testandolo e monitorando il risultato.<\/p>\n Inizia dall\u2019analizzare cosa sta succedendo sul tuo sito. Se il traffico dei bot sta influenzando i visitatori reali, proteggi prima il sito, poi verifica quanto traffico stai ricevendo, quali percorsi raggiunge e quali sistemi ne sono responsabili.<\/p>\n Da l\u00ec, scegli la modifica pi\u00f9 piccola che possa risolvere il problema. Potrebbe trattarsi di aggiornare un file I clienti Kinsta possono svolgere gran parte di questa analisi direttamente in MyKinsta. L\u2019analisi del traffico dei bot<\/a> distingue tra crawler AI, crawler AI con frequenza eccessiva, bot verificati, traffico automatizzato e altri tipi di richieste, mentre la sezione Traffico principale<\/strong>\u00a0mostra i percorsi, gli user agent, i paesi e gli IP da cui provengono.<\/p>\n Puoi anche confrontare questa attivit\u00e0 con il comportamento della cache<\/a>, la larghezza di banda del server<\/a> e le prestazioni PHP<\/a> per capire se il traffico sta davvero mettendo sotto pressione il tuo sito prima di decidere cosa bloccare.<\/p>\n","protected":false},"excerpt":{"rendered":" Quando scopri che gran parte del traffico del tuo sito web proviene dai bot, bloccarli pu\u00f2 sembrare la mossa pi\u00f9 ovvia da fare. In alcuni casi, …<\/p>\n","protected":false},"author":287,"featured_media":85337,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[26291,26290],"class_list":["post-85336","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-crawler-web","topic-traffico-bot"],"yoast_head":"\nErrore 1: considerare la percentuale come una diagnosi<\/h2>\n
![\"Grafico](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/kinsta-bot-protection-data.png\")
![\"Report](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/top-traffic-bot-data.png\")
\n
Errore n. 2: bloccare tutti i bot solo perch\u00e9 il traffico \u00e8 automatizzato<\/h2>\n
Google-Extended<\/code> che regola come i contenuti sottoposti a crawling possono essere utilizzati con Gemini. Google afferma esplicitamente che modificare tale impostazione non influisce sull\u2019inclusione o sul posizionamento nella Ricerca Google.<\/p>\n![\"Blocco](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/block-ai-crawlers.png\")
Errore 3: considerare ogni picco di crawler AI come un\u2019emergenza di sicurezza<\/h2>\n
![\"Scegliere](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/chnage-bot-protection-level.png\")
Errore 4: monitorare il volume delle richieste ignorando dove vanno a finire<\/h2>\n
![\"Richiesta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/website-request-flow.png\")
![\"Filtrare](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/filter-traffic-type.png\")
![\"Richieste](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/top-requests-server-bandwidth.png\")
GPTBot<\/code> o un altro crawler in cima a un report \u00e8 utile. Se noti che migliaia delle sue richieste vanno a \/blog\/<\/code>, questo ti dice una cosa. Se invece le vedi andare ai risultati di ricerca o a un URL WooCommerce parametrizzato, ti dice qualcos\u2019altro.<\/p>\nErrore 5: bloccare il crawler e non disfarsi della \u201ctrappola di scansione\u201d<\/h2>\n
\n
Errore 6: dare per scontato che il file robots.txt abbia bloccato il traffico<\/h2>\n
robots.txt<\/code> pu\u00f2 essere la risposta giusta quando vuoi dire a un crawler affidabile di non accedere a una parte o all\u2019intero sito, ma devi comunque controllare il traffico in seguito.robots.txt<\/code> si basa sul fatto che il crawler rispetti l\u2019istruzione e non impedisce fisicamente alla richiesta di raggiungere il tuo sito.<\/p>\nrobots.txt<\/code> comunica le preferenze di scansione, mentre llms.txt<\/code> fornisce un indice strutturato dei contenuti per gli strumenti che scelgono di leggerlo. L\u2019applicazione delle regole avviene altrove.<\/em><\/p>\nrobots.txt<\/code>, hai la prova che ha funzionato. Se il traffico continua, o se hai a che fare con un altro sistema automatizzato che non segue le istruzioni, ti serve un controllo di applicazione.<\/p>\nErrore 7: copiare le regole del firewall di un altro sito senza verificare cosa potrebbero bloccare<\/h2>\n
![\"Consentire](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/allow-typical-wp-automation-and-exceptions.png\")
Cosa fare quando scopri del traffico generato da bot AI<\/h2>\n
robots.txt<\/code>, bloccare o verificare un crawler, correggere un modello di URL indicizzabile, oppure non fare nulla se il traffico non sta causando danni.<\/p>\n