facebookexternalhit e Amazonbot saturano il server? Diagnosi, rate limiting e blocco selettivo dei crawler Meta e Amazon

Bot legittimi, volumi da DDoS: la dimensione del problema

Un cliente segnala il server in ginocchio. Dai log non emerge nessun attacco: il traffico arriva da user-agent dichiarati, facebookexternalhit/1.1 e Amazonbot/0.1, con IP che appartengono davvero a Meta e Amazon. È lo scenario più frequente del 2024-2026: non un DDoS, ma crawler legittimi che operano a volumi indistinguibili da un DDoS.

I numeri documentati pubblicamente danno la scala del fenomeno:

• Nel thread sul forum developer di Meta (giugno-agosto 2024) un singolo sito registra da facebookexternalhit una progressione di 62.772 → 84.284 → 137.907 → 197.321 richieste in un giorno (~565.000 in 5 giorni), con burst da 5.000 richieste in meno di 2 minuti e load average passato da 0,5 a 12-15. Risposta di Meta nel thread: nessuna.
• Un sito statico su Vercel ha ricevuto 11 milioni di richieste in 30 giorni da facebookexternalhit — una ogni 0,23 secondi, sempre sulle stesse ~50 URL di un sito non aggiornato da mesi. Fattura serverless: 2.417 dollari contro i 20-30 abituali.
• Read the Docs ha documentato 10 TB scaricati in un mese attribuiti al downloader di Facebook; bloccando gli AI crawler la banda è calata del 75% (~1.500 $/mese risparmiati). Le email a Meta sono tornate indietro.
• Secondo i dati Fastly relativi al Q2 2025, i crawler di Meta generano da soli il 52% del traffico mondiale da crawler AI, contro il 23% di Google e il 20% di OpenAI. Cloudflare Radar colloca meta-externalagent al terzo posto (19%) e Amazonbot al quarto (11%) tra gli AI crawler per volume.
• Sul fronte Amazon: un’istanza Discourse ha misurato 39.649 richieste in due giorni da Amazonbot contro 457 di tutti gli altri crawler; il pod diaspora* di Dennis Schubert ha contato 11,3 milioni di richieste in 60 giorni, di cui il 70% da bot AI, con Amazonbot al 14,9%.

Il problema ha tre caratteristiche che lo distinguono da un attacco: i bot si identificano onestamente nello user-agent (quindi sono filtrabili), non esiste alcun canale efficace per negoziare il ritmo (i canali ufficiali [email protected] e [email protected] risultano non rispondere nei casi documentati), e nessuno dei due operatori documenta un back-off su HTTP 429. La soluzione è quindi sempre lato tuo: server, CDN o WAF.

Questa guida copre il percorso completo: diagnosi dai log, identificazione dei bot (le famiglie Meta e Amazon nel 2026 sono più articolate di quanto sembri), verifica di autenticità, e una strategia di mitigazione a 4 livelli — dalla cache al blocco — con configurazioni pronte per Cloudflare, Nginx e Apache. Per la domanda strategica complementare — conviene farsi scansionare dai crawler AI in cambio di citazioni? — rimando all’analisi su come gestire i crawler AI: bloccare o farsi citare.

Diagnosi dai log: quantificare prima di toccare la configurazione

Prima di qualunque intervento servono quattro numeri: quante richieste fa ciascun bot, con che distribuzione temporale, su quali URL, e quanta banda consuma. Senza questi dati non puoi scegliere il livello di mitigazione corretto né misurare l’effetto dell’intervento. Se non hai familiarità con il formato combined log, parti da come leggere il log del web server.

# 1. Classifica degli user-agent per volume
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20

# 2. Distribuzione temporale di un bot (richieste per minuto: individua i burst)
grep -F 'facebookexternalhit' access.log \
  | awk '{print substr($4, 2, 17)}' | uniq -c | sort -rn | head -10

# 3. Le URL più richieste dal bot (il pattern "stesse 50 URL in loop" è tipico)
grep -F 'facebookexternalhit' access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

# 4. Banda consumata dal bot (colonna 10 = byte trasferiti nel combined log)
grep -F 'Amazonbot' access.log | awk '{s+=$10} END {printf "%.2f GB\n", s/1e9}'

# 5. Quota di richieste dagli IPv6 di Meta (suffisso caratteristico ::face:b00c)
grep -c 'face:b00c' access.log

Tre pattern ricorrenti a cui prestare attenzione:

• Stesse URL richieste in loop: nel caso Vercel citato sopra il bot richiedeva ~50 URL immutate milioni di volte. È il pattern ideale per la mitigazione via cache (livello 0), perché il contenuto è sempre identico.
• Endpoint dinamici a basso valore: Amazonbot è stato documentato mentre martellava /wp-json/oembed/1.0/embed su WordPress a migliaia di richieste al minuto — un endpoint che esegue PHP a ogni hit e che nessun utente reale usa direttamente. In questi casi la risposta corretta è un blocco chirurgico su quell’endpoint, non sull’intero sito.
• Traffico prevalentemente IPv6 per Meta: gli IP dei crawler Meta hanno spesso il suffisso vanity ::face:b00c (es. 2a03:2880:21ff:c::face:b00c), utile per un grep rapido.

Per il monitoraggio continuo in tempo reale, GoAccess resta lo strumento più rapido da mettere in campo; per analisi più profonde su log voluminosi vedi l’analisi log con Python e Regex.

La famiglia di crawler Meta nel 2026

La documentazione ufficiale Meta elenca oggi cinque crawler attivi, ciascuno con scopo e comportamento robots.txt diversi. Conoscerli è indispensabile: la mitigazione corretta per uno è sbagliata per un altro.

Crawler	User-agent	Scopo dichiarato	Rispetta robots.txt?
FacebookExternalHit	facebookexternalhit/1.1	Link preview su Facebook, Instagram, Messenger	Parziale: può bypassarlo per “security or integrity checks”
Meta-ExternalAgent	meta-externalagent/1.1	Training dei foundation model AI + indicizzazione prodotti	Sì (nessuna eccezione dichiarata)
Meta-WebIndexer	meta-webindexer/1.1	Qualità dei risultati e citazioni in Meta AI search	Sì (nessuna eccezione dichiarata)
Meta-ExternalFetcher	meta-externalfetcher/1.1	Fetch on-demand su richiesta utente (AI agentica)	No: “may bypass robots.txt” (fetch richiesti dall’utente)
Meta-ExternalAds	meta-externalads/1.1	Advertising e prodotti business	Sì (nessuna eccezione dichiarata)

Cinque fatti operativi che emergono dalla documentazione e dai casi sul campo:

• facebookexternalhit non è un crawler in senso classico: è un fetcher attivato dalle condivisioni. Ogni volta che un URL del tuo sito viene condiviso (o ri-processato) su Facebook, Instagram o Messenger, il fetcher lo richiede per generare l’anteprima. Per questo il volume non è proporzionale alle dimensioni del sito ma alla sua viralità — e per questo il robots.txt non è uno strumento di controllo affidabile su questo UA.
• meta-externalagent è il crawler AI, lanciato senza annuncio a fine luglio 2024. Nei log dei siti colpiti nel 2024 si osserva uno shift netto: il traffico che prima arrivava come facebookexternalhit si è progressivamente spostato su meta-externalagent/1.1 dal 26 luglio 2024. Rispetta robots.txt, quindi è il più facile da fermare.
• FacebookBot è stato ritirato: la sua pagina di documentazione risulta redirettata tra novembre 2024 e gennaio 2025. Era l’unico crawler Meta a dichiarare il supporto a Crawl-delay. Se lo trovi ancora nelle liste di blocco di settore è innocuo, ma nel 2026 va trattato come legacy: nessun crawler Meta attuale dichiara supporto a Crawl-delay.
• Il robots.txt viene cachato fino a 24 ore (“Please allow up to 24 hours for changes to robots.txt to take effect”): non aspettarti effetti immediati.
• Per simulare il crawler in debug, la doc ufficiale fornisce il comando esatto: curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "$URL".

La famiglia di bot Amazon nel 2026

Anche Amazon opera una famiglia di crawler, documentata su developer.amazon.com/amazonbot. La distinzione è cruciale perché i tre bot hanno scopi — e costi di blocco — molto diversi.

Bot	User-agent	Scopo dichiarato	AI training?
Amazonbot	Amazonbot/0.1	Migliorare prodotti e servizi Amazon	Sì: “may be used to train Amazon AI models”
Amzn-SearchBot	Amzn-SearchBot/0.1	Esperienze di ricerca Amazon (es. Alexa)	No (dichiarato esplicitamente)
Amzn-User	Amzn-User/0.1	Fetch on-demand per richieste utente (es. risposte Alexa live)	No (dichiarato esplicitamente)
AmazonAdBot	AmazonAdBot/1.0	Brand safety e contestualizzazione annunci (doc separata)	—

I fatti operativi chiave:

• Crawl-delay non è supportato, per dichiarazione esplicita. La doc ufficiale è testuale: “Amazon crawlers do not support the crawl-delay directive”. Qualunque guida che suggerisca Crawl-delay per Amazonbot propone una direttiva che il bot ignora per design.
• Allow/Disallow sono rispettati, ma con una cache del robots.txt fino a 30 giorni (“Amazon will fetch host-level robots.txt files or use a cached copy from the last 30 days”). Un Disallow inserito oggi può richiedere un mese per avere pieno effetto: nel frattempo serve una mitigazione server-side.
• Dal 15 giugno 2026 il robots.txt è l’unico canale di controllo: Amazon ha comunicato ai publisher che “crawl preferences for Amazonbot will be managed solely through the industry-standard directives”, chiudendo il vecchio processo manuale via Publisher Support (email riprodotta da Xe Iaso).
• L’opt-out dal training AI a livello di pagina passa dal meta robots noarchive, che la doc Amazon definisce “do not use the page for model training”.
• Come per Meta, nessun comportamento documentato su HTTP 429: la doc non menziona back-off né rate limit.

Verificare l'autenticità: una parte del traffico è spoofed

Prima di attribuire il sovraccarico a Meta o Amazon, verifica gli IP. Nel caso documentato da Xe Iaso (gennaio 2025) una quota rilevante del traffico “Amazonbot” arrivava da IP residenziali a rotazione con UA variabili: scraper terzi che impersonano bot noti per passare inosservati. Un dipendente Amazon ha confermato su Hacker News che il vero Amazonbot “should always come from an Amazon-owned IP address”. La logica è la stessa della verifica di Googlebot: mai fidarsi dello user-agent, sempre verificare l’origine.

Per Amazon esistono liste IP ufficiali in JSON, una per bot:

# Lista IP ufficiale di Amazonbot (JSON con creationTime e prefissi)
curl -s https://developer.amazon.com/amazonbot/ip-addresses/ | jq -r '.prefixes[].ipv4Prefix'
# Amzn-SearchBot: https://developer.amazon.com/amazonbot/searchbot-ip-addresses/
# Amzn-User:      https://developer.amazon.com/amazonbot/live-ip-addresses/

# Verifica reverse DNS + forward-confirm di un IP sospetto
dig -x 23.22.35.162 +short
# → 23-22-35-162.crawl.amazonbot.amazon  (dominio .amazon, non spoofabile)
dig 23-22-35-162.crawl.amazonbot.amazon +short
# → deve restituire lo stesso IP di partenza

Le liste vanno riscaricate periodicamente (il campo creationTime indica l’ultima revisione). Regola operativa: UA “Amazonbot” + IP fuori lista e senza PTR sotto crawl.amazonbot.amazon = impostore, bloccabile senza alcun rischio.

Per Meta la situazione è peggiore: la documentazione attuale suggerisce di mettere in allow-list “the user agent strings or the IP addresses (more secure)” ma non pubblica più né IP range né un endpoint machine-readable. Il metodo che la doc ufficiale raccomandava fino al redesign del 2024 — e che resta lo standard de facto del settore — è interrogare i route annunciati dall’ASN di Meta (AS32934):

# Route annunciati da AS32934 (Meta) — metodo storico-ufficiale, tuttora valido
whois -h whois.radb.net -- '-i origin AS32934' | grep ^route
# Esempi tipici: 69.63.176.0/21, 66.220.144.0/20, 2a03:2880::/32

Il reverse DNS verso *.facebook.com / *.fbsv.net funziona in pratica ma non è mai stato documentato da Meta: trattalo come euristica di supporto, non come fonte di verità.

Cosa non funziona: og:ttl, Crawl-delay e altre soluzioni obsolete

La maggior parte delle guide in circolazione su questo problema ricicla soluzioni che non funzionano più — o che non hanno mai funzionato. Verificarle sulle fonti primarie evita di sprecare giorni su interventi inefficaci.

og:ttl è morto nel 2020. Il meta tag <meta property="og:ttl" content="2592000" /> viene ancora raccomandato ovunque come rate limiter per il crawler di Facebook. La realtà documentata: og:ttl è stato rimosso dalla documentazione Meta nella seconda metà del 2020 (la sezione “Crawler Rate Limits” che lo conteneva è sparita tra giugno e dicembre 2020, come si verifica sugli snapshot della Wayback Machine) e non compare più in nessuna pagina della doc attuale. Già quando era documentato, il minimo era 345.600 secondi (4 giorni) e i report dell’epoca lo davano per ignorato in pratica. La guidance ufficiale attuale dice semplicemente che il crawler aggiorna i metadati dei link ogni 30 giorni in automatico. Se una guida ti propone og:ttl come soluzione, è ferma a sei anni fa.

Crawl-delay è quasi ovunque lettera morta. Lo stato reale del supporto nel 2026:

Bot	Supporto Crawl-delay	Fonte
Googlebot	No, mai supportato	Doc ufficiale robots.txt
Bingbot	Sì (finestra 1-30 s)	Doc/blog ufficiale Bing Webmaster
Amazonbot (famiglia)	No, esclusione dichiarata	Doc ufficiale
Crawler Meta attuali	Non documentato per nessuno dei 5	Doc ufficiale
FacebookBot (ritirato)	Sì, quando esisteva	Doc archiviata 2024

Per l’unico caso in cui la direttiva serve ancora (Bingbot), vedi la guida alla direttiva Crawl-delay. Per i bot di questo articolo: inutile.

Il 429 non “negozia” con questi bot. Googlebot tratta il 429 come segnale di sovraccarico e rallenta — ma attenzione: un 429 persistente porta alla rimozione degli URL dall’indice, quindi le regole di rate limiting non devono MAI colpire Googlebot, pena danni al crawl budget e all’indicizzazione. Per i crawler Meta non esiste alcuna documentazione su 429/Retry-After e l’evidenza empirica dal 2020 al 2025 è che non riducono il ritmo. Il 429 resta comunque la risposta corretta da servire (protegge l’origin ed è semanticamente onesta), ma va inteso come scudo, non come messaggio che il bot ascolterà.

fail2ban è strutturalmente debole contro questi bot. Il ban per IP funziona contro origini stabili, ma Meta e Amazon crawlano da centinaia di IP a rotazione (Meta prevalentemente IPv6): se ogni IP resta sotto la soglia, la jail non scatta mai mentre il volume aggregato resta identico. Gli stessi maintainer di fail2ban raccomandano prudenza (ban brevi, incrementali) e indicano alternative. Usalo come rete di sicurezza, non come mitigazione primaria.

Mitigazione a 4 livelli: dalla cache al blocco

La strategia corretta è una scala di escalation: si parte dal livello che non costa nulla in termini funzionali e si sale solo se i numeri nei log lo giustificano. Ogni livello copre bot diversi — per questo la diagnosi e le tabelle delle sezioni precedenti sono propedeutiche.

Livello 0 — Cache davanti all'origin: l'unica mitigazione senza trade-off

Se il pattern nei log è “stesse URL in loop” (il caso tipico di facebookexternalhit), la cache è la risposta più efficiente: il bot continua a ricevere 200, i link preview continuano a funzionare, ma l’origin viene colpito una frazione delle volte.

Con Cloudflare (qualsiasi piano) si crea una Cache Rule mirata: espressione (http.user_agent contains "facebookexternalhit"), azione “Eligible for cache” con Edge TTL (es. 1 ora, ignorando gli header dell’origin). I bot ricevono la copia edge, l’origin respira, gli utenti reali non sono toccati dalla regola.

Con Nginx self-hosted il pattern equivalente è il microcaching: cache di 1 secondo sull’HTML dinamico. Nel benchmark ufficiale il throughput passa da 5,5 a 2.185 richieste/secondo. Un burst di migliaia di richieste sulle stesse URL colpisce l’origin al massimo una volta al secondo per URL:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=micro:10m max_size=1g;

server {
    location / {
        proxy_cache micro;
        proxy_cache_valid 200 1s;        # cache brevissima: contenuto sempre fresco
        proxy_cache_lock on;             # 1 sola richiesta all'origin per URL in refresh
        proxy_cache_use_stale updating;  # serve lo stale mentre aggiorna
        proxy_pass http://backend;
    }
}

Livello 1 — robots.txt per i bot che lo rispettano

Il robots.txt spegne pulitamente i crawler che lo onorano: meta-externalagent, meta-externalads, Amazonbot e famiglia. È inutile per facebookexternalhit (bypass dichiarato) e meta-externalfetcher (fetch on-demand). Esempio calibrato sul caso “sovraccarico da Meta + Amazon”:

# Crawler AI di Meta (training + indicizzazione prodotti Meta)
User-agent: meta-externalagent
Disallow: /

# Crawler advertising di Meta
User-agent: meta-externalads
Disallow: /

# Bot Amazon (AI training e prodotti)
User-agent: Amazonbot
Disallow: /

Tre avvertenze:

• Tempi di reazione: Meta ricarica il robots.txt entro 24 ore, Amazon può usare una copia cache fino a 30 giorni. Il robots.txt è la soluzione strutturale, ma nel frattempo serve il livello 2 o 3.
• Scelta editoriale, non solo tecnica: bloccare meta-externalagent esclude i contenuti dal training dei modelli Meta ma anche dall’indicizzazione nei prodotti Meta; bloccare Meta-WebIndexer (qui volutamente non bloccato) eliminerebbe le citazioni in Meta AI. Il razionale completo è nell’articolo su crawler AI: bloccare o farsi citare.
• Se il robots.txt del sito ha una storia complessa, ripassa la guida completa al file robots.txt prima di modificarlo.

Chi usa Cloudflare può ottenere lo stesso risultato senza toccare il file: il managed robots.txt (tutti i piani) antepone al tuo robots.txt le direttive di blocco per gli AI crawler — la lista gestita include sia meta-externalagent sia Amazonbot, ma non facebookexternalhit, che non è classificato AI.

Livello 2 — Rate limiting per user-agent

Quando serve tenere il bot (es. vuoi i link preview di Facebook) ma a un ritmo sostenibile, il rate limiting per UA è il livello giusto. Il dettaglio che fa la differenza: il conteggio deve avvenire per user-agent, non per IP — questi bot ruotano su centinaia di IP e un limite per-IP non morde quasi mai.

Nginx è lo strumento più preciso per farlo, grazie a una proprietà documentata di limit_req_zone: le richieste con chiave vuota non vengono conteggiate. La map assegna una chiave costante per bot (bucket globale condiviso da tutti i suoi IP) e chiave vuota a tutto il resto del traffico:

http {
    # Chiave costante per i bot da limitare, vuota per tutti gli altri.
    # Chiave vuota = richiesta non conteggiata (doc ufficiale limit_req_zone).
    map $http_user_agent $aggressive_bot {
        default                 "";
        ~*facebookexternalhit   "fb";
        ~*meta-externalagent    "meta_ai";
        ~*amazonbot             "amazon";
    }

    # Un bucket globale per bot: 1 richiesta/secondo aggregata,
    # indipendentemente da quanti IP usa il crawler.
    limit_req_zone $aggressive_bot zone=bots:1m rate=1r/s;

    server {
        location / {
            limit_req zone=bots burst=5 nodelay;
            limit_req_status 429;            # il default sarebbe 503
        }

        # Risposta 429 con Retry-After esplicito
        error_page 429 = @toofast;
        location @toofast {
            add_header Retry-After 60 always;
            return 429;
        }
    }
}

Con rate=1r/s e burst=5 il bot ottiene al massimo ~86.400 richieste/giorno invece di 197.000, e l’eccedenza riceve 429 senza consumare PHP/database. Taratura: parti dal volume attuale nei log e imposta il rate a ciò che il server sostiene senza degrado.

Cloudflare: le Rate Limiting Rules esistono su tutti i piani ma con capacità diverse — ed è il punto che decide il budget:

Piano	Regole	UA nell’espressione?	Conteggio
Free	1	No (solo path e verified bot)	per IP, finestra 10 s
Pro	2	No	per IP
Business	5	Sì	per IP
Enterprise + Adv. RL	100	Sì	anche per valore header UA

Sul piano Business la regola tipo è: espressione (http.user_agent contains "facebookexternalhit"), conteggio per IP, soglia 5 richieste/10 secondi, azione Block per 1 ora. Nota il limite architetturale: il conteggio resta per-IP (ogni IP Meta ha il suo budget); il conteggio aggregato sul valore dello user-agent richiede l’Advanced Rate Limiting di Enterprise. Sul piano Free il rate limiting per UA non è configurabile: si passa direttamente al livello 3 (blocco, disponibile anche su Free) o al livello 0 (cache).

Apache: il rate limiting per UA esiste solo a livello server con ModSecurity (setvar/expirevar con contatore per UA e risposta 429 — esempio completo per Amazonbot) o mod_qos. Due trappole da evitare: le SecRule custom non funzionano in .htaccess (serve accesso root/WHM), e mod_ratelimit nonostante il nome non c’entra nulla — limita la banda in KiB/s della singola risposta, non le richieste al secondo. Su shared hosting Apache il rate limiting vero non è praticabile: la scelta reale è tra cache, robots.txt e blocco.

Livello 3 — Blocco selettivo

Quando i numeri non giustificano compromessi (o il piano/stack non permette il rate limiting), si blocca. Il blocco va fatto per user-agent — mirato e reversibile — e solo consapevoli del trade-off (sezione successiva).

Cloudflare WAF custom rule (disponibile anche su Free, 5 regole):

(http.user_agent contains "facebookexternalhit")
or (http.user_agent contains "meta-externalagent")
or (lower(http.user_agent) contains "amazonbot")

Azione: Block (o Managed Challenge, più prudente: un vero utente può superarlo, il bot no). Attenzione: contains è case-sensitive — per Amazonbot conviene normalizzare con lower(). Una custom rule su UA blocca il bot anche se è nella lista “verified bots” di Cloudflare, su qualunque piano. In alternativa, per i soli bot AI (quindi meta-externalagent e Amazonbot, non facebookexternalhit), l’AI Crawl Control offre il blocco per singolo crawler su tutti i piani.

Il blocco per ASN è l’opzione nucleare: (ip.src.asnum eq 32934) spegne tutto ciò che arriva dalla rete Meta — inclusi i fetch di WhatsApp e ogni altro servizio. Mai bloccare AS16509 (Amazon) intero: è l’intera AWS, inclusi servizi legittimi che potrebbero servirti; semmai combinare ASN + UA: (ip.src.asnum eq 16509 and lower(http.user_agent) contains "amazonbot").

Apache/.htaccess (shared hosting incluso) — due varianti equivalenti; la prima è quella che la doc Apache stessa raccomanda al posto di mod_rewrite:

# Variante 1: SetEnvIf + Require (Apache 2.4, risposta 403)
SetEnvIfNoCase User-Agent "(facebookexternalhit|meta-externalagent|Amazonbot)" bad_bot
<RequireAll>
    Require all granted
    Require not env bad_bot
</RequireAll>

# Variante 2: mod_rewrite con risposta 429 (semanticamente più corretta del 403)
RewriteEngine On
RewriteCond "%{HTTP_USER_AGENT}" "facebookexternalhit|meta-externalagent|Amazonbot" [NC]
RewriteRule "^" "-" [R=429,L]

Dettaglio sintattico: con il flag [F] il flag [L] è implicito (“When using [F], an [L] is implied” — doc ufficiale), quindi il classico [F,L] che si trova nelle guide è ridondante ma innocuo.

Nginx — blocco secco, eventualmente con return 444 (chiude la connessione senza nemmeno inviare la risposta, azzerando la banda in uscita):

map $http_user_agent $blocked_ua {
    default 0;
    ~*(facebookexternalhit|meta-externalagent|amazonbot) 1;
}

server {
    if ($blocked_ua) { return 429; }   # oppure: return 444;
}

L’if a livello server con solo return rientra negli usi dichiarati sicuri dalla nota “If is Evil” della doc Nginx — il problema noto riguarda if con direttive di contenuto dentro le location.

Un affinamento spesso risolutivo: bloccare solo dove fa male. Nel caso oEmbed citato sopra, un 403 mirato su /wp-json/oembed/* per il solo UA Amazonbot ha risolto il sovraccarico lasciando intatto tutto il resto.

Cosa perdi bloccando ciascun bot

Il blocco è una decisione di business, non solo sistemistica. Questa è la mappa costi/benefici per ogni bot, dalla documentazione ufficiale:

Bot	Cosa si perde bloccandolo	Gravità tipica
facebookexternalhit	Link preview su Facebook, Instagram, Messenger: i link condivisi appaiono “nudi”, senza titolo/immagine	Alta per chi vive di social
Meta-ExternalFetcher	Fetch degli agenti AI Meta su richiesta utente	Bassa
meta-externalagent	Contenuti esclusi dal training AI Meta e dall’indicizzazione nei prodotti Meta	Da valutare
Meta-WebIndexer	Citazioni e link nelle risposte di Meta AI	Media, crescente
Amazonbot	Presenza nei prodotti/AI Amazon	Bassa-media
Amzn-SearchBot	Contenuti esclusi dalle esperienze di ricerca Amazon (es. Alexa)	Bassa-media
AmazonAdBot	Impatto dichiarato sull’accesso alla domanda Amazon Ads	Alta solo per publisher con Amazon Ads

Due precisazioni importanti:

• WhatsApp: usa uno user-agent proprio (WhatsApp/2.x.y.z) per i link preview, quindi il blocco dell’UA facebookexternalhit in teoria non lo tocca. In pratica l’infrastruttura è condivisa e sono documentati fetch da facebookexternalhit innescati da condivisioni WhatsApp: se WhatsApp è un canale critico, testa le anteprime dopo ogni intervento. Il blocco per ASN 32934, invece, degrada WhatsApp con certezza.
• Nessun impatto SEO su Google e Bing: nessuno di questi bot c’entra con l’indicizzazione nei motori di ricerca tradizionali. Bloccarli non tocca il ranking — purché le regole siano scritte sugli UA specifici e non catturino per errore Googlebot o Bingbot.

Gestire la cache di condivisione Meta senza og:ttl

Se il problema è il re-scraping continuo delle stesse URL da parte di facebookexternalhit, gli strumenti attuali (post-og:ttl) sono tre:

• og:url coerente e canonico: se le tue pagine espongono og:url incoerenti (con/senza trailing slash, parametri di tracking, http/https misti), Facebook tratta ogni variante come oggetto separato e la ri-scansiona separatamente. Un og:url allineato al canonical riduce il numero di oggetti che il crawler gestisce.
• Refresh controllato: il crawler aggiorna i metadati automaticamente ogni 30 giorni. Quando pubblichi una modifica e vuoi l’anteprima aggiornata subito, forza il refresh dal Sharing Debugger o via API con POST https://graph.facebook.com/?id={url}&scrape=true.
• Immagini: cambia URL, non contenuto: le immagini delle anteprime sono cachate per URL. Per aggiornare l’immagine di un’anteprima, servi la nuova immagine da un URL diverso (“use a different image URL so that cached versions of the image aren’t used” — doc ufficiale).

Nessuno di questi strumenti è un rate limiter: se il crawler sta martellando, la protezione resta ai livelli 0-3. Questi accorgimenti riducono la superficie (meno oggetti, meno re-scrape), non il ritmo.

Monitoraggio post-intervento

Ogni intervento va verificato sui log, non sulle sensazioni. I tre controlli essenziali dopo il deploy:

# 1. Il rate limiting sta lavorando? (conteggio risposte 429/403 per il bot)
grep -F 'facebookexternalhit' access.log | awk '{print $9}' | sort | uniq -c

# 2. Confronto richieste/giorno del bot prima/dopo
grep -F 'Amazonbot' access.log | awk '{print substr($4, 2, 11)}' | uniq -c

# 3. Nessun falso positivo: Googlebot NON deve ricevere 429
grep -F 'Googlebot' access.log | awk '{print $9}' | sort | uniq -c

Il terzo controllo è il più importante: una regex troppo larga o una regola WAF mal scritta che colpisce Googlebot produce danni SEO superiori al problema di partenza. Verifica anche il load average e la banda sul periodo (i tool sono gli stessi della sezione diagnosi).

Infine, rivaluta periodicamente: gli user-agent di questa famiglia di bot cambiano spesso (FacebookBot ritirato nel 2024, meta-externalagent nato nel 2024, Meta-WebIndexer e i bot Amzn-* più recenti) e sono documentati casi di rotazione di identità degli UA. Le regole scritte oggi vanno riviste a ogni anomalia nei log — l’approccio corretto è monitorare i top UA con cadenza mensile, non “configura e dimentica”.

Checklist operativa

1. Quantifica dai log: richieste/giorno per UA, distribuzione temporale, top URL, banda. Senza numeri niente interventi.
2. Verifica l’autenticità degli IP: liste JSON ufficiali per Amazon, route AS32934 per Meta. Il traffico spoofed si blocca senza pensarci due volte.
3. Se hai una CDN/reverse proxy: attiva subito la cache per gli UA dei bot (livello 0) — protegge l’origin senza costi funzionali.
4. Scrivi il robots.txt per i bot che lo rispettano (meta-externalagent, Amazonbot): soluzione strutturale, effetto in 24h (Meta) / fino a 30 giorni (Amazon).
5. Nel transitorio, rate-limita per user-agent: Nginx map + limit_req (bucket globale per bot, risposta 429), Cloudflare Rate Limiting da Business in su, ModSecurity su Apache con root.
6. Blocca selettivamente ciò che non ti serve: WAF custom rule (anche su Cloudflare Free), .htaccess, return 444. Prima valuta il trade-off (preview social, AI, Alexa, Amazon Ads).
7. Verifica di non aver colpito Googlebot/Bingbot, controlla i 429 nei log, monitora i top UA mensilmente.