Crawler facebookexternalhit e Meta-ExternalAds: como identificar as requisições da Meta

Quando você vê no log uma requisição com user-agent contendo facebookexternalhit ou meta-externalads, está diante do crawler que a Meta usa para validar a landing page do anúncio antes ou durante a revisão. O problema prático não é bloquear, mas entender o que cada string significa e por que user-agent sozinho não basta para confirmar que veio da Meta.

O inventário de crawlers da Meta e suas strings exatas

A Meta documenta três user-agents principais que aparecem em logs de landing pages de anúncios. O facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) é o crawler responsável por gerar previews de links compartilhados em apps da família Meta. Ele visita a página uma única vez por versão de criativo e precisa renderizar o conteúdo para extrair Open Graph.

O meta-externalads/1.1 é o agente específico para melhorar produtos de publicidade. Ele faz fetch dirigido à URL de destino do anúncio e compara o que encontra com o que foi prometido no criativo. Já o meta-externalagent/1.1 indexa conteúdo para treinar modelos de IA ou melhorar outros produtos, e aparece com menor frequência em fluxos de revisão de anúncio.

Essas strings são públicas e qualquer script pode copiá-las. Por isso, logs que mostram apenas o user-agent não comprovam origem da Meta; servem apenas como primeiro indício.

Por que user-agent sozinho é sinal fraco

Qualquer operador de bot ou ferramenta de espionagem consegue enviar exatamente o mesmo cabeçalho User-Agent que a Meta publica. O sinal confiável começa na camada de rede: a requisição precisa vir de faixas de IP anunciadas pela AS32934, o ASN da Meta. Além disso, o rDNS reverso costuma resolver para domínios sob facebook.com ou fb.com.

A Meta publica listas de faixas de IP, mas não garante estabilidade. Faixas podem mudar sem aviso prévio e alguns crawlers usam proxies internos que não aparecem na lista pública. Verificar apenas o user-agent ou apenas o IP cria falsos positivos e falsos negativos.

Restrições técnicas reais do fetch da Meta

O crawler da Meta exige resposta em poucos segundos. Se a página demorar mais que isso para entregar o HTML inicial, o conteúdo simplesmente não aparece no preview ou na revisão. Open Graph tags precisam estar dentro dos primeiros 1 MB da resposta; tags depois desse limite são ignoradas.

Redirects são seguidos, mas o comportamento esperado é que o destino final entregue o mesmo conteúdo prometido no anúncio. Redirects em cadeia longos ou que mudam de domínio podem fazer a revisão falhar. O crawler também não executa JavaScript pesado de forma confiável, então páginas que dependem de renderização client-side para mostrar o conteúdo principal correm risco de serem consideradas vazias.

O que a presença desses hits revela sobre o ciclo de revisão

Um hit de meta-externalads costuma aparecer minutos ou horas após o envio do anúncio para revisão. Se o anúncio ainda está em análise, o hit indica que o sistema automatizado está validando a landing page. Hits repetidos na mesma URL em intervalos curtos sugerem que a Meta está reavaliando após uma mudança ou após uma reclamação.

A ausência de hits não significa que o anúncio não foi revisado; pode significar que a revisão usou cache ou outro caminho. A presença consistente de hits vindos de IPs da Meta, no entanto, confirma que a landing page está sendo avaliada ativamente.

Como identificar tráfego da Meta sem quebrar o preview

Registre o user-agent completo, o IP de origem e o rDNS em cada requisição. Compare o IP contra as faixas publicadas pela Meta e verifique se o rDNS termina em facebook.com. Combine esses sinais com o timestamp: hits de revisão costumam vir logo após upload do anúncio.

Evite regras de bloqueio baseadas só em user-agent. Bloquear facebookexternalhit impede que o preview funcione corretamente e pode ser interpretado como tentativa de evasão. Em vez disso, classifique a visita como "tráfego de plataforma" e sirva a página real sem modificação.

Trade-offs de diferentes abordagens de identificação

Verificar só user-agent é rápido de implementar, mas fraco contra falsificação. Verificar só IP é mais forte, porém as faixas da Meta mudam e alguns crawlers usam infraestrutura interna. A combinação de UA + ASN + rDNS + comportamento de tempo de resposta reduz falsos positivos e permite tratar o tráfego de revisão de forma distinta sem quebrar previews.

Bloquear facebookexternalhit quebra o preview de link no Facebook?

Sim. O crawler precisa acessar a página para gerar a imagem e o título do preview. Bloqueá-lo impede que o link apareça corretamente quando alguém compartilha o anúncio.

O meta-externalads é o único crawler que faz revisão de anúncio?

Não. Ele é o principal para validação de landing page de anúncios, mas facebookexternalhit também aparece em fluxos de preview e o meta-externalagent pode indexar conteúdo para outros produtos da Meta.

Dá para confiar só no user-agent para identificar o crawler da Meta?

Não. Qualquer script consegue copiar a string publicada. A verificação precisa incluir ASN, rDNS e, idealmente, fingerprint de conexão.

O que acontece se a página demorar mais que alguns segundos para responder?

O crawler da Meta desiste e o conteúdo não é indexado para preview ou revisão, o que pode fazer o anúncio ser rejeitado por "página não funcional".

A Meta publica todas as faixas de IP que usa para crawl?

Publica as principais, mas não garante que todos os crawlers usem apenas essas faixas nem que a lista permaneça estável.

Observe os logs com os três sinais combinados: user-agent, ASN e tempo de resposta. Isso separa tráfego de revisão legítimo de bots que apenas copiam a string de user-agent.