Bloqueio de crawlers de IA: o cuidado técnico que decide quem existe nas respostas

Um site médico tecnicamente exemplar, com conteúdo assinado, fontes acadêmicas e dados estruturados, estava invisível para o crawler da Anthropic. Nenhuma ferramenta acusou o problema. A causa era uma regra de firewall que nem o dono do site conhecia. Este artigo reconstrói o caso em primeira mão, explica as camadas onde o bloqueio invisível acontece e entrega o protocolo de auditoria que todo trabalho sério de GEO e AEO deveria incluir.

O caso: conteúdo exemplar, visibilidade zero

O site que motivou este artigo tinha tudo o que a literatura de GEO e AEO recomenda, e não como enfeite. É o site de um médico em São Paulo, atendido pela Flowup, com páginas de condições clínicas que trazem bloco de resposta direta no topo, perguntas frequentes extensas, sete fontes acadêmicas com referência completa por página, critérios diagnósticos internacionais tabelados, credenciais de conselho e registros de especialista visíveis, autoria assinada, data de atualização e aviso médico. Havia até uma base de conhecimento oficial construída especificamente para agentes de IA lerem.

E o agente de IA não conseguia chegar nela. Nem nela, nem em nenhuma outra página do domínio.

Durante uma sessão de trabalho em 25 de agosto de 2026, pedimos a um assistente de IA que lesse uma página do site para uma auditoria de conteúdo. Todas as tentativas retornaram o mesmo veredito: acesso automatizado proibido. A home, as páginas internas, o próprio robots.txt. Para o crawler da Anthropic, o domínio inteiro não existia.

O paradoxo é a tese deste artigo em um fato: o mercado vende GEO e AEO como disciplina de conteúdo, mas a primeira camada é de infraestrutura. Todo o trabalho editorial estava correto. A camada que ninguém audita derrubou o que a camada que todo mundo audita construiu.

A anatomia de uma falha silenciosa

O primeiro reflexo de qualquer profissional seria procurar um erro 403 nos logs. Não havia erro 403, e essa ausência é o dado mais importante do caso.

Quando reproduzimos a requisição do crawler com curl, de fora do servidor, o retorno foi o erro 52 do curl: resposta vazia. A conexão TCP era aceita, o handshake TLS era concluído, a requisição era enviada, e o servidor fechava a conexão sem devolver um único byte. Nenhum código de status, nenhum HTML de bloqueio, nenhum registro na camada da aplicação. Nas tentativas seguintes o comportamento mudou para o erro 35, conexão resetada ainda no handshake, porque a primeira requisição barrada havia colocado o IP de teste em uma lista temporária de banimento.

Essa é a assinatura da falha silenciosa: ela não aparece como erro em lugar nenhum. O site funcionava perfeitamente para pacientes. O Google seguia indexando normalmente. As ferramentas de análise não registravam nada anormal, porque medem visitantes com navegador. O firewall da aplicação não registrava o bloqueio, porque a requisição morria antes de chegar nele. O problema só se tornou visível porque alguém tentou usar a IA para ler o site, e falhou.

A investigação: descartar hipóteses também é método

Registramos aqui as hipóteses erradas de propósito. Um diagnóstico que apresenta só a resposta final parece elegante, mas não ensina a reproduzir o caminho, e é o caminho que separa o cuidado técnico do palpite.

Hipótese 1: robots.txt

Descartada com evidência direta. O arquivo estava no padrão mais permissivo possível: user-agent asterisco, disallow apenas em wp-admin. Nenhuma diretiva contra crawlers de IA. A lição embutida: quando o robots.txt é gerado dinamicamente pelo plugin de SEO, como era o caso, a requisição dele atravessa toda a pilha de PHP, e um bloqueio de camada inferior pode impedir até a leitura do arquivo que deveria declarar as permissões.

Hipótese 2: o plugin de segurança do WordPress

Plausível e errada. O site rodava um firewall de aplicação em modo estendido, carregado antes do WordPress em toda requisição PHP. Era o suspeito perfeito. Mas plugins de segurança respondem com páginas HTML de bloqueio e códigos 403; não fecham conexões em silêncio. O teste com curl absolveu a camada da aplicação inteira: a requisição nunca chegava ao PHP. Quem trabalha com segurança em WordPress conhece essa fronteira: o que acontece antes do PHP não é culpa do WordPress.

Hipóteses 3 e 4: bloqueio geográfico e fingerprint de cliente

O bloqueio geográfico caiu quando o teste feito de um IP residencial brasileiro falhou da mesma forma que o crawler americano. A detecção por fingerprint TLS, técnica que identifica a ferramenta pela assinatura criptográfica do handshake e não pelo user-agent, foi descartada pela própria hospedagem, com verificação nos logs do servidor.

Três hipóteses razoáveis, três descartes com evidência. O que sobrou apontava para uma única direção: uma regra de servidor, casando especificamente o user-agent do crawler.

A causa real: duas camadas e um cache no meio

A análise dos logs pelo suporte da hospedagem, uma empresa nacional que conduziu o diagnóstico com precisão, encontrou a primeira resposta: uma regra do conjunto comercial Malware.Expert para ModSecurity, identificada como 1200002, que classificava o user-agent ClaudeBot como padrão de ameaça. Quando a regra disparava, o servidor derrubava a conexão sem resposta e marcava o IP de origem como bot, recusando as conexões seguintes por um período. Isso explicava a sequência exata de erros observada nos testes.

Ninguém naquela hospedagem decidiu bloquear a Anthropic. Ninguém no site decidiu. A regra veio de fábrica, dentro de um pacote de segurança de terceiros, e estava ativa em um servidor compartilhado que hospeda dezenas de outros sites. Essa é a parte do caso que generaliza: o antagonista não é um vilão, é um padrão de fábrica que ninguém revisou.

A segunda camada

A primeira correção parecia ter resolvido. O robots.txt passou a responder 200 para o user-agent do crawler. Mas ao testar páginas internas em sequência, o servidor passou a responder 429, código de excesso de requisições, a partir da quinta requisição em três minutos. A investigação da hospedagem revelou que não era limite de taxa: era uma segunda lista de bloqueio de user-agents, em outra camada do firewall, que ainda continha a entrada do ClaudeBot. Duas regras independentes, com o mesmo alvo, em camadas diferentes da mesma pilha.

O cache que escondia o problema

E aqui está o detalhe mais traiçoeiro do caso. Depois da primeira correção, o robots.txt e a home respondiam 200 com um cabeçalho revelador: o acerto vinha do cache do servidor LiteSpeed, que responde antes da camada onde a segunda regra vivia. As páginas populares, servidas pelo cache, passavam. As páginas fora do cache, exatamente as menos acessadas e as mais recentes, batiam no servidor de aplicação e caíam na regra.

A consequência é perversa e vale ser dita com clareza: quanto mais nova e menos visitada a página, maior a chance de ela estar bloqueada. O conteúdo que você acabou de publicar, aquele que mais precisa ser descoberto, é o primeiro a ficar invisível. Um teste que confere só a home aprova o site e erra o diagnóstico.

O que a norma diz: sem resposta, o crawler assume proibição total

Há uma razão normativa para o bloqueio silencioso ser mais grave que um 403 comum. A RFC 9309, que padronizou o Robots Exclusion Protocol em 2022, define o comportamento esperado do crawler conforme a resposta do robots.txt: se o arquivo responde com erro de cliente, como 404, o rastreador pode tratar o site como liberado; mas se o robots.txt está indisponível, sem resposta utilizável do servidor, o rastreador deve assumir que o site inteiro está proibido.

Foi exatamente o que aconteceu no caso. A conexão derrubada sem resposta tornava o robots.txt indisponível, e o crawler, seguindo a norma, tratava o domínio completo como interditado. Um arquivo perfeitamente permissivo, que ninguém conseguia ler, produzia o efeito de um disallow total. A configuração declarada dizia sim; a infraestrutura respondia com silêncio; e a norma manda interpretar silêncio como não.

Por que ninguém percebe: GEO não tem Search Console

O SEO amadureceu apoiado em um painel gratuito de diagnóstico. O Search Console reporta erros de rastreamento, páginas excluídas, problemas de indexação, e notifica o dono do site. Para os crawlers de IA, esse equivalente não existe: nem Anthropic, nem OpenAI, nem Perplexity oferecem hoje um painel que avise o dono do site de que o rastreador foi bloqueado. Não há alerta, não há histórico, não há notificação. Um bloqueio pode durar meses sem que ninguém saiba, porque nenhum instrumento do stack tradicional foi desenhado para vê-lo.

O segundo motivo é a assimetria. No caso documentado, GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot e Bingbot acessavam o site normalmente, com status 200, inclusive de IPs americanos. Apenas o ClaudeBot estava barrado. Quem testasse a presença do site perguntando ao ChatGPT concluiria que estava tudo certo, e estaria certo apenas sobre um fornecedor. A heurística intuitiva de testar um crawler e assumir que vale pelos outros não sobrevive a este caso: cada plataforma tem seu rastreador, e o veredito é individual.

E o terceiro motivo é o já descrito efeito do cache, que faz o próprio teste mentir quando é feito apenas nas páginas mais visitadas.

O contexto de mercado: o bloqueio por padrão está crescendo

Este caso não é uma curiosidade isolada. Ele acontece dentro de um movimento estrutural da web, e conhecer o movimento é parte do cuidado técnico.

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, a mesma empresa refinou o sistema, separando os controles por finalidade: busca, agente e treinamento. A direção é inequívoca: o bloqueio de crawlers de IA deixou de ser exceção artesanal e virou configuração de fábrica em escala.

Ao mesmo tempo, o custo de estar bloqueado nunca foi tão alto. Compilações independentes de dados do Cloudflare Radar referentes a julho de 2026 registram o ClaudeBot com 16,28% do tráfego de bots de IA, à frente do GPTBot com 9,74%, e o Claude-User, o agente que busca páginas em tempo real quando um usuário pergunta algo ao Claude, como o segundo bot mais ativo de toda a web, atrás apenas do Googlebot. Bloquear a Anthropic em 2026 não significa perder um rastreador de treinamento: significa fechar a porta para o segundo maior leitor da internet, movido por demanda real de usuários em tempo real.

Há também o lado da escolha legítima. Na amostra de robots.txt analisada pelo Radar em junho de 2026, o GPTBot aparecia bloqueado em 712 domínios e o ClaudeBot em 623, números que crescem e que representam decisões editoriais declaradas. Essa distinção precisa ficar nítida: o dono de site que publica um disallow está exercendo governança sobre o próprio conteúdo, e isso é legítimo. O problema deste artigo é outro: o site que quer ser encontrado, investe em conteúdo para isso e está bloqueado sem saber, por uma camada que nunca auditou. Entender a diferença entre SEO e GEO ajuda a dimensionar o que está em jogo em cada uma dessas portas.

O protocolo técnico: como auditar o acesso de crawlers de IA

O que segue é o protocolo que aplicamos na Flowup, refinado por este caso. Ele não exige ferramenta paga; exige rigor na execução e na leitura.

1. Teste de fora do servidor, com o user-agent real de cada crawler. Use curl de uma máquina externa, enviando o user-agent oficial de cada rastreador, conferido na documentação de cada fornecedor na semana do teste. Teste no mínimo ClaudeBot, Claude-User, GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot e Bingbot. Testes de dentro do servidor não valem: não atravessam o firewall.
2. Três URLs por crawler, sempre incluindo uma página fora do cache. Robots.txt, home e uma página interna pouco acessada. O caso provou que o cache aprova as duas primeiras e esconde o bloqueio exatamente onde ele mais dói.
3. Requisição de controle antes e depois da bateria. Rode o mesmo teste com user-agent de navegador antes dos bots e repita ao final. Se o controle passa antes e falha depois, seu IP foi banido durante o teste e os resultados intermediários estão contaminados. Foi o que aconteceu no caso, e teria induzido a conclusão errada.
4. Confirme toda queda de conexão com uma segunda tentativa após pausa. Queda única pode ser instabilidade. Bloqueio de verdade cai duas vezes. Registre o tipo exato do erro: resposta vazia, conexão resetada, timeout e 403 apontam para camadas diferentes.
5. Leia o resultado camada por camada, não como veredito único. A tabela abaixo resume a correspondência entre sintoma, camada provável e forma de confirmação que este caso validou na prática.
6. Peça a regra específica à hospedagem, com evidência. Chamado eficaz leva IP de origem, horário exato, user-agent usado e o tipo de erro observado. Pergunte nominalmente por conjuntos de regras de ModSecurity, listas de user-agents no firewall e bloqueio geográfico. Neste caso, a hospedagem localizou a regra em horas porque recebeu o chamado com esses dados.
7. Libere por user-agent, nunca por IP, e revalide após reinício do serviço. Os fornecedores usam faixas de IP de nuvem que mudam; a Anthropic publica as faixas e a documentação oficial, mas a liberação estável se faz pelo agente. E uma correção de WAF só vale depois do restart do serviço web, testada de novo em página fora do cache.
8. Duas rodadas em dias distintos antes de dar o caso por encerrado. Só é bloqueio confirmado o que aparece nas duas. E como conjuntos de regras comerciais se atualizam sem aviso, a auditoria não é evento único: entra no calendário de manutenção, junto com a revisão de robots.txt e de rate limiting.

Para rodadas em escala, o mesmo protocolo se automatiza: um script que percorre uma lista de domínios, varia os user-agents, aplica as confirmações e classifica os vereditos. É assim que estamos medindo a extensão do problema em sites brasileiros, e os números dessa medição serão publicados quando as duas rodadas estiverem completas, com metodologia aberta.

Erros comuns ao diagnosticar e liberar crawlers de IA

Editar o robots.txt para resolver bloqueio de firewall. Se a requisição morre antes de chegar ao site, o arquivo é irrelevante: a correção precisa acontecer na camada que bloqueia. No caso relatado, o robots.txt já estava permissivo desde o início.

Testar só a home e dar o site por liberado. O cache aprova a home e esconde o resto. Página fora do cache é item obrigatório do teste, não refinamento.

Concluir por um crawler e assumir que vale para todos. O bloqueio é assimétrico por natureza, porque cada conjunto de regras lista agentes diferentes. O veredito é individual por fornecedor.

Liberar por IP. As faixas mudam, a liberação quebra em silêncio e o problema volta sem aviso. A liberação estável é por user-agent, com a possibilidade adicional de validar a origem pelas faixas oficiais publicadas.

Testar Googlebot de IP comum e concluir que o Google está bloqueado. Firewalls verificam a origem do Googlebot por DNS reverso, e barrar imitações é comportamento correto deles. Esse teste mede a defesa contra falsificação, não o acesso do Google real.

Tratar Google-Extended e Applebot-Extended como crawlers. São tokens que existem apenas como diretiva de robots.txt, para controle de uso em treinamento; nenhuma requisição chega ao servidor com esses nomes. Colocá-los em allowlist de firewall não produz efeito algum.

Acusar a hospedagem antes de levar evidência. Neste caso, o suporte da hospedagem diagnosticou e corrigiu as duas camadas em menos de 24 horas, justamente porque o chamado chegou com IP, horários, user-agents e tipos de erro. O padrão de fábrica de um conjunto de regras de terceiros não é má-fé de ninguém; é uma camada que precisa de revisão.

O que o acesso não garante

Este artigo defende uma tese de infraestrutura, e a honestidade exige delimitar o que ela não cobre. Liberar crawlers de IA não garante citação em resposta nenhuma. Com a porta aberta, começa o trabalho que decide o resto: conteúdo que responde perguntas reais com clareza extraível, consistência de entidade, fontes verificáveis, autoridade construída ao longo do tempo e concorrência em cada pergunta que importa. É a diferença entre condição necessária e suficiente, e quem promete citação garantida está vendendo o que não controla.

O que o acesso garante é o contrário: sem ele, todo o resto é irrelevante. Nenhuma qualidade editorial atravessa uma conexão que o servidor fecha em silêncio. Por isso, no Método B.I.N.A., a verificação de acessibilidade de crawlers é etapa de fundação, anterior ao trabalho de conteúdo, e o guia completo de GEO trata a camada editorial que vem depois dela. As duas camadas se completam; nenhuma substitui a outra.

Fica também o convite à verificação independente: o protocolo está descrito por inteiro neste artigo, é reprodutível com ferramentas gratuitas e não depende de acreditar em nós. Rode no seu site. Se tudo responder 200, você ganhou uma confirmação valiosa. Se não responder, você acabou de descobrir algo que nenhum painel ia te contar.

Perguntas frequentes

Nota de transparência: o caso é relatado em primeira mão, com datas, códigos de erro e sequência de eventos preservados dos registros originais. Cliente e hospedagem não são nomeados por padrão editorial; a hospedagem envolvida diagnosticou e corrigiu o problema em menos de 24 horas após receber o chamado com as evidências. Os números de mercado citados têm fonte e data no próprio parágrafo e refletem medições dos períodos indicados, sujeitas a variação mensal.