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.

Nota veloce sulla keyword “meta‑externalads”
Se sei arrivato qui cercando “meta‑externalads”, vuoi approdondire in merito al bot ufficiale di Meta Platforms (ex Facebook) usato per generare anteprime dei link condivisi sui social. Viene indicato nei log come meta‑externalads/1.1.
Anche se questo articolo parla in generale di “bot aggressivi” e “crawler” ad alto carico”, la buona notizia è che i concetti spiegati qui sono perfettamente applicabili anche a quel specifico user‑agent: cache bypassata a causa di parametri come fbclid, richieste ravvicinate al server, incremento sproporzionato del carico CPU.

Quindi, anche se la tua ricerca era più “Perché appare meta‑externalads/1.1 nei log?”, continua a leggere: imparerai non solo come riconoscerlo, ma anche come contenerlo e ottimizzare la configurazione del tuo CMS/hosting per non subirne gli effetti.

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).

Una soluzione più evoluta per contenere il traffico aggressivo del crawler di Facebook (meta-externalads/1.1) senza impedire agli utenti reali di navigare è utilizzare regole .htaccess che agiscono solo sul bot, invece di bloccare tutti indiscriminatamente. Ad esempio, puoi bloccare richieste su asset pesanti (CSS, JS, font, immagini di prodotto) e chiamate AJAX inutili, e applicare il redirect delle URL con query string ?q= (da valutare il parametro caso per caso) solo per il bot, lasciando intatto il normale traffico umano:

<IfModule mod_rewrite.c>
RewriteEngine On

# Blocca asset pesanti SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule \.(js|css)$ - [F,L]

RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule \.(woff|woff2|ttf|otf)$ - [F,L]

# Blocca AJAX inutili SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule ^modules/front/ajax.php - [F,L]

# Redirect URL con ?q= SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteCond %{QUERY_STRING} q=
RewriteRule ^(.*)$ /$1? [R=301,L]
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On

# Blocca asset pesanti SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule \.(js|css)$ - [F,L]

RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule \.(woff|woff2|ttf|otf)$ - [F,L]

# Blocca AJAX inutili SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteRule ^modules/front/ajax.php - [F,L]

# Redirect URL con ?q= SOLO per Meta
RewriteCond %{HTTP_USER_AGENT} meta-externalads [NC]
RewriteCond %{QUERY_STRING} q=
RewriteRule ^(.*)$ /$1? [R=301,L]
</IfModule>

In questo modo:

• Gli utenti reali e altri bot non vengono bloccati o reindirizzati.
• Meta continua a scaricare solo le informazioni necessarie per generare anteprime dei link.
• Il carico di CPU del server viene ridotto drasticamente, evitando errori 500 o rallentamenti.

Questa soluzione è particolarmente utile per siti e-commerce con molte immagini o AJAX, dove il bot rischia di saturare le risorse senza motivo.

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.

FAQ sul Facebook Crawler e traffico aggressivo

1. Cos’è meta-externalads/1.1?
È il bot ufficiale di Facebook/Meta che genera le anteprime dei link condivisi sui social. Non è un attacco, ma può generare molte richieste ravvicinate se non gestito correttamente.

2. Perché il mio sito diventa lento quando passa questo bot?
Ogni URL con parametri diversi (?fbclid, ?q=, utm_*) viene considerata una pagina nuova dal server. Se il bot fa molte richieste, PHP si avvia per ogni richiesta, saturando CPU e RAM.

3. Posso bloccare completamente il crawler di Facebook?
Non è consigliato: senza di lui le anteprime dei link non vengono generate. Meglio bloccare solo le risorse pesanti o i parametri inutili e limitare il numero di richieste.

4. Come faccio a ridurre il carico del bot sul server?

• Bloccare asset pesanti (JS, CSS, font, immagini di prodotto) solo per Meta
• Bloccare AJAX inutili per Meta
• Applicare redirect per URL con query string inutili solo per Meta
• Configurare correttamente la cache e ignorare parametri come fbclid, utm_*, gclid

5. Questo rallenterà la condivisione dei link su Facebook?
No. Le anteprime continueranno a funzionare, ma il bot non scaricherà risorse inutili, riducendo drasticamente il carico sul server.

6. Posso fare la stessa cosa per altri bot aggressivi?
Sì, il principio è lo stesso: identificare l’user-agent e bloccare solo le richieste non necessarie o troppo pesanti, senza interferire con l’accesso umano o bot “buoni” per indicizzazione.

7. E se il mio sito ha molte categorie e prodotti?
Le regole .htaccess e la gestione della cache vanno impostate in modo generico, così che tutte le URL con query string non necessarie vengano normalizzate, indipendentemente dal numero di categorie o prodotti.