Um site quase nunca passa de atender seu crawler normalmente para bloqueá-lo completamente em uma única etapa. O que acontece primeiro é mais silencioso. Algumas requisições a mais chegam a uma página de desafio. Algumas respostas voltam com 200 OK sem nada de útil dentro. A latência aumenta aos poucos. Alguns registros falham na validação. Cada sinal isoladamente parece ruído, e cada um vive em um painel diferente, então ninguém os conecta até que o conjunto de dados tenha um buraco nele.
Um target health score é a solução: um número por site que diz se aquele site ainda está se comportando como o seu próprio normal, com os motivos anexados. Este texto cobre quais sinais o alimentam, como combiná-los sem se enganar, e o que o crawler deve fazer quando o número cai.
Target health não é proxy health
Vale a pena ser preciso sobre o que está sendo medido, porque os dois se confundem.
Proxy health pergunta se uma rota funciona: um gateway, um país, uma sessão, uma saída. Target health pergunta se um site específico ainda está disposto e apto a atendê-lo. Uma rota de proxy morta falha contra todos os sites. Um site que se volta contra você falha em todas as rotas.
Essa diferença é o primeiro diagnóstico. Quando as falhas aumentam, divida-as por rota. Se elas se concentram em um país, um pool ou um padrão de sessão, é um problema de rota, e a abordagem em monitoramento da saúde de proxies residenciais em escala se aplica. Se aumentam uniformemente em todas as rotas que você envia para aquele site, o site mudou de ideia sobre você, e é para isso que esse score serve.
Os sinais
Agrupe os sinais pelo que eles revelam. Alguns são ruidosos, outros são quase silenciosos, e os silenciosos são os mais caros de deixar passar.
| Sinal | Como se parece | Por que importa |
|---|---|---|
| Bloqueios explícitos | 403, 429, resets de conexão | Recusa explícita; fácil de contar |
| Desafios | CAPTCHA ou páginas intersticiais | O site suspeita de automação e está testando |
| Bloqueios disfarçados | 200 OK com uma página de bloqueio, resultados vazios ou um layout truncado | Recusa disfarçada de sucesso |
| Deriva de latência | Tempo de resposta p95 subindo em relação ao próprio normal do site | Muitas vezes é uma redução deliberada, às vezes apenas carga |
| Falhas de extração | Campos obrigatórios ausentes, esquema que não corresponde mais | A página mudou, ou algo diferente está sendo servido a você |
| Deriva de custo | Mais tentativas, bytes ou créditos por registro válido | Tudo acima, expresso em dinheiro |
Os bloqueios disfarçados merecem atenção especial porque os códigos de status mentem. Em uma medição de 2023 sobre geo-bloqueio a partir de Cuba, 32 domínios serviram suas páginas de bloqueio com status 200 OK, como descrito em quais países são mais geo-bloqueados. Um crawler que confia no código de status registra isso como sucessos. Detecte bloqueios disfarçados pelo conteúdo: marcadores conhecidos de página de bloqueio, tamanho de resposta muito abaixo do normal para aquele tipo de página, ou uma extração que retorna vazio onde sempre retornou algo.
Dois responsáveis, dois scores
Uma distinção poupa muita confusão: separe “o site mudou” de “o site se voltou contra você”.
Um redesign quebra seu parser. Toda página carrega normalmente, mas os campos obrigatórios desaparecem. Isso é um problema de extração com uma correção de código, de responsabilidade de quem mantém o parser. Um site que começa a desafiar e a aplicar bloqueios disfarçados é um problema de relacionamento, e a correção é uma mudança em como, quanto ou se você coleta. Responsáveis diferentes, respostas diferentes.
Então calcule a hostilidade, ou seja, bloqueios, desafios, bloqueios disfarçados e latência, como o health score, e acompanhe a validade da extração paralelamente, como um sinal separado de saúde do parser. Quando os dois caem ao mesmo tempo, olhe primeiro para a hostilidade: um site que serve páginas de desafio também vai quebrar todos os extratores.
Compare o score contra o próprio normal do site
O erro mais comum é usar limiares globais. Uma taxa de desafio de 5% é alarmante em um site que nunca desafiou você, e inteiramente normal em um que desafia todo mundo na primeira visita. Cada sinal precisa ser comparado com a linha de base própria daquele site, ao longo de uma janela longa o suficiente para ser estável, como as duas semanas anteriores, e excluindo o dia mais recente, para que um dia ruim não se torne o novo normal.
Depois, pondere, limite e some:
from dataclasses import dataclass
@dataclass
class Window:
requests: int
hard_blocks: int # 403, 429, connection resets
challenges: int # CAPTCHA or interstitial pages
soft_blocks: int # 200 OK carrying a block page or an empty result
p95_latency_ms: float
MIN_REQUESTS = 50
WEIGHTS = {"hard_block": 35, "challenge": 25, "soft_block": 25, "latency": 15}
def signals(w):
n = max(1, w.requests)
return {
"hard_block": w.hard_blocks / n,
"challenge": w.challenges / n,
"soft_block": w.soft_blocks / n,
"latency": w.p95_latency_ms,
}
def badness(name, now, base):
if name == "latency":
# Full penalty at three times the site's own normal latency.
return min(1.0, max(0.0, (now / max(base, 1.0) - 1) / 2))
# Full penalty at 20 percentage points above the site's own normal rate.
return min(1.0, max(0.0, (now - base) / 0.20))
def health_score(current, baseline):
if current.requests < MIN_REQUESTS:
return None, ["not enough requests to judge"]
now, base = signals(current), signals(baseline)
penalty = {k: w * badness(k, now[k], base[k]) for k, w in WEIGHTS.items()}
score = round(100 - sum(penalty.values()))
reasons = [k for k, p in sorted(penalty.items(), key=lambda kv: -kv[1]) if p >= 1]
return score, reasonsAlgumas escolhas de projeto aqui são deliberadas.
- Só o excesso sobre a linha de base conta. Um site que sempre desafiou 3% das requisições não perde pontos por fazer isso hoje.
- Cada sinal tem um limite. Um sinal descontrolado não pode empurrar o score abaixo de zero nem afogar os outros, e a lista de motivos mostra qual predominou.
- Uma janela pequena não retorna score. Cinco requisições com um bloqueio não é uma taxa de bloqueio de 20%, é dados insuficientes. Um score ausente é mais honesto do que um score confiante e errado.
- Os pesos são opiniões. Comece com algo assim e ajuste depois de revisar alguns incidentes reais. Bloqueios explícitos e bloqueios disfarçados merecem o maior peso porque significam dados que você não obteve.
Suavize o score ao longo do tempo também, por exemplo com uma média exponencialmente ponderada, para que um único minuto ruim não dispare um alerta, enquanto um declínio constante ainda apareça dentro de uma hora.
Canários: uma verdade fundamental sob seu controle
Todo sinal acima é inferido. Canários oferecem algo mais próximo da verdade. Escolha um punhado de páginas estáveis por site onde você sabe qual é a resposta certa: um produto cujo preço você pode conferir, uma listagem cuja quantidade de itens você conhece, uma página cuja estrutura não muda há meses. Busque-as em um cronograma, pelo mesmo caminho do tráfego de produção.
Quando um canário retorna uma página que parece normal mas carrega o valor errado, você encontrou a falha mais difícil de detectar: conteúdo que faz o parsing perfeitamente e simplesmente não é o que um visitante real veria. Nenhum código de status ou gráfico de latência vai mostrar isso a você. Os canários também tornam a linha de base confiável, porque você conhece o comportamento correto deles independentemente do crawler.
Vincule ações a faixas, e mantenha humanos no processo
Um score que ninguém usa para agir é apenas um painel. Dê a ele faixas, e dê a cada faixa uma ação que o sistema toma por conta própria:
| Faixa | Significado | Ação automática |
|---|---|---|
| 80 a 100 | Comportando-se como seu próprio normal | Nenhuma |
| 50 a 79 | Degradando | Reduzir a concorrência para este site, aumentar os intervalos de revisita, verificar se as falhas são em todo o site ou específicas de rota |
| Abaixo de 50 | O site está claramente reagindo | Pausar o site, manter apenas os canários rodando, alertar uma pessoa |
A faixa de degradação alimenta diretamente o restante do crawler. Reduzir a concorrência é para isso que serve o limitador por host em backpressure e controle de fluxo, e um score em queda deveria elevar o custo efetivo daquele site em um agendador consciente de custo, para que o orçamento migre para sites onde ainda compra dados.
A faixa mais baixa é deliberadamente não automatizada além de uma pausa. Um site que está reagindo fortemente está lhe dizendo algo, e a resposta certa é uma decisão humana: desacelerar ainda mais, verificar se sua coleta ainda está de acordo com os termos do site, procurar uma API oficial ou feed de dados, ou parar. Escalar automaticamente para métodos de coleta mais agressivos sempre que o score cair só transforma um sinal em uma corrida armamentista, e é exatamente isso que um health score deveria ajudar a evitar. Limitação de taxa e throttling de requisições cobre como interpretar o que um site está pedindo de você.
Revise como qualquer outro alerta
Trate o score como um alerta com uma taxa de falso positivo, e revise-o. Depois de cada incidente, pergunte se o score se moveu cedo o suficiente, se os motivos apontaram para a causa real, e se a ação automática ajudou. A maior parte do ajuste vem de dois ou três incidentes reais, não de projetar pesos com antecedência. Mantenha o histórico: o score ao longo dos meses é o melhor registro que você tem de como a atitude de cada site em relação ao tráfego automatizado muda.
Conclusão
Sites se voltam contra crawlers de forma gradual e silenciosa, por meio de desafios, recusas disfarçadas e respostas mais lentas, muito antes de um bloqueio explícito. Cada sinal isolado é ambíguo. Comparados com o próprio normal do site, ponderados, limitados e combinados, eles dão um único número que se move cedo, com motivos anexados.
O score é mais valioso pelo que permite ao crawler fazer com calma: recuar antes de ser bloqueado, mover o orçamento para outro lugar, e passar as decisões difíceis a uma pessoa com as evidências à sua frente. As métricas mais amplas ao redor disso estão em monitoramento de um pipeline de web scraping.