Il traffico bot viene spesso inquadrato come un problema di sicurezza o di SEO. Ma sull’infrastruttura di hosting WordPress, si manifesta come un problema di prestazioni, in particolare concentrato in un insieme molto particolare di URL.
Non tutte le richieste hanno lo stesso costo. La differenza tra una pagina statica in cache e un endpoint dinamico non è una piccola sfumatura di prestazioni. È la differenza tra una richiesta che non costa quasi nulla e una che riserva un thread PHP, attiva un’intera query di database e genera overhead di sessione, indipendentemente dal fatto che il visitatore sia un cliente reale o un bot che non converte mai.
Capire perché alcuni endpoint sono molto più costosi di altri è ciò che separa una strategia di gestione dei bot che funziona davvero da una che blocca troppo o troppo poco.
Non tutte le richieste sono uguali
Quando un visitatore arriva su una tipica pagina di WordPress, come un post del blog, un elenco di prodotti o una pagina “about”, il server serve quasi sempre la risposta dalla cache.
La cache a pagina intera di Kinsta gestisce questo aspetto ai margini, in modo tale che la richiesta non attivi mai il PHP del server o il suo database.
Ma quando una richiesta arriva su un endpoint non memorizzabile nella cache, il server deve fare del lavoro vero e proprio. Un thread PHP viene allocato e mantenuto per tutta la durata della richiesta e il database viene interrogato. Se la pagina coinvolge lo stato del carrello, le sessioni dell’utente o contenuti personalizzati, la gestione delle sessioni aggiunge un ulteriore livello. Niente di tutto questo può essere messo in cache, perché la risposta è unica per ogni richiesta.
In un sito sano con visitatori prevalentemente umani, questo va bene. Gli endpoint dinamici servono clienti reali che aggiungono articoli al carrello, effettuano il check-out e cercano prodotti. Il carico è proporzionale all’utilizzo effettivo.
Il traffico bot rompe questo modello. Un crawler non aggiunge al carrello né converte, ma attiva la stessa esecuzione sul lato server che farebbe un cliente reale, a una velocità che nessun essere umano potrebbe mantenere.
Gli endpoint specifici su cui questo si ripercuote
Su un negozio WooCommerce, i seguenti schemi di URL ed endpoint non sono memorizzabili nella cache per scelta del cliente e sono proprio quelli che il traffico bot tende a colpire di più.
?add-to-cart=
Questo è l’esempio più dispendioso in termini di risorse che abbiamo documentato nel nostro rapporto su traffico AI e bot. L’aggiunta di un prodotto al carrello richiede l’esecuzione di PHP, la scrittura di un database e la creazione o la convalida di una sessione. Non esiste una versione in cache di questa risposta, in quanto ogni hit è un lavoro nuovo.
Per contestualizzare: i dati dell’infrastruttura di Kinsta una volta hanno registrato 7,67 milioni di hit al carrello da parte di cinque bot in un periodo di 24 ore.
Si tratta di circa una richiesta ogni 11 millisecondi, per tutto il giorno e tutta la notte, ognuna delle quali richiede l’esecuzione completa di PHP e database, ognuna delle quali non genera alcun risultato significativo per il crawler e nessuna serve a un cliente.
/cart e /checkout
Queste pagine sono escluse dalla cache per impostazione predefinita in WooCommerce. Contengono i dati della sessione, lo stato del carrello personalizzato e (nel caso del checkout) la logica di elaborazione del pagamento.
Un bot che colpisce ripetutamente /checkout non sta facendo nulla di utile, ma il server non lo sa. Elabora ogni richiesta come se si trattasse di una vera transazione.
?s= (Search queries)
Le query di ricerca di WordPress e WooCommerce vengono eseguite sul database ad ogni richiesta. Non esiste un livello di cache che possa assorbire una stringa di ricerca unica.
Un crawler che lavora attraverso variazioni di URL parametrizzate o che segue semplicemente ogni link di ricerca che trova può generare una lunga coda di query al database uniche e costose.
Navigazione sfaccettata e parametri di filtro
È qui che il problema si aggrava. Un tipico catalogo di prodotti WooCommerce genera URL come:
/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2Per un essere umano, queste sono variazioni minori della stessa pagina. Per un bot che segue i link, ognuna di esse è un URL unico che vale la pena di essere crawlato e ognuna richiede al server di eseguire una query di database filtrata da zero.
La documentazione di Google identifica esplicitamente la navigazione sfaccettata come una fonte di inefficienza di crawling, in cui i crawler esplorano variazioni quasi infinite dello stesso contenuto. Ma il problema non è solo lo spreco di budget per il crawling. Ogni variazione costa risorse reali del server per essere generata.
Interazioni con AJAX
Molti plugin di WordPress, come le liste dei desideri, i controlli di disponibilità, gli aggiornamenti dei prezzi in tempo reale e le visualizzazioni del calendario, si basano su richieste AJAX che aggirano completamente la cache della pagina.
Un bot che attiva queste interazioni, anche indirettamente caricando una pagina che le attiva, crea un carico sul lato server che non viene visualizzato come “richiesta di pagina” nei dati analitici, ma viene visualizzato nell’utilizzo dei thread PHP.
Cosa succede quando i thread PHP si esauriscono
Ogni hit di un endpoint dinamico mantiene un thread PHP per l’intera durata della richiesta. Questo dettaglio sembra di poco conto, ma la capacità dei thread è limitata e i bot non si mettono in coda in modo educato.
Kinsta assegna un numero fisso di thread PHP per ogni sito WordPress e ogni richiesta non memorizzata nella cache ne riserva uno per tutta la sua durata.
In condizioni di traffico normale, questo è raramente un limite. Le richieste arrivano, vengono elaborate rapidamente e i thread si liberano.
In caso di carico sostenuto da parte dei bot su endpoint dinamici, i thread vengono riservati e trattenuti. Quando tutti i thread sono occupati, le nuove richieste in arrivo attendono in coda. I clienti reali che cercano di aggiungere un prodotto al carrello o di completare il pagamento sperimentano un caricamento lento della pagina, timeout o errori 504 HTTP.
Questa è la realtà infrastrutturale che rende il traffico bot su endpoint dinamici materialmente diverso dal traffico bot su pagine memorizzabili nella cache.
Il problema del loop: quando i bot si bloccano
La maggior parte del traffico bot che il team dell’infrastruttura di Kinsta vede non è il risultato di un attacco intenzionale. È il risultato di crawler che seguono tutti i link di ogni pagina senza alcun meccanismo per riconoscere quando stanno girando in tondo.
Ecco come si presenta in pratica un ciclo query-string:
- Un bot arriva a
/shop/ - La pagina contiene un link a
/shop/?color=blue(una vista filtrata) - La pagina contiene un link a
/shop/?color=blue&size=M - La pagina contiene un link a
/shop/?color=blue&size=M&orderby=price - Questa pagina contiene un link per aggiungere qualcosa al carrello:
/shop/?add-to-cart=123 - Ognuno di questi link genera collegamenti leggermente diversi che il bot non ha ancora visitato
Il bot segue tutti. Non ha il concetto di “ho già visto questa pagina di prodotto in uno stato di filtro diverso”. Ogni URL sembra nuovo, viene richiesto e arriva al server fresco.
Questo schema esatto di bot che attraversano le variazioni delle stringhe di query attraverso endpoint dinamici è uno dei problemi più comuni che abbiamo rilevato nel nostro report. Una singola regola di loop attivata da uno schema scorretto ha filtrato 550 milioni di richieste in 30 giorni sull’infrastruttura di Kinsta. Non si tratta di un attacco, ma di un’automazione inefficiente su scala, che si aggrava perché non è stata colta in anticipo.
Come si presenta una buona gestione dei bot a livello di endpoint
Per i negozi WooCommerce e i siti WordPress con funzionalità dinamiche, sono validi alcuni principi, indipendentemente dalla tua configurazione specifica.
- Il file Robots.txt è un segnale, non uno scudo. Puoi (e dovresti) disabilitare i crawler dai percorsi
/cart,/checkoute?add-to-cart=nel tuorobots.txt. Googlebot lo rispetta. Tuttavia, l’adesione alle linee guida delrobots.txtè volontaria. Una quota crescente di crawler di training AI non lo controlla o non lo rispetta. Disabilitare un percorso nelrobots.txtcomunica la tua intenzione; per farlo rispettare è necessaria una regola a livello di WAF. - Rafforzare la generazione dei parametri URL. La configurazione predefinita di WooCommerce genera una lunga serie di varianti di URL attraverso token di sessione, parametri di quantità e combinazioni di filtri. Riducendo lo sprawl dei parametri alla fonte attraverso tag canonici, strutture di permalink consolidate e regole di
Disallowrobots.txt sulle varianti dei parametri, i crawler avranno meno loop in cui rimanere bloccati. - Monitora il livello dell’endpoint, non solo il volume totale delle richieste. Un picco di traffico complessivo potrebbe essere una campagna. Un picco di richieste a
?add-to-cart=da uno user agent non browser è un problema di bot. I log del server e gli strumenti di analisi che mostrano la distribuzione delle richieste in base allo schema di URL e allo user agent fanno la differenza tra l’individuare il problema in poche ore o in pochi giorni. - Proteggi la capacità dei thread PHP come parametro principale. Se i thread PHP funzionano regolarmente a pieno regime e non c’è un corrispondente picco di sessioni di utenti reali, il traffico bot sugli endpoint dinamici è quasi certamente un fattore che contribuisce. Lo strumento APM di Kinsta mostra le transazioni PHP più lente per endpoint, così se i percorsi del carrello o del checkout sono i colpevoli, potrai vederlo direttamente invece di tirare a indovinare.
Come si presenta la situazione per diversi tipi di sito
Il problema degli endpoint dinamici è più grave per i negozi WooCommerce, ma si presenta in diversi tipi di sito in varie forme.
- I negozi WooCommerce corrono il rischio maggiore perché i loro endpoint più costosi, come il carrello, il checkout e le pagine dei prodotti filtrati, sono esattamente quelli che i bot tendono a trovare attraverso il normale link-following. Le conseguenze sono dirette: L’esaurimento dei thread PHP durante i picchi di traffico dei bot riduce le prestazioni del checkout per i clienti reali.
- I siti di contenuti e i blog sono meno esposti dal punto di vista del checkout, ma possono essere influenzati in modo significativo dai bot che attraversano archivi paginati, pagine di tag e risultati di ricerca. Ogni singola query di ricerca è una nuova visita al database. Un crawler aggressivo che lavora sistematicamente su un archivio di grandi dimensioni può generare un carico sostenuto sul database anche senza toccare alcuna funzionalità del “negozio”.
- I siti aziendali e di servizi sono più esposti agli endpoint dei moduli (moduli di contatto, moduli di richiesta di preventivo e flussi di prenotazione), che comportano la gestione di sessioni e spesso la scrittura sul database. I dati dei moduli inviati dai bot rappresentano un altro tipo di problema (contaminazione del CRM, spreco di risorse per le vendite), ma il meccanismo di fondo è lo stesso: endpoint dinamici che costano risorse reali a ogni accesso.
- Le applicazioni web e i prodotti SaaS sono il caso più delicato. I loro endpoint API, le route della dashboard e la logica dell’applicazione sono interamente non memorizzabili nella cache e il traffico dei bot che raggiunge il livello dell’applicazione bypassa completamente l’infrastruttura di caching. La risposta appropriata in questo caso è di solito un blocco rigido di tutto il traffico non autenticato verso i percorsi
/apie/app, con una lista di permessi esplicita per le integrazioni legittime.
Approfondimento: il quadro completo del traffico bot
Il problema degli endpoint dinamici è una parte di un cambiamento più ampio nel modo in cui il traffico bot influisce sull’infrastruttura di WordPress. I crawler AI sono cresciuti in modo significativo in termini di volume e sono cambiati nel comportamento, con un link-following più aggressivo, una maggiore disponibilità a ignorare le direttive di crawl e un traffico più intenso che colpisce proprio gli endpoint che costano di più da servire.
Per uno sguardo completo a ciò che è cambiato, dei dati alla base di tali cambiamenti e a un quadro di riferimento per prendere decisioni sulla gestione dei bot in base al tipo di sito e alle priorità specifiche, il rapporto completo di Kinsta “Tutta la verità sul traffico AI & Bot” copre tutto questo, compresa l’analisi di oltre 10 miliardi di richieste sull’infrastruttura gestita da Kinsta.
Se credi sia arrivato anche per te il momento di agire sulla base di ciò che hai letto qui, la Protezione Bot di Kinsta gestisce automaticamente gli schemi più comuni, compresa la protezione degli endpoint dinamici ad alto costo. Attiva il livello di protezione che desideri una volta in MyKinsta e il sistema si occuperà di tutto il resto.
Puoi anche contattare il team di supporto se hai bisogno di chiarimenti.
