Nell’ultimo anno, il traffico dei bot è passato da qualcosa che chi gestisce siti poteva ignorare a qualcosa che influisce direttamente sul comportamento delle infrastrutture. Il cambiamento non riguarda solo il volume. Si tratta del modo in cui il traffico automatizzato interagisce con i siti web moderni, in particolare con i negozi WooCommerce.

In apparenza, potrebbe sembrare che una richiesta sia solo una richiesta. Ma non tutte le richieste sono uguali e WooCommerce rende questa differenza ancora più evidente.

In questo articolo vedremo perché i siti WooCommerce sono più sensibili al traffico dei bot, cosa succede quando i bot colpiscono gli endpoint chiave e perché le ipotesi comuni su traffico e prestazioni non reggono in un contesto di e-commerce.

Perché WooCommerce trasforma il traffico in carico di lavoro

In un tipico sito WordPress, la maggior parte delle pagine viene memorizzata nella cache su un CDN come Cloudflare, in modo che le richieste vengano servite senza coinvolgere il server di origine. Anche con volumi più elevati, il costo rimane relativamente basso perché il sistema è ottimizzato per riutilizzare l’output in cache.

Il funzionamento di un server CDN
Il funzionamento di un server CDN (Fonte: Seobility).

WooCommerce funziona in modo diverso. Gran parte delle richieste dipendono da dati in tempo reale e da un contesto specifico dell’utente e non possono essere servite dalla cache. Ogni richiesta deve essere elaborata da zero sul server di origine. Questo include:

  • Esecuzione di PHP per gestire la logica della richiesta
  • Interrogazione del database per i dati relativi ai prodotti, ai prezzi o alla sessione
  • Creazione della risposta in modo dinamico prima di inviarla

L’esecuzione di PHP per ogni richiesta occupa un thread PHP per tutta la durata del processo e il numero di thread disponibili per ogni sito è limitato. Una volta utilizzati tutti, le nuove richieste devono attendere. Potresti anche notare che il tuo sito raggiunge costantemente il limite di thread PHP.

Limite di thread PHP di MyKinsta
Limite di thread PHP di MyKinsta.

Allo stesso tempo, il database viene interrogato per ottenere dati e informazioni sulla sessione. La gestione della sessione avviene anche in background.

Anche senza considerare il comportamento dei bot, è chiaro che le richieste di WooCommerce sono intrinsecamente costose. Quando il traffico automatizzato entra in gioco, il costo aumenta.

Dove i bot causano i maggiori danni ai siti WooCommerce

L’impatto del traffico bot sui siti WooCommerce tende a concentrarsi su un piccolo gruppo di endpoint progettati per le interazioni con gli utenti reali.

Queste sono le parti del sito in cui le richieste sono più costose e meno memorizzabili:

  • Endpoint del carrello e del checkout (/cart, /checkout, ?add-to-cart=)
  • Query di ricerca
  • Pagine di prodotto filtrate e basate su parametri
  • Interazioni e componenti dinamici guidati da AJAX

Ognuno di questi elementi si comporta in modo diverso, ma ogni richiesta attiva un’elaborazione reale sul server.

Gli endpoint del carrello e del checkout sono gli esempi più ovvi. Una richiesta a /cart o qualsiasi cosa che coinvolga ?add-to-cart= attiva la logica dell’applicazione per convalidare la sessione, aggiornare lo stato del carrello, interrogare i dati dei prodotti e preparare una risposta specifica. Quando questo avviene ripetutamente su larga scala, consuma rapidamente le risorse del server.

Nel nostro rapporto pubblicato di recente, “Tutta la verità sul traffico AI & bot”, il nostro team di tecnici ha scoperto che oltre sette milioni di richieste bot hanno colpito gli URL add-to-cart sull’infrastruttura Kinsta in 24 ore.

7,67 milioni di richieste in 24 ore sull'infrastruttura Kinsta.
7,67 milioni di richieste in 24 ore sull’infrastruttura Kinsta.

Per mettere i numeri in prospettiva, 3,75 milioni di richieste in 24 ore da parte di ClaudeBot corrispondono a circa una richiesta ogni 23 millisecondi (tutto il giorno e tutta la notte), ognuna delle quali viene trattata come una nuova richiesta.

Oltre agli endpoint del carrello e del checkout, anche la ricerca e il filtraggio introducono un altro tipo di pressione. I negozi WooCommerce spesso permettono agli utenti di filtrare i prodotti in base ad attributi come il prezzo, la categoria, la taglia o la disponibilità. Ogni combinazione crea un URL leggermente diverso e, dal punto di vista di un crawler, vale la pena esplorare ogni variante.

Nel nostro report, abbiamo scoperto che il meta-externalagent (crawler di Facebook/Meta AI) rimaneva bloccato per giorni sulle pagine di confronto di WooCommerce e si imbatteva in variazioni senza senso sulle pagine del calendario.

I crawler AI si bloccano in modo anomalo sulle pagine dinamiche
I loop anomali dei crawler AI sulle pagine dinamiche.

Questo accade perché i crawler non comprendono il contesto. Il crawler segue la prima variante, poi scopre un’altra versione leggermente diversa, poi un’altra ancora e continua a espandere il suo percorso. In nessun momento si rende conto che sta visitando la stessa pagina più volte.

Nei siti WooCommerce questo diventa particolarmente problematico perché molte di queste variazioni sono legate a funzionalità dinamiche.

Perché il traffico bot non sembra un attacco (ma si comporta come tale)

Uno dei motivi per cui è facile trascurare questo problema è che non assomiglia a un attacco dannoso.

Quando si verifica un attacco dannoso, si notano picchi da un’unica fonte con chiari segni di abuso e possibilmente payload dannosi, ma con il traffico bot le richieste sembrano normali perché seguono la struttura del sito, accedono a URL validi e ricevono risposte valide.

Dall’esterno, spesso sembra un’attività di crawling legittima, ma il sistema non valuta l’intento. Si limita a elaborare le richieste.

Quando i crawler inefficienti o mal gestiti operano su scala, creano schemi che assomigliano a un abuso, anche se non era questo l’obiettivo originale. Richieste ripetute, loop e accessi ad alta frequenza a endpoint dinamici si traducono in un carico di lavoro sostenuto per il server.

Ecco perché la distinzione tra bot “buoni” e “cattivi” diventa meno utile nella pratica.

Un crawler può essere legittimo e generare comunque un traffico che peggiora le prestazioni. Il problema non è solo chi fa la richiesta, ma cosa questa richiesta costringe il sistema a fare.

Cosa significa per le prestazioni di WooCommerce

Quando questo tipo di traffico aumenta, gli effetti si manifestano in modi che è facile attribuire a cause errate.

  • Le pagine iniziano a caricarsi più lentamente, soprattutto durante i picchi di attività
  • I flussi di pagamento risultano ritardati o incoerenti
  • In alcuni casi, le richieste iniziano ad accodarsi perché i lavoratori PHP sono impegnati a gestire ripetute interazioni automatiche

Dall’esterno sembra un problema di prestazioni, ma la causa sottostante è spesso la pressione prolungata del traffico automatizzato che colpisce gli endpoint non memorizzati.

Questo influisce anche sul modo in cui il traffico viene interpretato. Grandi volumi di richieste automatiche possono gonfiare il numero di visite senza contribuire all’effettiva attività degli utenti. Un picco di traffico potrebbe non corrispondere a un aumento dell’engagement, delle conversioni o delle entrate. Senza visibilità su ciò che genera il traffico, diventa difficile separare la domanda reale dal carico automatico.

In scala, questo diventa un problema sia di prestazioni che di decisioni.

Perché bloccare i bot non è una soluzione completa

Se non hai ancora dimestichezza con il traffico dei bot, la tua reazione naturale a questo tipo di comportamento è quella di bloccarlo. In alcuni casi funziona. Ma nella maggior parte dei casi crea nuovi compromessi.

La verità è che non tutto il traffico automatizzato è dannoso. I crawler dei motori di ricerca sono essenziali per la visibilità. I crawler AI svolgono un ruolo nel modo in cui i contenuti vengono visualizzati dagli agenti dell’intelligenza artificiale, che ora viene definito come pratiche GEO e AEO.

Bloccare tutto elimina il problema del traffico, ma anche gli eventuali benefici. Consentire l’accesso a tutto evita le interruzioni, ma lascia il sistema esposto a carichi inutili.

La difficoltà sta nel fatto che i siti WooCommerce non hanno bisogno di un’unica regola per tutto il traffico. Hanno bisogno di un comportamento diverso a seconda della destinazione della richiesta e della fonte del traffico.

Un modo più pratico di pensare al traffico bot

Invece di chiedersi se l’accesso ai bot debba essere consentito o bloccato, la domanda più utile è: quali tipi di traffico deve poter accedere a quali parti del sito?

Gli endpoint del carrello e del checkout non devono essere accessibili ai crawler. Le pagine di ricerca e le pagine filtrate possono essere limitate senza influire sulle funzionalità principali. Allo stesso tempo, le pagine dei prodotti e delle categorie devono rimanere accessibili ai motori di ricerca.

Questo tipo di separazione rende gestibile il traffico dei bot.

Dalla nostra analisi di oltre 10 miliardi di richieste su infrastrutture gestite da Kinsta, questi schemi appaiono come comportamenti ricorrenti su siti WooCommerce reali. Se vuoi esplorare l’intero set di dati e vedere come si evolvono questi schemi tra i diversi tipi di sito, il report sul traffico bot e AI fornisce maggiori dettagli sull’argomento.

Allo stesso tempo, la gestione manuale è raramente pratica. Richiede aggiustamenti periodici, una chiara visibilità degli schemi di traffico e un modo per applicare le decisioni senza interrompere l’uso legittimo. È proprio questa la lacuna che lo strumento Protezione Bot di Kinsta è stato progettato per risolvere, dando ai proprietari dei siti la possibilità di controllare come vengono gestiti i diversi tipi di traffico senza affidarsi a regole univoche.

Non esitare a consultare la nostra documentazione e a contattare il supporto se hai bisogno di ulteriori chiarimenti su come questo strumento può funzionare per il tuo sito o la tua agenzia.

Joel Olawanle Kinsta

Joel è uno Frontend developer che lavora in Kinsta come redattore tecnico. È un insegnante appassionato che ama l'open source e ha scritto oltre 200 articoli tecnici principalmente su JavaScript e i suoi framework.