72% do nosso tráfego não é um navegador: o que medimos num site pequeno

Quase tudo o que se escreve sobre tráfego de bots é ou um argumentário de fornecedor ou uma história de guerra de um site suficientemente grande para ser atacado de propósito. Isto não é nem uma coisa nem outra. É o site de uma pequena agência, uma conta Cloudflare e os números que encontrámos quando finalmente olhámos com atenção.

A versão curta: 72,4% dos pedidos ao nosso site ao longo de 23 horas não traziam qualquer user agent de navegador reconhecível. O Chrome ficou-se por 19,7%. Todos os crawlers de pesquisa identificados juntos, Googlebot e Bingbot e Applebot, somaram 3,5%.

É este último número que reorganizou o nosso raciocínio. Quase todos os argumentos que se leem sobre gestão de crawlers dizem respeito à minoria identificada, e essa minoria é um erro de arredondamento ao lado de tudo o resto que bate à porta.

#O que medimos de facto

Todos os valores vêm da análise GraphQL da Cloudflare para a nossa própria zona, numa janela de 23 horas em agosto de 2026. Nada aqui é modelado nem extrapolado.

Em dois dias completos, o rácio entre pedidos e visitantes únicos ficou em 6,5 e 6,6. Uma pessoa que lê duas ou três páginas não gera seis pedidos e meio depois de excluídos os recursos, o que é a mesma história vista de outro ângulo.

Já tínhamos visto uma versão extrema disto no início do mês. Num dos dias os pedidos triplicaram para 173 093 enquanto os visitantes únicos se mantiveram nos 7 527. Pedidos triplicados com audiência estável não é crescimento, é uma varredura, e a distribuição por caminhos confirmou-o: o URL individual mais visitado levou apenas 677 pedidos desse total. Alguma coisa percorreu o corpus inteiro.

#A palavra “bots” está a carregar demasiado peso aqui

Conseguimos provar que esses clientes não se apresentam como navegadores. Não conseguimos provar o que são, e ninguém que corra a mesma consulta consegue.

Essa categoria inclui monitores de disponibilidade que pagamos, verificadores de ligações, bibliotecas HTTP dentro do script de alguém, scanners de segurança, leitores de feeds, crawlers de IA a construir conjuntos de treino e agentes a ir buscar uma página em nome de uma pessoa que fez uma pergunta. Parte deste tráfego é útil para nós. Parte é indiferente. Uma pequena parte é hostil.

Por isso o título honesto não é “72% do nosso tráfego são bots a atacar-nos”. É 72% do nosso tráfego não corre um navegador, e essa distinção muda o que se deve fazer a esse respeito.

#O que não encontrámos

Fomos primeiro à procura de um problema no robots.txt, porque é o mais barato de verificar e é um defeito genuinamente comum: o robots.txt é servido por protocolo e por subdomínio, portanto http, www e o apex podem discordar entre si sem que se note. Os nossos eram idênticos, byte a byte, todos a redirecionar para um endereço canónico.

Vale a pena dizê-lo com clareza, porque um resultado limpo também é um resultado. Se tivéssemos publicado apenas o que corrigimos, ficaria com uma ideia distorcida da frequência com que este trabalho encontra alguma coisa.

A outra coisa que importa afirmar: o robots.txt não reduz a carga. É um pedido de cooperação dirigido aos clientes que o leem. Tudo o que o ignora continua a chegar ao seu servidor e continua a consumir aquilo que corre no caminho do pedido. As camadas que reduzem carga a sério são as que são avaliadas antes de o código da sua aplicação correr.

Este texto trata do que chega ao servidor, ou seja, da camada que um programador WordPress tem de desenhar.

#A descoberta que não esperávamos: a nossa cache nunca tinha funcionado

Enquanto extraíamos estes números, reparámos na taxa de acerto da cache de edge: cerca de 4%, num site onde todas as páginas são pré-geradas no momento da compilação. Devia ser quase o oposto.

Todas as páginas enviam isto:

cache-control: public, max-age=60, s-maxage=3600, stale-while-revalidate=86400

E todas as páginas respondiam cf-cache-status: DYNAMIC. Pedíamos uma hora de cache no edge e nunca a tínhamos recebido nem uma única vez.

Duas causas, e só juntas explicam o caso.

A Cloudflare não guarda HTML em cache por predefinição. O nível de cache predefinido cobre uma lista de extensões estáticas, e o HTML não está nela, independentemente do que a origem diga. Enviar s-maxage não torna o HTML armazenável em cache; uma regra de cache torna.

A nossa própria funcionalidade bloqueou o resto. Servimos uma representação em Markdown de cada página aos agentes que a pedem com Accept: text/markdown. Isso significa que um URL tem duas representações. Para uma cache ser segura, a chave de cache tem de incluir Accept, e a chave de cache padrão da Cloudflare inclui apenas Vary: Accept-Encoding. Ligar a cache de forma ingénua acabaria por entregar a um agente uma página HTML em cache, ou entregar a uma pessoa Markdown em cache, o que é pior do que não ter cache nenhuma.

Esta é a parte que vale a pena generalizar: o custo era invisível porque pertencia a uma funcionalidade de que nos orgulhávamos. Ninguém audita o preço da sua própria boa ideia.

A correção foi uma regra de cache condicionada ao cabeçalho do pedido: guardar as páginas em cache, mas apenas quando o Accept não pede Markdown. Assim a chave de cache nunca precisa de transportar Accept, porque os pedidos que negoceiam ficam totalmente excluídos da cache. São cerca de uma centena por dia contra dezenas de milhares de visualizações de página normais.

Vem acompanhada de uma segunda metade que não é opcional: limpar a cache a cada implementação. Sem isso, cada implementação deixa até uma hora de páginas desatualizadas para parte da audiência, e a seguir ouve-se dizer que uma alteração não está visível. Uma regra de cache sem passo de limpeza é uma armadilha que se monta a si próprio.

#Porque é que isto é sobre resiliência e não sobre velocidade

Com max-age=60, a cache de edge muda pouco para uma pessoa que regressa. O que muda é o que acontece quando algo varre o site inteiro.

As nossas páginas passam por uma função de edge em cada pedido HTML, e o plano gratuito permite 100 000 invocações de função por dia. O dia mediano fica perto de 30 000. No dia daquela varredura chegou a 131 255, o que ultrapassa o limite.

Ou seja, a cache nunca foi um luxo de desempenho. Era a diferença entre um rastreio ser invisível e um rastreio deitar o site abaixo. Essa reformulação só ficou disponível quando a quota de bots e o rácio de cache ficaram na mesma página.

#O endpoint que esteve avariado durante semanas

Mantemos um contador separado para a superfície legível por máquinas, porque as ferramentas de análise de navegador não a conseguem ver: um agente que vai buscar um ficheiro JSON não corre JavaScript, portanto uma ferramenta de análise baseada num beacon não reporta absolutamente nada.

Esse contador indica cerca de 102 pedidos de agentes por dia. A distribuição surpreendeu-nos: dois terços vão para o nosso endpoint MCP, não para os cartões declarativos como o agent.json ou o llms.txt, que levam toda a atenção na conversa sobre visibilidade em IA.

Depois disse-nos algo pior. O endereço sem barra final estava a responder 301. Um redirecionamento transforma um POST num GET e descarta o corpo do pedido, portanto um cliente JSON-RPC ou não recebe nada ou recebe um erro de análise. Medido ao longo de um dia: 29 chamadas avariadas contra 2 que funcionaram.

Tínhamos um endpoint público para agentes que estava, para uma grande parte dos clientes, pura e simplesmente avariado, e não teríamos dado por isso. Não aparece em nenhum painel que um profissional de marketing consulte. Não gerou nenhum erro que alguém visse, porque aqueles a quem falhou não eram pessoas.

Três tentativas de o corrigir na aplicação falharam, porque a normalização da barra final feita pela plataforma acontece antes de o código da aplicação correr. A correção tinha de ficar acima da causa, como regra de reescrita no edge da rede. No dia seguinte: 12 respostas POST bem-sucedidas onde não havia nenhuma.

#Como fazer esta medição por si próprio

Nada disto exigiu uma ferramenta paga. O endpoint de análise GraphQL da Cloudflare responde a tudo, e o exercício inteiro resume-se a um token de API e a um punhado de consultas.

Duas armadilhas custaram-nos tempo, por isso vale a pena nomeá-las.

A permissão do token não é a óbvia. O nosso token de API de longa data conseguia implementar, limpar a cache e gerir regras, e devolvia um erro de permissões em todas as consultas de análise. A análise precisa especificamente de Zone / Analytics / Read, e um token pode ser perfeitamente capaz de alterar o seu site sem conseguir dizer-lhe seja o que for sobre ele. Pior ainda, um token com âmbito de conta pode falhar a verificação habitual em /user/tokens/verify e funcionar corretamente no GraphQL, portanto teste-o com uma consulta real em vez do endpoint de verificação.

A janela temporal tem limite. No nosso plano, o conjunto de dados de pedidos adaptativos recusa qualquer consulta que abranja mais de um dia e guarda cerca de três dias de histórico. Peça trinta dias e não recebe uma resposta parcial, recebe um erro. Percorra dia a dia e agregue do lado do cliente.

A forma da consulta que produziu a tabela de user agents é pequena:

{ viewer { zones(filter: {zoneTag: "YOUR_ZONE_ID"}) {
    httpRequestsAdaptiveGroups(
      limit: 12,
      filter: {datetime_geq: "2026-08-19T15:00:00Z"},
      orderBy: [count_DESC]
    ) { count dimensions { userAgentBrowser } }
} } }

Troque userAgentBrowser por cacheStatus, edgeResponseStatus, clientRequestPath ou clientCountryName e tem o resto do retrato. Para pedidos face a visitantes únicos, httpRequests1dGroups traz ambos na mesma linha.

Uma ressalva que conta quando ler os seus próprios resultados: userAgentBrowser é a classificação da Cloudflare, não a verdade absoluta. “Não reconhecido” significa que o analisador deles não correspondeu a uma assinatura de navegador conhecida. Um crawler que envie uma string de user agent do Chrome é contado como Chrome, portanto a quota real de tráfego sem navegador é um piso, não um teto.

#O que escolhemos não fazer, e porquê

O passo seguinte óbvio depois de encontrar 72% é começar a bloquear. Não o fizemos, e o raciocínio vale mais do que a decisão.

Não acrescentámos regras de WAF nem limitação de débito. Ambas funcionariam e ambas ficam na camada certa, antes do código da aplicação. Mas não tínhamos provas de dano. Nada estava em baixo, nada estava lento para as pessoas, e não havia custo a ser pago que uma regra de cache não removesse de forma mais barata. Bloquear tráfego que não demonstrou ser prejudicial troca um risco real, deixar de fora algo de que se depende, por um risco hipotético.

Não perseguimos um erro que se estava a resolver sozinho. A meio deste trabalho encontrámos 9 956 tempos limite de gateway num dia, espalhados por todo o site, incluindo as páginas de contacto em todas as línguas. Parecia uma emergência. Depois a análise detalhada mostrou que todos eles, sem exceção, traziam um user agent não reconhecido: zero do Chrome, do Safari, do Googlebot ou do Bingbot. Nenhuma pessoa e nenhum motor de pesquisa viu um único. Registámos e deixámos ficar. Um dia depois, a mesma janela mostrava três. Se o tivéssemos “corrigido”, teríamos corrigido o crawler de outra pessoa e enviado para a nossa base de código uma alteração que não curava nada.

Não financiámos o trabalho caro sobre agentes. O mesmo contador que encontrou o endpoint avariado também nos avaliou uma lista de pendentes. Documentos de identidade assinados, atestações de terceiros, um ambiente isolado, um contrato legível por máquinas: cada um é semanas de trabalho, e cada um se justifica pelo pressuposto de que os agentes que compram leem os nossos ficheiros declarativos. Com 26 pedidos por dia ao agent.json, esse pressuposto não sobrevive ao contacto com o contador. Duas medições independentes com um dia de intervalo concordaram, por isso a decisão assenta agora numa medição e não numa leitura única.

O padrão nos três casos é o mesmo. A medição dá o direito de não fazer nada, e é um uso dos dados que recebe muito menos crédito do que merece. A maior parte do valor que retirámos deste exercício não foram as duas correções. Foi saber qual dos números alarmantes merecia a nossa semana.

#O que diríamos a quem faz isto no seu próprio site

Meça antes de bloquear o que quer que seja. Extraia a repartição por user agent para um dia completo. O rácio entre pedidos e visitantes únicos é a verificação de sanidade mais rápida, e se estiver muito acima de dois ou três, olhe com mais atenção.

Verifique o estado da cache, não os cabeçalhos de cache. O cache-control é um pedido. O cf-cache-status, ou o equivalente na sua CDN, é a resposta. Passámos muito tempo a acreditar num cabeçalho que nunca tinha produzido efeito nenhum.

Conte o tráfego que a sua ferramenta de análise não consegue ver. Se a sua visibilidade para agentes de IA lhe interessa minimamente, o único sítio onde esse tráfego aparece são os registos do servidor ou do edge. Os nossos revelaram um endpoint avariado que falhava em silêncio havia semanas.

Tenha cuidado com o que chama ataque. A maior parte do que encontrámos não era nem malicioso nem útil. Era indiferente. A resposta útil a tráfego indiferente é torná-lo barato de servir, não combatê-lo.

Audite o custo das suas próprias funcionalidades. A coisa mais cara que encontrámos não foi um bot. Foi uma funcionalidade que construímos de propósito, avaliada em zero, que nos andava a custar a totalidade da cache de edge do HTML.