Muitos projetos de scraping descobrem o que protege um site da maneira mais difícil: o protótipo funciona na segunda-feira, uma página de desafio aparece na terça-feira e, na sexta-feira, a equipe está reconstruindo tudo em torno de um navegador headless. Grande parte disso poderia ser sabida no primeiro dia. Produtos de gerenciamento de bots deixam vestígios visíveis nos cabeçalhos de resposta e cookies de um site, e uma única requisição comum é suficiente para lê-los.
Construímos uma consulta curta que faz exatamente isso, a executamos contra as homepages dos 1.000 principais domínios e registramos o que um cliente HTTP comum recebeu como resposta. Este guia apresenta os resultados, o código e como usar essa resposta no planejamento de um projeto.
Principais conclusões
- Uma requisição revela muito. Cookies e cabeçalhos de fornecedores identificaram um fornecedor de proteção contra bots ou segurança de borda em 37% das 653 homepages dos principais sites que conseguimos carregar, e um produto de gerenciamento de bots ativamente em execução em 16%.
- A Cloudflare foi, de longe, a mais comum, presente em um quarto das homepages, seguida pela Akamai. DataDome, AWS WAF, Imperva e HUMAN apareceram com muito menos frequência, e DataDome e HUMAN desafiaram ou bloquearam todas as requisições que enviamos a elas.
- Um cliente HTTP comum se passando por Chrome recebeu 81% das homepages, foi desafiado em 10% e bloqueado em 9%. Com o User-Agent padrão da biblioteca, os bloqueios subiram para 16%.
- Fingir ser um navegador pode sair pela culatra. As dez lojas de um grande varejista, uma para cada país, entregaram homepages completas ao User-Agent honesto da biblioteca e uma página de desafio de um a dois kilobytes à requisição que se passava por Chrome.
- Trate a consulta como um dado de planejamento: ela indica o que esperar, se uma API oficial ou uma permissão é o melhor caminho, e como orçar o projeto.
O que uma única requisição pode revelar
Produtos de gerenciamento de bots e segurança de borda funcionam se posicionando na frente de um site e inspecionando cada requisição. Para isso, a maioria deles define cookies no navegador do visitante ou adiciona cabeçalhos de resposta, e esses nomes são estáveis e frequentemente documentados:
| Fornecedor | Evidência típica | De onde vem |
|---|---|---|
| Cloudflare | cabeçalho cf-ray em tudo que ela entrega; cookie __cf_bm onde o Bot Management ou o Bot Fight Mode está ativado; cf-mitigated: challenge em uma página de desafio | Documentação da Cloudflare |
| Akamai | cabeçalho Akamai-GRN com número da requisição; cookies _abck, ak_bmsc, bm_sz do Bot Manager | Documentação da Akamai para o cabeçalho; políticas de cookies dos sites para os cookies |
| DataDome | cookie datadome; cabeçalho x-datadome | Documentação da DataDome |
| HUMAN | cookies _px3, _pxhd, _pxvid | Documentação da HUMAN |
| Imperva | cookies visid_incap_, incap_ses_, nlbi_ | Políticas de cookies dos sites |
| AWS WAF | x-amzn-waf-action: challenge com HTTP 202 em um desafio; cookie aws-waf-token | Documentação da AWS |
Duas distinções importam na leitura dos resultados. Estar atrás de uma rede de entrega de conteúdo não é a mesma coisa que executar gerenciamento de bots: um cabeçalho cf-ray significa que o site usa Cloudflare, enquanto um cookie __cf_bm significa que um produto de bot da Cloudflare está ativamente pontuando visitantes. E a ausência de uma assinatura não prova nada; muitos sites executam sua própria detecção ou um produto que não deixa vestígio na primeira resposta.
O código
O módulo abaixo lê uma resposta e retorna os fornecedores que detecta com a evidência, se um produto de gerenciamento de bots está ativo, e o que a requisição recebeu: servida, desafiada ou bloqueada.
import re
# Cookies that each vendor's bot or WAF product sets, and headers it adds. Cookies are the strongest evidence.
SIGNATURES = {
"Cloudflare": {"headers": ["cf-ray"], "cookies": [r"^__cf_bm$", r"^cf_clearance$"]},
"Akamai": {"headers": ["akamai-grn"], "cookies": [r"^_abck$", r"^ak_bmsc$", r"^bm_sz$", r"^bm_sv$"]},
"DataDome": {"headers": ["x-datadome"], "cookies": [r"^datadome$"]},
"HUMAN": {"headers": [], "cookies": [r"^_px(3|hd|vid|cvid|de)$"]},
"Imperva": {"headers": [], "cookies": [r"^visid_incap_\d+$", r"^incap_ses_", r"^nlbi_\d+$", r"^reese84$"]},
"AWS WAF": {"headers": ["x-amzn-waf-action"], "cookies": [r"^aws-waf-token$"]},
}
# Evidence of an active bot-management product, as opposed to only the CDN in front of the site.
BOT_PRODUCT_COOKIES = [r"^__cf_bm$", r"^cf_clearance$", r"^_abck$", r"^ak_bmsc$", r"^bm_sz$", r"^datadome$", r"^_px", r"^reese84$"]
def cookie_names(response):
"""Names of every cookie the response tried to set."""
return {c.split("=", 1)[0].strip() for c in response.raw.headers.getlist("Set-Cookie")}
def detect_stack(response):
"""Return {vendor: [evidence]} from one response's headers and cookies."""
headers = {k.lower() for k in response.headers}
cookies = cookie_names(response)
found = {}
for vendor, sig in SIGNATURES.items():
evidence = [f"header {h}" for h in sig["headers"] if h in headers]
evidence += [f"cookie {c}" for c in sorted(cookies) if any(re.match(p, c) for p in sig["cookies"])]
if evidence:
found[vendor] = evidence
server = response.headers.get("server", "").lower()
if server == "cloudflare":
found.setdefault("Cloudflare", []).append("server header")
if "akamaighost" in server:
found.setdefault("Akamai", []).append("server header")
return found
def bot_product_active(response):
"""True when a cookie shows a bot-management product, not just a CDN, handled the request."""
return any(re.match(p, c) for c in cookie_names(response) for p in BOT_PRODUCT_COOKIES)
def outcome(response):
"""Classify what a request got: served, challenged or blocked."""
body = response.text[:20000].lower()
if (response.headers.get("cf-mitigated", "").lower() == "challenge"
or response.headers.get("x-amzn-waf-action", "").lower() == "challenge"
or "captcha-delivery.com" in body):
return "challenged"
if response.status_code in (401, 403, 405, 429) or response.status_code >= 500 or "incapsula incident id" in body:
return "blocked"
return "served"Ele funciona com uma resposta da biblioteca requests e lê os cookies a partir dos cabeçalhos brutos Set-Cookie, então enxerga cookies que o cliente não manteria de outra forma. Observe o que “servida” significa aqui: nenhum sinal de desafio ou bloqueio foi encontrado. Isso não prova que a página continha o conteúdo real, uma lacuna à qual voltamos mais adiante.
O que encontramos nos 1.000 principais domínios
Em 3 de outubro de 2026, requisitamos a homepage de cada um dos 1.000 principais domínios do ranking Tranco, uma vez com uma string de User-Agent do Chrome e outra com o padrão da biblioteca requests, a partir de uma única conexão na Romênia. Ambas as requisições vieram do mesmo cliente HTTP em Python, que não executa JavaScript e não tem a impressão digital de rede de um navegador. 653 sites distintos retornaram uma homepage HTML; o restante eram redes de conteúdo, hosts de API e outros domínios sem uma.
| Fornecedor detectado | Homepages | Com cookie ativo de gerenciamento de bots |
|---|---|---|
| Cloudflare | 162 (24,8%) | 79 |
| Akamai | 55 (8,4%) | 16 |
| AWS WAF | 14 (2,1%) | 0 |
| DataDome | 8 (1,2%) | 8 |
| HUMAN | 2 | 2 |
| Imperva | 2 | 0 |
| Qualquer um dos acima | 241 (36,9%) | 105 (16,1%) |
| Nenhum detectado | 412 (63,1%) | 0 |
Apenas duas homepages apresentaram dois fornecedores ao mesmo tempo. Dez dos 14 sites com AWS WAF eram lojas de país do mesmo varejista.
O que as requisições receberam:
| Requisição | Servida | Desafiada | Bloqueada |
|---|---|---|---|
| User-Agent Chrome, 653 homepages | 530 (81,2%) | 64 (9,8%) | 59 (9,0%) |
| User-Agent padrão da biblioteca, 650 homepages | 500 (76,9%) | 49 (7,5%) | 101 (15,5%) |
E detalhado pelo que protegia o site, contando sites onde ambas as requisições foram concluídas:
| Proteção detectada | Sites | User-Agent Chrome: desafiada ou bloqueada | Padrão da biblioteca: desafiada ou bloqueada |
|---|---|---|---|
| Cloudflare | 162 | 54 | 63 |
| Akamai | 54 | 26 | 22 |
| DataDome | 7 | 7 | 7 |
| Nenhum detectado | 411 | 19 | 53 |
O que os resultados dizem
A maior parte da web de destaque responde a uma requisição simples. Quatro em cada cinco homepages serviram um cliente HTTP básico se passando por Chrome sem um desafio visível. Uma homepage é a página mais fácil de um site, porém; resultados de busca, preços e fluxos de checkout costumam ser protegidos com mais rigor do que a porta de entrada.
Filtros simples e produtos sérios se comportam de maneira diferente. Nos sites sem fornecedor detectável, o User-Agent padrão da biblioteca foi desafiado ou bloqueado quase três vezes mais do que a string do Chrome, 53 vezes contra 19. Essa é a assinatura de uma filtragem simples por User-Agent. Nos sites que executam DataDome, ambas as requisições foram desafiadas ou bloqueadas em todas as vezes; o User-Agent não fez diferença.
Uma identidade incompatível pode ser pior do que uma honesta. As dez lojas de país do varejista responderam à requisição que se passava por Chrome com uma página de desafio ou um placeholder de um a dois kilobytes, e ao User-Agent honesto da biblioteca com a homepage completa, entre 678 KB e 1,4 MB. Repetimos a verificação para as dez e o padrão se manteve. Uma string de User-Agent do Chrome chegando por uma conexão que não parece ser do Chrome, como explicado em impressão digital de TLS e HTTP/2, é por si só um sinal.
Um status de sucesso não é uma página de sucesso. Três dessas páginas de placeholder voltaram com HTTP 200 e sem cabeçalho de desafio, então uma verificação baseada apenas no status as conta como servidas. Valide o conteúdo, não apenas os códigos de status, como abordado em a taxa de falha silenciosa e como saber quando um site está servindo conteúdo falso ou bloqueado.
Usando a consulta para planejar um projeto
Execute a consulta nas páginas que você realmente precisa, não apenas na homepage, e deixe a resposta moldar o plano:
| O que a consulta mostra | O que geralmente significa | Próximo passo sensato |
|---|---|---|
| Nenhum fornecedor, requisição simples servida | Pouco ou nenhum gerenciamento de bots nessa página | HTTP simples com identificação honesta, ritmo moderado e os cabeçalhos corretos |
| Apenas CDN, sem cookie de bot | Segurança de borda sem pontuação ativa de bots | HTTP simples, mas fique atento a desafios conforme o volume aumenta |
| Cookie de gerenciamento de bots, requisição servida | Pontuação ativa que permitiu essa requisição | Espere desafios em escala; monitore com um índice de saúde do alvo |
| Desafiada na primeira requisição | Uma decisão deliberada de filtrar clientes automatizados | Procure primeiro uma API oficial ou feed de dados, depois considere se um navegador se justifica, conforme quando você precisa de um navegador headless |
| Bloqueada na primeira requisição | Regras rígidas, frequentemente por rede ou região | Verifique se os dados estão disponíveis de outra forma, incluindo a API por trás da página, e se o bloqueio é regional |
A consulta também diz algo sobre intenção. Um site que executa um produto ativo de gerenciamento de bots decidiu controlar o acesso automatizado, e isso vale a pena ponderar junto com seus termos e seu robots.txt, como discutido em robots.txt, opt-outs de IA e sinais de reserva. Para muitos projetos, a resposta correta a um alvo fortemente protegido é uma licença, uma parceria ou uma API oficial, em vez de uma escalada. Onde a coleta é apropriada, a escada de escalada para sites protegidos explica as opções em ordem de custo.
Limites da medição
- Apenas homepages. Páginas mais profundas costumam ser protegidas de forma diferente.
- Uma requisição cada, a partir de uma rede. Os resultados podem variar por país, reputação de rede, horário do dia e histórico de requisições; abordamos diferenças regionais em quais países são mais bloqueados geograficamente.
- Nenhum navegador. Muitos desafios são projetados para serem superados por um navegador real executando JavaScript; nosso cliente não conseguiu, por design.
- Assinaturas deixam coisas passar. Detecção interna e produtos que não deixam vestígio na primeira requisição são contados como “nenhum detectado”, então a parcela real de sites protegidos é maior.
Conclusão
Uma única requisição comum informa a maior parte do que você precisa para planejar um projeto de scraping: quem protege o site, se a pontuação de bots está ativa e como um cliente simples é tratado. Nos 1.000 principais domínios, a maioria das homepages respondeu, um quarto estava atrás da Cloudflare, um em cada seis executava um produto ativo de gerenciamento de bots, e os produtos mais rígidos desafiaram ou bloquearam todas as requisições que enviamos.
Execute a consulta antes de escrever o scraper, nas páginas de que você precisa. Deixe que ela indique quando manter as coisas simples, quando planejar para um navegador e quando procurar uma via oficial para os dados.
Fontes e referências
- Cloudflare, Cookies da Cloudflare e detectando a resposta de uma página de desafio.
- Akamai, Número global de requisição.
- DataDome, Cookies e dados armazenados.
- HUMAN, Uso de cookies e armazenamento web.
- AWS, CAPTCHA e Challenge no AWS WAF.
- Tranco, lista Q2K34.
- Homepages requisitadas pela Shifter em 3 de outubro de 2026, usando o código acima.