robots.txt e IA: bloquear o GPTBot não bloqueia o ChatGPT

Em 2023, quando a OpenAI publicou o nome do seu robot de treino, milhares de sites acrescentaram duas linhas ao ficheiro robots.txt: User-agent: GPTBot e depois Disallow: /. Muitos julgam desde então que o ChatGPT já não consegue ler as suas páginas. É falso, e a confusão vem de uma realidade que os fornecedores de IA documentam com clareza: não enviam um robot, enviam vários, cada um com um papel e um token distintos. Bloquear um não bloqueia os outros.

Vários robots, vários papéis, em cada fornecedor

Na OpenAI, segundo a sua documentação dos robots:

• GPTBot recolhe páginas que podem servir para treinar os modelos. É o único cujo bloqueio protege contra a utilização em treino.
• OAI-SearchBot alimenta o índice da pesquisa integrada no ChatGPT. Bloqueá-lo retira as suas páginas dos resultados de pesquisa do ChatGPT, logo das citações que daí decorrem.
• ChatGPT-User vai buscar uma página precisa quando um utilizador o pede numa conversa, por exemplo ao colar um URL ou ao fazer uma pergunta que despoleta uma leitura. Não percorre a web de forma autónoma.

A Anthropic aplica a mesma separação, descrita na sua página de ajuda dedicada aos robots: ClaudeBot para o treino, Claude-SearchBot para o índice de pesquisa, Claude-User para as recuperações pedidas por um utilizador. A Perplexity documenta o PerplexityBot (índice) e o Perplexity-User (recuperação a pedido) na sua documentação dos crawlers.

Google e Apple: um token de controlo separado do robot

A Google funciona de outra maneira. O Googlebot continua a ser o único robot que explora as páginas para a pesquisa, e são essas mesmas páginas que alimentam os AI Overviews. O controlo da utilização em treino passa por um token distinto, Google-Extended, que não é um robot, mas uma diretiva lida pelo Googlebot, como explica a lista dos crawlers correntes da Google. A Google esclarece que este token nada altera na indexação das páginas. A Apple procede do mesmo modo com o Applebot-Extended, token documentado no seu artigo de assistência sobre o Applebot, que controla a utilização em treino sem tocar no próprio Applebot.

Há que acrescentar a esta lista o CCBot, o robot do Common Crawl, cujos arquivos abertos serviram de matéria-prima a numerosos modelos. Bloquear o CCBot é a alavanca mais larga contra o treino por parte de agentes que não têm robot próprio.

A tabela dos tokens, e o que cada bloqueio implica

O que o robots.txt pode e não pode fazer

O protocolo está hoje normalizado pela RFC 9309. Três das suas regras explicam a maior parte das surpresas:

1. O ficheiro só é lido na raiz do host. É o host e não o domínio: um robots.txt servido em exemplo.pt não governa blog.exemplo.pt, que é um host distinto. Um robots.txt colocado num subdiretório, por exemplo sob um caminho /blog/ alojado noutro sítio, nunca é consultado. As diretivas que contém, incluindo as declarações de sitemap, são invisíveis para todos os robots. Num meio de comunicação montado em subcaminho de um site principal, é o robots.txt do site principal que faz fé.
2. O grupo mais específico ganha, e substitui o grupo genérico. Um grupo User-agent: GPTBot que contenha apenas Disallow: / não herda as regras do grupo User-agent: *. Se o grupo genérico proibia facetas ou ficheiros, o robot nomeado volta a ter-lhes acesso. É um erro corrente quando se empilham grupos por robot ao longo dos meses.
3. O ficheiro é uma indicação, não uma barreira. Os fornecedores aqui citados declaram respeitá-lo. Um agente que não declara o seu nome escapa a toda a regra nominal. Para bloquear a sério, há que agir ao nível do servidor ou da firewall, com os efeitos secundários que descrevemos no artigo sobre o ponto cego dos bloqueios em edge.

Que política escolher

A decisão é editorial antes de ser técnica. Há três posições defensáveis:

• Abrir tudo. O site aceita o treino e a citação. É a posição por omissão de um meio de comunicação que procura visibilidade, incluindo dentro dos próprios modelos.
• Recusar o treino, aceitar a citação. Bloqueia-se o GPTBot, o ClaudeBot e o CCBot, proíbe-se o Google-Extended e o Applebot-Extended, deixando passar o OAI-SearchBot, o Claude-SearchBot, o PerplexityBot e os robots «User». É a posição de um editor que quer ser citado sem alimentar os modelos de graça.
• Fechar tudo. O site renuncia à visibilidade nas IA. É defensável para uma intranet ou um conteúdo pago, não para um meio de comunicação que quer pesar numa SERP ou numa resposta gerada.

A segunda posição é frequente entre os editores de imprensa, e muitas vezes mal aplicada: na prática, muitos proibiram de um só gesto tudo o que continha «GPT» ou «Claude», logo também os robots de pesquisa e de leitura. O resultado é um site ausente das respostas geradas, sem que ninguém na equipa o tenha decidido.

Verificar em vez de supor

O controlo cabe em dois gestos. Primeiro, reler o ficheiro robots.txt tal como é servido na raiz, token a token, com a tabela acima debaixo de olho. Depois, abrir os logs do servidor para ver que robots vêm realmente, com que frequência, e quais recebem um código 403 ou 404. Um robot de IA que nunca figura nos logs não está forçosamente ausente: pode ter sido travado a montante por uma firewall, antes de chegar ao servidor. Esta verificação está descrita passo a passo em «Ler um access log em 30 minutos».

Do lado da Google, a Search Console fornece um relatório robots.txt que mostra a última versão lida pelo Googlebot, a sua data de recuperação e os eventuais erros de análise; a apresentação do robots.txt pela Google descreve o seu uso. Para os outros fornecedores não existe equivalente: são os logs que fazem fé, e um teste manual com o user-agent de cada robot continua a ser a forma mais segura de verificar o que o servidor responde realmente.

Um meio de comunicação que quer ser citado não pode entregar-se a um ficheiro escrito há dois anos. Os tokens mudam, os robots multiplicam-se, e uma linha acrescentada por precaução num dia de 2023 pode custar toda a presença nas respostas das IA em 2026.