O teu site passa a receber visitas de máquinas em nome de outra máquina. Uma parte do tráfego automático já nem é de motores de busca clássicos: há robôs a ler para treinar modelos, há robôs a indexar para dar respostas com citações e há agentes a abrir páginas a pedido de alguém que está num chat. Este guia identifica os principais — GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot e restantes — mostra como distinguir treino, busca e agentes, e explica onde decidir: nas directivas do robots.txt e nas políticas de bots de IA da Cloudflare (o quadro onde um site WordPress atrás da Cloudflare, como o kbase.pt, pode decidir com efeito real e não só com boas intenções).

TL;DR — o essencial

  1. Os bots de IA partem-se em três famílias — treino (GPTBot, ClaudeBot, Bytespider), busca-respostas (OAI-SearchBot, Claude-SearchBot, PerplexityBot) e agentes de utilizador (ChatGPT-User, Claude-User, Perplexity-User) — e cada família usa o seu token no robots.txt.
  2. O robots.txt é sinal, não fechadura — o cumprimento é voluntário (a própria Cloudflare escreve-o à letra) e a aplicação técnica fica no proxy que está à frente do site.
  3. Na Cloudflare: Security Settings > Configure AI bot policies — presets Search, Agent e Training, cada um com Block, Block on pages with ads ou Allow — o Training tem además a 4.ª opção Disallow AI Training, que publica a preferência no robots.txt e bloqueia à edge quem só treina — com regras geridas que se auto-actualizam e não contam para os limites de custom rules.
  4. A 15 de Setembro de 2026 a Cloudflare aplicou defaults novos em domínios novos — Training e Agent bloqueados nas páginas com publicidade, Search permitida — e criou o Disallow AI Training: recusa o treino e mantém a busca, porque os Block passaram a apanhar também os crawlers de duplo propósito (Googlebot, Applebot, Bingbot) e já não são seguros.
  5. O Bot Preference Sync gera o robots.txt gerido com Content Signals e o AI Labyrinth amarra quem ignora os sinais — a vigilância fica no AI Crawl Control e no Security Analytics.

Quem anda lá no teu site

As empresas de IA usam crawlers por categorias de propósito, e cada uma usa um token próprio no robots.txt. A OpenAI documenta os quatro agentes com tabelas de propósito e strings de user-agent de exemplo, a Anthropic documenta três, a Perplexity dois. Os tokens são estes:

Bot Quem manda O que faz no teu site Token no robots.txt
GPTBot OpenAI Rastreia conteúdo que pode entrar no treino dos modelos fundacionais (a doc diz: torná-los mais úteis e seguros). Bloquear indica que o conteúdo não deve ser usado no treino. GPTBot
OAI-SearchBot OpenAI Faz os sites aparecerem nos resultados de busca do ChatGPT. A OpenAI recomenda permitir para manteres visibilidade nas respostas de busca. OAI-SearchBot
ChatGPT-User OpenAI Visita páginas a pedido de utilizadores no ChatGPT e em Custom GPTs. Não rastreia automaticamente — como é iniciado pelo utilizador, as regras do robots.txt podem não aplicar-se. ChatGPT-User
OAI-AdsBot OpenAI Valida páginas submetidas como anúncios no ChatGPT, só nessas páginas, e não treina com o que recolhe. OAI-AdsBot
ClaudeBot Anthropic Recolhe conteúdo web que pode contribuir para o treino dos modelos. A Anthropic diz que restringir o acesso sinaliza exclusão dos futuros conjuntos de treino. ClaudeBot
Claude-User Anthropic Acede a sites quando um utilizador do Claude o pede. Bloquear impede a recuperação do conteúdo em resposta a pedidos de utilizador. Claude-User
Claude-SearchBot Anthropic Indexa conteúdo para melhorar a qualidade e a precisão das respostas de busca do Claude. Claude-SearchBot
PerplexityBot Perplexity Faz aparecer e ligar sites nos resultados de busca da Perplexity — a doc diz à letra que não é usado para treinar modelos fundacionais. PerplexityBot
Perplexity-User Perplexity Visita páginas quando um utilizador faz uma pergunta — para dar resposta e incluir um link. Não é crawler nem recolhe para treino. Perplexity-User
Bytespider ByteDance Crawler da ByteDance que a Cloudflare inclui no bloco gerido de directivas de bloqueio de treino, ao lado de GPTBot e ClaudeBot. Bytespider

As strings de user-agent de exemplo, tal como as documentam a OpenAI e a Perplexity (o número de versão pode mudar):

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-AdsBot/1.0; +https://openai.com/adsbot
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)

A Anthropic documenta os três bots pelos tokens (ClaudeBot, Claude-User, Claude-SearchBot) no artigo oficial sobre rastejo, e publica em claude.com/crawling/bots.json a lista oficial de endereços IP dos seus bots — a lista serve para confirmar nos teus logs que quem bateu na porta era mesmo a Anthropic, porque uma string de user-agent é fácil de imitar. As listas equivalentes da OpenAI (gptbot.json, searchbot.json) e da Perplexity (perplexitybot.json) funcionam da mesma maneira.

Decide a tua política: treino, busca ou agentes

A pergunta certa não é deixo entrar a IA? — é entrar para quê?. Cada família de robô vai usar o teu conteúdo de um modo diferente e só uma delas tem qualquer retorno mensurável para o site:

  • O treino leva o conteúdo para dentro de um modelo e fica lá aprendido. Não há link de volta, não há citação com tráfego, não há nada que te apareça no analytics. É o caso do GPTBot e do ClaudeBot — conteúdo a fundo, devolução zero.
  • Busca-respostas — OAI-SearchBot, Claude-SearchBot e PerplexityBot indexam para o site poder aparecer nas respostas dos chats com link. A OpenAI diz directamente que sites fora do OAI-SearchBot não aparecem nas respostas de busca do ChatGPT (podem seguir como links navegacionais) e a Perplexity usa a mesma lógica. Aqui o debate é do site: se as respostas de IA partem tráfego que antes era do Google, esta é a porta a medir e por enquanto a mais razoável deixar aberta.
  • Agentes — ChatGPT-User, Claude-User e Perplexity-User actuam em tempo real a pedido de um utilizador concreto: abrir a página que ele partilhou, ler o que ele perguntou. É tráfego de utilizador disfarçado de máquina. Bloquear corta funções que os teus próprios leitores vão pedir, e nota que a OpenAI avisa que, por ser iniciado pelo utilizador, o robots.txt pode nem aplicar-se ao ChatGPT-User.

As duas casas tratam os três sinais como independentes: a OpenAI sugere literalmente permitir OAI-SearchBot enquanto bloqueias GPTBot para avisar que o conteúdo não é para treino, e nota que a actualização de um robots.txt demora cerca de 24 horas a reflectir na busca do ChatGPT. Em tempo, o mesmo raciocínio traduz-se nos três presets da Cloudflare — Search, Agent e Training — que já verás na secção 4, escolhendo Block, Block on pages with ads ou Allow. Deixa a busca medir tráfego, fecha ou limita o treino, e decide os agentes conforme o teu produto.

robots.txt: as directivas e a sua limitação

A Anthropic escreve o bloqueio completo à letra nos seus docs. O mesmo formato canónico de bloco por token serve para o GPTBot, o token que a OpenAI documenta como robots.txt tag. O bloqueio total dos dois fica assim:

User-agent: GPTBot
Disallow: /
#
User-agent: ClaudeBot
Disallow: /

A Anthropic documenta também uma alternativa mais suave: deixar ler, mas limitar a velocidade do rastejo (extensão Crawl-delay, não-standard):

User-agent: ClaudeBot
Crawl-delay: 1

Estas directivas são o sinal que a OpenAI e a Anthropic dizem honrar em todos os seus bots — a Anthropic diz mesmo que os seus bots respeitam sinais de do not crawl e tecnologias anti-contorno. E é todo o mecanismo: um robots.txt não é fechadura, é cartaz.

A limitação: robots.txt é voluntário

A própria documentação da Cloudflare diz-o à letra: o cumprimento do robots.txt é voluntário, o ficheiro exprime preferências mas não impede tecnicamente o acesso, e alguns operadores podem ignorar directivas como Disallow: / e rastrear na mesma. A Anthropic, pela sua vez, avisa que optar por fora exige a edição do robots.txt e que métodos alternativos — bloquear os IPs de onde os bots operam — podem não funcionar nem garantir o opt-out de forma duradoura, porque impedem justamente a leitura do robots.txt. Conclusão prática: o robots.txt vale como sinal normalizado, a aplicação técnica fica para o proxy que está à frente do site.

Cloudflare: políticas de bots de IA

Para um site atrás da Cloudflare — o caso do kbase.pt e de boa parte da web — o caminho com dentes são as políticas de bots de IA construídas na própria plataforma, onde o pedido é classificado na edge antes de chegar ao WordPress.

O caminho nas settings: no dashboard da Cloudflare, abres a zona do domínio e entras na página Security Settings, filtras por Bot traffic e abres Configure AI bot policies. Aí estão três presets — Search, Agent e Training — cada um com o seu propósito documentado (os significados são a tradução fiel da doc):

Preset O que cobre (segundo a doc da Cloudflare)
Search Crawlers que recolhem ou indexam o teu conteúdo para responder perguntas sobre ele mais tarde.
Agent Actividade automatizada a agir em tempo real em nome de uma pessoa, como bots de pesquisa de chat e agentes de uso de browser.
Training Crawlers que levam o teu conteúdo para treinar ou afinar um modelo — incluindo os crawlers de duplo propósito (mixed-purpose), usados tanto para treino como para busca.

Cada preset aceita quatro níveis de mitigação desde o dia 15 de Setembro de 2026, também eles os oficiais: Block (on all pages) — bloqueia em toda a zona, e desde Setembro aplica-se a todos os crawlers de treino, incluindo os de duplo propósito (Googlebot, Applebot, Bingbot): pode tirar-te da busca. Block on pages with ads — usa a detecção automática da Cloudflare das páginas do teu domínio que mostram publicidade para bloquear apenas nessas páginas — ao contrário do que dizia a doc de Julho, hoje também apanha o duplo propósito. Disallow AI Training — só existe no Training: publica a preferência de não-treino no robots.txt (via Bot Preference Sync) e bloqueia à edge os crawlers exclusivamente de treino — os mistos Accountable (Googlebot, Applebot, Bingbot) continuam a indexar. Allow (do not block) — não acrescenta qualquer bloqueio. Para um site WordPress com AdSense a decisão já não é a do meio: se o objectivo é treino fechado sem perder a busca, é Disallow AI Training.

Novos defaults aplicados a 15 de Setembro de 2026

A Cloudflare aplicou os defaults ao domínio novo a 15 de Setembro de 2026 — bots classificados como Training ou Agent passaram a estar bloqueados nas páginas que mostram publicidade e a Search ficou permitida, e os crawlers de duplo propósito, que combinam busca e treino, ficam bloqueados por todas as configurações de bloqueio de treino — incluindo a opção antiga Block AI bots. Na mesma data a Block AI bots ficou descontinuada: bloqueava bots verificados classificados como treino mais um conjunto de bots não verificados de comportamento semelhante, e excluía deliberadamente os mixed-purpose usados para treino e busca. O movimento de Setembro fechou essa fuga e migrou os bloqueios de Training existentes para Disallow AI Training — as escolhas de Search e Agent mantiveram-se. O blog oficial da Cloudflare é explícito: Block e Block on pages with ads passam a aplicar-se a mixed-use crawlers, incluindo Applebot, Bingbot e Googlebot, pelo que afectam a busca e o treino ao mesmo tempo — para parar treino e continuar na busca, Disallow AI Training.

Os presets usam regras geridas, auto-actualizadas

Os toggles de política vivem nas Security Settings e não contam para os limites de custom rules: a Cloudflare actualiza-os automaticamente quando identifica novas assinaturas de bots e novos crawlers de IA — o que significa que um crawler novo da lista entra nas tuas políticas sem nenhuma edição da tua parte, ao contrário de uma regra WAF escrita à mão.

Bot Preference Sync: robots.txt gerido e Content Signals

As políticas de edge e o robots.txt podem falar ao mesmo tempo. O Bot Preference Sync gera directivas geridas a partir das tuas políticas Search, Agent e Training desde que ao menos uma esteja em Block, em Block on pages with ads ou, no caso de Training, em Disallow AI Training. Se o teu domínio já tem robots.txt servido pela origem, a Cloudflare concatena o conteúdo gerido ANTES do teu (com a Content Signals Policy no topo) e cria um só ficheiro. Se não tiver, cria um com directivas de bloqueio para os crawlers de IA conhecidos e serve-o ela própria.

Caveat do Bing: por agora, selecting Disallow AI Training will not automatically convey a no-training preference to Bing through robots.txt — a Cloudflare avisa na nota oficial. O suporte da Microsoft à transmissão automática da preferência está previsto, no relato da PPC Land, para o início de 2027 — até lá, a exclusão no Bing faz-se nas ferramentas do Bing Webmaster Tools.

A activação está na mesma página: em Training escolhes Disallow, ligas Enable Bot Preference Sync e gravas. Com o sync ligado, a Cloudflare nota que gravar Training em Disallow acrescenta as directivas geridas e activa também o bloqueio na edge para crawlers de treino (os mixed-use ficam de fora desse bloqueio de edge). Os presets Search e Agent acrescentam as respectivas directivas geridas quando ficam em Block ou Block on pages with ads.

O conteúdo gerido tem esta forma (o exemplo da doc, abreviado nos comentários de topo):

# BEGIN Cloudflare Managed content
User-Agent: *
Content-signal: search=yes, ai-train=no, use=reference
Allow: /
User-agent: Amazonbot
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: Bytespider
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: GPTBot
Disallow: /
User-agent: meta-externalagent
Disallow: /
# END Cloudflare Managed Content

A linha Content-signal: search=yes, ai-train=no, use=reference é a Content Signals Policy, o anexo maquinável do ficheiro: três categorias — search índice de busca, ai-input injecção de conteúdo em modelos para respostas em tempo real, ai-train treino e afinação de modelos — e um quarto sinal experimental use= em três valores de permissividade (immediate interage e nada guarda, reference indexa e cita com link de volta, full resume e reproduz). No conteúdo gerido a Cloudflare acrescenta use=reference, alinhado com o par default search=yes, ai-train=no.

Verificação barata e valiosa: gravas as políticas, o conteúdo gerido aparece em segundos (a doc diz: sem purge de cache, basta recarregar o ficheiro), e confirmas com um simples pedido público. O robots.txt servido é o que os bots leem, não o teu ficheiro na origem. E se o Google Search Console reportar Syntax not understood sobre Content Signals, os autores dizem já não ter observado impacto em rastejo nem em SEO — é um aviso de parser, não de problema.

AI Labyrinth e regras personalizadas

Contra quem ignora os sinais todos, a Cloudflare tem o AI Labyrinth: injecta na página links invisíveis com atributos Nofollow e empurra os crawlers que rastreiam sem autorização para um labirinto de links sem fim — os detalhes de quem cai ficam registados e servem a todos os clientes Cloudflare que bloqueiam bots de IA. Segundo a doc, os links não afectam o SEO nem a aparência, só são vistos por bots, e os crawlers que respeitam as instruções de não-rastejo ignoram o honeypot.

A activação também vive nas Security Settings: filtras por Bot traffic, abres AI Labyrinth e tornas on. No Security Analytics aparecem depois duas acções sob o serviço AI Labyrinth — AI Labyrinth Served (links injected na resposta) e AI Labyrinth Crawls (um crawler seguiu o link e entrou no labirinto). Os próprios autores avisam: estas acções não são mitigações — a Cloudflare não bloqueia nem desafia o pedido.

As regras WAF personalizadas ficam para o que os toggles não dão: protecção por caminho (mais severa em /login do que em /public), thresholds de bot score à medida (os settings fixos usam 1 e 2-29), lógica composta com país/ASN/JA4/user agent, acções fora de Block/Managed Challenge/Allow — como Log para provar regras em silêncio antes de as activar — e o envio de dados de bot para a origem. O exemplo da doc, bloquear tráfego provavelmente automático só no endpoint de login:

(cf.bot_management.score lt 30 and not cf.bot_management.verified_bot and http.request.uri.path eq "/login")

WordPress e pedidos loopback

Se a protecção de bots estiver activa, os pedidos internos do próprio WordPress — loopback, cron — podem ficar do lado de fora. Nas settings de bots existe, na zona, a opção Optimize for WordPress (planos Pro, Business e Enterprise) que deixa passar esses pedidos pela protecção. Liga-a quando activares bloqueios agressivos: é o interruptor que evita quebras internas do próprio CMS.

Como vigiar: AI Crawl Control, Analytics e logs

O AI Crawl Control (o antigo AI Audit) é a dashboard de rastejo de IA da Cloudflare e está disponível em todos os planos. No domínio, abres AI Crawl Control e dentro a tab Crawlers — a tabela diz, para cada crawler que pediu o teu conteúdo, o operador e a categoria, os pedidos permitidos e os mal-sucedidos com gráfico de tendência, quantas violações cometeu ao teu robots.txt e a acção em curso. Os filtros de Name, Operator e Category afunilam a lista.

A acção é por crawler: Allow ou Block — e o Block cria ou actualiza uma regra WAF custom na tua zona, pronta a estender com excepções por caminho ou user-agents extra. Além dos dois há o Enforce robots.txt, que põe dentes nos sinais do teu ficheiro. No plano Free a detecção é pela string do user-agent e apanha bem crawlers que se identificam. Nos planos pagos a detecção sobe para o detection ID do Bot Management e fica mais fiel.

O Security Analytics e o Security Events fecham o quadro: é lá que se lê o que cada política aplicou, e os eventos AI Labyrinth da secção anterior aparecem nos dois. Para o ficheiro em si, o próprio AI Crawl Control acompanha a saúde do robots.txt — diz que crawlers o violam e com que frequência.

Do lado do servidor, os logs de acesso do WordPress e do Nginx/Apache dão a vista sem filtro — user-agent e endereço IP em cada pedido. Para confirmar que quem bateu era mesmo quem a string diz (uma UA imita-se em minutos), as listas oficiais de IP dos bots — as da OpenAI e da Perplexity e a da Anthropic, já referidas atrás — são o par de verificação de qualquer pedido estranho.

Plano prático para um site WordPress atrás da Cloudflare

Juntando tudo, este é o percurso numa tarde:

  • 1) Decide a política — busca aberta (é a porta com tráfego medível), treino fechado, agentes conforme o produto do teu site.
  • 2) Define as políticas — dashboard do domínio → Security Settings → filtrar Bot traffic → Configure AI bot policies: Training em Disallow AI Training (recusa o treino e deixa Googlebot/Applebot/Bingbot continuar na busca — Block e Block on pages with ads, desde 15/09/2026, apanham também os de duplo propósito — não uses aí) — Agent conforme decisão — Search em Allow.
  • 3) Liga o Enable Bot Preference Sync e grava — o robots.txt gerido aparece em segundos com os disallows e os Content Signals.
  • 4) Liga o AI Labyrinth no caminho Security Settings → Bot traffic → AI Labyrinth.
  • 5) Confirma o que o mundo vê — um pedido público ao ficheiro mostra as directivas que os bots vão ler, e nos Security Events segues as acções AI Labyrinth.
  • 6) Confirma identidade por IP quando algo estranho aparecer — as listas oficiais de endereços permitem distinguir um bot real de uma string imitada.
  • 7) Mede e re-avalia — a busca-respostas pode dar ou não tráfego — os teus analytics decidem se a Search fica aberta. O treino, esse, não devolve nada que se meça e não merece o benefício da dúvida.

O passo 5, concreto:

curl -s https://oteudominio.pt/robots.txt | head -20

Veredicto

Deixa a busca-respostas aberta e mede — é a única família que pode devolver visitas. Bloqueia o treino — o conteúdo não volta em forma de tráfego e hoje há mecanismos sólidos para pôr essa decisão na prática. Decide os agentes com cabeça: são pedidos de utilizadores reais e bloqueá-los corta funções do próprio produto. Na Cloudflare isto cabe em três presets — com o Disallow AI Training no Training — e dois interruptores, e a data dos defaults aplicados (15 de Setembro de 2026) vale para recordares que a decisão de omissão já é uma decisão. Um robots.txt sozinho é um cartaz — correcto, necessário e sem dentes. O que muda aqui é juntar o cartaz à porta.

Artigos Relacionados

Fontes Oficiais