Предизвикателството
Екипът ви пуска продукт за обяви. Работи три седмици. След това Zillow променя своя DOM, Rightmove затяга проверките си за ботове и вашият scraper спира да работи за четири от шест източника само за един уикенд.
Агрегирането на недвижими имоти има специфичен проблем, който мониторингът на цени и проследяването на SERP нямат. Вие не извличате структурирани данни от едно чисто API. Сглобявате обяви от портали, всеки от които използва различни стекове за засичане на ботове, различни оформления, различни локации и различна честота на обновяване. Zillow в САЩ, Redfin за данни от MLS, Rightmove във Великобритания, realestate.com.au в Австралия, Immobilienscout24 в Германия. Всеки портал е отделен инженерен проект.
Според проучването на Scrapfly от 2026 г. водещите портали за недвижими имоти проверяват сигнатурата на ниво връзка и отхвърлят клиенти, които не съответстват на handshake от браузърен клас. Тяхното ръководство за Rightmove разглежда JSON данни, вградени в JavaScript променливи, чиято структура се променя на всеки няколко месеца. Redfin фрагментира данните за имотите в десетки DOM възли, така че една малка промяна в оформлението може да изтрие половината ви полета едновременно. А регионалните портали показват различно съдържание според държавата на посетителя, което означава, че базиран в САЩ scraper не вижда нищо полезно в realestate.com.au.
Резултатът: актуалността на вашите обяви намалява незабелязано. Една трета от вашите имоти остаряват в рамките на 48 часа. Потребителите ви виждат цени от миналата седмица. Търговският ви екип среща недоволство, а запитванията към поддръжката скачат в понеделник, тъй като оформленията на порталите обикновено се променят през уикенда.
Подходът
Агрегирането на обяви в голям мащаб не е проблем със scraping. Това е проблем с надеждността, маскиран като такъв. Защо вашият scraper продължава да се чупи разглежда общия случай. Недвижимите имоти усилват всяка част от него.
Всяка платформа, която се справя добре с това, изисква четири работещи заедно компонента. Първо, request сигнатура, съответстваща на истински браузъри (не просто User-Agent низ, наподобяващ браузър, а реалните детайли на мрежово ниво, които Zillow и Rightmove използват, за да различават ботове от хора). Второ, географски точни residential IP адреси на всеки целеви пазар, защото немски агрегатор не може да изпраща трафик от центрове за данни в САЩ към Immobilienscout24 и да очаква полезни отговори. Трето, маршрутизиране на proxy според хоста, тъй като стратегията, работеща за Zillow, се проваля при realestate.com.au. Четвърто, browser rendering като резервен вариант за портали, които зареждат всичко от страна на клиента.
Примерен request към Rightmove през FourA Proxy изглежда приблизително така:
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, които връщат страница с отказ вместо данните за имота. Така процентът ви на успеваемост отразява това, което реално е сработило, а не какво твърди HTTP статусът.
Порталите, които зареждат цялото съдържание чрез JavaScript (Redfin е очевидният пример), изискват реално рендиране през браузър. Нашият продукт Browser обработва тези случаи с пълноценна браузърна инстанция, а не с олекотен емулатор, който бива засечен още при първата връзка. Засичането на ботове стана поведенческо през 2026 г., и всичко под нивото на реален браузър става все по-лесно разпознаваемо.
Резултати
Какво се случва, когато агрегатор на недвижими имоти премине от собствено разработен scraping стек към API-first подход? Моделите, които наблюдаваме в реални операции (илюстративен сценарий, базиран на индустриални бенчмаркове):
- Актуалност на обявите се подобрява от "обновено в рамките на 48 часа" до "обновено в рамките на 2 часа" за активни пазари
- Инженерното време за поддръжка на scraper-и намалява със 70%. Един инженер на ротация вместо цял отделен екип
- Покритието на портали се разширява от 6 сайта до 20+ без пропорционално увеличение на инфраструктурата
- Процентът на скрити блокирания пада под 3% при защитени портали, след като правилата за валидация прихванат меките блокирания
Модел, наблюдаван при екипите, използващи нашата платформа: щом слоят за надеждност стане споделен, добавянето на нов пазар се превръща в конфигурационна промяна вместо в цял спринт. Интересните въпроси се изместват от "защо това пак се счупи" към "кой портал да добавим следващия."
Честното ограничение: порталите за недвижими имоти, които изискват вход в профил (някои MLS системи, определени изгледи само за брокери), се нуждаят от управление на акаунти върху request инфраструктурата. Това е отделен проблем, който ние не решаваме, и не бива да се доверявате на никой, който твърди обратното, без да обясни как точно го прави.
Основен извод
Недвижимите имоти са една от малкото индустрии, където остарелите данни не са просто неудобство. Те са провал на продукта. Едноседмична цена в сайт за мода е леко неудобство. Едноседмична обява в динамичен пазар означава, че вашият потребител току-що е изпратил запитване за къща, продадена още във вторник.
Печелившите екипи в тази сфера не са тези с най-много източници. Те са тези, които са спрели да изграждат наново една и съща proxy и request инфраструктура за всеки нов портал. Щом този слой бъде споделен, започва същинската работа: качество на данните, SLA за актуалност, дедупликация между портали, анализ на ценовите тенденции. Това е продуктът. Всичко отдолу просто трябва да работи.