Por que "permitir ou bloquear" é a pergunta errada para os crawlers de IA?
A pergunta útil é o que cada crawler faz com o seu conteúdo. Alguns crawlers de IA coletam material que pode ser usado para treinar modelos. Outros acessam páginas para que um assistente possa pesquisar, ler e citar essas páginas quando um usuário faz uma pergunta. Tratar todos como uma única categoria cria um dilema que não precisa existir.
Para uma equipe B2B, o custo de bloquear em excesso costuma ser maior do que o custo de permitir o acesso para busca. Se as suas páginas de produto, comparativos e documentação ficarem invisíveis para os mecanismos de resposta, compradores que pedem a assistentes listas de fornecedores nunca vão ver a sua marca. O objetivo é decidir, crawler por crawler, qual finalidade você aceita.
Um framework prático tem três camadas: acesso para treinamento, acesso para busca e citação, e recuperação iniciada pelo usuário. Defina uma decisão para cada camada e, depois, implemente-a no robots.txt. Revise essas decisões quando os fornecedores atualizarem a documentação, porque os nomes e o comportamento dos crawlers podem mudar.
O que são GPTBot, OAI-SearchBot e ChatGPT-User, e quais você deve permitir?
O GPTBot é o crawler da OpenAI associado à coleta de dados para treinamento. O OAI-SearchBot está associado à busca do ChatGPT, então indexa conteúdo que pode aparecer nas respostas de busca. O ChatGPT-User é usado quando uma pessoa pede ao ChatGPT que abra uma página durante uma conversa. Cada um tem uma finalidade diferente e, de acordo com a documentação de crawlers da OpenAI, cada um é controlado de forma diferente.
Uma decisão comum para marcas B2B é bloquear o GPTBot, permitir o OAI-SearchBot e tratar o ChatGPT-User como uma requisição iniciada pelo usuário. Consulte a documentação atual da OpenAI antes de finalizar as regras, porque os detalhes de como cada agente lida com o robots.txt são o tipo de coisa que os fornecedores costumam revisar.
| Crawler | Finalidade principal | Decisão típica para um site B2B | O que o bloqueio faz |
|---|---|---|---|
| GPTBot | Coleta de dados para treinamento | Bloquear se você optar por não participar do treinamento | Interrompe a coleta para treinamento; não remove, por si só, a visibilidade na busca |
| OAI-SearchBot | Indexação para a busca do ChatGPT | Permitir se você quiser ser citado | O bloqueio pode manter suas páginas fora dos resultados de busca do ChatGPT |
| ChatGPT-User | Busca de uma página a pedido do usuário | Geralmente é uma decisão de produto, não de treinamento | Pode não ser governado pelo robots.txt da mesma forma que os crawlers |
Bloquear o Google-Extended afeta o Google Search ou as Visões Gerais de IA?
Bloquear o Google-Extended não remove suas páginas da Pesquisa Google tradicional e, segundo a documentação do Google, não afeta a inclusão nas Visões Gerais de IA. O Google-Extended é um token do robots.txt que controla se o conteúdo rastreado pelo Google pode ser usado para treinar os modelos Gemini e para determinados usos de fundamentação. Ele não é um rastreador separado que busca suas páginas.
O risco está em confundi-lo com o Googlebot. Se você bloquear o Googlebot, suas páginas saem da Pesquisa e dos recursos de IA que dependem dela. Bloquear o Google-Extended apenas sinaliza que seu conteúdo não deve ser usado para treinar o Gemini e em usos relacionados.
Antes de alterar qualquer coisa, confirme explicitamente suas regras para o Googlebot. Uma diretiva Disallow ampla para todos os user agents, copiada de um modelo antigo, é o motivo mais comum de um site desaparecer do Google quando a equipe só queria optar por não participar do treinamento de IA.
Como escrever regras no robots.txt que permitam a citação, mas optem por não participar do treinamento?
Crie um grupo User-agent separado para cada rastreador de IA que você quer controlar, e mantenha os grupos do Googlebot e do Bingbot para a busca tradicional. As regras são aplicadas por grupo, então um Disallow em um grupo do GPTBot não afeta o OAI-SearchBot. Mantenha o arquivo na raiz de cada hostname, porque as regras do robots.txt não se estendem a subdomínios.
As regras abaixo são um ponto de partida para uma equipe que quer optar por não participar do treinamento, mas deseja ser citada. Ajuste-as à sua posição sobre o treinamento e não as copie sem revisar quais caminhos você realmente quer proteger.
- User-agent: GPTBot / Disallow: /
- User-agent: Google-Extended / Disallow: /
- User-agent: OAI-SearchBot / Allow: /
- User-agent: PerplexityBot / Allow: /
- User-agent: Googlebot / Allow: /
- User-agent: * / Disallow: /account/ e /staging/
- Audite seu robots.txt atual e anote regras amplas no user agent com asterisco, pois elas também se aplicam aos rastreadores de IA.
- Adicione um grupo para o GPTBot com Disallow: / se você optar por não participar do treinamento da OpenAI.
- Adicione um grupo para o Google-Extended com Disallow: / se você optar por não participar do treinamento do Gemini. Mantenha o Googlebot sem restrições.
- Adicione um grupo para o OAI-SearchBot e o PerplexityBot com Allow: / para que o acesso deles à busca fique explícito.
- Proteja caminhos privados, como áreas de conta, pastas de staging e resultados de busca interna, com regras Disallow que se apliquem a todos os agentes.
- Teste o arquivo nas ferramentas do Search Console e em um validador de robots.txt, depois publique e verifique novamente após cada atualização do site.
Quais rastreadores de IA respeitam o robots.txt e quais podem não respeitar?
Os principais operadores de IA que publicam documentação sobre seus rastreadores geralmente informam que os rastreadores declarados respeitam o robots.txt. Essas declarações servem como referência básica, mas são promessas, não garantias, e a redação de cada fornecedor deve ser conferida na documentação própria dele.
O robots.txt é uma diretriz, não uma barreira. Ele funciona porque os rastreadores bem-comportados optam por lê-lo. Algumas requisições iniciadas pelo usuário e algumas feitas por meio de ferramentas de terceiros podem não seguir as mesmas regras. Relatórios de terceiros também afirmaram que certos motores de resposta buscaram conteúdo usando user agents que não correspondiam aos nomes declarados. Trate qualquer string de user agent como uma alegação até verificá-la.
Se você precisa de aplicação efetiva, o robots.txt sozinho não basta. Use autenticação para conteúdo privado, limites de requisições (rate limits) ou um firewall de aplicação web (WAF) para tráfego abusivo, e reconheça internamente que uma regra publicada é um sinal, não uma trava.
Como verificar se uma requisição do PerplexityBot ou do GPTBot é genuína?
Verificar significa conferir se a requisição vem de um endereço IP que pertence ao operador declarado. A string de user agent é fácil de copiar, então não prova nada por si só. Os principais operadores que executam rastreadores dedicados publicaram listas de faixas de IP, e o Google documenta como verificar o Googlebot por meio de uma consulta de DNS reverso seguida de uma consulta de DNS direto.
A verificação é simples de fazer a partir de um shell ou de uma ferramenta de análise de logs. Compare os endereços IP dos seus logs com a lista publicada pelo operador e trate qualquer requisição que declare um nome mas venha de fora dessas faixas como não verificada. Mantenha um registro da data em que você obteve cada lista, porque as faixas mudam.
- Extraia dos logs do servidor as requisições cujo user agent contenha GPTBot, OAI-SearchBot, PerplexityBot, Perplexity-User ou Googlebot.
- Reúna os endereços IP de origem únicos para cada nome declarado.
- Para cada operador que publica faixas, verifique se o IP está dentro das faixas listadas.
- Para o Googlebot, faça uma consulta de DNS reverso no IP e confirme que o hostname pertence ao Google; em seguida, faça uma consulta de DNS direto para confirmar que ele resolve de volta para o mesmo IP.
- Classifique cada origem como verificada, não verificada ou sem lista publicada, e confie apenas nas contagens de rastreamento de origens verificadas.
- Repita a verificação mensalmente, já que novos endereços IP e novos user agents surgem com o tempo.
Como confirmar nos logs do servidor que os rastreadores de IA chegam às suas páginas B2B principais?
Os logs do servidor mostram o que os rastreadores solicitaram, quando, e qual código de status o servidor retornou. Em um site B2B, filtre essas requisições para as páginas que geram pipeline, como as de produto, preços, integrações, segurança e comparação, e verifique se os rastreadores de IA chegam até elas. Um rastreador que nunca solicita uma página-chave não consegue usá-la como citação, independentemente do que diz o seu robots.txt.
Observe três pontos: quais user agents de IA aparecem, quais caminhos de URL eles solicitam e se essas requisições retornam status 200. Respostas 403, 404 ou 5xx frequentes para rastreadores de IA verificados apontam para problemas de acesso, como uma regra de firewall ou um template quebrado, e não para uma decisão tomada no robots.txt.
- Exporte os logs de acesso brutos de pelo menos um período representativo e confirme o fuso horário.
- Filtre pelos user agents de IA e separe as requisições verificadas das não verificadas usando o método descrito acima.
- Conte as requisições por caminho de URL, agrupando por tipo de página, como produto, artigo, documentação e jurídico.
- Verifique os códigos de status retornados a cada rastreador verificado e corrija qualquer padrão de 4xx ou 5xx.
- Compare os caminhos solicitados com as páginas que você quer ver citadas e vincule as lacunas à sua estrutura de links internos e ao sitemap.
- Registre os resultados para poder compará-los após cada alteração no robots.txt ou na estrutura do site.
Onde a Rixe se encaixa
A análise manual dos logs é útil para uma primeira auditoria, mas não mostra como os motores de resposta descrevem a sua marca para as perguntas que os compradores fazem. Uma plataforma de visibilidade em IA, como a Rixe, mede como os assistentes mencionam e citam uma marca para um conjunto de prompts, o que permite verificar se o acesso dos rastreadores está se convertendo em visibilidade.