O Desafio
Sua equipe lança um produto de anúncios. Ele funciona por três semanas. Então a Zillow altera seu DOM, o Rightmove reforça suas verificações de TLS, e seu scraper fica fora do ar em quatro de 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á extraindo dados estruturados de uma API limpa. Você está consolidando anúncios de portais que usam, cada um, diferentes stacks 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 é seu próprio projeto de engenharia.
De acordo com a pesquisa de 2026 da Scrapfly, os principais portais imobiliários inspecionam TLS fingerprints e rejeitam clientes que não imitam handshakes de nível de navegador. O guia do Rightmove deles detalha o JSON incorporado em variáveis JavaScript que muda de estrutura a cada poucos meses. O Redfin fragmenta os dados de propriedades em dezenas de nós DOM, de modo que um único ajuste de layout pode derrubar metade dos seus campos de uma só vez. E portais regionais servem conteúdos diferentes 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: o frescor dos seus anúncios degrada silenciosamente. Um terço das suas propriedades fica desatualizado em 48 horas. Seus usuários veem preços da semana passada. Sua equipe de vendas começa a enfrentar resistência, e seus tickets de suporte disparam nas segundas-feiras porque os layouts dos portais tendem a mudar nos fins de semana.
A Abordagem
Agregar anúncios em escala não é um problema de scraping. É um problema de confiabilidade disfarçado. Por que seu scraper continua quebrando aborda o caso geral. O setor imobiliário amplifica cada parte disso.
Qualquer plataforma que lide bem com isso precisa de quatro coisas funcionando juntas. Primeiro, TLS fingerprints que correspondam a navegadores reais (não apenas uma string de User-Agent no formato de navegador, mas a ordem real de ciphers e as extensões ClientHello que o Zillow e o Rightmove usam para separar bots de humanos). Segundo, IPs residenciais geograficamente precisos em cada mercado-alvo, porque um agregador alemão não pode enviar tráfego de datacenter dos EUA para o 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, renderização de 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 isto:
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 junto com o TLS fingerprint correspondente. maxTries: 5 instrui o gerenciador de proxy a rotacionar por até cinco IPs até que um funcione. As regras de validação capturam bloqueios silenciosos: as respostas 200 que retornam uma página de soft-block em vez dos dados do anúncio. Assim, sua taxa de sucesso reflete o que realmente funcionou, não o que o status HTTP alegou.
Portais que servem tudo via JavaScript (o Redfin é o exemplo óbvio) precisam de renderização de navegador real. Nosso produto Browser lida com isso usando uma instância real do Chromium, não um emulador leve que é detectado no primeiro handshake. A detecção de bots tornou-se comportamental em 2026, e qualquer coisa menor que um navegador real é cada vez mais visível.
Resultados
O que acontece quando um agregador imobiliário muda de uma stack de scraping personalizada para uma abordagem API-first? Os padrões que vemos em operações reais (cenário ilustrativo baseado em referências do setor):
- Frescor dos anúncios melhora de "atualizado em 48 horas" para "atualizado em 2 horas" para mercados ativos
- Tempo de engenharia na manutenção de scrapers cai 70%. Um engenheiro em rotação em vez de uma equipe dedicada
- Cobertura de portais expande de 6 sites para mais de 20 sem um aumento proporcional na infraestrutura
- Taxas de bloqueio silencioso caem para menos de 3% em portais protegidos assim que as regras de validação capturam soft-blocks
Um padrão das equipes que usam nossa plataforma: uma vez 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: portais imobiliários que exigem sessões logadas (alguns sistemas MLS, certas visualizações exclusivas para corretores) precisam de gerenciamento de contas além da infraestrutura de request. Esse é um problema separado que não resolvemos, e você não deve confiar em ninguém que diga que resolve sem explicar como.
Principal Conclusão
O setor imobiliário é um dos poucos setores onde dados desatualizados não são apenas um incômodo. É uma falha do produto. Um preço de uma semana atrás em um site de moda é um leve constrangimento. Um anúncio de uma semana atrás em um mercado aquecido significa que 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 as que têm mais fontes. São as que pararam de reconstruir os mesmos mecanismos de proxy e anti-bot para cada novo portal. Uma vez que essa camada é compartilhada, o trabalho interessante começa: qualidade dos dados, SLAs de frescor, desduplicação entre portais, análise de tendências de preços. Esse é o produto. Tudo por baixo deve simplesmente funcionar.