Di conseguenza, i costi di gestione aumentano, ma i problemi di prestazioni rimangono gli stessi. Lo strumento Protezione Bot di Kinsta<\/a> \u00e8 pensato proprio per questo tipo di situazione, poich\u00e9 ti permette di controllare ci\u00f2 che raggiunge il tuo server, invece di ampliare la superficie che lo assorbe.<\/p>\n Un visitatore umano che si imbatte in una pagina lenta potrebbe aspettare, ricaricarla o semplicemente andarsene. Al contrario, un bot continua a inviare lo stesso volume di richieste indipendentemente da come risponde il server. Questo problema fondamentale, ovvero che il traffico dei bot non \u00e8 in grado di autoregolarsi quando aggiungi risorse, significa che l\u2019aggiornamento del piano offre ai bot pi\u00f9 capacit\u00e0 da consumare.<\/p>\n La questione si complica se si considera come i moderni siti WordPress gestiscono le richieste. La maggior parte del traffico dei bot non arriva su pagine statiche che la cache pu\u00f2 assorbire. Al contrario, colpisce endpoint che aggirano i sistemi di caching e costringono il server a lavorare di pi\u00f9. Su qualsiasi sito che utilizza WooCommerce, la funzione di ricerca o i filtri, ci\u00f2 significa che i bot colpiscono diversi elementi:<\/p>\n Nessuna di queste \u00e8 memorizzabile nella cache come lo \u00e8 una pagina statica. Per ogni richiesta che arriva su uno di questi endpoint, ci sono alcune cose che succedono sul lato server:<\/p>\n Dai dati della nostra infrastruttura<\/a>, un singolo bot \u00e8 riuscito a generare 3,75 milioni di richieste verso gli URL “aggiungi al carrello” in un periodo di 24 ore. Ci\u00f2 equivale all\u2019incirca a una richiesta ogni 23 millisecondi, 24 ore su 24. Inoltre, una singola regola di rilevamento dei loop ha filtrato 550 milioni di richieste su tutta la piattaforma in un periodo di 30 giorni.<\/p>\n Tuttavia, questi non sono volumi di attacchi nel senso tradizionale del termine. Sono il risultato di bot progettati per seguire ogni URL che trovano, comprese alcune variazioni delle stringhe di query e percorsi basati su parametri.<\/p>\n \u00abDal punto di vista dell\u2019infrastruttura, non esiste una cosa come il “semplice traffico dei bot”. Ogni richiesta \u00e8 un carico di lavoro reale. Su larga scala, il crawling inefficiente smette di essere un problema di traffico e diventa un problema di risorse.\u00bb \u2013 Daniel Pataki, CTO, Kinsta<\/em><\/p>\n Un modello comune per le agenzie segue un ciclo: una volta che l\u2019utilizzo delle risorse aumenta, i clienti passano a un piano superiore, poi l\u2019utilizzo delle risorse aumenta di nuovo. Nel frattempo, le prestazioni non migliorano perch\u00e9 il volume di richieste sottostante non \u00e8 cambiato.<\/p>\n Dato che la fatturazione di Kinsta esclude il traffico bot<\/a> dall\u2019utilizzo del piano, hai un modo veloce per capire se i bot sono un problema. Gli user agent dei bot riconosciuti vengono gi\u00e0 filtrati dalla schermata Visite <\/strong>nella sezione Statistiche<\/strong>\u00a0di MyKinsta. Se queste statistiche sembrano normali mentre il tuo server \u00e8 sotto pressione, il traffico automatizzato \u00e8 probabilmente la causa.<\/p>\n La sezione Bot e traffico automatizzato<\/strong> in MyKinsta offre una ripartizione pi\u00f9 chiara del traffico che raggiunge il sito, inclusi bot verificati, probabili bot, crawler AI, crawler aggressivi, traffico automatizzato e probabili utenti umani.<\/p>\n Questo rende pi\u00f9 facile capire quando \u00e8 il traffico automatizzato a far aumentare l\u2019utilizzo delle risorse. Ad esempio, i picchi di crawler aggressivi o di traffico automatizzato spesso indicano che i bot stanno colpendo ripetutamente endpoint non memorizzati nella cache.<\/p>\n Il grafico dei risultati della protezione bot mostra anche come vengono gestite le richieste dopo la classificazione, compreso il traffico che \u00e8 stato consentito, verificato o bloccato. Ci\u00f2 offre un quadro pi\u00f9 chiaro di come le attuali impostazioni di protezione influenzano il traffico in entrata.<\/p>\n Il report Richieste principali per visualizzazioni<\/strong> riflette anche ci\u00f2 che sta generando carico sul server e include tutto il traffico, non solo le visite fatturabili. La differenza tra questi due valori \u00e8 proprio dove si accumulano i tuoi costi senza una spiegazione chiara.<\/p>\n Ecco come interpretare questa differenza:<\/p>\n Se gestisci portafogli di clienti, ogni sito colpito dal carico generato dai bot rappresenta un costo difficile da giustificare, specialmente quando le prestazioni non migliorano dopo un aggiornamento. Il traffico dei bot AI \u00e8 cresciuto del 300%<\/a> nell\u2019ultimo anno, mentre una visita web su 31 \u00e8 effettuata da un bot basato AI<\/a>. Non si tratta di un volume che si risolve da solo.<\/p>\n La sicurezza a livello di piattaforma di Kinsta blocca gi\u00e0 il traffico in entrata classificato come dannoso prima che raggiunga il tuo sito, il che include la mitigazione degli attacchi DDoS<\/a> e le richieste provenienti da IP associati a fonti di attacco note. Tra questo traffico e quello che ti interessa c\u2019\u00e8 una categoria di richieste automatizzate non verificate, ad alto volume e che consumano molte risorse, che comunque raggiungono il tuo server. I controlli di Protezione bot di Kinsta aiutano a ridurre quel volume.<\/p>\n I controlli di protezione dai bot in MyKinsta operano a livello di infrastruttura e il filtraggio avviene prima ancora che WordPress entri in gioco. Di conseguenza, non c\u2019\u00e8 nessun plugin da installare n\u00e9 alcuna configurazione di WordPress da modificare.<\/p>\n Kinsta classifica ogni richiesta utilizzando una combinazione della propria analisi del traffico e del sistema di machine learning di Cloudflare<\/a>, che assegna a ogni visitatore un punteggio bot compreso tra 1 e 99. I punteggi alti indicano che la richiesta proviene molto probabilmente da un essere umano; i punteggi bassi indicano che si tratta di attivit\u00e0 automatizzata.<\/p>\n Il traffico viene raggruppato in categorie quali bot verificati, probabili bot, crawler AI, crawler aggressivi, traffico automatizzato e probabili utenti umani. Il livello di protezione che scegli determina come viene gestita ciascuna categoria.<\/p>\n Puoi gestire la Protezione dai bot all\u2019interno di MyKinsta alla voce Siti<\/strong> > nome del sito<\/strong> > Protezione dai bot<\/strong>.<\/p>\n Ci sono quattro livelli tra cui scegliere nel pannello Livello di protezione<\/strong> della schermata Protezione bot<\/strong>:<\/p>\n Per cambiare il livello, vai su Siti<\/strong>\u00a0> Tuttavia, quando si passa a Verifica bot<\/strong>\u00a0o a un livello superiore, qualsiasi strumento che si connetta al tuo sito in modo programmatico e non sia presente nella directory dei bot verificati di Cloudflare<\/a> verr\u00e0 bloccato o sottoposto a verifica. Questo include integrazioni personalizzate, script di distribuzione e monitor di uptime self-hosted. Se utilizzi uno di questi strumenti, ti conviene verificare che compaiano nell\u2019elenco prima di aumentare il livello di protezione.<\/p>\n L’opzione Blocca crawler AI<\/strong>\u00a0prende di mira specificatamente i crawler basati sull\u2019intelligenza artificiale<\/a>. Si tratta di bot che raccolgono contenuti per l\u2019addestramento dei modelli, la generazione potenziata dal recupero e le funzionalit\u00e0 di ricerca basate sull\u2019intelligenza artificiale. Ci\u00f2 non influisce sui crawler dei motori di ricerca, ma include crawler dedicati come GPTBot. Googlebot e Bingbot continuano a indicizzare il tuo sito indipendentemente dal fatto che l\u2019interruttore sia attivo o disattivo.<\/p>\n In generale, l\u201980% di tutta l\u2019attivit\u00e0 di crawling dell\u2019IA \u00e8 finalizzata all\u2019addestramento dei modelli piuttosto che a query innescate dagli utenti. Questo non genera traffico di provenienza verso il tuo sito. Pertanto, attivare questa opzione \u00e8 una buona idea. Per attivarla, vai su Siti<\/strong> > Tuttavia, il compromesso \u00e8 una minore visibilit\u00e0 nelle panoramiche e nei riassunti dei contenuti generati dall\u2019AI. Se questa visibilit\u00e0 \u00e8 importante per la tua strategia di contenuti, vale la pena monitorare l\u2019impatto prima di lasciare l’opzione attiva in modo permanente.<\/p>\n Se la tua priorit\u00e0 \u00e8 gestire il carico del server, \u00e8 un\u2019opzione pi\u00f9 semplice rispetto alla modifica del file robots.txt<\/a> o alla creazione di regole specifiche per ogni bot. A differenza di questi approcci, agisce a livello di infrastruttura prima ancora che una richiesta raggiunga WordPress.<\/p>\n Siti diversi richiedono livelli di protezione variabili, quindi un negozio WooCommerce<\/a> con pagine di prodotti filtrate non sar\u00e0 uguale a una piattaforma di contenuti. Inoltre, ogni sito nel portafoglio clienti presenta un profilo di traffico diverso, un insieme di integrazioni e una tolleranza diversa per le fasi di verifica. Questo significa che applicare un\u2019unica politica a tutto il portafoglio finir\u00e0 per limitare troppo alcuni siti o lasciarne altri poco protetti.<\/p>\n Quando noti i segnali che indicano che il traffico dei bot sta facendo lievitare i costi sul sito di un cliente, ecco un flusso di lavoro pratico:<\/p>\n Per le agenzie che gestiscono ampi portafogli su hosting WordPress<\/a>, questo rende l\u2019operazione un\u2019attivit\u00e0 di routine piuttosto che un progetto. Quando le impostazioni di protezione corrispondono al profilo di traffico effettivo di ciascun sito, l\u2019utilizzo delle risorse pu\u00f2 riflettere l\u2019attivit\u00e0 reale degli utenti. Le metriche sulle prestazioni corrispondono a ci\u00f2 che vivono i visitatori reali: La spiegazione che dai a un cliente sui costi dovrebbe riferirsi alle decisioni che hai preso riguardo al suo traffico, non alla capacit\u00e0 che hai aggiunto in risposta a un carico che non riesci a identificare.<\/p>\n Scalare la tua infrastruttura aumenta la quantit\u00e0 di carico che il tuo server pu\u00f2 assorbire. Protezione bot riduce invece la quantit\u00e0 di carico che lo raggiunge. Non si tratta di risposte equivalenti allo stesso problema: una aggiunge capacit\u00e0, mentre l\u2019altra rimuove la pressione che, in primo luogo, faceva sembrare necessaria una maggiore capacit\u00e0.<\/p>\nPerch\u00e9 i bot non si comportano come il traffico reale<\/h2>\n
\n
?add-to-cart=<\/code>.<\/li>\n\n
Quanto costa il traffico bot<\/h2>\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/kinsta-analytics.png\")
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-results.png\")
\n
sitename<\/code> > Statistiche<\/strong> > Utilizzo del piano<\/strong>. Se le visite sembrano normali, non si tratta di un vero e proprio picco di traffico umano.<\/li>\nCome funziona Protezione bot di Kinsta<\/h2>\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/protection-level.png\")
Scegliere un livello di protezione<\/h3>\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/change-level.png\")
\n
sitename<\/code> > Protezione dai bot<\/strong> e clicca su Modifica<\/strong>. Tramite Siti<\/strong> puoi selezionare i siti interessati e utilizzare Azioni<\/strong> > Modifica protezione bot<\/strong>.<\/p>\nBlocco dei crawler AI<\/h3>\n
sitename<\/code> > Protezione dai bot<\/strong> e clicca sul cursore accanto a Blocca crawler AI<\/strong>. Se hai pi\u00f9 siti, usa Azioni<\/strong> > Modifica blocco crawler AI<\/strong> dalla vista Siti<\/strong>.<\/p>\n![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/block-crawler.png\")
Gestire la protezione in un portafoglio clienti<\/h2>\n
\n
\n
\n\u00abL\u2019errore comune \u00e8 pensare che il traffico dei bot sia un semplice problema di \u201cbloccare o consentire\u201d l’accesso al traffico. In realt\u00e0, si tratta di politica, visibilit\u00e0 e controllo economico.\u00bb \u2013 Cristian Lopez, caporedattore, HostingAdvice<\/em><\/p>\nSmetti di scalare per aggirare un problema che puoi controllare<\/h2>\n