El desafío
Tu equipo lanza un producto de listados inmobiliarios. Funciona durante tres semanas. Luego, Zillow cambia su DOM, Rightmove endurece sus controles de bots y tu scraper deja de funcionar en cuatro de cada seis fuentes durante un solo fin de semana.
La agregación de bienes raíces tiene un problema específico que la monitorización de precios y el seguimiento de SERP no comparten. No estás extrayendo datos estructurados de una única API limpia. Estás uniendo listados de portales que utilizan diferentes stacks de detección de bots, diferentes layouts, diferentes geografías y diferentes frecuencias de actualización. Zillow en EE. UU., Redfin para datos respaldados por MLS, Rightmove en el Reino Unido, realestate.com.au en Australia, Immobilienscout24 en Alemania. Cada portal es un proyecto de ingeniería independiente.
Según la investigación de Scrapfly de 2026, los principales portales inmobiliarios inspeccionan la firma a nivel de conexión y rechazan clientes que no coinciden con un handshake de nivel de navegador. Su guía de Rightmove analiza el JSON incrustado en variables de JavaScript que cambia de estructura cada pocos meses. Redfin fragmenta los datos de las propiedades en docenas de nodos DOM, por lo que un solo ajuste de layout puede hacer que pierdas la mitad de tus campos a la vez. Además, los portales regionales ofrecen contenido diferente según el país del visitante, lo que significa que un scraper basado en EE. UU. no ve nada útil en realestate.com.au.
El resultado: la frescura de tus listados se degrada silenciosamente. Un tercio de tus propiedades queda desactualizado en 48 horas. Tus usuarios ven precios de la semana pasada. Tu equipo de ventas comienza a recibir quejas y tus tickets de soporte aumentan los lunes porque los layouts de los portales suelen cambiar los fines de semana.
El enfoque
Agregar listados a escala no es un problema de scraping. Es un problema de confiabilidad disfrazado de scraping. Por qué tu scraper se sigue rompiendo cubre el caso general. El sector inmobiliario amplifica cada parte del problema.
Cualquier plataforma que maneje esto de forma adecuada necesita cuatro elementos funcionando juntos. Primero, una firma de request que coincida con la de navegadores reales (no solo un string de User-Agent con forma de navegador, sino los detalles reales a nivel de red que Zillow y Rightmove utilizan para separar bots de humanos). Segundo, IP residenciales con precisión geográfica en cada mercado objetivo, porque un agregador alemán no puede enviar tráfico de centros de datos de EE. UU. a Immobilienscout24 y esperar respuestas útiles. Tercero, enrutamiento de proxy por host, porque la estrategia que funciona en Zillow falla en realestate.com.au. Cuarto, renderizado de navegador como fallback para los portales que procesan todo del lado del cliente.
Una request de ejemplo hacia Rightmove a través del producto Proxy de FourA se ve algo así:
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"]}
}
}
}'
El flag unblocker inyecta un conjunto completo de headers de navegador junto con la firma correspondiente a nivel de cable. maxTries: 5 le indica al administrador de proxies que rote hasta cinco IPs hasta que una tenga éxito. Las reglas de validación detectan bloqueos silenciosos: las respuestas 200 que devuelven una página de rechazo suave en lugar de los datos del listado. De este modo, tu tasa de éxito refleja lo que realmente funcionó, no lo que afirmó el estado HTTP.
Los portales que sirven todo a través de JavaScript (Redfin es el ejemplo obvio) necesitan renderizado en un navegador real. Nuestro producto Browser maneja esos casos con una instancia de navegador completa, no con un emulador ligero que resulta detectado en la primera conexión. La detección de bots pasó a ser conductual en 2026, y cualquier cosa inferior a un navegador real es cada vez más visible.
Resultados
¿Qué sucede cuando un agregador inmobiliario cambia un stack de scraping personalizado por un enfoque basado en APIs? Los patrones que observamos en operaciones reales (escenario ilustrativo basado en benchmarks del sector):
- Frescura de listados: mejora de "actualizado en 48 horas" a "actualizado en 2 horas" para mercados activos
- Tiempo de ingeniería: el mantenimiento del scraper se reduce un 70%. Un ingeniero en rotación en lugar de un equipo dedicado
- Cobertura de portales: se expande de 6 sitios a más de 20 sin un aumento proporcional en infraestructura
- Tasas de bloqueos silenciosos: caen por debajo del 3% en portales protegidos una vez que las reglas de validación capturan los bloqueos suaves
Un patrón común entre los equipos que usan nuestra plataforma: una vez que se comparte la capa de confiabilidad, añadir un nuevo mercado se convierte en un cambio de configuración en lugar de un sprint. Las preguntas interesantes pasan de ser "por qué falló esto otra vez" a "qué portal deberíamos añadir ahora".
La limitación honesta: los portales inmobiliarios que requieren sesiones autenticadas (algunos sistemas MLS, ciertas vistas exclusivas para agentes) necesitan gestión de cuentas además de la infraestructura de requests. Ese es un problema distinto que no resolvemos, y no deberías confiar en nadie que afirme hacerlo sin explicar cómo.
Conclusión clave
El sector inmobiliario es una de las pocas industrias donde los datos obsoletos no son solo una molestia. Son un fallo de producto. Un precio desactualizado por una semana en un sitio de moda es un detalle menor. Un listado desactualizado por una semana en un mercado activo significa que tu usuario acaba de consultar por una casa que se vendió el martes.
Pero los equipos que triunfan en esto no son los que tienen más fuentes. Son los que han dejado de reconstruir la misma infraestructura de proxies y requests para cada portal nuevo. Una vez que esa capa se comparte, comienza el trabajo interesante: calidad de datos, SLAs de frescura, deduplicación entre portales y análisis de tendencias de precios. Ese es el producto. Todo lo que está por debajo simplemente debería funcionar.