Предизвикателството
Вашият екип пуска продукт за обяви. Той работи три седмици. След това Zillow променя своя DOM, Rightmove затяга своите bot проверки и вашият скрапер спира да работи за четири от шест източника в рамките на един уикенд.
Агрегирането на недвижими имоти има специфичен проблем, който мониторингът на цени и SERP проследяването нямат. Вие не извличате структурирани данни от един чист API. Вие сглобявате обяви от портали, всеки от които използва различни anti-bot стекове, различни оформления, различни географии и различен ритъм на актуализация. Zillow в САЩ, Redfin за данни от MLS, Rightmove в Обединеното кралство, realestate.com.au в Австралия, Immobilienscout24 в Германия. Всеки портал е собствен инженерен проект.
Според проучването на Scrapfly от 2026 г., водещите портали за недвижими имоти проверяват подписа на ниво връзка и отхвърлят клиенти, които не съответстват на browser-grade handshake. Тяхното ръководство за Rightmove разглежда JSON, вграден в JavaScript променливи, който променя структурата си на всеки няколко месеца. Redfin фрагментира данните за имота в десетки DOM възли, така че една малка промяна в оформлението може да премахне половината ви полета наведнъж. А регионалните портали предоставят различно съдържание въз основа на държавата на посетителя, което означава, че базиран в САЩ скрапер не вижда нищо полезно в realestate.com.au.
Резултатът: свежестта на вашите обяви се влошава незабележимо. Една трета от вашите имоти остаряват в рамките на 48 часа. Потребителите ви виждат цени от миналата седмица. Търговският ви екип започва да получава откази, а тикетите за поддръжка скачат в понеделник, тъй като оформленията на порталите обикновено се променят през уикендите.
Подходът
Агрегирането на обяви в голям мащаб не е проблем със скрапинга. Това е проблем с надеждността, маскиран като такъв. Защо вашият скрапер продължава да се чупи покрива общия случай. Недвижимите имоти усилват всяка част от него.
Всяка платформа, която се справя добре с това, се нуждае от четири неща, работещи заедно. Първо, request подпис, който съвпада с реални браузъри (не само User-Agent низ, оформен като браузър, а действителните wire-level детайли, които Zillow и Rightmove използват за отделяне на ботове от хора). Второ, географски точни residential IP адреси във всеки целеви пазар, тъй като немски агрегатор не може да изпраща трафик от център за данни в САЩ към Immobilienscout24 и да очаква полезни отговори. Трето, per-host proxy рутиране, тъй като стратегията, която работи за Zillow, се проваля при realestate.com.au. Четвърто, рендиране в браузър като резервен вариант за портали, които изнасят всичко от страна на клиента.
Примерен request към Rightmove чрез Proxy продукта на FourA изглежда приблизително така:
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"]}
}
}
}'
Флагът unblocker инжектира пълен набор от браузърни header-и заедно със съответстващия wire-level подпис. maxTries: 5 казва на proxy мениджъра да ротира до пет IP адреса, докато един не успее. Правилата за валидация улавят тихите блокирания: отговорите с код 200, които връщат страница за soft-block вместо данни за обяви. Така че вашият процент на успех отразява това, което действително е проработило, а не това, което HTTP статусът твърди.
Порталите, които предоставят всичко чрез JavaScript (Redfin е очевидният пример), се нуждаят от реално рендиране в браузър. Нашият Browser продукт се справя с тях чрез пълна инстанция на браузър, а не чрез лек емулатор, който бива маркиран още при първата връзка. Засичането на ботове стана поведенческо през 2026 г. и всичко по-малко от истински браузър става все по-видимо.
Резултати
Какво се случва, когато агрегатор на недвижими имоти премине от къстъм скрапинг стек към API-first подход? Моделите, които виждаме в реални операции (илюстративен сценарий, базиран на индустриални бенчмаркове):
- Свежестта на обявите се подобрява от "актуализирано в рамките на 48 часа" на "актуализирано в рамките на 2 часа" за активни пазари
- Инженерното време за поддръжка на скрапери спада със 70%. Един инженер на ротация вместо специализиран екип
- Покритието на портали се разширява от 6 сайта на над 20 без пропорционално увеличение на инфраструктурата
- Процентите на тихо блокиране падат под 3% при защитени портали, след като правилата за валидация уловят soft blocks
Един модел от екипите, използващи нашата платформа: след като слоят за надеждност бъде споделен, добавянето на нов пазар става промяна в конфигурацията вместо спринт. Интересните въпроси се изместват от "защо това се счупи отново" към "кой портал трябва да добавим след това".
Честното ограничение: порталите за недвижими имоти, които изискват сесии с влизане (някои MLS системи, определени изгледи само за агенти), се нуждаят от управление на акаунти върху инфраструктурата за request-и. Това е отделен проблем, който ние не решаваме, и не трябва да се доверявате на никого, който твърди, че го прави, без да обясни как.
Ключов извод
Недвижимите имоти са една от малкото индустрии, в които остарелите данни не са просто неудобство. Те са продуктов провал. Цена на една седмица в моден сайт е леко неудобство. Обява на една седмица на горещ пазар означава, че вашият потребител току-що е попитал за къща, която е продадена във вторник.
Но екипите, които печелят в това, не са тези с най-много източници. Те са тези, които са спрели да изграждат отново един и същ proxy и anti-bot механизъм за всеки нов портал. След като този слой бъде споделен, започва интересната работа: качество на данните, SLAs за свежест, дедупликация между портали, анализ на ценовите тенденции. Това е продуктът. Всичко отдолу просто трябва да работи.