FAQ - Perché Meta-ExternalAgent può creare problemi?
In alcuni casi può capitare di rilevare nei log del proprio sito un numero molto elevato di richieste provenienti dal crawler di Meta identificato dal seguente User-Agent:
| meta-externalagent |
oppure, ad esempio:
| meta-externalagent/1.1 |
Meta-ExternalAgent è un crawler utilizzato da Meta per acquisire contenuti pubblicamente disponibili sul Web.
Tra le sue finalità rientrano attività legate ai sistemi di intelligenza artificiale di Meta, compreso l'utilizzo dei contenuti per l'addestramento dei modelli AI e per il miglioramento dei prodotti Meta attraverso l'indicizzazione dei contenuti presenti sul Web.
Per maggiori informazioni è possibile consultare la documentazione ufficiale Meta:
https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/
Si tratta quindi di un crawler legittimo e la sua presenza nei log non indica, di per sé, che il sito sia sotto attacco o compromesso.
Il problema può nascere quando Meta-ExternalAgent effettua un numero molto elevato di richieste in un breve periodo oppure continua a visitare il sito con elevata frequenza per molte ore o giorni.
In condizioni normali la presenza di un crawler nei log di un sito non rappresenta necessariamente un problema.
Abbiamo però riscontrato casi nei quali Meta-ExternalAgent ha effettuato un numero molto elevato di richieste, generando una parte significativa del traffico mensile del sito e, contemporaneamente, un utilizzo rilevante delle risorse assegnate all'account hosting.
Il problema può diventare particolarmente evidente quando il sito contiene molte:
| - | pagine; |
| - | immagini; |
| - | schede prodotto; |
| - | categorie; |
| - | articoli; |
| - | URL dinamiche; |
| - | pagine generate da CMS come WordPress, PrestaShop o Joomla. |
Un crawler che visita continuamente un numero elevato di URL può infatti determinare:
| - | un elevato numero di richieste HTTP; |
| - | un notevole consumo di traffico dati; |
| - | un utilizzo molto elevato della banda mensile disponibile; |
| - | un aumento dell'utilizzo della CPU; |
| - | un aumento del consumo di memoria RAM; |
| - | un elevato numero di processi PHP contemporanei; |
| - | numerose interrogazioni al database; |
| - | un aumento delle connessioni contemporanee al web server; |
| - | il raggiungimento dei limiti di risorse previsti dal piano hosting. |
Sì.
Questo è uno degli aspetti che può risultare maggiormente evidente in presenza di crawling particolarmente intenso.
Anche quando una singola pagina trasferisce solamente alcune centinaia di KB, migliaia o decine di migliaia di richieste possono generare rapidamente diversi GB di traffico.
Se il crawler continua a visitare il sito per giorni o settimane, il volume complessivamente trasferito può diventare molto elevato.
In casi particolarmente intensi, una parte rilevante del traffico mensile del sito può quindi essere generata non dai normali visitatori, ma proprio dai crawler automatici.
Sì.
Il problema non riguarda solamente la banda.
Su un sito dinamico ogni richiesta potrebbe comportare:
| 1. | l'esecuzione di PHP; |
| 2. | il caricamento del CMS; |
| 3. | l'esecuzione di plugin o moduli; |
| 4. | interrogazioni al database; |
| 5. | la generazione dinamica della pagina; |
| 6. | il trasferimento del contenuto al crawler. |
Se queste operazioni vengono ripetute centinaia o migliaia di volte in un breve intervallo, il crawler può contribuire a saturare:
| - | CPU; |
| - | memoria RAM; |
| - | processi PHP; |
| - | connessioni contemporanee; |
| - | risorse del database. |
Il sito potrebbe quindi rallentare o diventare temporaneamente difficile da raggiungere anche quando il limite mensile di banda non è stato ancora raggiunto.
Allo stesso modo, un sito potrebbe avere risorse hardware sufficienti ma esaurire comunque la banda a causa dell'elevata quantità di dati trasferiti.
Se il piano hosting prevede un limite mensile di traffico e questo viene completamente utilizzato, il sito potrebbe temporaneamente non essere più raggiungibile.
A seconda della configurazione del server potrebbe, ad esempio, essere visualizzato un messaggio simile a:
| Bandwidth Limit Exceeded |
In una situazione di questo tipo potrebbe sembrare necessario effettuare immediatamente un upgrade del piano hosting.
Prima di procedere consigliamo però di verificare da dove proviene effettivamente il traffico.
Se una parte consistente della banda è stata utilizzata da Meta-ExternalAgent o da altri crawler automatici, potrebbe essere possibile ridurre drasticamente il consumo intervenendo sul crawler, senza che sia necessariamente necessario aumentare il piano hosting.
È possibile verificarlo analizzando gli access log del dominio e cercando richieste contenenti:
| meta-externalagent |
Ad esempio:
| meta-externalagent/1.1 |
La semplice presenza di alcune richieste non rappresenta normalmente un problema.
Ciò che deve essere valutato è soprattutto:
| - | il numero complessivo delle richieste; |
| - | la frequenza delle richieste; |
| - | per quanto tempo continuano; |
| - | quante URL differenti vengono visitate; |
| - | quanto traffico dati viene generato; |
| - | quale percentuale della banda del sito è riconducibile al crawler. |
Se vengono rilevate centinaia o migliaia di richieste concentrate in un breve intervallo oppure richieste continue per molte ore, il traffico generato può diventare rilevante.
No.
Meta-ExternalAgent è un crawler dichiarato da Meta.
La sua presenza nei log non significa quindi che il sito sia sotto attacco o che sia stato compromesso.
Il problema, quando presente, è legato principalmente alla quantità e alla frequenza delle richieste.
Anche un crawler legittimo può infatti provocare un consumo rilevante di banda e risorse se effettua un numero molto elevato di accessi.
No.
Meta utilizza differenti crawler per differenti finalità.
Meta-ExternalAgent è specificamente associato all'acquisizione e indicizzazione di contenuti Web anche per finalità relative ai sistemi di intelligenza artificiale e al miglioramento dei prodotti Meta.
Non deve quindi essere confuso automaticamente con gli altri crawler utilizzati da Facebook e Meta per funzionalità differenti, come il recupero di informazioni relative ai link condivisi.
Questo significa che bloccare esclusivamente:
| meta-externalagent |
non equivale a bloccare tutti i crawler o tutti i servizi Facebook, Instagram o Meta.
Sì.
È possibile intervenire in diversi modi, a seconda delle esigenze e della configurazione dell'hosting:
| - | tramite robots.txt; |
| - | tramite .htaccess; |
| - | tramite firewall applicativo; |
| - | tramite ModSecurity; |
| - | tramite altre regole di sicurezza lato server. |
Quando il crawler sta generando un traffico particolarmente elevato, può essere preferibile utilizzare un sistema che blocchi effettivamente le richieste prima che queste raggiungano il CMS.
È possibile aggiungere al file robots.txt:
|
User-agent: meta-externalagent Disallow: / |
In questo modo viene indicato al crawler che non deve visitare le pagine del sito.
Il file robots.txt rappresenta però principalmente una direttiva destinata ai crawler e non deve essere considerato un sistema di sicurezza o un vero controllo degli accessi.
Quando l'obiettivo è interrompere rapidamente un'attività che sta consumando una quantità elevata di banda o di risorse, può essere preferibile effettuare un blocco direttamente a livello server.
Su hosting Apache è possibile inserire nel file .htaccess presente nella directory principale del sito:
|
RewriteEngine On RewriteCond %{HTTP_USER_AGENT} meta-externalagent [NC] RewriteRule ^ - [F,L] |
Le richieste contenenti meta-externalagent nello User-Agent riceveranno una risposta HTTP:
| 403 Forbidden |
La regola riguarda esclusivamente questo User-Agent.
Non vengono quindi bloccati i normali visitatori, Googlebot o altri crawler che utilizzano User-Agent differenti.
Quando il crawler sta generando un numero particolarmente elevato di richieste, è preferibile bloccarlo il prima possibile nel processo di elaborazione.
Su un sito dinamico una richiesta che raggiunge normalmente WordPress, PrestaShop, Joomla o un altro CMS può comportare:
| 1. | avvio di PHP; |
| 2. | caricamento dell'applicazione; |
| 3. | caricamento di plugin e moduli; |
| 4. | interrogazioni al database; |
| 5. | generazione della pagina; |
| 6. | trasferimento della risposta. |
Ripetendo queste operazioni migliaia di volte, il consumo complessivo di CPU, RAM, processi PHP e database può diventare significativo.
Se invece la richiesta viene intercettata da una regola di sicurezza prima di raggiungere l'applicazione, gran parte di queste elaborazioni può essere evitata.
Per questo motivo, soprattutto in presenza di overcrawling, può essere particolarmente efficace applicare una regola ModSecurity direttamente lato server.
ModSecurity consente di applicare regole di sicurezza direttamente a livello web server.
È quindi possibile creare una regola che riconosca lo User-Agent:
| meta-externalagent |
e bloccare le relative richieste prima che queste vengano normalmente elaborate dall'applicazione.
Rispetto a un blocco realizzato tramite un plugin del CMS, questo approccio presenta il vantaggio di intervenire prima che WordPress, PrestaShop o altri software debbano essere caricati.
Può quindi contribuire a ridurre:
| - | utilizzo della CPU; |
| - | utilizzo della RAM; |
| - | processi PHP; |
| - | interrogazioni al database; |
| - | connessioni contemporanee; |
| - | traffico generato dalle pagine che non vengono più trasferite integralmente al crawler. |
Se non sai come intervenire direttamente sul sito oppure non vuoi modificare autonomamente .htaccess o robots.txt, puoi richiedere assistenza tecnica.
Se il sito è ospitato sui nostri server, puoi aprire un ticket chiedendo la verifica del traffico generato da:
| Meta-ExternalAgent |
e, qualora necessario, richiederne il blocco direttamente lato server tramite ModSecurity.
Possiamo in questo modo applicare una specifica regola di sicurezza che impedisca al crawler di continuare a effettuare richieste verso il sito.
Questa soluzione può essere particolarmente utile quando Meta-ExternalAgent sta effettuando richieste continue e il cliente non riesce a bloccarlo autonomamente.
Un blocco lato server può contribuire a ridurre:
| - | consumo della banda; |
| - | utilizzo della CPU; |
| - | consumo della memoria RAM; |
| - | numero di processi PHP; |
| - | interrogazioni al database; |
| - | connessioni contemporanee; |
| - | rischio di raggiungere i limiti di risorse del piano hosting. |
Sì, se il crawler rappresenta una quota significativa del traffico complessivo.
Naturalmente il beneficio dipende dalla situazione specifica.
Se Meta-ExternalAgent genera solamente una percentuale minima del traffico, la differenza sarà limitata.
Se invece l'analisi dei log evidenzia migliaia di richieste e una parte importante della banda mensile viene utilizzata dal crawler, il blocco può determinare una riduzione molto significativa del traffico.
Abbiamo riscontrato casi nei quali una quota rilevante del traffico di un sito proveniva proprio da Meta-ExternalAgent e il crawler contribuiva al raggiungimento del limite mensile di banda disponibile.
Dipende dalla causa effettiva del consumo.
Se il sito riceve realmente molti visitatori e le risorse o la banda disponibili non sono più sufficienti, l'upgrade del piano hosting può essere la soluzione corretta.
Se invece una parte molto elevata del traffico e delle risorse viene utilizzata automaticamente da Meta-ExternalAgent, può essere opportuno intervenire prima sul crawler.
Effettuare semplicemente un upgrade aumenterebbe infatti le risorse o la quantità di banda disponibile senza eliminare la causa del consumo anomalo.
Consigliamo quindi di:
| 1. | verificare il traffico complessivo del sito; |
| 2. | analizzare gli access log; |
| 3. | individuare i crawler che effettuano il maggior numero di richieste; |
| 4. | verificare quanta banda e quante risorse utilizzano; |
| 5. | bloccare eventualmente Meta-ExternalAgent; |
| 6. | verificare successivamente se il piano hosting risulta ancora insufficiente. |
Le tre soluzioni operano in maniera differente.
robots.txt
Comunica al crawler che non deve visitare il sito:
|
User-agent: meta-externalagent Disallow: / |
È semplice da configurare, ma non rappresenta un vero sistema di blocco degli accessi.
.htaccess
Rifiuta le richieste quando raggiungono Apache:
|
RewriteEngine On RewriteCond %{HTTP_USER_AGENT} meta-externalagent [NC] RewriteRule ^ - [F,L] |
È una soluzione efficace e può essere gestita direttamente dal proprietario del sito quando dispone dell'accesso ai relativi file.
ModSecurity
Consente di intercettare il crawler attraverso una regola di sicurezza applicata direttamente lato server.
È particolarmente indicato quando il traffico è molto intenso oppure quando il cliente non può o non sa modificare autonomamente la configurazione del sito.
Quando l'obiettivo principale è ridurre immediatamente il consumo di CPU, RAM, processi PHP e banda provocato da un'attività di crawling particolarmente intensa, un blocco lato server tramite ModSecurity può rappresentare una delle soluzioni più efficaci.
Se viene bloccato esclusivamente lo User-Agent:
| meta-externalagent |
non vengono automaticamente bloccati tutti i servizi Meta.
Meta utilizza infatti crawler e User-Agent differenti per funzioni differenti.
Il blocco di Meta-ExternalAgent non deve quindi essere confuso con il blocco generale di Facebook, Instagram o di tutti i sistemi Meta.
È comunque opportuno tenere presente che Meta può modificare nel tempo il funzionamento e le finalità dei propri crawler.
Per informazioni aggiornate consigliamo pertanto di consultare la documentazione ufficiale:
https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/
Meta-ExternalAgent è un crawler legittimo utilizzato da Meta per acquisire e indicizzare contenuti pubblicamente disponibili sul Web, anche per finalità relative all'addestramento dei modelli di intelligenza artificiale e al miglioramento dei prodotti Meta.
La sua presenza nei log non rappresenta quindi, di per sé, un attacco o una compromissione del sito.
Il problema può nascere quando il crawler effettua un numero particolarmente elevato di richieste per periodi prolungati.
In queste circostanze il consumo può riguardare non solamente la banda disponibile, ma anche le risorse hardware e applicative dell'hosting, quali CPU, memoria RAM, processi PHP, connessioni contemporanee e database.
Su un sito dinamico migliaia di richieste automatiche possono contribuire alla saturazione delle risorse disponibili, provocando rallentamenti o, nei casi più intensi, rendendo temporaneamente difficile o impossibile la normale navigazione.
Allo stesso tempo, un'attività prolungata del crawler può generare un volume di traffico molto elevato e contribuire significativamente al raggiungimento del limite mensile di banda.
Prima di effettuare un upgrade del piano esclusivamente per aumentare la banda o le risorse disponibili è quindi consigliabile verificare l'origine effettiva del traffico.
Se una parte significativa delle richieste proviene da Meta-ExternalAgent, è possibile intervenire tramite robots.txt, .htaccess oppure mediante una specifica regola ModSecurity applicata direttamente lato server.
Se non sai come intervenire autonomamente, puoi aprire un ticket di assistenza richiedendo la verifica ed eventualmente il blocco lato server di Meta-ExternalAgent, in modo da evitare che richieste automatiche continue possano consumare inutilmente una parte significativa della banda e delle risorse hardware disponibili.


©