Bot WordPress: come rallentano il sito e sporcano i dati

Il traffico bot su WordPress è un costo nascosto. Non compare tra gli incidenti, ma logora il server ogni giorno: sovraccarica PHP e database, rallenta il sito, soprattutto WooCommerce, e falsa le metriche di analisi. Una richiesta automatica identica a quella di un visitatore, moltiplicata per migliaia di istanze al minuto, consuma risorse vere. Si misura e si governa.

Che cos'è il traffico bot (e perché non è solo spam)

Un bot è un client che naviga senza un umano. Alcuni sono innocui: crawler dei motori di ricerca, monitoraggi. Altri sono parassiti: scraper che clonano cataloghi, sonde che tentano il credential stuffing su wp-login.php, reti che amplificano attacchi via xmlrpc.php. Ci sono poi i crawler di AI, che leggono il sito in massa. Il problema è il volume, non il singolo bot.

Come i bot prosciugano le risorse di WordPress

WordPress è dinamico: ogni richiesta non servita dalla cache esegue PHP e interroga MySQL. Il traffico bot sfrutta proprio i punti che non sono cacheabili. Tre vettori tipici:

admin-ajax.php: molte chiamate AJAX e il controllo heartbeat colpiscono questo endpoint, sempre dinamico.
wp-login.php e ricerca: raffiche di POST contro il login e query ?s= pesanti sul database.
xmlrpc.php: un solo pingback può innescare richieste multiple, amplificazione classica.

Il risultato si vede nel TTFB che sale, nelle query lente e nei timeout sotto carico, soprattutto sugli endpoint dinamici e meno sulla homepage in cache.

L'impatto su WooCommerce e sulle metriche

Su WooCommerce il danno è doppio. Le pagine di carrello e checkout usano sessioni e query che non vanno messe in cache: ogni bot che simula un visitatore consuma risorse come un cliente reale. Il server paga il conto, il cliente vero trova il carrello lento e abbandona. Nel frattempo l'analytics si sporca: sessioni fittizie, rimbalzi artificiali, conversioni che non esistono. In Google Analytics 4 i bot noti sono esclusi in automatico e non è possibile modificare questa impostazione (documentazione Google); quelli sconosciuti restano nei dati. Confronta sempre i report con i log del server, altrimenti prendi decisioni su numeri gonfiati.

Come riconoscerlo con i dati

Prima di agire, misura. Controlla i log del server e cerca questi segnali:

Uno user agent anomalo o assente, concentrato su pochi URL (/, /?author=1, /xmlrpc.php).
Richieste per IP molto alte, a intervalli regolari, su pagine che un utente reale non visiterebbe in sequenza.
Picchi di POST su wp-login.php e admin-ajax.php in fasce orarie insolite.
Query MySQL lente correlate a endpoint dinamici, con cache che non viene mai colpita.

Se il traffico cresce ma le vendite restano piatte, il sospetto è fondato.

Come fermarlo, in ordine di costo

Non serve un plugin pesante per tutto. Si parte dalle mosse a costo zero e si sale:

Chiudi le porte: disattiva xmlrpc.php se non serve, limita admin-ajax.php, blocca le richieste ?author= che rivelano i nomi utente.
Limite di richieste (rate limit) a monte: sposta la protezione su CDN/WAF, prima che il traffico arrivi a PHP; una richiesta bloccata alla rete non consuma database.
Cache aggressiva sul contenuto statico e controllo dell'heartbeat nelle aree riservate.
Analisi pulita: incrocia analytics e log del server per riportare i dati alla realtà.

Il resto è manutenzione ordinaria e conoscenza del proprio mezzo: un servizio di manutenzione WordPress e, quando serve, uno sviluppo plugin su misura che applichi regole specifiche sul tuo ambiente.

Misura prima di bloccare

Un altro plugin generico da installare e dimenticare non risolve il problema: serve sapere cosa ti sta colpendo e reagire in modo proporzionato. Se vuoi capire quanto pesano i bot sul tuo sito, parti dalla consulenza iniziale gratuita: si guardano versioni, plugin e rischi, e il preventivo scritto arriva dopo aver visto il sito. Il Cyber Health Check serve a inquadrare l'esposizione dell'azienda nel suo insieme.

Come fare, passo per passo: misurare e ridurre il traffico bot

1. Leggere i log

Se hai accesso ai log di Nginx o Apache nel formato combinato, tre comandi danno un quadro rapido. Sostituisci il percorso con quello del tuo server.

# IP con più richieste
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# user agent più frequenti
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# IP che fanno POST al login
grep 'POST /wp-login.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Il primo conta le richieste per indirizzo, il secondo per user agent, il terzo i tentativi di accesso. Confronta i numeri con le visite che vedi in analytics: la differenza è il tuo traffico automatico. Prima di bloccare un IP, verifica che non sia di un servizio che usi (monitoraggio, motore di ricerca, pagamenti).

2. Chiudere xmlrpc.php

Se non usi app che lo richiedono, blocca il file a livello di server. Su Apache 2.4, nel file .htaccess:

<Files xmlrpc.php>
  Require all denied
</Files>

Su Nginx, nel blocco server:

location = /xmlrpc.php {
  deny all;
}

Il filtro xmlrpc_enabled di WordPress disattiva la funzione, ma la richiesta arriva comunque a PHP: bloccare a livello di server è più economico.

3. Rallentare il login

Su Nginx un limite di richieste evita le raffiche sul login. La direttiva limit_req_zone va nel contesto http, il limit_req nel blocco del login:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
  limit_req zone=login burst=3 nodelay;
  # qui le tue direttive FastCGI abituali
}

La zona tiene traccia degli indirizzi e consente cinque richieste al minuto con una piccola eccedenza. Prova con un tuo accesso prima di attivarla in produzione: più utenti dietro lo stesso IP aziendale possono scattare insieme.

4. Bloccare l'enumerazione degli utenti

Su Apache, prima del blocco di WordPress in .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_URI} !/wp-admin/
RewriteCond %{QUERY_STRING} (^|&)author=\d+ [NC]
RewriteRule ^ - [F]

La regola risponde 403 alle richieste ?author=1, che servono a ricavare i nomi utente. La prima condizione lascia funzionare il filtro per autore dell'area amministrativa (wp-admin/edit.php?author=N).

5. Ridurre il peso dell'heartbeat

L'API Heartbeat di WordPress interroga il server a intervalli regolari. Per allungare l'intervallo, nel file del tema figlio o in un plugin personalizzato:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

Il valore è in secondi e WordPress accetta tra 15 e 120. Ridurre le chiamate non cambia l'esperienza per chi scrive articoli.

6. Dichiarare le regole per i crawler

Il file robots.txt serve a dichiarare cosa non vuoi che i crawler leggano. Alcuni crawler di AI dichiarano i loro nomi:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

GPTBot è il crawler di OpenAI e CCBot quello di Common Crawl. Il file è una richiesta di cortesia: i bot onesti la rispettano, quelli ostili la ignorano. Per quelli ostili servono WAF e limiti a monte.

Checklist

Hai misurato richieste per IP e user agent negli ultimi giorni.
xmlrpc.php è bloccato se non serve.
Il login ha un limite di richieste e la MFA per gli amministratori.
Le richieste ?author= non rivelano i nomi utente.
Carrello, checkout e area cliente sono esclusi dalla cache; il resto è in cache.
Il WAF o la CDN filtrano le richieste prima di PHP.
Analytics e log del server vengono confrontati ogni mese.
Il robots.txt indica ciò che non vuoi far leggere ai crawler.

Errori da evitare

Bloccare un intervallo di IP senza controllare chi lo usa.
Installare più plugin di sicurezza che si sovrappongono e appesantiscono il sito.
Mettere in cache il checkout per "migliorare i tempi".
Disattivare l'heartbeat dappertutto: certe funzioni dell'editor ne hanno bisogno.
Limitare il login a livello troppo stretto e chiudere fuori i clienti veri.
Considerare i dati di analytics come l'unica verità.

Consigli pratici

Controlla il TTFB di una pagina non in cache e di una in cache: se la prima è molto più lenta, il costo dei bot sul PHP sale.
Attiva la cache a livello di pagina sul server o sulla CDN per le pagine pubbliche, così il bot incontra un file statico e non PHP.
Per la ricerca interna, valuta di bloccare le richieste ?s= con termini casuali o di limitarle.
Dopo ogni modifica di regole, riguarda i log il giorno dopo e confronta con prima.
Tieni un elenco degli IP e degli user agent che hai deciso di fermare, con data e motivo.
Un singolo wp-cron.php che parte a ogni visita pesa: usa un cron di sistema e imposta DISABLE_WP_CRON a true in wp-config.php.

Domande frequenti

Tutti i bot sono dannosi? No. Motori di ricerca e monitoraggi servono. L'obiettivo è governare il volume e bloccare quelli che non portano nulla.

Un plugin basta? Aiuta, ma il filtro più efficace sta a monte, su CDN, WAF o server, prima che la richiesta raggiunga PHP.

Bloccare i crawler di AI danneggia la SEO? I crawler di AI sono distinti da quelli dei motori di ricerca. Bloccare GPTBot o CCBot non tocca Googlebot, ma decidi in base a come vuoi essere citato.

Come capisco se il rallentamento dipende dai bot? Confronta i picchi di richieste nei log con i momenti di lentezza e con le visite in analytics. Se le richieste salgono e gli ordini no, i bot sono sospetti.

In sintesi

Il traffico bot è un prelievo quotidiano su CPU, database e affidabilità delle tue decisioni. Si riconosce con i log e si ferma al margine della rete, prima di PHP. Prima misura, poi blocca, poi automatizza la difesa.