---
title: "Como funciona a detecção de bots: a lógica anti-bot"
description: "A detecção de bots não é uma única checagem: reputação do IP, impressão digital TLS, cabeçalhos, sinais do navegador e comportamento viram uma só pontuação."
url: https://proxynet.io/pt-br/blog/how-bot-detection-works
date: 2026-09-19
author: "Acar Diveroli"
category: "Web scraping"
lang: pt-BR
---

# Como funciona a detecção de bots: a lógica anti-bot

O responsável por uma loja online abre o relatório da manhã: às três da madrugada o número de visitantes quadruplicou, as adições ao carrinho não mudaram e a página de login registra milhares de tentativas sem sucesso. Quanto desse tráfego é buscador, quanto é serviço de comparação de preços, quanto é um script testando senhas roubadas? A detecção de bots é o esforço do dono do site para responder a essa pergunta em cada requisição, em milissegundos.

Neste artigo descrevemos a detecção de bots pelo lado do dono do site: por quais camadas uma requisição passa, o que cada camada mede, como os sinais viram uma única pontuação e quem paga a conta quando essa pontuação erra. Resumimos seis camadas em ordem e deixamos o detalhe para o artigo próprio de cada uma. Como os navegadores headless são reconhecidos, como os bots bons comprovam quem são e qual é o caminho legítimo para quem opera automação também estão aqui. Formas de contornar proteções não são o assunto deste artigo.

> **Nota: Resposta rápida**
>
> A detecção de bots funciona em camadas. Antes de a conexão ser estabelecida, consultam-se a reputação do endereço IP e a rede (ASN) à qual ele pertence. Durante a conexão, leem-se o handshake TLS, as configurações de HTTP/2 e a coerência dos cabeçalhos. Quando a página abre, o JavaScript examina o ambiente do navegador, e ao longo da sessão o ritmo e o padrão de navegação são acompanhados. Nenhum sinal decide sozinho: todos se juntam em uma pontuação, e o dono do site permite, limita a velocidade, mostra uma verificação ou bloqueia com base nela.

## O que é detecção de bots?

Detecção de bots é o trabalho de distinguir se uma requisição que chega a um site veio do navegador usado por uma pessoa ou de um programa automático. O software que faz isso é chamado de sistema anti-bot, proteção contra bots ou gerenciamento de bots; a maior parte dele roda não no código do próprio site, mas no CDN ou no firewall de aplicação web (WAF) que fica à frente. Cloudflare, Akamai e DataDome são fornecedores citados com frequência nessa área. O sistema busca resposta para duas perguntas: a requisição é automática e, se for, é do tipo desejado?

## O que é tráfego de bots: como separar bots bons de ruins?

Tráfego de bots é toda requisição produzida pela decisão de um programa, e não pelo clique de uma pessoa. Nos logs, três tipos ficam lado a lado:

- **Os bots que o site quer.** Rastreadores de buscadores, serviços que monitoram disponibilidade, aplicativos de mensagem que geram prévias de links, a própria automação de testes do site.
- **Os bots que o site pondera.** Serviços de comparação de preços, ferramentas de arquivamento, rastreadores de IA, scripts de pesquisa. Alguns sites abrem a porta, outros aceitam com limite de velocidade.
- **A automação que o site não quer.** [O projeto de ameaças automatizadas da OWASP](https://owasp.org/www-project-automated-threats-to-web-applications/) cataloga esse grupo dando nome a ele: o teste em massa de senhas roubadas (credential stuffing), a validação de números de cartão roubados (carding), a compra automatizada de estoque limitado (scalping) e a cópia em massa de conteúdo (scraping) estão nessa lista.

A dificuldade é que os três se parecem na rede. Por isso o sistema não olha um sinal isolado, e sim a soma das camadas.

## Em que ordem uma requisição é avaliada?

1. **A conexão chega.** Antes de qualquer conteúdo ser lido, o IP de origem já é conhecido; consultam-se sua reputação, seu país e sua rede.
2. **O handshake TLS acontece.** A primeira mensagem (ClientHello) carrega uma pista sobre qual software está falando.
3. **A conexão HTTP é estabelecida.** No HTTP/2 o cliente anuncia suas configurações de conexão; depois vêm o método, o endereço e os cabeçalhos.
4. **A pontuação do lado do servidor é calculada.** Os sinais dos três primeiros passos se juntam ao histórico recente do endereço; a requisição já pode ser recusada aqui.
5. **A página chega ao navegador.** Um pequeno script na página examina o ambiente do navegador e devolve o resultado.
6. **A sessão é acompanhada.** A frequência das requisições, a ordem de navegação e a interação atualizam a pontuação ao longo da sessão.
7. **Se o limiar for ultrapassado, vem a ação.** Um limite de velocidade, uma tela de verificação ou um bloqueio.

Os quatro primeiros passos acontecem no servidor sem que o visitante perceba nada; o quinto e o sexto só produzem dados em clientes que executam JavaScript.

## As camadas em uma tabela: o que cada camada mede?

| Camada | O que mede? | Ponto forte | Risco de falso positivo |
|---|---|---|---|
| Rede | Reputação do IP, ASN, país, denúncias anteriores | Trabalha barato, antes de ler qualquer conteúdo | IPs compartilhados: CGNAT, rede corporativa, VPN |
| Protocolo | ClientHello do TLS, configurações de HTTP/2 | Mostra o software cliente independentemente dos cabeçalhos | Aparelhos antigos, redes com inspeção TLS corporativa |
| Cabeçalho | `User-Agent`, Client Hints, conjunto e coerência dos cabeçalhos | Compara o que é declarado com o que é real | Extensões de privacidade, navegadores pouco conhecidos |
| Navegador | Ambiente JavaScript, sinalizadores de automação, impressão digital | Separa um navegador real da imitação | Bloqueadores de script, ferramentas de acessibilidade |
| Comportamento | Ritmo de requisições, ordem de navegação, interação | Olha a sessão inteira, não uma requisição isolada | Usuários reais muito rápidos, navegação por teclado |
| Verificação | Teste visível ou invisível | Dá uma segunda chance ao tráfego suspeito | Todo teste cria atrito para clientes reais |

A última coluna carrega a ideia central do artigo: cada camada tem um grupo de pessoas com quem erra, e os limiares são ajustados sabendo desse custo.

## A camada de rede: o que dizem a reputação do IP e o ASN?

O endereço IP é a informação mais precoce sobre uma requisição. O sistema olha o histórico de abuso do endereço, seu país e, pelo ASN (número de sistema autônomo), a qual rede ele está registrado. Uma requisição vinda da rede de uma empresa de hospedagem e outra vinda de um bloco que um provedor reserva a assinantes residenciais não recebem o mesmo tratamento: usuários domésticos não saem para a internet por um data center. Como os sites classificam um endereço como «provedor» ou «hospedagem» explicamos em [Proxy ISP e proxy residencial: diferenças](/pt-br/blog/isp-vs-residential-proxy).

A reputação vem de duas fontes: listas negras que registram se o endereço já foi denunciado como origem de spam ou ataque ([listas negras de IP](/pt-br/blog/ip-blacklist)) e serviços de pontuação de risco que reduzem a um único número o tipo do endereço e se ele é saída de proxy ou VPN ([IP Fraud Score](/pt-br/blog/ip-fraud-score)). A fraqueza da camada é medir o endereço, não a pessoa. Operadoras móveis e muitos provedores colocam um número enorme de assinantes atrás do mesmo endereço ([CGNAT](/pt-br/blog/what-is-cgnat)); um script rodando dali derruba a reputação de todo mundo que divide aquele endereço.

## A camada de protocolo: impressão digital TLS e configurações de HTTP/2

Na primeira mensagem de uma conexão HTTPS, o cliente envia de forma aberta as suítes de cifra que suporta, as extensões e a ordem delas. A lista muda de navegador para navegador e de biblioteca para biblioteca; quando o servidor a transforma em um resumo curto (JA3 e JA4 são formatos comuns), ele passa a ter uma marca independente dos cabeçalhos. Uma requisição cujo cabeçalho `User-Agent` diz Chrome mas cujo handshake se parece com o de uma biblioteca Python se destaca por essa incoerência. O detalhe do cálculo e seus limites estão em [Impressão digital TLS e JA3](/pt-br/blog/tls-fingerprinting).

A [RFC 9113](https://www.rfc-editor.org/rfc/rfc9113#name-settings) exige que os dois lados enviem um quadro `SETTINGS` no início de uma conexão HTTP/2. Os valores desse quadro e a ordem em que os pseudocabeçalhos (`:method`, `:authority`, `:scheme`, `:path`) são enviados variam em cada pilha HTTP. O valor da camada é não depender de nenhuma declaração; o risco é que funcionários atrás de equipamentos de segurança corporativos, que abrem e refazem o tráfego TLS, cheguem com um handshake que não combina com o navegador deles.

## A camada de cabeçalhos: User-Agent e coerência

Cabeçalhos são a declaração que o cliente faz sobre si mesmo: o `User-Agent` informa o navegador e o sistema operacional, os cabeçalhos de Client Hints (a família `Sec-CH-UA`) repetem a mesma informação de forma estruturada e o `Accept-Language` anuncia a preferência de idioma. Ninguém verifica essa declaração; qualquer programa pode escrever o valor que quiser. Como essa cadeia é lida está em [O que é o User-Agent?](/pt-br/blog/what-is-user-agent).

Por isso o sistema anti-bot não olha a declaração em si, e sim o encaixe dela com as outras camadas. A versão de navegador declarada realmente envia aquele conjunto de cabeçalhos, naquela ordem? A preferência de idioma combina com o país do IP, e o fuso horário com o que o navegador informa? Nenhuma incoerência é prova sozinha (quem mora fora se conecta de outro país com o navegador no idioma natal), mas cada uma puxa a pontuação um pouco para baixo.

## A camada do navegador: sinais de JavaScript

Quando a página abre, a proteção alcança um terreno que não via pelo servidor: o próprio navegador. Um script inserido na página lê as medidas da tela, as fontes instaladas, o resultado de desenho do hardware gráfico, o fuso horário e as APIs suportadas; a combinação desses valores é a impressão digital do navegador. Ela serve para duas coisas: reconhecer o mesmo cliente mesmo com o IP mudando e testar se o ambiente declarado é real. Um ambiente que diz ser Chrome no Windows mas informa um driver gráfico que só existe em servidores Linux tropeça nesse teste. A lista completa de sinais está em [Impressão digital do navegador](/pt-br/blog/browser-fingerprinting).

Clientes que nunca executam o script (bibliotecas HTTP como cURL ou Python Requests) não produzem dados nessa camada. Em um endpoint de API isso é o esperado; em uma página HTML, a ausência completa de resultado do script já basta para o cliente não contar como navegador.

## O que é um navegador headless e como os sites o reconhecem?

Um navegador headless é um navegador de verdade que roda sem abrir janela na tela: carrega a página, executa o JavaScript e entrega o resultado ao código. É usado em testes de ponta a ponta, na geração de PDF, no monitoramento de sites e na coleta de dados autorizada; as ferramentas comuns são Playwright, Puppeteer e Selenium. Quando ele é necessário explicamos em [Páginas estáticas e dinâmicas](/pt-br/blog/static-vs-dynamic-pages), e a diferença entre as duas ferramentas em [Playwright e Selenium](/pt-br/blog/playwright-vs-selenium).

Os sites reconhecem um navegador conduzido por automação por três marcas:

| Sinal | De onde vem | Como o dono do site interpreta |
|---|---|---|
| `navigator.webdriver` valer `true` | [Padrão W3C WebDriver](https://www.w3.org/TR/webdriver2/): se o navegador é controlado remotamente, o sinalizador é ligado | É a declaração do próprio navegador; a automação de testes também carrega esse sinalizador |
| Diferenças de ambiente | Efeitos colaterais de rodar sem janela: medidas da janela, lista de plugins, algumas APIs | Fraco sozinho, significativo junto de outros sinais |
| Forma de interação | Eventos produzidos por código, não por uma mão humana | É repassado à camada de comportamento |

O sinalizador da primeira linha não é um truque de detecção, e sim parte do padrão: o texto do W3C o define como a maneira padronizada de o navegador informar ao documento que está sendo controlado pelo WebDriver.

O peso da segunda linha diminuiu com o tempo. Segundo [a documentação headless do Chrome](https://developer.chrome.com/docs/chromium/headless), o modo headless antigo era um aplicativo à parte que não compartilhava o código do navegador; a partir do Chrome 132 ele é oferecido apenas como um binário separado chamado `chrome-headless-shell`, enquanto o `--headless` executa o código real do Chrome. Conforme as diferenças de ambiente encolheram, o peso migrou para o comportamento.

A lição para o dono do site é esta: detectar um navegador headless não é detectar má intenção. Seu time de QA e seu serviço de monitoramento carregam as mesmas marcas; separar esse tráfego com um IP conhecido ou uma regra de requisição assinada causa menos dano do que olhar o sinalizador e bloquear em bloco.

## A camada de comportamento: ritmo e padrão de navegação

As camadas anteriores olham de quem veio a requisição; a de comportamento olha o que ela faz. A medida mais simples é o ritmo: quantas requisições chegam em um período do mesmo endereço, sessão ou conta. Quando o limite é ultrapassado, o servidor devolve `429 Too Many Requests`. Sobre o que os contadores são mantidos e como funcionam os algoritmos de janela fixa, janela deslizante e token bucket explicamos em [429 Too Many Requests](/pt-br/blog/http-429-too-many-requests).

Além do ritmo existe o padrão de navegação. Uma pessoa vai da página inicial para uma categoria e dali para um produto, e o navegador dela também baixa as imagens e as folhas de estilo; uma sessão que percorre só endereços de produto em intervalos constantes, sem pedir nenhum arquivo secundário, tem outra cara. Requisições a links ocultos que um visitante nunca conseguiria ver também são sinal dessa camada ([armadilhas honeypot](/pt-br/blog/honeypot-traps)). Sistemas mais novos acompanham a interação dentro da página (movimento do cursor, se a aba está visível) ao longo da sessão; um exemplo atual analisamos em [Cloudflare Precursor](/pt-br/blog/cloudflare-precursor).

Essa camada diz pouco sobre uma requisição e muito sobre cem. O preço é o atraso: é preciso acumular dados para decidir.

## Como os sinais viram decisão: pontuação e verificação

Nenhuma camada diz sozinha «isto é um bot». Os resultados delas se juntam em uma pontuação. [A documentação da Cloudflare sobre pontuação de bots](https://developers.cloudflare.com/bots/concepts/bot-score/) é um exemplo claro dessa abordagem: cada requisição recebe um valor entre 1 e 99, em que 1 indica alta confiança de que a requisição foi automática e 99, de que veio de uma pessoa; abaixo de 30 conta como «provavelmente automático». Segundo a documentação, alimentam essa pontuação as regras heurísticas, o aprendizado de máquina, a detecção de anomalias e as checagens de JavaScript.

Pontuação não é ação. A ação é definida pela regra que o dono do site escreve, e as opções formam uma escada:

1. **Permitir.** A pontuação é alta ou a requisição vem de um bot verificado.
2. **Limitar a velocidade.** A requisição é aceita e sua frequência é cortada.
3. **Mostrar verificação.** Ao navegador é apresentado um teste invisível e ao visitante uma caixa de seleção; o que essa tela significa do lado do visitante está em [Cloudflare «Verify You Are Human»](/pt-br/blog/cloudflare-verify-you-are-human).
4. **Bloquear.** A requisição é recusada com um `403` ou uma página de bloqueio.

A escada é ajustada por endpoint: em uma página de blog, deixar passar uma requisição de pontuação baixa custa alguns kilobytes de tráfego; na página de login, custa uma conta invadida.

## O custo do falso positivo: e se um visitante real for tomado por bot?

A detecção de bots tem dois tipos de erro. Tomar um bot por pessoa (falso negativo) volta como carga, conta falsa ou conteúdo roubado. Tomar uma pessoa por bot (falso positivo) é receita perdida: o cliente que desiste na tela de verificação, o pagamento que não se completa. O segundo erro não aparece nos relatórios, porque o visitante bloqueado nunca chega à ferramenta de analytics.

As principais fontes são estas:

- **Endereços IP compartilhados.** Assinantes de operadoras móveis e usuários de redes de alojamento estudantil, cafés e empresas pagam pelo comportamento dos outros.
- **VPN e ferramentas de privacidade.** Como o endereço parece de data center, a camada de rede baixa a pontuação ([VPN ou proxy detectado](/pt-br/blog/vpn-or-proxy-detected)).
- **Bloqueadores de script, ferramentas de acessibilidade, navegação por teclado.** A camada do navegador não recebe dados e a de comportamento não encontra o padrão que espera.

Do lado do visitante, isso aparece como mensagens do tipo «detectado como bot» ou «tráfego incomum detectado»: dois exemplos tratamos em [erro «tráfego incomum» do Google](/pt-br/blog/google-unusual-traffic-error) e [«Sorry, You Have Been Blocked»](/pt-br/blog/sorry-you-have-been-blocked).

A conclusão prática: mostre verificação antes de bloquear e acompanhe a proporção de quem passa. Cada requisição que passa é registro de que a regra estava parando a pessoa errada.

## Bots verificados: como um site reconhece um bot bom?

Escrever «Googlebot» no cabeçalho `User-Agent` é trabalho de uma linha; por isso um bot bom é reconhecido pela prova, não pela declaração. Hoje três métodos estão em uso.

**Verificação por DNS reverso.** [A documentação do Google sobre verificar o Googlebot](https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot) dá o método: faz-se uma consulta DNS reversa para o IP do log, confere-se se o nome devolvido está sob `googlebot.com`, `google.com` ou `googleusercontent.com`, e depois esse nome é resolvido de volta para um IP e confirmado como igual ao primeiro endereço.

**Listas de bots verificados.** Serviços de gerenciamento de bots fazem essa checagem em nome do dono do site; [a documentação da Cloudflare sobre bots verificados](https://developers.cloudflare.com/bots/concepts/bot/verified-bots/) lista duas condições: o bot se identificar com honestidade (por assinatura criptográfica, lista de IPs publicada ou DNS reverso) e não abusar dessa confiança, ou seja, respeitar o robots.txt e manter um ritmo de requisições razoável. Não respeitar a diretiva `crawl-delay` ou gerar tráfego que não bate com o propósito declarado são motivos de saída da lista.

**Requisições assinadas (Web Bot Auth).** Na abordagem mais nova o bot assina cada requisição com sua chave privada, publica a chave pública no próprio domínio e o site verifica a assinatura. O padrão de base é a [RFC 9421 HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421), e para adaptá-la aos bots foi criado no IETF um [grupo de trabalho Web Bot Auth](https://datatracker.ietf.org/wg/webbotauth/about/). O grupo considera insuficientes as soluções atuais, como listas de IP, cadeias de `User-Agent` e chaves de API compartilhadas; a identidade do agente que faz requisições em nome de um usuário está no escopo, e a do usuário final por trás do agente fica de fora. Os cabeçalhos da assinatura descrevemos em [Por que agentes de compra com IA são bloqueados em sites](/pt-br/blog/ai-shopping-agents-blocked).

Nos três casos a identidade se constrói com uma prova (registro DNS, propriedade do IP, chave privada), não com o que o cliente declara.

## Se você opera automação, qual é o caminho legítimo?

O mapa leva ao mesmo resultado para quem opera automação: o sistema é montado para abrir caminho ao tráfego que se identifica e age com moderação.

- **Use a API oficial, se houver.** O acesso se apoia em um acordo e a detecção de bots nem entra em cena.
- **Respeite o robots.txt.** O formato dele e como checá-lo em Python estão em [O que é o arquivo robots.txt?](/pt-br/blog/robots-txt).
- **Limite seu ritmo por site.** Respeite as respostas `429` e `Retry-After`.
- **Dê um nome ao seu bot.** O nome do bot e um endereço de contato no `User-Agent` dão ao administrador a opção de escrever para você em vez de bloquear.
- **Peça permissão para acesso de grande volume.** Se você opera um rastreador de serviço público, candidate-se aos programas de bots verificados.
- **Pare quando aparecer uma tela de verificação.** Essa tela é a preferência declarada do site; não recomendamos serviços de resolução de CAPTCHA.

A aplicação desses passos (concorrência, requisições condicionais, a diferença entre rotação e sessão fixa) está com código testado em [Como coletar dados sem ser bloqueado](/pt-br/blog/web-scraping-without-getting-blocked).

## Casos de uso: quem precisa conhecer esse mapa e para quê?

- **Times de marketing e analytics:** para separar a origem dos picos de tráfego e proteger o orçamento de anúncios do clique falso. O lado publicitário está em [fraude de cliques no Google Ads](/pt-br/blog/google-ads-click-fraud) e na nossa página de [solução de verificação de anúncios](/pt-br/ad-verification).
- **Times de dados:** para entender qual comportamento parece suspeito e por quê ao coletar dados de páginas públicas; o desenho geral está na nossa página de [solução de extração de dados](/pt-br/data-scraping) e, para conteúdo que muda conforme a localização, usa-se um [Proxies residenciais](https://proxynet.io/pt-br/residential-proxy).
- **Times de QA e teste:** a proteção contra bots do seu próprio site pode parar a sua própria automação de testes. Tire o tráfego de teste por um endereço fixo e escreva uma regra de permissão para ele; para isso usa-se um [Proxies ISP](https://proxynet.io/pt-br/static-isp-residential-proxy) ou seu próprio IP estático ([solução de teste de aplicativos](/pt-br/app-testing)).
- **Times de proteção de marca:** as varreduras por lojas falsas e anúncios de imitação também são automação e passam pelas mesmas camadas; o escopo está na nossa página de [solução de proteção de marca](/pt-br/brand-protection).

## Erros comuns

- **Bloquear por um sinal só.** Uma regra que olha apenas o ASN de data center ou o sinalizador `navigator.webdriver` também para serviços de monitoramento e seus próprios testes.
- **Confiar no `User-Agent` e abrir a porta para «Googlebot».** Declaração não é prova; use DNS reverso ou uma lista de bots verificados.
- **Aplicar o mesmo limiar a todos os endpoints.** A página de login e um artigo de blog não carregam o mesmo risco.
- **Não medir os falsos positivos.** Se a proporção de requisições que passam na verificação não é acompanhada, você não sabe quem sua regra está parando.
- **Do lado da automação: tratar o bloqueio como um enigma técnico.** A tela de verificação não é erro, é a resposta do dono do site; revise seu ritmo, seu alcance e sua situação de permissão.

## Guia de decisão

| Sua situação | Recomendação |
|---|---|
| Você tem tráfego inexplicado no site | Separe os logs por ASN e endpoint; primeiro limite de velocidade, depois verificação |
| Você vê tentativas de senha em massa na página de login | Limiar baixo e verificação nesse endpoint; limite de tentativas por conta |
| Você teme bloquear bots de buscadores por engano | Lista de bots verificados ou verificação por DNS reverso |
| Clientes reclamam da tela de verificação | Olhe a proporção que passa na verificação e afrouxe o limiar |
| Sua própria automação de testes está sendo bloqueada | Tire os testes por um endereço fixo e escreva uma regra de permissão para ele |
| Você coleta dados públicos com regularidade | Primeiro a API; se não houver, robots.txt, ritmo baixo, identidade de bot com nome |
| Você opera um rastreador ou agente de serviço público | Programa de bots verificados, requisições assinadas |
| Como visitante, você vê a mensagem «bot detectado» | Tente com a VPN e as extensões desligadas; se continuar, sua rede sai por um endereço compartilhado |

## Perguntas frequentes

### O que é anti-bot e para que serve?

Anti-bot é a camada de software que classifica o tráfego automático que chega a um site e, conforme as regras do dono, permite, desacelera, pede verificação ou bloqueia. O objetivo não é parar todos os bots, e sim separar a automação nociva dos bots desejados, como os dos buscadores.

### O que significa «detectado como bot»?

Significa que a camada de proteção do site deu uma pontuação baixa à sua requisição; isso não quer dizer que você usou um programa. As causas mais comuns são VPN ou IP compartilhado, extensões que bloqueiam scripts e abrir muitas páginas em pouco tempo. O primeiro passo é desligar a VPN e as extensões e recarregar a página.

### Por que Selenium e Playwright caem na detecção de bots?

Essas ferramentas conduzem o navegador por WebDriver ou protocolo parecido, e o padrão exige que o navegador informe isso com o sinalizador `navigator.webdriver`. Somam-se a isso as diferenças de ambiente e um ritmo que não lembra interação humana. Se você está testando o próprio site, a solução é escrever uma regra de permissão para o tráfego de teste do lado da proteção.

### A detecção de bots olha só o endereço IP?

Não. O IP é o sinal mais precoce, não o único: o handshake TLS, a coerência dos cabeçalhos, o ambiente do navegador e o comportamento ao longo da sessão são avaliados separadamente. Por isso trocar só o IP não afeta as outras camadas.

### Como identifico tráfego de bots no Google Analytics?

Um pico repentino vindo de uma única cidade ou rede, tempo de interação perto de zero e sessões sem relação com conversões são marcas típicas. Para uma separação segura a ferramenta de analytics não basta; examine a mesma faixa de horário nos logs do servidor ou do CDN, quebrados por IP, ASN e `User-Agent`.

### Por onde começar para proteger um site pequeno de bots?

Comece com três passos: coloque limites de velocidade em endpoints caros como login, cadastro e busca, ligue a proteção básica contra bots do seu CDN em modo de verificação em vez de bloqueio, e confira se os bots de buscadores estão passando pela lista de verificados.

## Em resumo

A detecção de bots não é um muro, e sim uma série de medições enfileiradas: a camada de rede lê a reputação e o ASN do endereço, a de protocolo o rastro de TLS e HTTP/2, a de cabeçalhos a coerência da declaração, a do navegador a autenticidade do ambiente, a de comportamento o padrão de navegação. Tudo se junta em uma pontuação, e o dono do site escolhe permitir, limitar a velocidade, verificar ou bloquear conforme o risco do endpoint. Como cada camada erra com usuários reais, um sistema bem montado verifica primeiro e bloqueia depois. Bots bons provam quem são com DNS reverso, listas de bots verificados e assinaturas baseadas na RFC 9421; para quem opera automação, o caminho duradouro passa pela API oficial, pelo robots.txt, por um ritmo moderado e por uma identidade aberta. Para seus trabalhos de coleta de dados dentro das regras, você encontra os tipos de proxy nos nossos [serviços de proxy](/pt-br/proxy).