Facebook crawler e CPU al 100%: come riconoscere e gestire i bot troppo aggressivi

Se un sito WordPress o PrestaShop diventa improvvisamente lento, con CPU al 90% e errori 500 inspiegabili, la prima reazione è pensare a un attacco. Ma a volte la causa è diversa: un bot ufficiale (in questo caso Facebook crawler), cioè un crawler che scandaglia le pagine per motivi legittimi, ma che può comportarsi in modo aggressivo.

Un esempio concreto è il crawler di Facebook, identificato con lo user agent:

meta-externalads/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)

Cos’è il crawler di Facebook

Il bot di Facebook (oggi Meta) viene usato ogni volta che una pagina viene condivisa sul social.
Il suo compito è raccogliere:

• Titolo della pagina,
• Descrizione,
• Immagine di anteprima (tag Open Graph).

È uno strumento utile, perché senza di esso i link su Facebook apparirebbero “nudi”, senza anteprime. Il problema nasce quando il crawler effettua troppe richieste ravvicinate e manda in sofferenza il server.

Caso reale: un e-commerce Prestashop in crisi

Un cliente mi ha contattato perché il suo shop Prestashop era inutilizzabile da ore.

1. Sintomi iniziali: il sito restituiva a tratti errori 500, ma nei log di cPanel (sarebbe stato lo stesso per Plesk) non c’erano anomalie evidenti. Questo mi ha insospettito: se non c’è traccia nei log, il problema potrebbe essere “a monte”.
2. CPU sotto stress: dal Pannello di controllo ho notato che la CPU era oltre il 90%, con il comando “top" da terminale ho visto decine di processi lsphp attivi.
3. Traffico reale assente: non c’era stato alcun picco di visite umane. Con la cache attiva, la maggior parte delle richieste avrebbe dovuto essere servita senza avviare PHP.
4. La scoperta: negli access log ho trovato lo user agent “meta-externalads/1.1”: il crawler di Facebook stava letteralmente martellando il sito.

Perché la cache non funzionava: il problema di ?fbclid

Un dettaglio tecnico ha reso il problema ancora più impattante: ogni URL richiesto dal bot conteneva il parametro ?fbclid=....

• Per il server, pagina.php e pagina.php?fbclid=123 sono due pagine diverse.
• La cache non li riconosce come la stessa risorsa, quindi ogni richiesta ha generato un nuovo processo PHP.
• Risultato: la cache era “bypassata” e la CPU si è saturata.

La lezione è chiara: quando si usa la cache, bisogna configurarla per ignorare i parametri inutili (fbclid, utm_source, utm_campaign, ecc.), altrimenti ogni URL diventa unico e la cache non serve più a nulla.

Sintomi tipici di un bot aggressivo

• CPU e RAM elevate senza traffico reale.
• Errori 500 intermittenti.
• Processi PHP o lsphp saturi.
• Log visitatori con centinaia di richieste ravvicinate dallo stesso user agent.

L’errore 500 spesso è sintomo di un server che fatica a sostenere il sito ospitato, un bot aggressivo agisce sul server come un picco di visitatori, molti visitatori. Ma fai attenzione, se un bot solo, per quanto aggressivo, è in grado di saturare il tuo server forse è il caso di adottare due soluzioni:

• Migliorare le performance del sito
• Passare ad un piano hosting più professionale

Come gestire il crawler di Facebook (senza bloccarlo del tutto)

Bloccarlo non conviene, perché senza di lui i link condivisi su Facebook non avranno anteprima. Le soluzioni sono:

1. Cache configurata correttamente → escludere i parametri inutili (fbclid, utm_*).
2. Rate limiting → limitare il numero di richieste al secondo per singolo IP o user agent.
3. Robots.txt mirato → impedire al bot di visitare aree pesanti (es. carrello, checkout).

Come configurare la cache per escludere fbclid, utm_* e altri parametri inutili

Molti bot (e anche gli utenti che arrivano da campagne) atterrano sul sito con URL che contengono parametri come:

• ?fbclid=XYZ123 → parametro di tracciamento di Facebook
• ?utm_source=... → parametri di Google Analytics / campagne
• ?gclid=... → parametro di Google Ads

Il problema è che la cache li considera URL diversi, quindi invece di servire la pagina già salvata, il server genera la pagina da zero, moltiplicando i processi PHP.

Ecco le possibili soluzioni:

Configurare il sistema di cache (a livello CMS o plugin):

• In WordPress, molti plugin come WP Rocket, LiteSpeed Cache o W3 Total Cache hanno una sezione per ignorare determinati query string (fbclid, utm_*, gclid).
• In PrestaShop si può agire via mod_rewrite o moduli di cache avanzata.

A livello server (Nginx o Apache):

Puoi dire al server di ignorare i parametri non rilevanti per il contenuto.

Nginx: In questo modo rimuovi i parametri e servi la versione cache pulita.

location / {
    if ($arg_fbclid != "") {
        return 301 $scheme://$host$uri;
    }
    if ($arg_gclid != "") {
        return 301 $scheme://$host$uri;
    }
    if ($arg_utm_source != "" ) {
        return 301 $scheme://$host$uri;
    }
}

location / {
    if ($arg_fbclid != "") {
        return 301 $scheme://$host$uri;
    }
    if ($arg_gclid != "") {
        return 301 $scheme://$host$uri;
    }
    if ($arg_utm_source != "" ) {
        return 301 $scheme://$host$uri;
    }
}

Apache (.htaccess): Qui rigeneri l’URL senza i parametri.

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)fbclid=[^&]+ [OR]
RewriteCond %{QUERY_STRING} (^|&)gclid=[^&]+ [OR]
RewriteCond %{QUERY_STRING} (^|&)utm_[^&]+
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)fbclid=[^&]+ [OR]
RewriteCond %{QUERY_STRING} (^|&)gclid=[^&]+ [OR]
RewriteCond %{QUERY_STRING} (^|&)utm_[^&]+
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

Elenco di user-agent da verificare / tenere d’occhio

Ecco una lista di user-agent che spesso appaiono nei log — alcuni sono “buoni” / ufficiali, altri da monitorare per abusi. Puoi usarla per fare controlli nei tuoi log o impostarla in regole di filtraggio o robots.txt.

• meta-externalads/1.1 → Crawler di Facebook/Meta per generare anteprime quando una pagina viene condivisa sui social. Può generare traffico massivo se non controllato.
• facebookexternalhit/1.1 → Altro bot di Facebook per preview link condivisi. Simile al precedente, utile riconoscerlo nei log.
• Googlebot / Googlebot/2.1 → Bot ufficiale di Google per indicizzazione delle pagine. Essenziale tenerlo, ma si può limitare il crawl se troppo frequente.
• Bingbot → Bot ufficiale di Bing per indicizzazione.
• Applebot → Bot di Apple, usato per rilevamento e anteprime dei link.
• AdsBot-Google / AdsBot-Google-Mobile → Bot di Google per controlli AdSense e pubblicità. Può generare carico se molte pagine contengono annunci.
• LinkedInBot → Bot ufficiale di LinkedIn, per anteprime e condivisioni.
• HeadlessChrome / Chrome-Headless → Browser senza UI, usato per test automatici e scraping. Può essere benigno o malintenzionato.
• cURL → Strumento da linea di comando, usato sia per test che per scraping; molti hit simili possono indicare abuso.

Conclusione: come gestire il Facebook crawler e la CPU al 100%

I bot come meta-externalads/1.1 non sono attacchi, ma strumenti ufficiali. Tuttavia, senza configurazioni adeguate possono mettere in ginocchio un sito WordPress o Prestashop.

Monitorare i log, gestire la cache correttamente e applicare regole di limitazione significa proteggere il sito senza rinunciare alla visibilità.

Se noti rallentamenti inspiegabili o picchi di CPU sul tuo sito, può essere utile dare un’occhiata ai log e alla configurazione della cache. Una gestione attenta dei bot può aiutare a mantenere il sito stabile e performante.