Проблема
Ваша команда запускает агрегатор объявлений. Он работает три недели. Затем Zillow меняет свой DOM, Rightmove ужесточает проверки ботов, и за один уик-энд ваш скрапер отключается на четырех из шести источников.
У агрегации недвижимости есть специфическая проблема, которой нет у мониторинга цен или отслеживания SERP. Вы не получаете структурированные данные из одного чистого API. Вы собираете объявления с порталов, каждый из которых использует разные стеки защиты от ботов, разные макеты, разные геолокации и разные интервалы обновлений. Zillow в США, Redfin для данных на базе MLS, Rightmove в Великобритании, realestate.com.au в Австралии, Immobilienscout24 в Германии. Каждый портал представляет собой отдельный инженерный проект.
Согласно исследованию Scrapfly за 2026 год, ведущие порталы недвижимости проверяют сигнатуру на уровне соединения и отклоняют клиентов, чье рукопожатие не совпадает с браузерным. Их руководство по Rightmove разбирает JSON, встроенный в переменные JavaScript, структура которого меняется раз в несколько месяцев. Redfin фрагментирует данные об объектах по десяткам узлов DOM, поэтому единичное изменение макета может мгновенно отсечь половину ваших полей. А региональные порталы отдают разный контент в зависимости от страны посетителя, из-за чего скрапер из США не увидит ничего полезного на realestate.com.au.
Результат: актуальность вашей базы объявлений незаметно падает. Треть объектов устаревает в течение 48 часов. Пользователи видят цены прошлой недели. Отдел продаж начинает сталкиваться с претензиями, а количество обращений в поддержку резко возрастает по понедельникам, так как макеты порталов обычно меняются на выходных.
Подход
Агрегация объявлений в масштабе не является задачей скрапинга. Это задача надежности, замаскированная под него. В статье Почему ваш скрапер постоянно ломается разобран общий случай. Недвижимость же усиливает каждую его составляющую.
Любая платформа, которая эффективно решает эту задачу, требует слаженной работы четырех компонентов. Во-первых, сигнатура запроса, полностью совпадающая с реальными браузерами (не просто строка User-Agent нужного формата, а реальные детали сетевого уровня, по которым Zillow и Rightmove отличают ботов от людей). Во-вторых, точные по геолокации резидентные IP на каждом целевом рынке, поскольку немецкий агрегатор не может отправлять трафик дата-центров США на Immobilienscout24 и рассчитывать на полезный ответ. В-третьих, маршрутизация proxy для каждого хоста, так как стратегия, работающая на Zillow, не сработает на realestate.com.au. В-четвертых, рендеринг в браузере как запасной вариант для порталов, которые переносят всю логику на сторону клиента.
Пример запроса к 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 внедряет полный набор browser header вместе с соответствующей сигнатурой на уровне протокола. maxTries: 5 указывает proxy manager перебирать до пяти IP, пока один не сработает успешно. Правила валидации отлавливают скрытые блокировки: ответы 200, которые возвращают страницу мягкого отказа вместо данных объявлений. Поэтому ваш success rate отражает то, что реально сработало, а не то, о чем заявил HTTP status.
Порталы, которые отдают весь контент через JavaScript (Redfin здесь очевидный пример), требуют рендеринга в реальном браузере. Наш продукт Browser обрабатывает их с помощью полноценного экземпляра браузера, а не легковесного эмулятора, который вычисляется при первом же подключении. Системы защиты от ботов перешли на поведенческий анализ в 2026 году, и все, что уступает реальному браузеру, становится все более заметным.
Результаты
Что происходит, когда агрегатор недвижимости переходит со своего кастомного стека парсинга на подход API-first? Паттерны, которые мы наблюдаем в реальных проектах (показательный сценарий на основе отраслевых бенчмарков):
- Свежесть объявлений улучшается с "обновлено в течение 48 часов" до "обновлено в течение 2 часов" для активных рынков
- Затраты времени инженеров на поддержку скраперов падают на 70%. Один дежурный инженер вместо выделенной команды
- Охват порталов расширяется с 6 сайтов до 20+ без пропорционального роста инфраструктуры
- Доля скрытых блокировок падает ниже 3% на защищенных порталах, как только правила валидации начинают отсекать мягкие отказы
Характерная деталь от команд, использующих нашу платформу: как только уровень надежности становится общим, добавление нового рынка превращается в изменение конфигурации, а не в отдельный спринт. Фокус вопросов смещается с "почему это снова упало" на "какой портал подключить следующим".
Честное ограничение: порталы недвижимости, требующие авторизованных сессий (некоторые системы MLS, определенные разделы только для агентов), требуют управления аккаунтами поверх инфраструктуры запросов. Это отдельная задача, которую мы не решаем, и не стоит доверять тем, кто заявляет обратное, не объясняя деталей реализации.
Главный вывод
Недвижимость одна из немногих сфер, где устаревшие данные это не просто неудобство. Это провал продукта. Недельной давности цена на сайте одежды вызывает легкое смущение. Недельной давности объявление на горячем рынке означает, что ваш пользователь только что запросил информацию о доме, проданном во вторник.
Но побеждают здесь не те команды, у которых больше всего источников. Побеждают те, кто перестал заново собирать одну и ту же обвязку для proxy и запросов под каждый новый портал. Когда этот слой стандартизирован, начинается настоящая работа: качество данных, SLA по свежести, дедупликация между площадками, аналитика динамики цен. Это и есть продукт. Все, что находится под ним, должно просто работать.