O teu robots.txt diz que sim e o teu firewall diz que não
Uma permissão no robots.txt não garante que o rastreador chegue. Como detetar um bloqueio do firewall em dois minutos, e porque é que o caso mais perigoso devolve HTTP 200.
Neste artigo7
Um robots.txt não abre nem fecha nada. É um letreiro na porta. Diz quem o dono gostaria que entrasse, e os rastreadores sérios respeitam-no. Mas quem decide mesmo quem passa não é o letreiro: é a infraestrutura que está à frente do servidor.
Daí sai uma das falhas mais frequentes que vemos, e também a mais difícil de detetar por dentro: um robots.txt impecável, com permissão explícita para todos os rastreadores de IA, e um firewall que os expulsa antes de chegarem a lê-lo.
Ninguém decidiu bloqueá-los
Isto quase nunca é uma decisão. É uma configuração herdada, ou um valor por omissão que ninguém reviu. As causas repetem-se:
- «Bot Fight Mode» ativado na Cloudflare. É um interruptor, está a um clique e soa bem. O que faz é devolver um desafio a tráfego automatizado que não esteja na sua lista de bots verificados.
- Regras geridas do WAF. Os pacotes de regras por omissão incluem categorias do género «scrapers» ou «ferramentas automatizadas» que varrem muito mais do que o nome sugere.
- Um plugin de segurança do WordPress. Vários trazem listas negras de user-agent que se atualizam sozinhas, e algumas dessas listas meteram os rastreadores de IA no mesmo saco que os scrapers de conteúdo.
- Limitação por frequência. Um rastreador que pede vinte páginas seguidas parece um ataque se o limite estiver definido para um humano a ler.
- Bloqueio geográfico. Se o teu site só admite tráfego a partir de um único país, tem em conta que os rastreadores saem de centros de dados, quase sempre lá fora. Filtrar por país filtra-os a eles.
Há ainda uma mudança de fundo que convém conhecer: em julho de 2025 a Cloudflare passou a bloquear rastreadores de IA por omissão nos domínios novos, e ofereceu aos existentes a hipótese de o ativar com um clique. Se o teu site foi montado depois dessa data atrás da Cloudflare, a pergunta não é se alguém o ativou, mas se alguém o desativou.
O que o rastreador vê quando não passa
Um bloqueio manifesta-se de três maneiras, e não são igualmente graves porque não são igualmente visíveis.
Um 403 ou um 401. O servidor nega o acesso aos agentes que não reconhece. Pelo menos é honesto: o rastreador vai-se embora a saber que o expulsaram. No nosso diagnóstico este é o caso que marcamos como bloqueio, porque não há ambiguidade.
Um 503 com página de espera. O clássico «Just a moment…» enquanto se resolve um desafio. Um navegador passa-o em dois segundos e o utilizador nem dá por isso. Um rastreador de IA não: não executa o JavaScript do desafio e não resolve um CAPTCHA. Para ele, o site acaba ali.
Um 200 que não é a tua página. Este é o pior, e é o que quase nenhuma ferramenta trata bem. O desafio é servido com estado 200 e com HTML próprio. Tudo parece correto: há resposta, há código de sucesso, há conteúdo. Só que o conteúdo não é o teu site.
Esse último caso é o que produz diagnósticos disparatados. Uma ferramenta que leia esse corpo sem verificar de que é corpo vai dizer-te que o teu site não tem H1, nem JSON-LD, nem meta description, sem nunca os ter visto. Descreve-te a página do firewall e cobra-ta como se fosse a tua.
Por isso no nosso motor há uma regra que não se negoceia: quando o que chega não é o conteúdo do site, as verificações que dependem do corpo declaram-se não conclusivas e saem do cálculo. Não contam como zero. Acusar um site de uma falha que não conseguimos observar é pior do que não dar o dado.
Como verificá-lo no teu próprio site, em dois minutos
O teste é uma comparação: pede a mesma página duas vezes, uma como navegador e outra como rastreador, e vê se te respondem o mesmo.
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36" https://tudominio.es/
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
https://tudominio.es/Se o primeiro devolver 200 e o segundo 403 ou 503, já o tens. Repete com PerplexityBot e com ClaudeBot: nem sempre se comportam da mesma maneira, porque as listas de bots verificados não são as mesmas em todo o lado.
E para apanhar o caso do 200 enganador, olha para o corpo em vez do código:
curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
https://tudominio.es/ | grep -i -E "just a moment|challenge-platform|datadome|incapsula"Qualquer correspondência significa que te estão a servir um desafio, e não o teu site.
Um aviso sobre isto: declarar um user-agent alheio para testar o teu próprio site é legítimo e é a única forma de reproduzir o que acontece. Fazê-lo contra sites de terceiros já é usurpação de identidade. Nós não o fazemos: analisamos com o nosso próprio agente identificado e detetamos a assinatura do desafio no que nos chega —Cloudflare, Imperva, DataDome, Akamai, Sucuri, PerimeterX e o cabeçalho cf-mitigated—, o que é informação suficiente sem fingir ser ninguém.
Onde procurar se o bloqueio aparecer
Na Cloudflare, por ordem de probabilidade: Security → Bots (Bot Fight Mode e, se o tiveres, a configuração do Super Bot Fight Mode para «Definitely automated»), a secção de rastreadores de IA, as regras geridas do WAF, e as regras de limitação de frequência. No painel de eventos de segurança podes filtrar por user-agent e ver, com data e hora, que regra concreta expulsou quem. É o sítio onde acabam as hipóteses.
Se o bloqueio vem do alojamento ou de um plugin, a ordem é a mesma: procura primeiro a lista de user-agent, depois o limite de pedidos.
Bloquear nem sempre é mau
Convém dizê-lo, porque o setor tende a tratar isto como se só houvesse uma resposta certa. Há motivos legítimos para fechar a porta: o rastreio de IA consome largura de banda que és tu que pagas, e há editores que decidiram que o seu conteúdo não viaja de graça. Isso é uma posição, não um erro.
O que quase nunca é uma posição é o estado em que está a maioria dos sites que analisamos: bloqueados por arrasto, por uma configuração que ninguém escolheu, enquanto o robots.txt jura o contrário. Se decides bloquear, bloqueia de propósito. E se o fizeres, separa bem as coisas: fechar o rastreio de treino não te custa nenhuma citação; fechar o rastreio de resposta custa, e é aí que se perde tráfego sem dar por isso.
Duas perguntas, não uma
No fim, tudo se resume a isto. Permites no papel? É o que diz o teu robots.txt. Chega na prática? Isso di-lo a tua infraestrutura. À primeira pergunta responde-se abrindo um ficheiro de texto. A segunda tem de ser provocada.
O nosso diagnóstico gratuito faz as duas coisas: calcula as regras do robots.txt agente a agente e, ao mesmo tempo, verifica o que se recebe realmente ao pedir as tuas páginas. Quando as duas respostas não coincidem, essa contradição é o resultado mais útil que te vamos dar.
Perguntas frequentes
Como sei se o meu firewall está a bloquear os rastreadores de IA?
Pede a mesma página duas vezes com curl, uma a declarar um user-agent de navegador e outra o de um rastreador como o OAI-SearchBot, e compara. Se a primeira devolver 200 e a segunda 403 ou 503, tens um bloqueio. Se as duas devolverem 200, procura no corpo da resposta marcas como «Just a moment», challenge-platform ou datadome: significam que te estão a servir um desafio em vez do teu site.
O meu robots.txt permite o acesso. Porque é que mesmo assim não me leem?
Porque o robots.txt não abre nem fecha nada: é um letreiro na porta, e quem decide quem passa é a infraestrutura que está à frente do servidor. Um «Bot Fight Mode» ativado na Cloudflare, uma regra do WAF, um plugin de segurança, um limite de pedidos ou um filtro por país podem expulsar o rastreador antes de ele chegar a ler o ficheiro que lhe dá permissão.
Se o site devolve HTTP 200, está tudo bem?
Não necessariamente, e é o caso mais perigoso. Um desafio anti-bot pode ser servido com estado 200 e com HTML próprio: há resposta, há código de sucesso e há conteúdo, só que o conteúdo não é o teu site. Uma ferramenta que leia esse corpo sem verificar de que é corpo vai dizer-te que a tua página não tem H1, nem JSON-LD, nem meta description, sem nunca os ter visto.
Bloquear o GPTBot tira-me visibilidade no ChatGPT?
Não. O GPTBot recolhe texto para treinar modelos, e bloqueá-lo é uma decisão editorial legítima que não custa nenhuma citação. O que custa visibilidade é bloquear os rastreadores de resposta —OAI-SearchBot, ChatGPT-User, PerplexityBot—, porque são esses que leem o teu site em direto quando alguém pergunta, e é daí que saem as citações com ligação.
É mau bloquear os rastreadores de IA?
Não, desde que seja uma decisão. O rastreio consome largura de banda que és tu que pagas, e há editores que decidiram que o seu conteúdo não viaja de graça. O problema é o estado em que está a maioria dos sites: bloqueados por arrasto, por uma configuração que ninguém escolheu, enquanto o robots.txt jura o contrário.
Onde procuro na Cloudflare se aparecer um bloqueio?
Por ordem de probabilidade: a secção de bots dentro de Security (Bot Fight Mode e a configuração do Super Bot Fight Mode), a secção de rastreadores de IA, as regras geridas do WAF e as regras de limitação de frequência. No painel de eventos de segurança podes filtrar por user-agent e ver, com data e hora, que regra concreta expulsou quem.
