Crawlers de IA: quem lê o seu site, o que cada um faz e as três portas que decidem o acesso

Anthropic, OpenAI, Perplexity, Google, Meta, Apple e Amazon operam rastreadores próprios, com finalidades e consequências diferentes. Este guia traz a lista atualizada de 2026, os dados de tráfego que mostram quem mais lê a web hoje, o custo real de bloquear cada operador e o modelo das três portas: a declarada no robots.txt, a invisível na infraestrutura e a terceirizada na CDN. Duas delas quase ninguém audita.

O modelo das três portas: por que este guia existe

Quase tudo o que se publica sobre crawlers de IA trata de uma única pergunta: o que escrever no robots.txt. É uma pergunta necessária e insuficiente. O robots.txt é apenas a porta declarada, a que o dono do site escolhe e publica. Existem outras duas, e elas mandam mais.

A segunda porta é a da infraestrutura: firewalls de aplicação, conjuntos de regras de segurança comerciais e configurações de servidor que barram crawlers antes de a requisição chegar ao site, muitas vezes por padrão de fábrica e sem conhecimento de ninguém. A terceira é a da CDN: desde julho de 2025, a maior provedora de infraestrutura da web bloqueia crawlers de IA por padrão em novos domínios, o que significa que a decisão pode já ter sido tomada por um fornecedor, não por você.

O resultado prático: um site pode ter o robots.txt mais permissivo do mundo e estar completamente invisível para uma plataforma de IA, sem nenhum alerta em nenhuma ferramenta. Documentamos um caso assim em primeira mão, em um site tecnicamente exemplar, e ele mudou a forma como tratamos o tema. Este guia percorre as três portas na ordem, com a lista atualizada de quem bate nelas e um método de auditoria que enxerga o que os logs não mostram.

O que são crawlers de IA e as três finalidades que mudam a decisão

Crawlers de IA são programas automatizados que percorrem a web coletando conteúdo para sistemas de inteligência artificial. O mecanismo é o mesmo de qualquer rastreador: requisições HTTP, extração de conteúdo, descoberta de links. O que muda é o destino do que foi lido, e é o destino que define a decisão estratégica.

A divisão tradicional em dois tipos, treinamento e inferência, ficou insuficiente para o ecossistema de 2026. São três finalidades, e os próprios provedores de infraestrutura passaram a classificá-las separadamente em seus controles.

Treinamento

GPTBot, ClaudeBot, Meta-ExternalAgent e Bytespider coletam conteúdo para compor os datasets de versões futuras dos modelos. O efeito de bloquear é de longo prazo e difuso: o conteúdo deixa de moldar o que os modelos saberão, mas nada muda nas respostas de hoje. Pelos dados do Cloudflare Radar compilados para julho de 2026, o treinamento respondia por 44,54% da finalidade declarada de rastreamento de IA, contra 35,74% um ano antes.

Busca e indexação

OAI-SearchBot, Claude-SearchBot e PerplexityBot constroem os índices que os produtos de busca com IA consultam. O efeito de bloquear é direto: o site sai dos resultados daquela plataforma. É a categoria que mais se aproxima do papel histórico do Googlebot, e a que menos deveria ser bloqueada por quem depende de ser encontrado.

Ação do usuário

Claude-User, ChatGPT-User e Perplexity-User não rastreiam por conta própria: buscam páginas em tempo real quando uma pessoa pede. Alguém cola a URL do seu site no Claude e pergunta o que a empresa faz; é o Claude-User que vai ler. O efeito de bloquear é imediato e o mais subestimado da lista: a IA não consegue ler o seu site nem quando o seu próprio cliente pede, e a citação em respostas em tempo real desaparece.

Essa terceira categoria muda o cálculo inteiro. Bloquear treinamento é uma posição negociável sobre propriedade intelectual. Bloquear ação do usuário é recusar leitura a um cliente que está, naquele momento, pesquisando você.

O tamanho disso em 2026: quem mais lê a web hoje

Os números de 2026 aposentaram duas intuições comuns: a de que crawler de IA é tráfego marginal e a de que a OpenAI domina o rastreamento.

Pelos dados do Cloudflare Radar referentes a julho de 2026, em compilação independente documentada, o ClaudeBot respondia por 16,28% do tráfego de bots de IA, à frente do GPTBot, com 9,74%. Doze meses antes, a ordem era a inversa. A liderança entre os dois oscila com os ciclos de treinamento de cada laboratório, e qualquer número deste parágrafo deve ser lido com a data ao lado: são medições mensais de um ecossistema volátil.

O dado mais importante, porém, não é de treinamento. No corte por bots individuais do mesmo período, o Claude-User aparecia como o segundo bot mais ativo de toda a web, com 8,31% das requisições, atrás apenas do Googlebot, com 12,88%, e à frente de Meta-ExternalAgent e GPTBot. Um agente de ação do usuário, movido por demanda humana em tempo real, ultrapassou os rastreadores clássicos de busca. O que era previsão sobre a web agêntica virou a segunda linha da tabela.

O contraponto honesto é a razão entre rastreamento e retorno. Na mesma janela de julho de 2026, a razão entre páginas rastreadas e visitas referenciadas era de 2.237 para 1 na Anthropic e 217 para 1 na OpenAI, contra razões próximas da paridade em buscadores tradicionais. Crawlers de IA leem muito e devolvem pouco clique, e é exatamente essa assimetria que alimenta o movimento de bloqueio por padrão que este guia trata na terceira porta. A decisão de liberar não é óbvia; ela é estratégica, e depende de onde a sua marca precisa existir: nos cliques, nas respostas, ou nos dois. A diferença entre esses dois mundos é o tema central de SEO versus GEO.

A lista 2026: user-agents, finalidades e o custo de bloquear

A tabela abaixo consolida os crawlers relevantes em agosto de 2026, com a coluna que costuma faltar nas listas: o que se perde, na prática, ao fechar a porta para cada um. Tokens que existem apenas como diretiva de robots.txt estão identificados, porque tratá-los como crawlers é um erro comum de configuração. A conformidade com robots.txt reflete o que cada operador declara em documentação, somada a relatos públicos de descumprimento onde existem.

Duas observações de leitura. Primeira: as strings completas de user-agent variam de versão para versão, e regras de firewall costumam casar o token, não a string inteira; antes de configurar qualquer coisa, confira a documentação oficial de cada operador, listada nas referências. Segunda: a linha do Google-Extended corrige um erro frequente. Pela documentação do Google, o AI Overviews é um recurso da Busca e segue o índice do Googlebot; o Google-Extended controla o uso de conteúdo no treinamento e no grounding do Gemini. Bloquear o token não remove o site do AI Overviews, e a confusão entre as duas coisas já levou muita gente a decisões erradas nas duas direções.

Operador por operador: o que se perde em cada porta fechada

A tabela resume; a decisão pede um parágrafo a mais sobre os operadores que concentram o tráfego.

Anthropic. É o operador que mais cresceu no ano e o único com os três tipos de bot em volume alto simultaneamente. Bloquear o trio inteiro em 2026 significa ficar invisível para o segundo maior leitor da web e para um índice de busca em expansão. A empresa publica documentação, faixas de IP oficiais e canal de contato para o crawler, o que a coloca entre os operadores mais verificáveis.

OpenAI. Mantém a separação mais didática entre finalidades, com um bot por função e documentação com faixas de IP para verificação de origem. A decisão granular clássica, bloquear GPTBot e liberar OAI-SearchBot e ChatGPT-User, protege conteúdo de treinamento sem sair das respostas.

Perplexity. Opera busca e ação do usuário, com histórico público de episódios de descumprimento de robots.txt que a empresa tratou como corrigidos. A nuance que quase ninguém lê: a documentação do agente de ação do usuário registra que requisições iniciadas por pessoas podem não seguir a diretiva, sob a lógica de que quem pediu foi um humano. Para quem precisa de bloqueio efetivo, isso transfere o controle da porta declarada para as portas de imposição.

Google e Apple. Os dois casos em que a confusão entre crawler e token mais custa caro. Googlebot e Applebot são rastreadores de busca e não devem ser bloqueados por quem quer ser encontrado; Google-Extended e Applebot-Extended são tokens de robots.txt que controlam apenas treinamento. Nenhuma requisição chega ao servidor com o nome dos tokens, e colocá-los em allowlist de firewall não produz efeito algum.

Common Crawl. O CCBot alimenta um arquivo público usado no treinamento de muitos modelos abertos. Bloqueá-lo tem efeito em cascata sobre um ecossistema inteiro, não sobre uma única empresa, e a decisão merece esse enquadramento.

Porta 1: robots.txt, a camada declarada

O robots.txt continua sendo o instrumento central de governança, e o único dos três com comportamento definido por norma, a RFC 9309. Ele funciona por cooperação: os operadores principais declaram conformidade e, em geral, cumprem. Três desenhos cobrem a maioria dos casos.

Permitir tudo é a ausência de regra: sem diretiva para um user-agent, o acesso está liberado. É a postura natural de quem disputa visibilidade em mecanismos de resposta.

Bloquear treinamento e liberar busca e ação do usuário é o desenho granular mais usado por quem quer proteger conteúdo editorial sem sair das respostas:

User-agent: GPTBot
Disallow: /
 
User-agent: ClaudeBot
Disallow: /
 
User-agent: Google-Extended
Disallow: /
 
User-agent: OAI-SearchBot
Allow: /
 
User-agent: Claude-SearchBot
Allow: /
 
User-agent: ChatGPT-User
Allow: /
 
User-agent: Claude-User
Allow: /

Bloquear por seção combina proteção comercial com visibilidade informacional: um e-commerce pode fechar os diretórios de preço e estoque e manter o blog aberto, com regras de Disallow por caminho em vez de bloqueio total.

Duas notas de precisão. A diretiva Crawl-delay não faz parte da norma e tem suporte inconsistente entre crawlers de IA; controle de carga se faz com rate limiting no servidor ou na CDN, com limites tolerantes o bastante para não interromper rastreamentos legítimos. E o llms.txt não pertence a esta porta: é uma proposta de curadoria que aponta conteúdo relevante aos modelos, sem poder de bloqueio e ainda sem adoção declarada pelos grandes operadores, como tratamos na análise sobre se o llms.txt funciona. Quem quer orientar leitura pode mantê-lo como aposta de baixo custo; quem quer impedir acesso precisa das portas seguintes.

Porta 2: a infraestrutura, a camada que bloqueia sem avisar

Aqui mora o problema que as listas de user-agent não contam. Entre o crawler e o seu robots.txt existe uma pilha inteira: firewall de rede, conjuntos de regras de segurança do servidor, firewall de aplicação, cache. Qualquer uma dessas camadas pode derrubar a requisição antes de ela chegar ao WordPress, ao robots.txt e aos seus logs de aplicação, e as regras que fazem isso costumam vir de fábrica em pacotes comerciais de segurança, ativadas por padrão em servidores compartilhados.

Documentamos um caso assim em agosto de 2026: um site médico tecnicamente exemplar, com robots.txt permissivo, em que uma regra comercial de ModSecurity classificava o ClaudeBot como ameaça e encerrava as conexões sem devolver nenhuma resposta HTTP. Todos os demais crawlers passavam com status 200; só um operador estava barrado, e ninguém havia decidido isso. O cache do servidor mascarava o problema nas páginas populares, e nenhuma ferramenta tradicional acusou nada. A reconstrução completa, com a investigação, as duas camadas de bloqueio encontradas e o protocolo de correção, está no estudo de caso sobre bloqueio de crawlers de IA.

A consequência normativa é o que torna essa porta tão severa. Pela RFC 9309, quando o robots.txt está indisponível, sem resposta utilizável do servidor, o crawler deve assumir que o site inteiro está proibido. Um bloqueio silencioso de infraestrutura não nega uma página: converte o domínio completo em território interditado, por norma. E como não existe um painel equivalente ao Search Console para crawlers de IA, nenhum fornecedor avisa o dono do site. O bloqueio dura até alguém testar.

Porta 3: a CDN, a camada que decide por padrão

A terceira porta não fica no seu servidor: fica no fornecedor na frente dele. Em 1º de julho de 2025, a Cloudflare, por onde passa cerca de um quinto do tráfego da web segundo a própria empresa, tornou-se a primeira grande provedora de infraestrutura a bloquear crawlers de IA por padrão em novos domínios, invertendo o modelo de opt-out para opt-in e lançando um mercado de cobrança por rastreamento. Em julho de 2026, refinou o sistema com controles separados por finalidade: busca, agente e treinamento, além de proteção específica para páginas monetizadas por anúncios.

Para quem publica conteúdo e quer ser citado, a implicação é direta: se o site está atrás de uma CDN com esses controles, a política de acesso a crawlers de IA pode ter sido definida por um padrão de fornecedor, na criação da zona, sem passar por nenhuma decisão editorial sua. A auditoria dessa porta é um painel, não um arquivo: os controles de bots da CDN precisam entrar na mesma revisão periódica que o robots.txt, com a pergunta explícita de quais categorias estão bloqueadas, limitadas ou liberadas, e se aquilo reflete a estratégia ou apenas o default.

O movimento também explica o clima geral: com razões de rastreamento por visita na casa dos milhares para um, o bloqueio por padrão virou produto, e a tendência é de mais fricção, não menos. Quem decide liberar precisa decidir de verdade, nas três portas, porque o ecossistema inteiro está decidindo o contrário por inércia.

Como auditar: de fora para dentro, não só pelos logs

O método tradicional de gestão de bots começa nos logs do servidor: filtrar por user-agent, medir volume, verificar autenticidade por DNS reverso. Continua necessário, e tem um ponto cego estrutural: o log mostra quem chegou. Não mostra quem foi barrado antes de chegar, porque os bloqueios das portas 2 e 3 acontecem antes do registro da aplicação. Um site pode ter zero requisições do ClaudeBot nos logs por dois motivos opostos, desinteresse ou bloqueio, e o log não distingue os dois.

A auditoria completa soma as duas direções.

1. De fora para dentro: teste de acesso. De uma máquina externa ao servidor, requisições com o user-agent de cada crawler relevante para três URLs: robots.txt, home e uma página interna pouco acessada, fora do cache. Requisição de controle com user-agent de navegador antes e depois da bateria, para detectar banimento do IP de teste. Queda de conexão confirmada com segunda tentativa após pausa. Status 200 é acesso; 403, 429 e conexão encerrada sem resposta são bloqueio ou limitação, cada um apontando para uma camada diferente.
2. De dentro para fora: leitura de logs com verificação de origem. Filtragem por user-agent nos logs de acesso, com validação por DNS reverso e pelas faixas de IP oficiais que Anthropic e OpenAI publicam, para separar crawlers autênticos de imitações. Aqui entram as ferramentas clássicas de análise de log e os painéis de bots da CDN.
3. Painéis das portas 1 e 3. Revisão do robots.txt publicado, do que o plugin de SEO gera dinamicamente e dos controles de bots da CDN, com registro do que está bloqueado por escolha e do que está bloqueado por padrão.
4. Duas rodadas e calendário. Só é bloqueio confirmado o que aparece em duas baterias em dias distintos. E como conjuntos de regras comerciais se atualizam sem aviso, a auditoria entra na rotina de manutenção, não no rol de eventos únicos.

O protocolo detalhado, com os comandos, a tabela de sintomas por camada e o roteiro de chamado para a hospedagem, está no estudo de caso citado na Porta 2. Para quem administra WordPress, a revisão das camadas de segurança conversa diretamente com o trabalho de segurança e limpeza de WordPress: as mesmas ferramentas que protegem o site são as que, mal calibradas, o tornam invisível.

Matriz de decisão: modelo de negócio x finalidade do bot

Não existe resposta universal para liberar ou bloquear; existe cruzamento entre o que o site vende e o que cada categoria de bot faz. A matriz abaixo resume a recomendação de partida por perfil, sempre sujeita à estratégia específica.

Duas regras atravessam todos os perfis. A primeira: a decisão declarada na Porta 1 precisa ser conferida nas Portas 2 e 3, porque de nada adianta liberar no robots.txt o que o firewall derruba. A segunda: liberar é fundação, não resultado. A citação depende do que vem depois do acesso, e é trabalho de conteúdo, entidade e autoridade, o território do guia completo de GEO e da sua base de conhecimento oficial para IAs.

Erros comuns na gestão de crawlers de IA

Editar o robots.txt para resolver um bloqueio de firewall. Se a requisição morre antes de chegar ao site, o arquivo é irrelevante. Primeiro identifica-se a camada, depois se corrige nela.

Concluir pelo log que não há bloqueio. Ausência de requisições no log é compatível com bloqueio nas camadas anteriores. O teste de fora para dentro é o único que responde.

Testar só a home. O cache aprova as páginas populares e esconde o bloqueio exatamente nas URLs novas e pouco acessadas, as que mais precisam ser descobertas.

Tratar Google-Extended e Applebot-Extended como crawlers. São tokens de robots.txt; nenhuma requisição chega com esses nomes, e allowlist de firewall para eles não produz efeito.

Bloquear Googlebot ou Applebot ao mirar treinamento. São os rastreadores de busca. O alvo de quem quer restringir treinamento são os tokens Extended e os bots de treinamento, nunca os de busca.

Confiar em Crawl-delay. Fora da norma e de suporte inconsistente. Controle de carga é rate limiting bem calibrado, tolerante com rastreadores legítimos.

Testar Googlebot de IP comum e concluir bloqueio. Firewalls verificam a origem do Googlebot por DNS reverso e barram imitações por design. Esse teste mede a defesa contra falsificação, não o acesso do Google real.

Liberar por IP em vez de user-agent. As faixas de IP dos operadores mudam; a liberação estável é por agente, com as faixas oficiais servindo à verificação de autenticidade, não à regra principal.

Decidir uma vez e nunca revisar. Rulesets comerciais se atualizam sem aviso, CDNs mudam padrões, operadores lançam bots novos. A gestão de crawlers de IA é rotina de manutenção com dono e calendário, dentro do mesmo raciocínio de fundação do Método B.I.N.A..

Perguntas frequentes

Nota de transparência: os números de tráfego citados vêm de compilações independentes e documentadas de dados do Cloudflare Radar e variam mês a mês; cada um está datado no próprio parágrafo. A coluna de conformidade com robots.txt reflete o que cada operador declara em documentação oficial, somada a relatos públicos de descumprimento quando existem, e não constitui verificação independente da Flowup. Strings de user-agent devem ser conferidas na documentação de cada operador antes de qualquer configuração.