O que a firewall esconde dos seus logs: o ponto cego dos bloqueios em edge

Um responsável de site abre os seus logs, procura GPTBot, ClaudeBot ou PerplexityBot, não encontra nada e conclui que as IA não se interessam pelo seu conteúdo. A conclusão é muitas vezes falsa, e por uma razão mecânica: quando uma firewall ou um CDN recusa um pedido, este para na periferia da rede, em edge, e nunca chega ao servidor de origem. Não existe, portanto, em nenhum log de origem. O silêncio dos logs não significa a ausência dos robots; pode significar exatamente o contrário.

Como um pedido pode desaparecer

Num site servido por trás de um CDN como a Cloudflare, cada pedido atravessa várias camadas antes de chegar ao servidor. A firewall aplicacional, descrita na documentação do WAF da Cloudflare, avalia regras e pode bloquear, redirecionar ou mostrar um desafio. Um módulo de gestão de robots, detalhado na documentação Bots, classifica o tráfego automatizado e aplica-lhe uma política. Desde 2024, estas plataformas propõem bloquear os robots de IA num clique, como a Cloudflare anunciou no seu artigo sobre o bloqueio dos robots de IA, e muitos sites ativaram a opção sem medir o que ela fazia.

Qualquer pedido travado a este nível recebe uma resposta fabricada pelo CDN, em regra um código 403 ou uma página de desafio. O servidor de origem não vê nada disso. Os logs do Apache, do nginx ou da aplicação não o contêm, e uma ferramenta de análise de logs que só lê a origem não o consegue contar.

Os três erros de raciocínio que isto produz

1. «Nenhuma IA vem ter connosco.» É o mais corrente. O site é de facto visitado, mas cada visita é recusada a montante. Uma regra ativada por precaução, às vezes por um prestador, às vezes por uma caixa assinalada numa interface, corta em silêncio qualquer possibilidade de ser citado.
2. «A nossa taxa de sucesso de crawl é de 100 %.» Um painel que conta as respostas 200 servidas pela origem mostra uma pontuação perfeita, já que só os pedidos aceites lá chegam. A taxa real, bloqueios incluídos, pode ser muito baixa.
3. «O robot não respeita o nosso robots.txt.» Se o próprio robots.txt é servido pela origem mas o primeiro pedido do robot é bloqueado em edge, ele nunca o leu. Acusa-se o robot de um comportamento cuja causa é local.

Como verificar o que se passa em edge

Os controlos, do mais simples ao mais completo:

• Reler a configuração do CDN. Regras WAF, modo de gestão dos robots, opções «bloquear os robots de IA», listas de user-agents recusados. É preciso lê-la tal como está, e não tal como se julga tê-la regulado: num site que auditámos este verão, uma regra de bloqueio herdada de uma configuração anterior cortava robots que ninguém na equipa julgava estar a bloquear.
• Testar com os user-agents verdadeiros. Enviar por si próprio um pedido a uma página pública declarando o user-agent de cada robot de IA, a partir do exterior da rede, e olhar para o código de resposta e para quem o emitiu. Um 403 assinado pelo CDN quando a origem responde 200 é a prova direta do bloqueio em edge.
• Ler os logs do CDN, e não apenas os da origem. Os grandes CDN expõem estatísticas de tráfego que incluem os pedidos recusados, por regra e por user-agent, e às vezes por caminho. É aí que se veem os robots que se julgavam ausentes. Na Cloudflare, estes dados estão acessíveis pela interface e por API com um token que disponha do direito de leitura Zone Analytics; numa oferta gratuita, a repartição por caminho obriga a passar pela API.

Um caso medido

Noutro site, industrial, auditado no mesmo verão, os logs de origem não mostravam nenhum pedido de um robot de IA ao longo de várias semanas, e o painel de crawl exibia uma taxa de sucesso perfeita. Os logs do CDN contavam outra coisa: várias centenas de pedidos de robots de IA recusados com 403 por uma regra de firewall, de que ninguém tinha registo. A conclusão inicial, «as IA não vêm», era o exato inverso da realidade: vinham, com regularidade, e iam-se embora sem ler nada. O site não aparecia em nenhuma resposta gerada, não por falta de interesse dos motores, mas por causa de uma definição de segurança. O diagnóstico levou uma hora; podia nunca ter sido feito.

A armadilha do endereço IP

Um segundo efeito do CDN complica a leitura dos logs de origem: o endereço IP que o servidor vê é o do CDN, não o do visitante, a menos que o servidor esteja configurado para ler o cabeçalho que transporta o endereço de origem. Quando essa definição falta, todos os visitantes, humanos e robots, parecem vir de algumas dezenas de endereços pertencentes ao CDN. As verificações de autenticidade descritas no nosso artigo sobre o reverse DNS e as gamas de IP tornam-se impossíveis, e um robot autêntico pode ser tomado por um impostor, ou o inverso. Um cabeçalho proprietário acrescentado pelo CDN sobrevive em regra a todos os saltos intermédios onde um cabeçalho genérico pode ser sobrescrito. Na Cloudflare é o CF-Connecting-IP; o cabeçalho genérico, X-Forwarded-For, pode ser reescrito por qualquer intermediário. Peça ao seu alojamento o nome exato do que ele acrescenta, e confirme que chega efetivamente ao log de origem.

Que política adotar

A questão de fundo é editorial: um meio de comunicação que quer ser citado pelas IA não tem razão nenhuma para bloquear em edge os seus robots de pesquisa e de leitura. Bloquear o treino é uma decisão legítima, mas toma-se no robots.txt, user-agent a user-agent, como explicamos em «robots.txt e IA», e não com um interruptor que recusa tudo o que se pareça com uma IA. Um bloqueio em edge só faz sentido perante tráfego abusivo comprovado: volumes anormais, usurpação de identidade, scrapers que ignoram o robots.txt.

Há uma precaução a manter: não bloquear também os usurpadores com uma regra larga sobre o user-agent. Uma regra que recusa todos os «GPTBot» vindos de um endereço fora das gamas publicadas pela OpenAI parece prudente; na prática, recusa igualmente os pedidos legítimos no dia em que a OpenAI acrescenta uma gama que a lista local ainda não tem. A boa resposta à usurpação é a medição e a limitação de débito, e não a recusa cega.

O que medir quer dizer, uma vez levantado o bloqueio

Quando o edge deixa passar, os logs de origem voltam a ser uma fonte fiável, desde que transportem o endereço de origem e conservem o user-agent completo. Passa a ser possível contar, por robot e por uso (treino, pesquisa, leitura a pedido), o que as IA leem realmente: que páginas, com que frequência, com que código de resposta. É esta leitura, e não um painel de origem, que permite afirmar que um conteúdo é alcançado pelos motores generativos. Detalhamos o método em «Ler um access log em 30 minutos».

O princípio está aqui: um log de origem só prova o que chegou até à origem. Tudo o que foi recusado antes não deixa aí rasto nenhum, e é precisamente isso que é preciso ir procurar noutro lado antes de concluir o que quer que seja sobre as IA.