Boas Práticas de Web Scraping em 2026: Um Guia Prático
Estas são as práticas que mais importam depois de construir e manter os scrapers de produção do meu catálogo.
Arquitetura: Pense em Pipelines, Não em Scripts
O maior erro que vejo é tratar o scraping como um processo de etapa única. Scrapers de produção são pipelines de dados:
- Descoberta de URLs — encontrar o que raspar (sitemaps, páginas de categoria, busca, APIs)
- Execução de Requisições — buscar os dados com retry e rotação adequados
- Parsing — extrair campos estruturados a partir das respostas brutas
- Normalização — limpar, validar e padronizar a saída
- Armazenamento — enviar para datasets, bancos de dados ou sistemas downstream
Cada etapa deve ser testável e reexecutável de forma independente. Quando a Sephora muda o layout da página de produto, só a etapa 3 precisa ser atualizada — o resto do pipeline permanece estável.
Sempre Prefira APIs em Vez de Parsing de HTML
Antes de escrever um único seletor CSS, verifique se o site tem:
- APIs públicas — endpoints documentados que retornam JSON
- APIs privadas — chamadas XHR/fetch visíveis no DevTools do navegador
- Endpoints GraphQL — cada vez mais comuns, muitas vezes com introspection habilitada
- JSON embutido —
__NEXT_DATA__,window.__INITIAL_STATE__, ou JSON-LD no HTML
Respostas de API são estruturadas, versionadas e muito mais estáveis do que layouts HTML.
Estratégia de Proxy: Corresponda à Proteção
Nem todo site precisa de proxies residenciais. Aqui está o meu framework de decisão:
| Nível de Proteção | Tipo de Proxy | Sites de Exemplo |
|---|---|---|
| Nenhuma / Básica | Datacenter | Sites pequenos, muitas APIs públicas |
| Rate limiting | Datacenter rotativo | E-commerce médio, sites de conteúdo |
| Fingerprinting | Residencial | Grandes marcas |
| WAF avançado | Residencial + fingerprint de TLS | Akamai, Cloudflare Enterprise |
O insight principal: o custo do proxy escala com o nível de proteção. Não pague por proxies residenciais em sites que só fazem rate limiting. Meu Shopify scraper usa por padrão o proxy de datacenter da Apify, mas muitas lojas bloqueiam faixas de datacenter, então proxies residenciais são a configuração recomendada.
Gerenciamento de Sessão É Tudo
A diferença entre uma taxa de sucesso de 60% e de 99% costuma ser o gerenciamento de sessão:
- Alterne sessões, não só IPs — um IP novo com os mesmos cookies parece suspeito
- Aqueça as sessões — visite a homepage antes de acessar páginas de produto
- Respeite os rate limits — 5 requisições simultâneas vencem 50 que são bloqueadas
- Backoff exponencial — retries de 1s, 2s, 4s, 8s, nunca retries imediatos
Um scraper robusto gerencia tokens de sessão com refresh automático e backoff exponencial, mantendo sessões persistentes que se parecem com padrões reais de navegação.
Normalize a Sua Saída
Dados brutos de scraping são bagunçados. Normalize tudo:
Preços
Armazene como inteiros (centavos, não dólares). $29.99 vira 2999. Isso evita erros de precisão de ponto flutuante que corrompem dados financeiros mais adiante no pipeline. Meus scrapers de e-commerce seguem essa convenção, com uma exceção: o scraper da Sephora mantém preços decimais (72.0).
URLs
Sempre armazene URLs absolutas, nunca caminhos relativos. Resolva-as no momento da extração.
Datas
ISO 8601 (2026-04-01T00:00:00Z), sempre com timezone. Nunca armazene datas formatadas por locale.
Texto
Remova espaços em branco excedentes, normalize Unicode e defina uma política para lidar com HTML (remover tags vs. preservar formatação).
Tratamento de Erros: Espere Falhas
Scrapers de produção falham o tempo todo — a questão é o quão bem. Minha abordagem:
1Request fails (network error, timeout, 4xx/5xx)
2 → Retry with exponential backoff (up to 5 attempts)
3 → Rotate session/proxy on retry
4 → Log failure with full context if all retries exhausted
5 → Continue processing remaining URLs (don't crash the batch)
Acompanhe as taxas de sucesso por padrão de URL. Se as páginas /category/* caírem repentinamente abaixo de 90% de sucesso, o site provavelmente mudou algo — você vai perceber antes que os usuários reportem.
Monitore e Alerte
Um scraper sem monitoramento é um scraper esperando para falhar silenciosamente. Acompanhe:
- Taxa de sucesso por execução e por padrão de URL
- Contagem de saída — quedas repentinas significam que algo quebrou
- Qualidade dos dados — campos nulos, valores inesperados, violações de esquema
- Custo — uso de proxy, tempo de computação, armazenamento
Todos os meus atores Apify expõem essas métricas. Quando as taxas de sucesso caem, sou notificado em questão de horas — muitas vezes antes que qualquer usuário perceba.
Comece Simples, Adicione Complexidade
Todo scraper que eu construo começa como a coisa mais simples que funciona:
- HTTP + Cheerio primeiro (mais rápido, mais barato)
- Adicione fingerprinting só se for bloqueado
- Adicione renderização em navegador só se JavaScript for necessário
- Adicione rotação de proxy só se houver rate limiting
Um scraper que lê dados estruturados por HTTP simples não precisa de navegador. Meu Universal Web Printer usa Playwright porque precisa renderizar JavaScript. A ferramenta certa para cada trabalho.
Esses não são princípios teóricos — eles vêm da operação real de scrapers de produção. Se você precisa de um scraper personalizado construído com essas práticas, vamos conversar.