O desafio
A sua equipe lança um produto de anúncios. Ele funciona por três semanas. Então, o Zillow muda o DOM, o Rightmove aperta as verificações de bot, e o seu scraper apaga em quatro das seis fontes em um único fim de semana.
A agregação imobiliária tem um problema específico que o monitoramento de preços e o rastreamento de SERP não compartilham. Você não está puxando dados estruturados de uma API limpa. Você está costurando anúncios de portais que usam diferentes pilhas anti-bot, diferentes layouts, diferentes geografias e diferentes cadências de atualização. Zillow nos EUA, Redfin para dados baseados em MLS, Rightmove no Reino Unido, realestate.com.au na Austrália, Immobilienscout24 na Alemanha. Cada portal é o seu próprio projeto de engenharia.
De acordo com a pesquisa da Scrapfly de 2026, os principais portais imobiliários inspecionam a assinatura de nível de conexão e rejeitam clientes que não correspondem a um handshake de nível de navegador. O seu guia sobre o Rightmove percorre o JSON embutido em variáveis JavaScript que muda a estrutura a cada poucos meses. A Redfin fragmenta dados de propriedades através de dezenas de nós no DOM, então um único ajuste no layout pode derrubar metade dos seus campos de uma vez. E os portais regionais servem conteúdo diferente com base no país do visitante, o que significa que um scraper baseado nos EUA não vê nada de útil no realestate.com.au.
O resultado: a atualização dos seus anúncios se degrada silenciosamente. Um terço das suas propriedades envelhecem dentro de 48 horas. Os seus usuários veem preços da semana passada. A sua equipe de vendas começa a receber resistência, e os seus chamados de suporte disparam às segundas-feiras porque os layouts de portal tendem a mudar nos fins de semana.
A abordagem
Agregar anúncios em escala não é um problema de scraping. É um problema de confiabilidade vestido de um. Por que o seu scraper continua quebrando cobre o caso geral. O setor imobiliário amplifica cada parte dele.
Qualquer plataforma que lide bem com isso precisa que quatro coisas funcionem em conjunto. Primeiro, uma request signature que corresponda a navegadores reais (não apenas uma string User-Agent com formato de navegador, mas os detalhes reais no nível do fio que o Zillow e o Rightmove usam para separar bots de humanos). Segundo, IPs residenciais geo-precisos em cada mercado-alvo, porque um agregador alemão não pode enviar tráfego de datacenter dos EUA no Immobilienscout24 e esperar respostas úteis. Terceiro, roteamento de proxy por host, porque a estratégia que funciona no Zillow falha no realestate.com.au. Quarto, a renderização em navegador como fallback para portais que empurram tudo para o lado do cliente.
Uma request de exemplo para o Rightmove através do produto Proxy da FourA se parece com isso:
curl -X POST https://api.foura.ai/api/proxy/ \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"timeout_ms": 45000,
"request": {
"method": "GET",
"url": "https://www.rightmove.co.uk/properties/123456",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": {"accept": [200]},
"data": {"fail": ["blocked", "access denied"]}
}
}
}'
A flag unblocker injeta um conjunto completo de headers de navegador ao lado da assinatura de nível de fio correspondente. maxTries: 5 informa o gerenciador de proxy para alternar entre até cinco IPs até que um tenha sucesso. As regras de validação capturam bloqueios silenciosos: as 200 responses que retornam uma página de bloqueio suave em vez de dados do anúncio. Então a sua taxa de sucesso reflete o que realmente funcionou, não o que o status HTTP reivindicou.
Portais que servem tudo através do JavaScript (o Redfin é o exemplo óbvio) precisam de renderização de navegador real. O nosso produto Browser lida com eles com uma instância completa de navegador, não com um emulador leve que é sinalizado na primeira conexão. A detecção de bot tornou-se comportamental em 2026, e qualquer coisa menos do que um navegador real é cada vez mais visível.
Resultados
O que acontece quando um agregador de imóveis muda de uma pilha de scraping personalizada para uma abordagem API-first? Os padrões que vemos em operações reais (cenário ilustrativo baseado em benchmarks do setor):
- A atualização de anúncios melhora de "atualizado em 48 horas" para "atualizado em 2 horas" para mercados ativos
- O tempo de engenharia na manutenção do scraper cai 70%. Um engenheiro em rodízio em vez de uma equipe dedicada
- A cobertura do portal se expande de 6 sites para mais de 20 sem um aumento proporcional na infraestrutura
- As taxas de bloqueio silencioso caem abaixo de 3% em portais protegidos assim que as regras de validação capturam blocos suaves
Um padrão de equipes usando a nossa plataforma: assim que a camada de confiabilidade é compartilhada, adicionar um novo mercado torna-se uma mudança de configuração em vez de um sprint. As perguntas interessantes mudam de "por que isso quebrou de novo" para "qual portal devemos adicionar a seguir".
A limitação honesta: os portais imobiliários que requerem sessões com login (alguns sistemas MLS, certas visualizações exclusivas de agentes) precisam de gerenciamento de contas no topo da infraestrutura de requests. Esse é um problema separado que não resolvemos, e você não deve confiar em ninguém que diga que faz sem explicar como.
Ponto principal
O setor imobiliário é um dos poucos em que dados obsoletos não são um incômodo. É uma falha no produto. Um preço com uma semana em um site de moda é um leve constrangimento. Um anúncio com uma semana em um mercado aquecido significa que o seu usuário acabou de perguntar sobre uma casa que foi vendida na terça-feira.
Mas as equipes que vencem nisso não são aquelas com mais fontes. São as que pararam de reconstruir o mesmo encanamento de proxy e anti-bot para cada novo portal. Uma vez que a camada é compartilhada, o trabalho interessante começa: qualidade dos dados, SLAs de atualização, deduplicação entre portais, análise de tendências de preços. Esse é o produto. Tudo embaixo deve apenas funcionar.