I bot WordPress richiedono una risposta misurata, non un divieto generalizzato
I WordPress bots sono ormai un problema operativo di routine per i proprietari di siti, e Kinsta afferma che la sua analisi di oltre 10 miliardi di richieste in un anno conferma perché richiedano una gestione attiva. L’azienda inquadra il problema in un più ampio aumento del traffico automatizzato, compreso un incremento segnalato del 300% del traffico bot guidato dall’AI. Per editori, negozi e agenzie che usano WordPress, il punto pratico è chiaro: non tutte le richieste automatizzate sono dannose, ma il traffico bot non gestito può comunque consumare risorse di hosting, rallentare le pagine e disturbare i visitatori reali.
Un bot è un software che visita automaticamente un sito web invece di navigarlo come farebbe una persona cliccando tra le pagine. Alcuni bot sono utili. I crawler di ricerca aiutano i motori di ricerca a trovare e indicizzare le pagine, gli strumenti di monitoraggio controllano se un sito funziona e alcuni crawler AI possono supportare la visibilità o le citazioni nelle risposte generate dall’AI. Altri bot possono copiare contenuti, sondare le pagine di login, colpire pagine dinamiche costose o generare grandi numeri di richieste senza offrire alcun beneficio chiaro. La raccomandazione centrale di Kinsta non è bloccare tutto, ma valutare il traffico, stabilizzare il sito se necessario, decidere cosa consentire, sottoporre a verifica o bloccare, quindi monitorare e documentare il risultato.
Il primo passo è capire se il sito sta affrontando un normale problema di gestione dei bot o un incidente acuto. Kinsta consiglia di verificare se i caricamenti delle pagine sono rallentati, se gli errori sono aumentati, se l’uso di server, PHP o database è cresciuto, se i picchi di traffico non corrispondono alle metriche dei visitatori reali o se molte richieste arrivano sugli stessi URL. PHP è il linguaggio di programmazione che WordPress usa per costruire molte pagine, e un database è l’archivio in cui WordPress conserva post, impostazioni, utenti e dati degli ordini. Se questi sistemi vengono sovraccaricati, i visitatori legittimi possono trovarsi a competere con il traffico automatizzato per le stesse risorse.
Kinsta descrive le proprie analisi dei bot come una suddivisione delle richieste in categorie che includono probabili esseri umani, bot verificati come verificati da Cloudflare, probabili bot, crawler AI, crawler AI a frequenza eccessiva, traffico non classificato, traffico automatizzato, traffico malevolo, regole personalizzate configurate per un sito da Kinsta e automazioni WP. La sua dashboard può anche mostrare i percorsi principali, gli user agent, i Paesi e gli IP per diverse classificazioni del traffico. Uno user agent è l’etichetta che un browser o un bot invia per identificarsi, e un indirizzo IP è l’indirizzo di rete da cui proviene una richiesta. Questi dettagli aiutano il proprietario di un sito a capire se uno specifico crawler sta raggiungendo contenuti utili, se uno scraper sconosciuto sta eseguendo la scansione di migliaia di URL o se le richieste automatizzate sono concentrate su pagine sensibili o ad alto consumo di risorse.
Se i visitatori reali sono già interessati dal problema, Kinsta afferma che i proprietari dei siti dovrebbero prima stabilizzare la situazione e indagare più in dettaglio in seguito. Questo può significare aumentare temporaneamente la protezione dai bot, bloccare il traffico chiaramente abusivo prima che raggiunga il sito, sottoporre a verifica il traffico sospetto e preservare l’accesso per crawler e integrazioni critici. Una challenge è un passaggio di verifica aggiuntivo prima che l’accesso venga consentito. Kinsta afferma che, con il suo sistema, un visitatore che supera con successo una challenge generalmente non verrà sottoposto di nuovo a challenge per almeno 10 giorni mentre utilizza lo stesso browser e lo stesso indirizzo IP. L’azienda afferma che le sue protezioni di sicurezza di base bloccano già il traffico classificato come malevolo, mentre livelli più severi possono essere usati per traffico automatizzato non necessariamente classificato come malevolo, ad esempio sottoponendo a challenge tutti i bot non verificati o sottoponendo tutti a challenge durante un grave evento di pressione.
Una volta che il sito è stabile, la decisione a lungo termine è se ogni tipo di traffico automatizzato debba essere consentito, sottoposto a challenge o bloccato. Consentire significa che la richiesta può raggiungere il sito. Bloccare significa che non può farlo. La challenge si colloca tra le due opzioni quando la risposta giusta è incerta. Kinsta suggerisce di valutare tre domande: se il bot fornisce valore, quanto costa il traffico in termini di elaborazione, larghezza di banda e query al database, e cosa accadrebbe se il bot venisse bloccato. Un bot che recupera un post di blog dalla cache di solito costa meno di uno che colpisce una pagina dinamica come un carrello WooCommerce. Cache significa una copia salvata di una pagina che può essere servita più velocemente senza ricostruirla ogni volta.
Questa distinzione è importante perché i siti WordPress spesso contengono sia pagine a basso costo sia pagine ad alto costo. I contenuti statici o in cache possono gestire bene il traffico dei crawler. Gli endpoint dinamici, cioè pagine o funzioni generate da zero per ogni visitatore, possono essere molto più costosi. Kinsta cita esempi come carrelli, checkout, ricerche e login, e osserva che questo è comune nei negozi WooCommerce ma può riguardare anche altri tipi di siti. Le richieste verso queste aree possono aggirare la cache, richiedere elaborazione PHP, attivare query al database e lasciare i clienti reali a competere per le risorse. La risposta misurata consiste nel proteggere gli endpoint specifici più costosi, impedire l’accesso non necessario dei crawler alle funzioni di carrello e checkout, indagare la proliferazione dei parametri URL e i cicli di crawling, e mantenere la possibilità per i crawler di ricerca di raggiungere contenuti di valore altrove.
I crawler dei motori di ricerca richiedono particolare attenzione. Se un crawler sta generando traffico pesante, Kinsta consiglia di controllare quali URL sta visitando, se quegli URL sono contenuti utili e indicizzabili, se è bloccato in parametri, filtri o endpoint dinamici, e se le prestazioni reali stanno effettivamente soffrendo. I contenuti indicizzabili sono materiali che un motore di ricerca può aggiungere ai propri risultati. Bloccare un intero crawler di ricerca può essere dannoso, soprattutto se impedisce a Googlebot di eseguire la scansione e indicizzare i contenuti, perché ciò può compromettere gravemente la visibilità in Google Search. Una risposta migliore è preservare l’accesso alle pagine importanti limitando o scoraggiando al tempo stesso la scansione di variazioni di URL dinamiche non necessarie.
I crawler AI sono più ambigui. Kinsta osserva che possono creare molte richieste, mentre il loro valore può essere difficile da valutare. I proprietari dei siti dovrebbero chiedersi se la visibilità o le citazioni nell’AI siano importanti per loro, se un crawler invii traffico referral significativo, se stia principalmente raccogliendo contenuti senza un beneficio evidente e se il traffico consumi risorse infrastrutturali rilevanti. Kinsta sottolinea inoltre che non tutti i crawler AI devono essere trattati allo stesso modo. Alcuni possono essere in linea con gli obiettivi di un sito, mentre i crawler aggressivi possono essere sottoposti a challenge o limitati, e quelli che offrono poco valore creando costi significativi possono essere bloccati.
Gli scraper sconosciuti meritano un’indagine invece di ipotesi immediate. Kinsta afferma che un bot non identificato non è automaticamente malevolo, ma se esegue la scansione in modo aggressivo e consuma risorse, i proprietari dovrebbero controllarne user agent, IP, percorsi e comportamento delle richieste. Dovrebbero anche confermare se appartiene a un’integrazione da cui il sito dipende realmente. In caso di incertezza, una challenge può ridurre il rischio. Se il traffico è chiaramente indesiderato e causa problemi, il blocco può essere appropriato. In seguito, i proprietari dovrebbero monitorare eventuali servizi interrotti, rotazione dell’identità o cambiamenti nei modelli di richiesta.
Il monitoraggio chiude il ciclo.