Todo dashboard de scraping tem uma taxa de sucesso, e praticamente todos contam a mesma coisa: respostas com um HTTP 200. É um número fácil de coletar e reconfortante de reportar. Também é o número mais enganoso na coleta de dados web, porque um 200 significa apenas que um servidor devolveu algo. Não diz nada sobre se esse algo era a página que você pediu.
A lacuna entre essas duas coisas é a taxa de falha silenciosa: a parcela de requisições “bem-sucedidas” que retornaram o conteúdo errado. É a falha que você não vê nos seus logs, e ela chega ao seu dataset parecendo exatamente com dados bons.
Então, qual é o tamanho dela? A resposta honesta é que ninguém publicou isso. Essa ausência acaba sendo a descoberta mais interessante, e o restante deste texto trata do motivo dela existir, do que as medições próximas de fato mostram, e de como medir a sua própria taxa.
Principais conclusões
- Nenhum estudo publicado mede qual parcela das respostas HTTP 200 carrega o conteúdo errado na web como um todo. O estudo mais recente e abrangente sobre bloqueio de bots afirma por escrito que a degradação de conteúdo dentro de respostas 200 estava fora do seu escopo.
- O bloqueio é comum e mal identificado. Um estudo sobre o Common Crawl encontrou pelo menos 1,68% dos sites recusando explicitamente o crawler, com um uso inconsistente e até incorreto de códigos de status.
- Páginas de bloqueio de fato chegam como 200. Em uma medição de 2023 feita em Cuba, 32 dos 395 domínios que serviram uma página de bloqueio o fizeram com um status 200.
- Os principais estudos sobre link rot contam páginas de soft 404 como ativas, porque verificar o conteúdo é muito mais difícil do que verificar códigos de status.
- Sua própria taxa de falha silenciosa é mensurável, mas apenas validando o conteúdo, não o status.
O que conta como falha silenciosa
Uma falha silenciosa é qualquer resposta que reporta sucesso e não contém o que um visitante real teria recebido. As formas comuns:
| Forma | O que você recebe | Por que passa como sucesso |
|---|---|---|
| Página de bloqueio servida como 200 | Uma mensagem de recusa onde a página deveria estar | O status diz OK |
| Desafio ou interstitial | Um CAPTCHA ou página de “verificando seu navegador” | Frequentemente um 200, às vezes um código de erro |
| Soft 404 | Uma página genérica ou a página inicial para um conteúdo que não existe mais | O servidor retorna 200 em vez de 404 |
| Shell vazio | HTML sem conteúdo, porque a página se constrói via JavaScript | Um documento completo e válido |
| Consentimento ou paywall | Uma tela de consentimento na frente do conteúdo | A página carregou; o conteúdo não |
| Variante errada | A página, o preço ou o idioma de outro país | Uma página perfeitamente real, só que não a que você queria |
Cada uma dessas passa pelo parsing, é armazenada e agregada como dado bom. Nenhuma delas dispara um alerta de erro.
O número que ninguém mediu
Pesquisadores que estudam bloqueio de bots e decadência da web têm repetidamente contornado essa questão, e vários dizem isso explicitamente.
O estudo mais recente e abrangente, “Detecting Bot Detection” de Gundelach, Mühlhauser e Herrmann (Universidade de Bamberg, junho de 2026), escaneou os 10.000 principais sites do Tranco entre 27 de fevereiro e 2 de março de 2026 sob várias configurações de navegador. Sua seção de limitações é direta: “content degradation within HTTP 200 responses is outside our observational scope” (a degradação de conteúdo dentro de respostas HTTP 200 está fora do nosso escopo observacional). Os autores também pesquisaram 81 artigos sobre medição web e descobriram que “only 5% of papers explicitly quantify bot detection or blocking rates, and 83% omit any discussion” (apenas 5% dos artigos quantificam explicitamente taxas de detecção ou bloqueio de bots, e 83% omitem qualquer discussão) sobre o tema.
Eles estão em boa companhia. O estudo do PAM 2025 sobre recusas no Common Crawl trabalhou a partir de respostas não-200. O estudo global de geobloqueio de 2018 observou que um site poderia carregar enquanto “the login button has disappeared, or that some content is not available” (o botão de login desapareceu, ou que algum conteúdo não está disponível), e deixou essas “more nuanced changes in content” (mudanças mais sutis no conteúdo) para trabalhos futuros. O estudo de link rot de 2024 do Pew Research Center tratou como acessíveis “ambiguous situations in which we could not guarantee that the content exists, like soft 404 pages” (situações ambíguas nas quais não podíamos garantir que o conteúdo existe, como páginas de soft 404). O estudo de abril de 2026 do Internet Archive sobre a web morta “relied on HTTP status codes and did not look into the contents of the pages to check for any soft-404s” (dependeu de códigos de status HTTP e não analisou o conteúdo das páginas para verificar soft-404s).
Nada disso é descuido. Classificar códigos de status escala para milhões de páginas; julgar se o conteúdo está correto exige saber como é o conteúdo correto para cada página. É exatamente por isso que a taxa de falha silenciosa não é medida em escala de web, e exatamente por isso que ela é mensurável para seus próprios alvos, onde você de fato sabe como é o correto.
O que as medições próximas mostram
Nenhum número único responde à pergunta, mas várias medições delimitam o problema.
| Achado | Fonte | Medido em |
|---|---|---|
| O Chromium headless foi soft-blocked em 15,2% dos principais sites, contra 6,8% a 7,2% para outras configurações de navegador; 81,9% dos sites com soft block foram atribuídos à detecção de bots | Gundelach, Mühlhauser e Herrmann, arXiv, junho de 2026 | Fev a mar de 2026 |
| Pelo menos 1,68% dos sites recusaram explicitamente o Common Crawl, com códigos de status inconsistentes e até incorretos; 80% dos domínios que recusaram bloquearam todas as requisições | Ansar, Sperotto e Holz, PAM 2025 | Snapshot do Common Crawl, final de 2023 |
| 32 de 395 domínios que serviram páginas de bloqueio a usuários cubanos usaram um status 200 | Ablove et al., USENIX Security 2024 | Maio de 2023 |
| Rastreamentos automatizados perderam 45% dos sites de fingerprinting que usuários reais encontraram, em parte por falhar em passar pela detecção de bots | Annamalai, Bilogrevic e De Cristofaro, WWW 2025 | 30 usuários ao longo de 10 semanas |
| Cookie walls em 0,6% de 45.000 sites, e em 8,5% dos 1.000 principais sites da Alemanha | Rasaii, Gosain e Gasser, IMC 2023 | 2023 |
| 7,35% dos servidores web retornaram 200 para um documento desconhecido em vez de 404 | Prieto Álvarez, Álvarez Díaz e Cacheda Seijo, 2014 | Antes de 2014 |
| Soft 404s representaram mais de 15% dos links mortos | Bar-Yossef, Broder, Kumar e Tomkins, WWW 2004 | Antes de 2004 |
As duas primeiras linhas descrevem bloqueio visível por meio de códigos de erro, que é a parte fácil de ver. A terceira mostra que a outra parte existe: aproximadamente uma em cada doze páginas de bloqueio nesse estudo chegou disfarçada de sucesso. Os números de soft 404 são antigos, e são os mais recentes já publicados.
O que isso custa a jusante
O retrato mais claro de falha silenciosa em um dataset real vem de estatísticas oficiais. Quando o Office for National Statistics do Reino Unido testou índices de preços a partir de dados de supermercados extraídos da web, sua atualização de maio de 2016 relatou que “the total percentage of products that were classified as anomalous or misclassifications after this validation step was 25%” (o percentual total de produtos classificados como anômalos ou mal classificados após essa etapa de validação foi de 25%), removendo preços “from 3.4 million to 2.5 million” (de 3,4 milhões para 2,5 milhões). Dados ausentes, acrescentou, “were mainly caused by retailers making structural changes to their websites” (foram causados principalmente por varejistas fazendo mudanças estruturais em seus sites).
Esses 25% não são uma taxa de falha em nível de HTTP. A maior parte era de produtos extraídos para a categoria errada e preços fora da curva. É exatamente esse o ponto: cada um desses registros veio de uma requisição bem-sucedida, e um quarto deles era inutilizável. Foi preciso uma etapa de validação, construída por um instituto de estatística, para encontrá-los.
Por que códigos de status não conseguem carregar esse sinal
Seria conveniente se os servidores reportassem recusas com honestidade. As evidências mostram que eles não fazem isso de forma consistente. O estudo do Common Crawl encontrou recusas sinalizadas por um uso inconsistente e até incorreto de códigos de status HTTP. O estudo de Cuba encontrou bloqueios distribuídos entre falhas de DNS, timeouts, 403s, alguns casos do código dedicado 451, e 200s.
Alguma infraestrutura de fato ajuda. A Cloudflare define um cabeçalho de resposta cf-mitigated: challenge para todos os seus tipos de página de desafio, o que é um sinal muito mais confiável do que o código de status. Verifique por ele. Mas um cabeçalho de um único provedor não é um padrão web, e a maioria das falhas silenciosas não carrega nenhum marcador.
Medindo sua própria taxa de falha silenciosa
A definição é simples: das respostas que seu sistema contou como bem-sucedidas, a parcela que falhou na validação de conteúdo. O trabalho está na validação.
- Valide registros, não respostas. Decida quais campos todo registro de um tipo de página deve conter, e marque como falha qualquer 200 que não os produza.
- Compare o tamanho contra o normal do tipo de página. Uma página de produto que de repente tem um quinto do seu tamanho habitual raramente é uma página de produto.
- Procure marcadores de bloqueio e desafio, incluindo cabeçalhos como
cf-mitigated, e frases que seus alvos realmente usam. - Execute canários. Busque páginas cujo conteúdo correto você conhece de forma independente, pelo mesmo caminho usado em produção, e compare.
- Registre de onde você buscou. Uma variante do país errado só é detectável se você registrou o ponto de vantagem, o que é o argumento defendido em o padrão de ponto de vantagem.
- Faça amostragem para revisão humana. Algumas dezenas de respostas por semana, lidas por uma pessoa, capturam modos de falha que nenhuma regra previu.
Um classificador de primeira passada pode ser bem pequeno:
BLOCK_MARKERS = ("captcha", "access denied", "unusual traffic", "verify you are human")
REQUIRED_FIELDS = ("title", "price")
def classify(resp, record, baseline_bytes):
"""Label one response. Anything but "ok" on a 200 is a silent failure."""
if resp.headers.get("cf-mitigated") == "challenge":
return "challenge"
if resp.status_code != 200:
return "http_error"
if not record and any(m in resp.text.lower() for m in BLOCK_MARKERS):
return "block_page"
if len(resp.content) < 0.2 * baseline_bytes:
return "too_small"
if not record or any(record.get(f) in (None, "") for f in REQUIRED_FIELDS):
return "missing_fields"
return "ok"Reporte o resultado por alvo e por tipo de página, ao lado da taxa de sucesso que você já tem. Quando os dois divergem, a taxa de sucesso está mentindo para você. O aumento de soft blocks em um site também é um dos primeiros sinais de que ele está se voltando contra o seu crawler, algo que um índice de saúde do alvo foi criado para capturar. As métricas mais amplas estão em monitorando um pipeline de web scraping.
Onde as ferramentas ajudam, e onde não conseguem
A coleta gerenciada elimina algumas falhas silenciosas antes que elas cheguem até você. O Web Scraping API da Shifter reexecuta automaticamente buscas falhas, CAPTCHAs e erros transitórios do alvo, até três vezes com proxies diferentes, e cobra apenas por requisições bem-sucedidas. A renderização de JavaScript elimina o problema do shell vazio para páginas que se constroem no navegador, e extract_rules retorna campos nomeados, o que torna fácil detectar um campo ausente.
O que nenhuma camada de coleta consegue fazer é saber que uma página perfeitamente bem formada contém o preço errado ou o catálogo do país errado. Só você sabe como é o correto para os seus dados. A validação de conteúdo pertence ao seu pipeline, independentemente de como as páginas foram buscadas.
Conclusão
Um 200 é uma afirmação feita por um servidor, não uma garantia sobre o conteúdo. Páginas de bloqueio, desafios, soft 404s, shells vazios, paredes de consentimento e variantes erradas chegam todos disfarçados de sucesso, e a pesquisa publicada, por razões práticas compreensíveis, mediu quase tudo sobre bloqueio na web, exceto isso.
A consequência é que a única taxa de falha silenciosa que você jamais terá é a que você mesmo medir. Valide todo registro, mantenha canários cujas respostas você conhece, e coloque o resultado no mesmo dashboard que a sua taxa de sucesso. A diferença entre os dois números é a parte do seu dataset em que atualmente você não pode confiar.
Fontes e referências
- Gundelach, Mühlhauser e Herrmann, Detecting Bot Detection: Prevalence, Techniques, and Implications for Web Measurement Research, arXiv, 12 de junho de 2026. Escaneamentos de 27 de fevereiro a 2 de março de 2026.
- Ansar, Sperotto e Holz, Web Crawl Refusals: Insights From Common Crawl, PAM 2025, 7 de março de 2025.
- Ablove et al., Digital Discrimination of Users in Sanctioned States: The Case of the Cuba Embargo, USENIX Security 2024. Medido em maio de 2023.
- McDonald et al., 403 Forbidden: A Global View of CDN Geoblocking, ACM IMC 2018.
- Annamalai, Bilogrevic e De Cristofaro, Beyond the Crawl: Unmasking Browser Fingerprinting in Real User Interactions, WWW 2025.
- Rasaii, Gosain e Gasser, Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web, ACM IMC 2023.
- Prieto Álvarez, Álvarez Díaz e Cacheda Seijo, Soft-404 Pages, a Crawling Problem, Journal of Digital Information Management, 2014.
- Bar-Yossef, Broder, Kumar e Tomkins, Sic Transit Gloria Telae: Towards an Understanding of the Web’s Decay, WWW 2004.
- Pew Research Center, When Online Content Disappears: methodology, 17 de maio de 2024.
- Sawood Alam, Internet Archive, Gone but Not Forgotten: Recovering the Dead Web, 23 de abril de 2026.
- Office for National Statistics, Research indices using web scraped data: May 2016 update, 23 de maio de 2016.
- Cloudflare, Detect a Challenge Page response.
- Shifter, Web Scraping API errors and limits.