Se a sua equipe técnica já tentou usar o robots.txt para impedir que uma IA treine modelos com o conteúdo do site — mas sem perder a visibilidade no Google —, vale revisar a premissa. O Google acaba de reforçar, oficialmente, que o robots.txt nunca foi desenhado para controlar isso.
O que o Google disse
Em um vídeo do Search Central publicado nesta semana, Gary Illyes, do time de Search Relations do Google, foi direto: conforme definido pela RFC 9309 — o padrão técnico que formaliza o robots.txt —, o arquivo é “um protocolo de preferência de acesso”. Ele determina quais URLs um rastreador pode ou não solicitar. O que acontece com o conteúdo depois de rastreado está fora do escopo do protocolo.
Na prática, isso significa que uma linha genérica tentando proibir “uso para treinamento de IA” — como o exemplo fictício “No-AI-Chicken-Training” exibido no próprio vídeo — é simplesmente ignorada por qualquer parser. O Google reconhece apenas quatro elementos no robots.txt: User-Agent, Allow, Disallow e Sitemap. Qualquer coisa fora disso não tem efeito garantido, porque a RFC 9309 deixa a cargo de cada rastreador decidir como interpretar instruções fora do protocolo.
Para bloquear um crawler de IA específico, a orientação de Illyes é uma só: identificar e direcionar o user-agent token exato daquele rastreador — e repetir o processo para cada um que a marca quiser excluir.
Google-Extended não é a mesma coisa
Um ponto que gera confusão: o Google-Extended não é um user-agent próprio — o Google rastreia com os crawlers que já usa normalmente. É um token de controle, documentado separadamente, que define se o conteúdo rastreado pode ser usado para treinar futuros modelos Gemini e para grounding (no Gemini Apps e no Grounding with Google Search, via Vertex AI). Ele não afeta a indexação no Google Search nem funciona como fator de ranqueamento — é exclusivamente uma chave de uso de dados para os produtos de IA do próprio Google.
Um padrão ainda em rascunho
Illyes é coautor, com Martin Thomson (Mozilla), de um Internet-Draft em discussão no IETF que propõe justamente preencher essa lacuna: uma regra “Content-Usage” para o robots.txt (e um header HTTP equivalente), permitindo declarar preferências de uso — por exemplo, train-ai=n — separadas da permissão de rastreamento. Allow e Disallow continuariam controlando o acesso; Content-Usage trataria do que pode ser feito com o que já foi permitido rastrear.
O rascunho, datado de 19 de agosto, ainda é um documento de working group: não foi submetido à revisão do IESG (o plano era enviá-lo em agosto de 2026) e expira em 20 de fevereiro de 2027 caso não seja renovado. Ou seja: hoje, não existe um padrão único e estável para declarar “não treine IA com este conteúdo” — só uma proposta em andamento.
Caminhos não ingleses pedem atenção
Outra recomendação do episódio, de Cherry Prommawin (Google Search Relations): caminhos do robots.txt com caracteres não ingleses ou emoji devem ser escritos em percent-encoding. O parser do Google trata a versão crua e a codificada da mesma forma, mas crawlers mais antigos ou de terceiros podem não interpretar corretamente caracteres UTF-8 brutos.
Visão Estratégica da Web Estratégica
- Separar, na governança técnica do cliente, o que controla rastreamento (robots.txt, Disallow por user-agent) do que controla uso dos dados para treino — hoje, isso só existe de forma padronizada para o ecossistema Google, via Google-Extended.
- Mapear, por marca, quais crawlers de IA relevantes precisam de uma linha própria no robots.txt — bloquear “IA” de forma genérica não funciona; cada rastreador exige o token específico.
- Acompanhar a evolução do Internet-Draft do IETF: se for adotado, passa a existir um padrão formal de “Content-Usage” que pode se tornar prática recomendada de mercado — e vale o cliente já estar preparado para adotá-lo.
