Tráfego de bots é qualquer pedido feito a um site por software e não por uma pessoa diante de um ecrã. Essa única definição abrange coisas tão diferentes como o Googlebot a indexar uma página de produto, um monitor de disponibilidade a consultar a página inicial a cada sessenta segundos, um scraper a recolher os preços e um script de credential stuffing a percorrer uma lista de palavras-passe divulgada. O erro está em juntar tudo no mesmo saco. Este guia trata de os distinguir, porque a resposta certa a cada um é completamente diferente.
Pontos essenciais
- O tráfego de bots não é um fenómeno único. Divide-se em automatização útil, automatização hostil e tráfego sintético gerado pelo próprio, e cada um costuma ter um responsável diferente dentro de uma organização.
- O Google Analytics 4 exclui automaticamente o tráfego de bots e spiders conhecidos com base na Lista Internacional de Spiders e Bots da IAB/MRC. Esse filtro é real, mas funciona a partir de uma lista de bots conhecidos, que é precisamente a ferramenta errada para apanhar automatização que está a tentar não ser conhecida.
- As cadeias de User-Agent e o
robots.txtsão declarações, não controlos. Ambos funcionam bem com bots bem-comportados e não significam nada para os restantes. - A identidade deve ser verificada ao nível da rede (DNS inverso ou intervalos de IP publicados), e não retirada de um cabeçalho que qualquer cliente pode definir.
- A partir do momento em que a automatização visa autenticações, checkout, formulários ou preços, deixou de ser um incómodo de relatórios e passou a ser um assunto de segurança, com outro caminho de escalada.
O que conta afinal como tráfego de bots?
A fronteira útil é a intenção de quem opera, não a tecnologia. Um navegador headless não é intrinsecamente malicioso; a suíte de QA da própria empresa provavelmente usa um. Três perguntas resolvem a maioria dos casos: quem está a executar isto, o que está a levar ou a fazer, e anunciou-se? Um crawler que se identifica e respeita as diretivas de rastreio do site é um convidado com cartão de visita. Um conjunto de IP residenciais a percorrer os URL dos produtos a três pedidos por segundo por trás de um User-Agent de Chrome comum é outra coisa, ainda que ambos, tecnicamente, se limitem a obter páginas.
As três categorias que vale a pena separar
Automatização útil
Estes bots existem porque há benefício em estar visível ou observável. Crawlers de motores de busca como o Googlebot e o Bingbot constroem o índice de que depende o tráfego orgânico. Monitores de disponibilidade obtêm páginas de forma agendada para que uma falha seja conhecida antes de os clientes darem por ela. Crawlers de comparação de preços e de afiliação podem fazer parte de um canal de distribuição que interessa manter. Os agentes de pré-visualização de ligações renderizam o cartão que alguém vê quando o URL é partilhado numa conversa.
Uma entrada mais recente neste grupo é o crawler de IA. A OpenAI documenta o GPTBot, a Anthropic documenta o ClaudeBot e a Common Crawl opera há muito o CCBot. Cada um publica documentação a descrever o agente e a forma de o permitir ou bloquear. Querer ou não recebê-los é uma decisão de negócio sobre a utilização do conteúdo próprio, não uma questão técnica de defesa. Note-se que bloqueá-los é uma escolha genuína, com um custo de ambos os lados, o que não sucede com a categoria seguinte.
Automatização hostil
Aqui o ganho de quem opera corresponde a uma perda do lado do site. Scrapers de conteúdo e de preços copiam o catálogo, muitas vezes a uma cadência de pedidos que custa capacidade real de servidor. Scripts de credential stuffing repetem pares de utilizador e palavra-passe provenientes de fugas alheias no ponto de autenticação do site, razão pela qual um pico de autenticações falhadas a partir de muitos IP merece atenção em horas e não no ciclo de relatórios seguinte. A fraude de cliques consome orçamento de publicidade paga em cliques que nenhum humano deu. O spam de formulários e comentários polui o CRM e, pior, os dados de conversão. Os bots de açambarcamento de existências colocam stock limitado em carrinhos que nunca tencionam pagar.
O comportamento que define este grupo é a evasão. Este tráfego roda endereços IP, imita impressões digitais de navegadores comuns, dosea-se abaixo dos limiares óbvios e ignora tudo o que estiver escrito no robots.txt, porque cumprir apenas reduziria aquilo que recolhe.
Tráfego sintético de teste
A terceira categoria é a automatização encomendada pelo próprio: testes de carga, execuções de validação de análise, verificações de disponibilidade que se configuraram, sessões encenadas para confirmar que um evento de conversão dispara com os parâmetros certos. Não é hostil, mas também não é humana, e vai distorcer qualquer relatório que a inclua. A característica distintiva é que está sob controlo próprio, o que significa que pode ser etiquetada, agendada e excluída de forma limpa. Fazê-lo ou não é a diferença entre uma experiência reversível e uma propriedade de análise permanentemente baralhada.
| Categoria | Identifica-se? | Respeita o robots.txt? | Quem deve ficar com a resposta |
|---|---|---|---|
| Crawlers de pesquisa e de IA | Sim, e de forma verificável | Em geral sim | SEO / estratégia de conteúdo |
| Monitorização e pré-visualização | Normalmente | Muitas vezes isentos por conceção | Engenharia / operações |
| Scrapers e credential stuffing | Não | Não | Segurança |
| Fraude de cliques e spam de formulários | Não | Não aplicável | Meios pagos / segurança |
| O próprio tráfego sintético | Só se for etiquetado | Sob controlo próprio | Responsável pela análise |
O que o GA4 filtra automaticamente e o que escapa
O Google Analytics 4 exclui por predefinição o tráfego de bots e spiders conhecidos. A documentação da Google descreve isto como baseado na Lista Internacional de Spiders e Bots da IAB/MRC, combinada com a identificação interna da Google, e é aplicado automaticamente e não como uma definição que se possa ligar ou desligar. Para o caso comum, crawlers declarados a aceder a uma página com o código de medição, funciona bem e sem ruído.
A limitação decorre diretamente do mecanismo. Um filtro baseado numa lista apanha automatização que consta de uma lista. Não foi concebido para identificar software que se apresenta como uma sessão normal do Chrome a partir de um endereço IP residencial, e não se deve esperar isso dele. Vale a pena nomear três lacunas práticas:
- Automatização não declarada. Tudo o que imite deliberadamente um navegador será, em geral, medido como uma sessão, com dispositivo, geografia e referenciador plausíveis.
- Tráfego que nunca executa o JavaScript. Muitos bots obtêm o HTML e param por aí. O GA4 nunca chega a vê-los, pelo que a análise subestima a carga total. Esta é a falha inversa da anterior, e é a razão pela qual a análise, sozinha, não diz quanta automatização o servidor está a suportar.
- As sessões sintéticas próprias. Nada no filtro automático sabe que o teste de carga encomendado não era um cliente. Essa exclusão tem de ser construída por quem o encomendou.
A lição geral: o filtro de bots do GA4 é uma funcionalidade de higiene para os relatórios, não um sistema de deteção. Convém encará-lo como algo que remove ruído óbvio, não como resposta à pergunta «quanto deste tráfego era humano?».
Como distingui-los nos registos do servidor
Os registos do servidor guardam todos os pedidos que chegaram, incluindo os que nunca executaram uma linha de JavaScript. Isso torna-os o registo mais completo e o sítio onde a classificação efetivamente acontece.
Os sinais com peso, aproximadamente por ordem de fiabilidade:
- Identidade verificada. A Google publica um procedimento de verificação para os seus crawlers: uma consulta de DNS inverso ao IP de origem e depois uma consulta direta ao nome de anfitrião resultante, para confirmar que aponta de volta para o mesmo endereço. A Google publica também os intervalos de IP dos seus crawlers em JSON, e a OpenAI publica os intervalos do GPTBot. A Bing disponibiliza uma ferramenta de verificação equivalente. Esta é a única classe de sinal que um cliente não pode simplesmente alegar.
- Padrão de pedidos. Intervalos perfeitamente regulares, enumeração sequencial de URL e pedidos de HTML sem os correspondentes pedidos de CSS, imagens ou tipos de letra sugerem todos um cliente que não é um navegador.
- Concentração em endpoints. Tráfego intenso para
/login, para um endpoint de pesquisa ou para um modelo que apresenta preços, com pouco interesse por tudo o resto, descreve um propósito. - Origem na rede. O espaço de endereços de centros de dados é normal em crawlers declarados e invulgar em visitas de consumidores. O tráfego de proxies residenciais inverte isto e é uma das razões pelas quais a origem, por si só, não é conclusiva.
- Cadeia de User-Agent. Útil para agrupar, sem valor como prova. Vem em último lugar por uma razão.
Um ponto adicional específico da classificação: o conjunto de clientes que aparece no registo de acesso mas nunca na análise é, quase por definição, automatização que não usa navegador. Esse conjunto é invisível para quem trabalha apenas a partir da análise.
Por que razão o robots.txt e o User-Agent são sinais fracos
O robots.txt é um pedido de cooperação voluntária. O Protocolo de Exclusão de Robôs foi formalizado como RFC 9309 em 2022, e a própria norma descreve o cumprimento como voluntário por parte do crawler. Os grandes motores de busca respeitam-no; um scraper não tem motivo nenhum para o fazer. Há ainda uma armadilha: publicar uma regra Disallow para um caminho sensível anuncia esse caminho a quem quer que leia o ficheiro, que é público por definição. Convém usá-lo para gerir o comportamento e o orçamento de rastreio, nunca como controlo de acesso.
O cabeçalho User-Agent tem a mesma fragilidade estrutural. É uma cadeia escolhida pelo cliente. Qualquer um pode enviar Googlebot nesse campo, e qualquer um pode enviar antes uma cadeia de Chrome atual. É justamente por isso que existe o passo de verificação descrito acima. Na prática, convém tratar o User-Agent como um rótulo para organizar tráfego que já classificou por outros meios.
Que parte da web é automatizada?
Resposta honesta: ninguém consegue dar um número que se possa citar com confiança. As estimativas publicadas vêm sobretudo de fornecedores de segurança, com maior visibilidade para o Bad Bot Report anual da Imperva e telemetria semelhante de outros fornecedores. São úteis como indicação de sentido, mas derivam do tráfego que passa pela base de clientes de cada fornecedor, o que enviesa para sites suficientemente grandes para comprar mitigação de bots e para as superfícies de ataque que esses sites apresentam. Fornecedores diferentes, metodologias diferentes, números diferentes.
O que se pode afirmar com segurança em termos qualitativos é que a fração automatizada é suficientemente grande para ser relevante em praticamente qualquer site público, e que varia enormemente conforme o tipo de site. Um serviço de consumo com muitas autenticações, uma plataforma de bilheteira e um site estático de documentação não enfrentam de todo a mesma mistura. O número que deve orientar as decisões é o dos registos próprios, não uma média do setor.
Quando o tráfego de bots se torna um problema de segurança
A linha é comportamental, não volumétrica. O tráfego de bots é um problema de análise enquanto se limita a inflacionar contagens. Torna-se um problema de segurança no momento em que interage com algo que tem consequências.
Convém escalar em vez de filtrar sempre que se observar algum destes casos: um aumento de tentativas de autenticação falhadas repartidas por muitos endereços de origem, submissões de formulários a gerar eventos de conversão sem qualquer atividade posterior plausível, ações de checkout ou de carrinho que nunca se concluem, enumeração sistemática de identificadores de utilizador ou de números de encomenda, ou volume de pedidos a causar tensão real de capacidade. Cada um destes tem um custo que continua a correr, quer se exclua ou não o tráfego de um painel.
A consequência prática de errar esta fronteira é que uma campanha de credential stuffing acaba tratada como um incómodo de relatórios, filtrada numa vista do GA4 e deixada a correr no ponto de autenticação. O filtro tornou o sintoma invisível sem tocar na causa.
Perguntas frequentes
Todo o tráfego de bots é mau?
Não, e tratá-lo assim causa danos reais. Bloquear crawlers de motores de busca retira o site do índice. Bloquear os agentes de pré-visualização de ligações estraga o aspeto dos URL quando são partilhados. O objetivo é classificar e responder de forma adequada, não eliminar.
O GA4 remove todo o tráfego de bots?
Remove automaticamente o tráfego de bots e spiders conhecidos que constam da lista da IAB/MRC. Não remove automatização que se apresente como um navegador comum, e nunca chega a ver clientes que não executem o código de medição. São dois pontos cegos distintos e em sentidos opostos.
É possível identificar o Googlebot apenas pela cadeia de User-Agent?
Não. A documentação da Google recomenda explicitamente verificar por consulta de DNS inverso seguida de consulta direta, ou por correspondência com os intervalos de IP de crawlers publicados pela Google. O User-Agent é trivialmente falsificável e nunca deve servir de base para conceder acesso.
Convém bloquear crawlers de IA como o GPTBot ou o ClaudeBot?
Essa é uma decisão de licenciamento de conteúdo e não de segurança. Ambos estão documentados e ambos podem ser bloqueados no robots.txt. Convém pesar o valor de aparecer em respostas geradas por IA face à posição de cada um sobre a utilização do próprio conteúdo para treino. Não há resposta tecnicamente correta, apenas uma resposta comercial.
Qual é a primeira coisa a verificar num pico de tráfego inexplicado?
Os registos do servidor, não a análise. Convém ver que endpoints foram acedidos, com que intervalo, a partir de que redes, e se os pedidos foram buscar os recursos da página ou apenas o HTML. Essas quatro observações identificam habitualmente a categoria em minutos, e a categoria determina quem a deve tratar.