\u00abDal punto di vista dell\u2019infrastruttura, non esiste una cosa come il “semplice traffico dei bot”\u00bb, afferma Daniel Pataki, CTO di Kinsta. \u00abOgni richiesta implica un vero consumo di risorse. Su larga scala, una scansione inefficiente smette di essere un problema di traffico e diventa un problema di risorse.\u00bb<\/p>\n
Questo articolo spiega perch\u00e9 si \u00e8 verificato questo cambiamento, quanto costa effettivamente ai proprietari di siti WordPress e come deve cambiare la narrativa.<\/p>\n
Il vecchio modello non funziona pi\u00f9<\/h2>\n
La gestione tradizionale dei bot si basava su una premessa semplice: bloccare quelli cattivi e lasciar passare quelli buoni. Per anni, questo \u00e8 bastato. Googlebot scansionava le pagine, indicizzava i contenuti e andava avanti. I bot dannosi cercavano di intrufolarsi nelle pagine di login. Due problemi molto diversi, due soluzioni molto diverse.<\/p>\n
Ci\u00f2 di cui nessuno dei due modelli teneva conto era una terza categoria: il traffico automatizzato che non \u00e8 dannoso n\u00e9 viene bloccato, ma che sta causando un danno misurabile alle prestazioni dei siti su larga scala.<\/p>\n
I crawler AI<\/a>, ovvero bot progettati non solo per indicizzare le pagine ai fini dei risultati di ricerca, ma anche per acquisire contenuti per l\u2019addestramento dei modelli, la generazione retrieval-augmented e le query degli utenti in tempo reale, operano su una scala fondamentalmente diversa rispetto a qualsiasi cosa vista in precedenza. Il solo GPTBot \u00e8 cresciuto del 305% tra maggio 2024 e maggio 2025. All\u2019inizio del 2025, circa una visita web su 200 era effettuata da un bot AI. Entro la fine dell\u2019anno, quel rapporto era salito a una su 31.<\/p>\n Verso la fine del 2025, i crawler AI rappresentavano il 4,2% di tutte le richieste HTML sulla rete di Cloudflare, una cifra che \u00e8 passata dal 2,4% all\u2019inizio di aprile al 6,4% alla fine di giugno, quasi triplicandosi nel giro di un anno.<\/p>\n Questi crawler sono insistenti e frequenti, e non si comportano come i tradizionali bot dei motori di ricerca. Molti generano grandi volumi di richieste verso endpoint dinamici non memorizzati nella cache, il che comporta un \u201clavoro vero e proprio\u201d per il tuo server.<\/p>\n \u00c8 qui che il problema dell\u2019infrastruttura diventa evidente, ed \u00e8 un aspetto che spesso viene trascurato nella maggior parte delle analisi sul traffico dei bot.<\/p>\n Quando un visitatore carica una pagina memorizzata nella cache su un sito WordPress, il server fa ben poco. Restituisce un file HTML<\/a> gi\u00e0 pronto, proprio come farebbe per servire un\u2019immagine o un file CSS<\/a>. Il server di origine se ne accorge a malapena. \u00c8 proprio questo il senso della cache.<\/p>\n Ma una parte significativa delle richieste su un vero sito WordPress, e in particolare sugli store WooCommerce, non pu\u00f2 essere gestita dalla cache. Queste richieste includono:<\/p>\n Quando un bot accede a questi endpoint, ecco cosa succede effettivamente sul server:<\/p>\n Questo \u00e8 il meccanismo attraverso cui il traffico dei bot diventa un problema per l\u2019infrastruttura. Non \u00e8 una teoria. \u00c8 la catena specifica di eventi che si verifica quando le richieste automatizzate inondano gli endpoint dinamici di un sito WordPress attivo.<\/p>\n L\u2019astratto diventa concreto quando si osservano i dati reali provenienti dall\u2019infrastruttura che gestiamo su larga scala.<\/p>\n Un dato che abbiamo trovato particolarmente sorprendente \u00e8 che un singolo bot (ClaudeBot) ha generato 3,75 milioni di richieste di \u201caggiungi al carrello\u201d nell\u2019arco di 24 ore<\/strong>. Si tratta all\u2019incirca di una richiesta ogni 23 millisecondi (giorno e notte), ognuna delle quali viene trattata dal server come una nuova richiesta perch\u00e9 gli endpoint del carrello sono intrinsecamente dinamici.<\/p>\n Per contestualizzare: le richieste di \u201caggiungi al carrello\u201d sono tra gli endpoint pi\u00f9 onerosi di un negozio WooCommerce. Creano sessioni, eseguono query e aggiornano lo stato del carrello. Ognuna di esse comporta un carico di lavoro reale. I 3,75 milioni di richieste che abbiamo rilevato da un\u2019unica fonte in un solo giorno rappresentano il tipo di andamento del traffico che pu\u00f2 mandare un sito fuori uso.<\/p>\n Un secondo dato sottolinea quanto questi modelli possano essere persistenti: un ciclo anomalo ha generato 550 milioni di richieste in 30 giorni<\/strong>, un traffico tale da giustificare una regola di mitigazione dedicata nella nostra infrastruttura. Non si tratta di un attacco DDoS n\u00e9 di una campagna di malware, ma di un bot bloccato in un ciclo di scansione, che richiede ripetutamente URL che ha gi\u00e0 visto.<\/p>\n Questi non sono casi isolati. Sono modelli che osserviamo su tutta la nostra piattaforma.<\/p>\n Uno degli aspetti pi\u00f9 sottovalutati dell\u2019attuale problema del traffico dei bot \u00e8 che la maggior parte di ci\u00f2 che causa danni all\u2019infrastruttura non \u00e8 affatto malevolo. Si tratta di automazione inefficiente su larga scala.<\/p>\n I siti web moderni, specialmente i negozi di e-commerce, generano URL leggermente diversi per pagine sostanzialmente identiche:<\/p>\n Per un essere umano, queste sono tutte \u201cla stessa pagina\u201d. Per un bot che segue gli URL, ognuna sembra una pagina nuova da scansionare.<\/p>\n Quindi il bot segue il primo link. Quella pagina genera un\u2019altra variante dell\u2019URL, che il bot segue. Poi un\u2019altra. E poi un\u2019altra ancora. Non ha alcun meccanismo per rendersi conto che sta girando in tondo, e alcuni di questi loop sono rimasti inosservati sull\u2019infrastruttura monitorata per diversi giorni prima che le regole di mitigazione li intercettassero.<\/p>\n Nel report sul traffico AI e bot che abbiamo pubblicato di recente, David Belson<\/a>, ex responsabile di Data Insights presso Cloudflare, ha detto: \u00abC\u2019\u00e8 chi ieri non sapeva nemmeno cosa diavolo stesse facendo, ma oggi ha programmato un bot al volo e l\u2019ha lasciato libero. Non si prendono nemmeno la briga di controllare i file Questo comportamento non viene sempre da utenti malintenzionati. Proviene da sistemi di crawler AI che non sono stati progettati tenendo conto della navigazione sfaccettata, della proliferazione dei parametri URL o degli URL generati dalle sessioni, che sono caratteristiche standard dei moderni siti WordPress.<\/p>\n Google stesso identifica esplicitamente la navigazione per faccette<\/a> e gli URL basati su parametri come una fonte di inefficienza nella scansione, sottolineando che i bot possono esplorare variazioni quasi infinite della stessa pagina.<\/p>\n Fino a poco tempo fa, molti piani di hosting erano dimensionati in base al numero di visite, il che funzionava abbastanza bene come indicatore dell\u2019utilizzo reale da parte degli utenti umani. Si partiva dal presupposto che le visite fossero pi\u00f9 o meno correlate alle persone che interagivano con il sito.<\/p>\n Quel presupposto non regge pi\u00f9.<\/p>\n Il traffico automatizzato ha gonfiato il numero di visite in un modo che ha ben poco a che vedere con l\u2019effettiva attivit\u00e0 commerciale. Le richieste dei bot possono generare visite senza produrre il corrispondente coinvolgimento, conversioni o ricavi. I proprietari dei siti ricevevano avvisi di superamento del limite sui piani basati sulle visite, causati dall\u2019attivit\u00e0 dei bot che non potevano controllare e che non avevano invitato.<\/p>\n Questo fenomeno era talmente evidente come modello sistemico che Kinsta ha introdotto<\/a> piani di hosting basati sulla larghezza di banda<\/a> proprio in risposta a una categoria di siti le cui metriche sulle visite avevano iniziato a discostarsi in modo significativo dal loro effettivo consumo di risorse. Se le visite di un sito crescevano ma la larghezza di banda non riusciva a stare al passo, era quasi sempre un segnale della presenza di bot. Passare a un modello basato sulla larghezza di banda ha di fatto svincolato la fatturazione da una metrica che i bot avevano imparato a gonfiare.<\/p>\n Il problema della fatturazione \u00e8 misurabile e risolvibile. Il problema pi\u00f9 difficile \u00e8 che la maggior parte dei proprietari di siti non si rende conto che tutto questo sta accadendo perch\u00e9 le loro dashboard non mostrano il quadro completo.<\/p>\n Una conseguenza del traffico generato dai bot su questa scala \u00e8 che gli strumenti di analisi standard non sono pi\u00f9 affidabili nel descrivere le reali prestazioni del tuo sito.<\/p>\n Se il numero delle visite sta aumentando ma le entrate, il tempo trascorso sulla pagina e il tasso di rimbalzo non seguono lo stesso andamento, probabilmente i bot c\u2019entrano qualcosa. Se il tuo server mostra un calo delle prestazioni che non corrisponde ai picchi di traffico che ti aspetteresti da contenuti o attivit\u00e0 di marketing, vale la pena indagare sul traffico dei bot verso endpoint non memorizzati nella cache.<\/p>\n Kinsta filtra automaticamente gli user agent noti come bot dalle analisi e dai calcoli sull\u2019utilizzo del piano. Tuttavia, il traffico automatizzato che assomiglia molto al comportamento umano potrebbe comunque comparire nelle tue metriche.<\/p>\n Gli schemi da tenere d\u2019occhio:<\/p>\n Nessuno di questi fattori \u00e8 determinante di per s\u00e9, ma qualsiasi combinazione richiede un\u2019analisi approfondita prima di attribuire questi numeri alla crescita del business.<\/p>\n L\u2019istinto pi\u00f9 comune quando ci si trova di fronte ai dati sul traffico dei bot \u00e8 quello di bloccare tutto. Altri, invece, potrebbero consentire tutto il traffico, perch\u00e9 \u201cl\u2019AI \u00e8 il futuro\u201d.<\/p>\n Nessuna delle due soluzioni funziona!<\/p>\n Bloccare indiscriminatamente significa bloccare anche i crawler verificati, compreso Googlebot, la cui copertura di scansione determina se i tuoi contenuti compaiono o meno nei risultati di ricerca. Significa bloccare i bot di scoperta AI che potrebbero far emergere i tuoi contenuti nei risultati di ricerca conversazionale, nei consigli AI o nei motori di risposta. Per un negozio WooCommerce<\/a> o un editore di contenuti, si tratta di un costo di distribuzione significativo.<\/p>\n Lasciare passare tutto significa accettare costi di infrastruttura che non generano alcun ritorno. E per gli endpoint dinamici che i bot tendono a colpire con maggiore intensit\u00e0, quei costi non sono marginali. Si accumulano e si aggravano, specialmente sotto un carico automatizzato prolungato.<\/p>\n La risposta giusta sta da qualche parte nel mezzo, e richiede di capire le differenze tra le categorie di traffico invece di trattare tutti i bot come un\u2019unica classe.<\/p>\n Come ha spiegato Cristian Lopez, caporedattore di HostingAdvice, nel rapporto<\/a>: \u00abL\u2019errore \u00e8 pensare che il traffico dei bot sia un semplice problema di \u201cbloccare o consentire\u201d. In realt\u00e0, si tratta di politica, visibilit\u00e0 e controllo economico\u00bb.<\/p>\n I bot verificati, tra cui Googlebot, Bing e gli strumenti di monitoraggio legittimi, dovrebbero generalmente essere consentiti, con eventuali restrizioni di percorso sugli endpoint che non hanno alcun valore di scansione (la pagina di checkout non contribuisce in alcun modo al tuo posizionamento nei risultati di ricerca). I bot non verificati, privi di informazioni identificative o di uno scopo preciso, meritano un esame pi\u00f9 approfondito. I crawler di addestramento dell\u2019AI<\/a> che generano elevati volumi di richieste verso endpoint dinamici rappresentano una categoria specifica che potrebbe richiedere il blocco o la limitazione della frequenza, a seconda del tipo di sito e delle tue priorit\u00e0.<\/p>\n Nel nostro rapporto sul traffico generato da AI e bot<\/a>, abbiamo creato un modello decisionale interattivo che illustra l\u2019approccio corretto per diversi tipi di siti. L\u2019esempio qui sotto mostra la configurazione consigliata per un negozio WooCommerce incentrata sulle prestazioni e sulla stabilit\u00e0 del sito:<\/p>\n Questo tipo di controllo sfumato e sensibile alle categorie \u00e8 esattamente ci\u00f2 che la maggior parte degli strumenti esistenti non ti offre.<\/p>\n Quello che abbiamo realizzato con Protezione bot di Kinsta<\/a> \u00e8 stato progettato specificamente per affrontare le sfide infrastrutturali descritte sopra.<\/p>\n Il sistema classifica il traffico<\/a> in categorie quali bot verificati, probabili utenti umani, probabili bot, traffico automatizzato e traffico dannoso, e permette di impostare livelli di protezione che corrispondono alle reali esigenze del sito.<\/p>\n I livelli non sono binari. “Blocca le automazioni” prende di mira il traffico automatizzato confermato, lasciando inalterati i bot verificati. “Verifica bot” aggiunge una fase di verifica per le automazioni non verificate senza disturbare i visitatori legittimi. “Verifica tutti” \u00e8 disponibile per i periodi di picco di traffico, ma comporta i compromessi che ti aspetteresti.<\/p>\n Fondamentalmente, lo strumento si basa sul sistema di valutazione dei bot di livello enterprise di Cloudflare, una classificazione in tempo reale basata sull\u2019apprendimento automatico che assegna a ogni visitatore un punteggio da 1 a 99 in base a segnali comportamentali, non solo alle stringhe dell\u2019user-agent. Questo \u00e8 importante perch\u00e9 il solo confronto dell\u2019user-agent sta diventando sempre meno efficace, dato che il 12,9% dei bot basati sull\u2019intelligenza artificiale ora ignora le direttive C\u2019\u00e8 anche un sistema di eccezioni “Consenti sempre<\/a>” per integrazioni affidabili, servizi di monitoraggio e automazioni fondamentali per l\u2019attivit\u00e0 che non dovrebbero essere bloccate dalle regole di protezione, perch\u00e9 anche il blocco eccessivo comporta un costo reale, in particolare per i negozi WooCommerce che si affidano alla sincronizzazione automatica degli ordini, alle integrazioni con i gateway di pagamento o ai monitor di uptime.<\/p>\n L’opzione di blocco dei crawler AI<\/a> prende di mira specificatamente i bot di addestramento dell\u2019AI senza influire sui crawler dei motori di ricerca come Googlebot o Bingbot. Per i siti che hanno identificato l\u2019attivit\u00e0 dei crawler AI come fattore di miglioramento delle prestazioni, questa \u00e8 una misura di mitigazione in un solo passaggio che non richiede la configurazione di regole individuali.<\/p>\n Sapere che lo strumento esiste \u00e8 una cosa. Sapere quando e come usarlo \u00e8 un\u2019altra.<\/p>\n Se noti gli schemi descritti sopra, ecco un punto di partenza pratico, ordinato in base all\u2019impatto:<\/p>\n Primo: verifica la fonte.<\/strong> Usa il grafico di ripartizione delle richieste<\/a> nella scheda Protezione dai bot di MyKinsta per capire come viene classificato il traffico verso il tuo sito.<\/p>\n Se una parte consistente \u00e8 automatizzata o non verificata, \u00e8 il segnale che devi agire. Non saltare questo passaggio, perch\u00e9 apportare modifiche alla protezione senza sapere da cosa ti stai proteggendo porta a configurazioni errate.<\/p>\n Secondo: adatta il livello di protezione al tipo di sito.<\/strong> Un negozio WooCommerce ha priorit\u00e0 diverse rispetto a un sito di pubblicazione di contenuti, che a sua volta ha priorit\u00e0 diverse rispetto a un ambiente di staging. Bloccare il traffico automatizzato e mettere alla prova i potenziali bot ha senso per un negozio con endpoint dinamici. Un sito di contenuti potrebbe dare priorit\u00e0 all\u2019accesso ai bot di discovery AI, bloccando al contempo i crawler di addestramento dell\u2019AI. Un ambiente di staging dovrebbe comunque essere completamente bloccato.<\/p>\n Terzo: proteggi prima i percorsi pi\u00f9 costosi.<\/strong> Prima di applicare regole di protezione generiche, valuta se i tuoi endpoint pi\u00f9 costosi, come il carrello, il checkout e gli handler AJAX, siano accessibili a crawler che non hanno motivo di trovarsi l\u00ec. Bloccare gli user agent noti dei bot provenienti da Quarto: monitora, poi modifica.<\/strong> I modelli di traffico dei bot cambiano pi\u00f9 velocemente di quanto la maggior parte dei proprietari di siti si renda conto. La quota di traffico di GPTBot \u00e8 triplicata nel giro di un solo anno. Impostare le regole di protezione una volta sola e poi smettere di pensarci non \u00e8 una strategia. Il grafico dei risultati della protezione bot<\/a> in MyKinsta tiene traccia di ci\u00f2 che viene bloccato, verificato e consentito nel tempo.<\/p>\n Questi dati dovrebbero guidarti nell\u2019ottimizzazione delle tue impostazioni.<\/p>\n Se i bot stanno generando un superamento del limite di visite su un piano basato sulle visite, potrebbe valere la pena valutare parallelamente i piani di hosting basati sulla larghezza di banda<\/a> di Kinsta. Passare a un piano basato sulla larghezza di banda non risolve il problema di fondo dei bot, ma pu\u00f2 riflettere meglio il costo effettivo dell\u2019infrastruttura per il tuo mix di traffico, che spesso \u00e8 notevolmente inferiore a quanto suggerisce il conteggio delle visite.<\/p>\n Il traffico agentico sta gi\u00e0 comparendo nei log dell\u2019infrastruttura. Google ha annunciato uno user agent dedicato<\/a> per quando i suoi agenti AI interagiscono con i siti. Si tratta di sistemi automatizzati che cliccano sui link, compilano moduli ed effettuano richieste che assomigliano sempre di pi\u00f9 al comportamento delle sessioni umane.<\/p>\n I segnali che attualmente funzionano per la classificazione dei bot, come le stringhe degli user agent, la frequenza delle richieste e il punteggio comportamentale, diventano pi\u00f9 difficili da applicare in modo preciso man mano che il confine tra interazione automatizzata e umana continua a sfumarsi.<\/p>\nCosa significa \u201clavoro vero e proprio\u201d per un sito WordPress<\/h2>\n
\n
?add-to-cart=<\/code>, \/cart<\/code>, \/checkout<\/code>)<\/li>\n\n
![\"Come](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/how-bot-talk-to-server.png\")
Cosa mostrano effettivamente i dati sull\u2019infrastruttura di Kinsta<\/h2>\n
![\"7,67](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bots-hit-add-to-cart-url.png\")
Il problema del loop: i bot non stanno attaccando, sono bloccati<\/h2>\n
\n
![\"I](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-causing-loop-problem.png\")
robots.txt<\/code>\u00bb.<\/p>\nLa fattura del server \u00e8 ormai un problema di gestione dei bot<\/h2>\n
![\"Piani](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/kinsta-bandwidth-hosting-plans.png\")
Cosa ti dicono (e cosa no) i tuoi dati di analisi<\/h2>\n
\n
Perch\u00e9 \u00e8 un problema pi\u00f9 complesso di quanto sembri<\/h2>\n
![\"Quadro](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/ai-bot-traffic-report-decision-framework.png\")
L\u2019approccio di Kinsta alla protezione dai bot<\/h2>\n
![\"Livelli](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-levels-mykinsta.png\")
robots.txt<\/code>, in aumento rispetto al 3,3% di appena un trimestre fa. La classificazione comportamentale rileva ci\u00f2 che le regole basate sull\u2019user-agent non riescono a individuare.<\/p>\n![\"Protezione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/always-allow-exception-bot-protection-mykinsta.png\")
![\"Bloccare](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/mykinsta-bot-protection-ai-crawlers.png\")
Cosa fare se il traffico bot diventa un problema<\/h2>\n
![\"Grafico](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-request-breakdown-mykinsta.png\")
\/cart<\/code> e ?add-to-cart=<\/code> tramite robots.txt<\/code> \u00e8 un punto di partenza; applicarlo a livello di WAF (non solo segnalarlo) \u00e8 ci\u00f2 che impedisce effettivamente il sovraccarico.<\/p>\n![\"Grafico](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-results.png\")
Il quadro generale: questo problema diventer\u00e0 pi\u00f9 complesso<\/h2>\n