Web scraping que continua a funcionar quando o site muda
Extraímos dados de sites que não lhe dão uma API: agendas, catálogos, preços, anúncios, boletins. Cada fonte com a estratégia de que precisa, um teste que a chama de verdade a cada poucos dias e um alerta no dia em que muda de design, antes que alguém dê pela falta de um dado.
O web scraping é a extração automatizada de dados publicados em sites que não oferecem uma API nem um ficheiro para descarregar. Na Soamee construímos scrapers à medida em Node.js e TypeScript: para cada fonte escolhemos entre a sua API interna, o seu feed RSS, o HTML que o servidor devolve ou um navegador headless com Playwright, e passamos todos os resultados pelo mesmo normalizador, pelo que chegam à sua base de dados num formato comum e sem duplicados. Quando um site bloqueia os pedidos automáticos (403, CAPTCHAs, cortes por IP) integramos a Bright Data: Web Unlocker, Scraping Browser ou proxies residenciais. Cada fonte tem um teste contra o site real que corre a cada poucos dias e um alerta por email com o diagnóstico quando falha.
Do inventário de fontes ao dado limpo na sua base de dados
Um scraper que funciona hoje escreve-se numa tarde. O trabalho está em que continue a funcionar daqui a seis meses, com trinta fontes que mudam cada uma ao seu ritmo.
Inventário e viabilidade por fonte
Antes de escrever código revemos cada site: se tem API pública ou interna, se é um WordPress com /wp-json aberto, se carrega os dados por XHR, o que diz o seu robots.txt e se bloqueia pedidos automáticos. Sai uma ficha por fonte com estratégia, riscos e frequência.
Uma estratégia por tipo de fonte
API, RSS, HTML estático ou navegador headless por trás de uma mesma interface. Acrescentar uma fonte costuma consistir em escrever a sua configuração (URL, seletores, mapeamento de campos) e o seu teste, sem programar um scraper do zero.
Normalização e deduplicação
Datas em espanhol como «del 10 al 28 de junio», preços escritos como texto, HTML embutido, a mesma categoria com cinco nomes. Tudo passa por um normalizador e é guardado com chave única por fonte e identificador externo, pelo que voltar a executar atualiza em vez de duplicar.
Sites com proteção anti-bots
Para as fontes que devolvem 403 ou CAPTCHA integramos a Bright Data: Web Unlocker para pedidos HTTP, Scraping Browser para páginas que precisam de JavaScript e proxies residenciais quando o problema é o IP. Só nessas fontes; as restantes saem diretas e não consomem desbloqueio.
Filas, novas tentativas e planeamento
Cada fonte é um trabalho numa fila BullMQ sobre Redis, com a sua frequência, três novas tentativas com espera exponencial e um registo por execução: quantos elementos encontrou, quantos eram novos e quanto demorou.
Smoke tests e alertas
Um teste por fonte que chama o site real a cada três dias em CI, mais testes unitários sobre uma captura guardada da resposta. Se uma execução falha, chega um email com o código HTTP, um excerto da resposta e o que verificar primeiro.
Quatro estratégias, da mais estável à mais frágil
Usamos a primeira da lista que a fonte permita. Cada degrau abaixo custa velocidade e estabilidade, por isso só descemos quando a fonte nos obriga.
| Estratégia | Quando a usamos | Custo | O que se parte |
|---|---|---|---|
| API pública ou interna | O site carrega os seus dados a partir de um JSON: portais de dados abertos, WordPress com REST API, plugins de eventos, endpoints visíveis no separador Network | ~200 ms por pedido | Alterações de esquema, pouco frequentes |
| RSS / Atom | A fonte publica um feed e bastam título, link e resumo | ~200 ms por feed | A data do feed é a da publicação, não a do evento nem a da oferta |
| HTML estático | O conteúdo vem no HTML que o servidor devolve | Um pedido por listagem, mais um por ficha se faltar algum campo | Os seletores CSS, a cada redesign |
| Navegador headless | Conteúdo renderizado com JavaScript, scroll infinito, botões de «carregar mais» ou bloqueio a clientes HTTP | 3-5 s por página e 100-200 MB de RAM por navegador | Tempos de espera e o binário do navegador em cada ambiente |
O que temos a funcionar
Números de uma plataforma de agregação que mantemos, com fontes públicas muito diferentes entre si: portais de dados abertos, WordPress, Drupal, sites em React e páginas feitas à mão.
fontes, cada uma com o seu smoke test contra o site real
estratégias de extração por trás de uma mesma interface
entre cada passagem dos smoke tests em CI
novas tentativas com espera exponencial antes de dar uma execução por falhada
A avaria mais frequente é um redesign da fonte. O smoke test deteta-a em três dias, no máximo. Para os sites que bloqueiam pedidos automáticos trabalhamos com a Bright Data.
Integração com a Bright Data →Da lista de URLs ao primeiro dado na sua base de dados
Primeiro uma fonte de cada tipo, para que os problemas reais apareçam cedo. Depois, as restantes por lotes.
Ficha por fonte
Revemos cada site, escolhemos a estratégia e anotamos o que é estranho: formatos de data, paginação, bloqueios, campos que só estão na página de detalhe.
Piloto por estratégia
Implementamos uma fonte de cada tipo com o seu teste unitário, o seu smoke test e o seu documento. É aí que aparecem os problemas que o inventário não vê.
Restantes fontes
Com o modelo validado, cada fonte nova costuma ser configuração mais um teste. As que precisam de navegador ou de desbloqueio vão num lote à parte.
Operação
Planeamento, alertas, relatório de execuções e manutenção quando uma fonte muda. Se preferir operá-lo com a sua equipa, deixamos tudo documentado fonte a fonte.
Perguntas frequentes sobre web scraping
O web scraping é legal em Portugal e na UE? +
Extrair dados publicados sem restrição de acesso é uma prática habitual, mas há três limites que revemos em cada fonte: os termos de utilização do site, o direito sui generis das bases de dados (não se pode extrair uma parte substancial de uma base de dados alheia para a reutilizar) e o RGPD quando há dados pessoais. Não entramos em áreas com login sem autorização do titular. Se o caso for duvidoso, recomendamos uma revisão jurídica antes de começar.
O que acontece quando o site muda de design? +
O smoke test dessa fonte falha na passagem seguinte, no máximo ao fim de três dias, e chega um alerta com o erro. As fontes por API ou RSS quase nunca são afetadas por redesigns. Nas de HTML ou navegador headless costuma bastar atualizar os seletores na configuração da fonte, sem fazer deploy de código.
Quando é que a Bright Data é necessária? +
Quando o site devolve 403 a qualquer cliente automatizado, mostra CAPTCHAs ou corta por IP. Aí um navegador headless próprio não chega, porque o bloqueio depende do IP e da impressão digital do navegador. Ativamo-la só nas fontes que precisam; as outras continuam a sair diretas.
Com que frequência são atualizados os dados? +
Cada fonte tem a sua: de hora a hora para preços ou disponibilidade, uma vez por dia para agendas ou catálogos que mudam pouco. É também uma questão de cortesia com o site de origem: pedir a cada cinco minutos algo que muda uma vez por dia só gera carga.
Em que formato recebo os dados? +
Na sua base de dados, normalmente PostgreSQL, com um esquema comum para todas as fontes, ou através de uma API REST. Também podemos gerar exportações CSV ou JSON periódicas ou enviar as alterações por webhook.
Posso usar os dados para alimentar um modelo de IA? +
Sim, e é um dos usos mais habituais: os dados normalizados servem de base para um motor de pesquisa semântica, um RAG ou um agente. Aplicam-se os mesmos limites legais que a qualquer outro uso, e guardamos o URL e a data de origem de cada registo para poder citar a fonte.
Também lhe pode interessar
Envie-nos a lista de fontes
Mande-nos os URLs de onde precisa de dados e os campos que lhe interessam. Devolvemos-lhe uma ficha por fonte com a estratégia, os riscos e a frequência que recomendamos.
Diga-nos de que fontes precisaConte-nos seu desafio. Propomos uma solução.
Sem compromisso. Em menos de 24 horas, você recebe uma proposta com escopo, cronograma e orçamento. Sem letras miúdas.