O robots.txt que você configurou contra crawlers de IA provavelmente não bloqueia nada

Divulgação: O Expediente presta serviço de otimização para motores generativos. O que este texto descreve vale igual para o cliente e para a casa — não há exceção.

Um arquivo robots.txt dizendo "não deixe este crawler entrar" é a demo, e a demo não tem legado: funciona até o caso que importa. Um estudo da LovedByAI publicado em 8 de setembro de 2026 testou 314 sites contra 38 tokens de crawler de IA diferentes — buscando o robots.txt de cada site, simulando a visita de cada crawler e comparando o resultado com quatro semanas de log de servidor real, coletadas entre 27 e 30 de agosto. O achado que importa para quem decide isso na empresa: boa parte do bloqueio que existe só existe no papel.

O que o teste mediu, e por que a amostra tem limite

A amostra são clientes pagantes da própria LovedByAI, majoritariamente pequenas e médias empresas em WordPress — não é amostra aleatória da web, é o perfil de quem já paga por ferramenta de visibilidade em IA. Isso não invalida o método (é uma checagem ativa, não uma pesquisa de opinião), mas limita a generalização: um site de mídia grande, com time de infraestrutura próprio, tende a ter controle mais preciso do que a pequena empresa que compõe a maior parte da amostra.

O bloqueio que existe só no papel

43% dos 314 sites (135 no total) recusaram pelo menos um dos 38 crawlers testados. Até aqui, nada surpreendente. O que quebra a expectativa é como esse bloqueio acontece: dos 135 sites que recusam, só 23 têm uma regra escrita no robots.txt — o arquivo de texto público que qualquer crawler educado consulta antes de acessar o site, e que só funciona por convenção voluntária, não por trava técnica. Dos 23, 18 foram escritos pela Cloudflare por padrão, não pelo dono do site. Os outros 112 sites recusam no nível de servidor, sem regra nenhuma visível em robots.txt — quem administra o site nem saberia dizer, olhando o robots.txt, que aquele bloqueio existe.

Por que o seu próprio log não resolve essa dúvida

Alma já mapeou o que o termo de uso de cada crawler diz que ele faz — este texto é sobre a distância entre o que o crawler promete respeitar e o que ele de fato respeita. Aqui mora o dado que interessa a quem mantém isso no dia a dia, e o estudo mede por crawler, não em bloco: para o OAI-SearchBot, bloqueio feito só na origem — o próprio servidor da aplicação, sem uma camada de rede na frente — ainda aparece em 84,6% dos logs (11 em 13 sites que disseram tê-lo bloqueado assim), porque o crawler manda a requisição e ela chega ao servidor de qualquer forma antes de ser recusada ali. Bloqueio feito na borda de rede, como a Cloudflare faz por padrão, aparece em 0% dos logs desse mesmo crawler (nenhum dos 8 sites nessa condição) — a requisição nunca chega a ser processada pela aplicação. O padrão se repete nos outros três crawlers medidos, mas com magnitude bem menor: GPTBot vaza 29,4% na origem contra 0% na borda (n=17/n=9), ClaudeBot 26,3% contra 4,2% (n=19/n=24), PerplexityBot 20% contra 11,1% (n=15/n=9). A direção é sempre a mesma — origem vaza mais que borda —, mas o tamanho do vazamento vai de quase zero a mais de 80 pontos dependendo do crawler, e amostras deste tamanho (entre 8 e 24 sites por combinação) não sustentam um número fechado para nenhum dos dois lados. Checar o próprio log de acesso não diferencia bloqueio-que-funciona de nenhum-bloqueio — nos dois casos a aplicação não vê nada de suspeito —, mas quanto vaza por trás disso depende de qual crawler e de qual camada, não é uma regra geral única.

E o robots.txt sozinho, mesmo quando existe, não é lei — é pedido. Sites que desautorizaram o GPTBot ainda registraram requisições reais dele em 33,3% dos casos nos quatro meses anteriores; para o ClaudeBot, a taxa foi 17,6%. Cada crawler decide, por conta própria, o quanto respeita a instrução — e a taxa muda de um para o outro.

Nem todo crawler é o mesmo problema — e é aí que mora a decisão

A tabela do estudo separa dois tipos de crawler por função, e a taxa de rejeição muda de acordo: raspadores para treinamento de modelo (Bytespider 32,2%, Amazonbot 29,6%, ClaudeBot 18,8%, GPTBot 14,0%) levam rejeição bem mais alta que crawlers de busca ao vivo, que buscam a página no momento em que alguém faz uma pergunta a um assistente (PerplexityBot 8,0%, ChatGPT-User 7,6%, OAI-SearchBot 7,0%). Isso é coerente com a distinção que Zeca já fez entre tráfego direto de IA e o valor da citação em si: quem não quer o próprio conteúdo virando dado de treinamento, mas quer aparecer citado quando alguém pergunta a um assistente de IA, tem motivo real para tratar os dois tipos de forma diferente — só que a distinção precisa estar na configuração técnica, não na intenção. Um robots.txt que bloqueia "todo bot de IA" pela mesma regra genérica não faz essa separação, e o custo aparece depois: no dia em que a empresa quer saber por que sumiu da resposta de um assistente e descobre que o próprio bloqueio, mal configurado, incluiu o crawler de busca junto com o de treinamento.

O teste que substitui olhar o robots.txt e confiar

Quem decide isso numa empresa não devia perguntar "o que está escrito no nosso robots.txt" — devia simular a visita de cada crawler que importa, como o estudo fez, e comparar com o log real por algumas semanas. É mais trabalho que ler um arquivo de texto, mas é a única forma de saber se o bloqueio existe de verdade ou só no papel. Regra prática, sem meio-termo: bloqueio que ninguém testou contra uma requisição real não é bloqueio — é intenção documentada, e intenção documentada não impede nenhum crawler de fazer o que sempre fez.