Como verificar rastreadores e agentes de IA pelo IP: DNS reverso, intervalos CIDR e Web Bot Auth

Você vê GPTBot, ClaudeBot ou PerplexityBot nos seus logs e precisa decidir: permitir, limitar a taxa ou bloquear. Mas, antes de tudo isso, precisa responder a uma pergunta mais básica: é mesmo esse bot? Porque um cabeçalho User-Agent é uma alegação, não uma prova. Qualquer um pode rodar curl -A "GPTBot/1.3" https://your-site.com e os seus logs vão registrar "GPTBot" obedientemente.

Isso não é teórico. A equipe Satori da HUMAN Security constatou que 5,7% de todo o tráfego que dizia ser um rastreador de IA conhecido era falsificado, com picos de 7,7% em alguns dias (~2 milhões de requisições/dia), e o agente ChatGPT-User imitado em aproximadamente uma de cada seis requisições. Este guia mostra as três formas reais de verificar um rastreador nas camadas de IP e de criptografia (DNS reverso com confirmação direta, allowlists CIDR publicadas pelos operadores e Web Bot Auth), além dos modos de falha que derrubam quase todos os outros guias.

Por que um User-Agent "GPTBot" não prova nada

O User-Agent é um metadado autodeclarado. Não há autenticação nele, nada assinado, nada que um servidor de origem possa checar. Verificar um rastreador significa vincular a requisição a uma infraestrutura ou a uma chave que o operador realmente controla. Existem exatamente três regimes que fazem isso:

1. DNS reverso com confirmação direta (FCrDNS): provar que o IP resolve para o domínio do operador e a partir dele.
2. Allowlists CIDR publicadas: comparar o IP com os intervalos que o operador publica.
3. Web Bot Auth (RFC 9421): verificar uma assinatura criptográfica na própria requisição.

Tudo o que vem a seguir trata de fazer isso corretamente e de saber o que cada método pode e não pode provar.

O que está em jogo em 2026: os bots são a maioria da web

A verificação de rastreadores deixou de ser um nicho de SEO no momento em que o tráfego automatizado se tornou a maior parte da internet. O Bad Bot Report 2026 da Imperva constatou que o tráfego automatizado representou 53% do tráfego web observado em 2025 e que só os bots maliciosos representaram 40%. Quando a maioria das requisições é automatizada e os rastreadores de IA continuam crescendo em volume, "esse bot é real?" vira uma pergunta nos seus endpoints de login, cadastro e checkout, não só no seu robots.txt. No checkout, agora também é uma questão de fraude: veja como barrar fraudes de agentes de compra com IA sem bloquear vendas reais feitas por agentes. Para saber qual sinal de IP responde a qual pergunta sobre bots, de intervalos de rastreadores a sinalizações de scanners, veja o nosso guia central sobre detecção de bots pelo IP.

Método 1: DNS reverso com confirmação direta, do jeito certo

O FCrDNS é o método canônico que o Google documenta para verificar o Googlebot. Quatro etapas:

Por que a etapa direta é essencial: um atacante controla o registro reverso (PTR) do próprio IP, então pode apontar 1.2.3.4 para crawl-fake.googlebot.com. O que ele não consegue é forjar o DNS direto autoritativo de googlebot.com para fazer esse hostname resolver de volta para 1.2.3.4. Uma checagem que só compara a string do registro PTR com "googlebot.com" (o que um número surpreendente de tutoriais sugere) pode, ela mesma, ser falsificada. A confirmação direta é o ponto central. No caso específico do Google, com os seus três tipos de rastreador e os respectivos arquivos de intervalos, veja o nosso guia sobre como verificar o Googlebot pelo IP e identificar Googlebots falsos.

O limite de precisão a destacar: registros PTR são opcionais e frequentemente ausentes, sobretudo nos fornecedores de IA mais novos. Quando não há PTR, o FCrDNS retorna "não verificável", o que não é nem aprovação nem reprovação. É aí que entra o Método 2.

Método 2: allowlists CIDR publicadas, por bot

A maioria dos fornecedores de IA não publica registros PTR e, em vez disso, publica os intervalos de IP dos rastreadores em JSON. Essa é a checagem mais prática no dia a dia. Baixe o feed de fonte primária de cada operador:

• OpenAI: arquivos por bot: openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json (documentação dos rastreadores da OpenAI).
• Google: cinco arquivos de CIDRs em developers.google.com/static/crawling/ipranges/.
• Anthropic: publica um único arquivo para os seus bots, claude.com/crawling/bots.json, vinculado na sua página de ajuda sobre rastreadores. A lista de endereços da documentação da plataforma é para a API, não para os rastreadores.
• Perplexity: perplexitybot.json e perplexity-user.json.
• Apple iCloud Private Relay: um CSV de saídas em mask-api.icloud.com/egress-ip-ranges.csv (documentação da Apple). Atenção: são pessoas em um relay de privacidade, não bots. Coloque-as na allowlist; não as bloqueie.

Carregamos 19 arquivos de intervalos de rastreadores de 10 operadores; a lista de IPs de rastreadores verificados traz cada um, com a data correspondente e como montar a allowlist.

Três regras separam uma implementação correta de uma quebrada:

• Associe cada bot aos arquivos do seu operador, e ao próprio arquivo apenas quando o operador publica um por bot. O GPTBot está em gptbot.json, não em "algum intervalo da OpenAI", e comparar com o arquivo errado da OpenAI confunde um rastreador de treinamento com um fetcher iniciado pelo usuário. A Anthropic publica um único arquivo compartilhado para os seus três bots, e os dois arquivos do DuckDuckGo são idênticos, então nesses casos o operador é a correspondência mais precisa disponível. A nossa comparação GPTBot vs OAI-SearchBot vs ChatGPT-User mostra o que cada bot da OpenAI faz, quanto custa bloqueá-lo e uma consulta real de cada arquivo.
• Compare com o prefixo exato publicado, nunca com o ASN de hospedagem. Colocar "toda a AWS" ou "todo o Google Cloud" na allowlist porque um bot roda lá vai deixar passar todo atacante na mesma nuvem.
• Atualize periodicamente. Esses intervalos mudam; trate-os como um feed, não como uma constante.

Assimetria entre fornecedores: qual método sequer existe

A maioria dos guias mistura os fornecedores. Eles diferem tanto em qual método de verificação existe quanto nos tokens de rastreador que cada um usa, que têm implicações de política diferentes:

A nuance que quebra pipelines ingênuos: fetchers dirigidos por usuários se comportam como visitantes reais e podem, legitimamente, vir de fora dos intervalos de bots publicados. Quando um usuário pede a um assistente que abra uma URL específica, essa busca pode vir de infraestrutura de nuvem genérica com um User-Agent de navegador comum. Bloquear "o que não está no intervalo do GPTBot" pode, portanto, bloquear a ação do agente de um usuário real. A política de limite de taxa e de bloqueio precisa variar por token, não por fornecedor.

Como verificar rastreadores de SEO e de analytics: o AhrefsBot e companhia

Os mesmos dois métodos da camada de IP verificam os rastreadores de SEO e de analytics que as pessoas mais querem identificar nos logs: o AhrefsBot e outros como SemrushBot e DataForSeoBot. Eles não são rastreadores de IA, mas a verificação é idêntica:

• O AhrefsBot pode ser verificado por DNS reverso com confirmação direta (os endereços dele resolvem para hostnames sob os próprios domínios da Ahrefs), e a Ahrefs publica os intervalos de IP do seu rastreador para allowlists. Faça a mesma checagem FCrDNS do Método 1 ou compare com a lista publicada do Método 2.
• A armadilha é a mesma que pega os rastreadores de IA: não use allowlist por ASN. Um "AhrefsBot" chegando de um intervalo de hospedagem aleatório que você nunca verificou é exatamente o padrão de falsificação, já que qualquer um pode enviar User-Agent: AhrefsBot/7.0. Confirme o IP, não a string.

Se você está procurando "endereços IP do AhrefsBot" para montar uma regra de firewall, a versão duradoura é uma checagem de DNS reverso com confirmação direta mais o intervalo publicado pelo operador, atualizado periodicamente, e não uma lista fixa de IPs que fica obsoleta na primeira vez que o rastreador ganha capacidade.

Método 3: Web Bot Auth e verificação criptográfica

A correção estrutural para a falsificação é deixar de confiar na posição de rede e verificar uma assinatura. No Web Bot Auth, o agente assina cada requisição com uma chave Ed25519 usando as HTTP Message Signatures da RFC 9421 (um Proposed Standard, fev. de 2024). A requisição leva:

• Signature: o valor da assinatura
• Signature-Input: os componentes cobertos, created/expires, keyid e tag="web-bot-auth"
• Signature-Agent: opcional, identifica o agente que assina

As chaves são descobertas como um JWKS em /.well-known/http-message-signatures-directory (com base no mecanismo de URIs well-known da RFC 8615). A verificação: baixar o diretório, casar a impressão digital do keyid e verificar a assinatura e a janela created/expires. A vantagem sobre os métodos por IP é decisiva: ele resiste a endereços compartilhados, rotativos e de CGNAT, porque a identidade viaja com a requisição, não com a rota.

Choque de realidade: é experimental, não um padrão

Seja honesto com a sua arquitetura aqui. O Web Bot Auth é especificado em Internet-Drafts da IETF (draft-meunier-web-bot-auth-architecture, 2 de março de 2026, autores da Cloudflare e do Google) que trazem o texto padrão "não endossado pela IETF e sem status formal" e expiram em 3 de setembro de 2026. O suporte do próprio Google é explicitamente experimental. Ele "ainda não assina todas as requisições" e orienta os operadores a continuar usando a verificação por IP, DNS reverso e User-Agent. Na camada de infraestrutura, o avanço é maior: a Cloudflare incorporou as Message Signatures ao seu Verified Bots Program (jul. de 2025) e o AWS WAF passou a oferecer suporte (nov. de 2025). Veredito: prefira assinaturas quando existirem, mas ainda não dependa delas.

O pipeline de decisão em camadas (copie este)

Combine os três métodos em uma ordem de precedência e, depois, enriqueça e classifique. Depois que um bot for verificado, decida o que fazer com cada rastreador de IA verificado com a política em três níveis desse guia:

A etapa 5 é onde a GeoIPHub se encaixa: quando o IP de um bot autoidentificado não está em um intervalo publicado e não tem PTR, o dono do ASN, a sinalização de data center/hospedagem, as sinalizações de VPN, proxy e Tor e uma pontuação de risco são o que permite pontuar os casos inconclusivos no login, no cadastro e no checkout em vez de adivinhar. Se você aplica limite de taxa ao grupo declarado-mas-não-verificado, use o prefixo como chave para origens IPv6, não o endereço; o nosso guia sobre limite de taxa e bloqueio de IPv6 por prefixo /64 explica por quê.

Mesmo ASN do Google, um Googlebot verificado e outro não

Dois endereços na mesma rede do Google recebem vereditos de rastreador opostos, porque a checagem usa o prefixo publicado, não o ASN. Consultamos dois IPs do Google em 05/10/2026 (os resultados mudam conforme os intervalos se movem): 192.178.4.0, o primeiro endereço do primeiro prefixo IPv4 do arquivo de intervalos do Googlebot publicado pelo Google, e 8.8.8.8, o Google Public DNS.

Os dois estão no AS15169 e os dois são hospedagem, então uma allowlist por ASN trataria ambos da mesma forma. Só o primeiro está dentro do arquivo do Googlebot, e threat.crawler.verification_method: "ip_range_list" mostra que o veredito veio do Método 2. O sinal verified_crawler leva o fraud_score dele a 0, enquanto 8.8.8.8 mantém a pontuação simples de data center, 15. O método no_ptr_datacenter dispara nos dois porque o nosso registro não guarda PTR para eles, embora um dig -x 192.178.4.0 ao vivo retorne crawl-192-178-4-0.googlebot.com. É um exemplo pequeno e real de por que a checagem por intervalos é a que deve ser automatizada: ela não depende do sucesso de uma consulta de PTR.

Modos de falha e falsos positivos

É aqui que os artigos mais bem ranqueados erram:

• Fora do intervalo ≠ falso. O caso da Perplexity (Cloudflare, ago. de 2025) mostrou um rastreador usando um UA genérico do Chrome, IPs fora do seu intervalo publicado e ASNs rotativos, com 3 a 6 milhões de requisições/dia. Dentro do intervalo é um verdadeiro positivo; fora do intervalo é inconclusivo, não prova de falsificação.
• Viés geográfico do CGNAT. Uma pesquisa da Cloudflare no fim de 2025 (via The Register) constatou que IPs de CGNAT sofriam limitação de taxa ~3× mais, apesar de sinais de bot menores. Centenas de usuários compartilham um único IPv4, com concentração na África e na Ásia. Bloqueio ingênuo por IP é um problema de equidade.
• iCloud Private Relay. IPs de saída compartilhados e rotativos que carregam pessoas reais; coloque-os na allowlist usando o CSV da Apple.
• Proxies residenciais. Eles derrotam completamente a allowlist por ASN (o relatório de 2025 da Imperva constatou que 21% dos ataques de bots os usaram), e é exatamente por isso que detectar tráfego anonimizado sem bloquear clientes reais é um problema comportamental, não uma consulta a uma lista.

A regra: reserve bloqueios definitivos para comportamento mais procedência, nunca apenas para a ausência em uma lista.

Bots verificados são GIVT, bots falsificados são SIVT

Na taxonomia do Media Rating Council, rastreadores declarados e IPs de data center conhecidos são General Invalid Traffic (tráfego inválido geral), filtrável por listas, enquanto bots "que se passam por usuários legítimos" são Sophisticated Invalid Traffic (tráfego inválido sofisticado), que exige análise e revisão. Verificar um rastreador pelo IP é o que move uma requisição do segundo grupo para o primeiro. As listas completas de categorias, as nove categorias do próprio Google e quais delas uma consulta de IP consegue ver estão em GIVT vs SIVT: as categorias de tráfego inválido do Google.

Verifique rastreadores e agentes de IA com a GeoIPHub

A GeoIPHub fornece o enriquecimento da etapa 5 que os fornecedores tradicionais de geo-IP deixam de fora dos seus conteúdos práticos: ASN e tipo de conexão, detecção de hospedagem/data center, sinalizações de VPN / proxy / Tor, sinalizações de rastreador verificado a partir de 19 feeds oficiais de intervalos (incluindo GPTBot, ClaudeBot, PerplexityBot e AhrefsBot) e uma pontuação de risco de fraude de IP. Não detectamos proxies residenciais; eles exigem sinais comportamentais. Isso permite confirmar que um bot autoidentificado realmente vem da infraestrutura do fornecedor e pontuar os casos inconclusivos em vez de bloqueá-los às cegas. Combine isso com os métodos de verificação acima e com os guias relacionados sobre detecção de tomada de conta e credential stuffing e sobre qual é a precisão real da geolocalização de IP.

Perguntas frequentes

Como verifico se uma requisição vem mesmo do GPTBot e não de uma falsificação?

Não confie no cabeçalho User-Agent; ele é trivial de forjar. Compare o IP de origem com o arquivo de intervalos por bot publicado pela OpenAI (openai.com/gptbot.json), restringindo a checagem especificamente ao GPTBot em vez de um intervalo genérico da OpenAI. Se houver uma assinatura Web Bot Auth válida, verifique-a primeiro no diretório de chaves da OpenAI, já que isso independe do IP. Trate um IP fora do intervalo publicado como inconclusivo, não como falso comprovado, porque o tráfego de agentes dirigido por usuários pode vir de outra infraestrutura. A nossa comparação GPTBot vs OAI-SearchBot vs ChatGPT-User mostra uma consulta real de cada arquivo de intervalos da OpenAI.

O que é DNS reverso com confirmação direta (FCrDNS)?

O FCrDNS é uma checagem em quatro etapas: resolver o IP de origem por DNS reverso até um hostname, confirmar que o hostname termina no domínio do operador, resolver esse hostname por DNS direto e confirmar que ele aponta de volta para o IP original. A etapa direta é o que derrota a falsificação: um atacante pode definir um registro PTR falso no próprio IP, mas não consegue forjar o DNS direto autoritativo do operador. Uma checagem que só inspeciona a string do PTR pode ser falsificada.

Por que não posso simplesmente bloquear rastreadores de IA pela string de User-Agent?

Porque o User-Agent é uma alegação que qualquer um pode enviar. A HUMAN Security constatou que 5,7% de todo o tráfego identificado como um rastreador de IA conhecido era falso, chegando perto de uma em cada seis requisições no caso do agente ChatGPT-User. Bloquear apenas pelo cabeçalho deixa passar bots falsificados e não faz nada contra um operador que simplesmente para de se identificar.

O que é o Web Bot Auth e ele já é um padrão finalizado?

O Web Bot Auth é um método emergente em que um bot assina criptograficamente cada requisição HTTP com uma chave Ed25519 usando as HTTP Message Signatures da RFC 9421, e a origem a verifica com as chaves publicadas em /.well-known/http-message-signatures-directory. A RFC 9421 em si é um Proposed Standard (fev. de 2024), mas o Web Bot Auth ainda é um Internet-Draft da IETF, sem status formal em meados de 2026. Trate-o como experimental: verifique assinaturas quando existirem, mas mantenha a verificação por IP e por DNS reverso como base.

Onde os fornecedores de IA publicam os intervalos de IP dos seus rastreadores?

A OpenAI publica JSON por bot em openai.com/gptbot.json, searchbot.json e chatgpt-user.json; o Google publica JSON de CIDRs em developers.google.com/static/crawling/ipranges/; a Anthropic publica um único arquivo para os seus bots em claude.com/crawling/bots.json; a Perplexity publica perplexitybot.json e perplexity-user.json. Restrinja cada checagem ao arquivo do bot específico, compare com os prefixos exatos publicados em vez do ASN de hospedagem e atualize os arquivos periodicamente. Para os três arquivos da OpenAI e a contagem atual de prefixos, veja intervalos de IP do GPTBot, do OAI-SearchBot e do ChatGPT-User.

Se um IP não está no intervalo publicado pelo fornecedor, a requisição é falsa?

Não. Um IP dentro do intervalo, um FCrDNS aprovado ou uma assinatura válida são verdadeiros positivos de alta confiança, mas um IP fora do intervalo é inconclusivo. Pode ser tráfego legítimo de agente dirigido por usuário vindo de outra infraestrutura, um endereço compartilhado por CGNAT, uma saída do iCloud Private Relay, um fornecedor que não publica registros PTR ou um arquivo de intervalos desatualizado do seu lado. Reserve bloqueios definitivos para sinais de comportamento e de procedência, não apenas para a ausência em uma lista.

Bloquear intervalos de IP de rastreadores não vai afetar usuários reais em endereços compartilhados?

Sim, e é por isso que a ausência do IP em uma lista não deve disparar bloqueios definitivos. Uma pesquisa da Cloudflare no fim de 2025 constatou que endereços de CGNAT sofriam limitação de taxa cerca de três vezes mais do que endereços sem CGNAT, apesar de apresentarem menos indicadores de bot, porque centenas a milhares de usuários compartilham um único endereço IPv4, e o CGNAT se concentra em partes da África e da Ásia, o que cria um viés geográfico. Os IPs de saída do iCloud Private Relay também carregam pessoas reais e devem entrar em allowlist usando o CSV publicado pela Apple.