Парсинг агрегаторов недвижимости: карты, фильтры и обход anti-scrape с помощью гео-прокси

Рынок недвижимости — один из самых данных насыщенных сегментов, а агрегаторы вроде Циан, Авито Недвижимость и Домклик стали основными источниками информации для аналитиков, риелторов и инвесторов. Попытка получить эти данные автоматически наталкивается на серьёзную эшелонированную защиту: динамические карты, фильтры, привязанные к сессии, геолокационные редиректы и антискрейпинговые механизмы. В этой статье мы детально рассмотрим, почему парсинг недвижимости сложен, как работают гео-фильтры и карты, и почему именно гео-прокси становятся ключом к стабильному сбору объявлений.

Почему агрегаторы недвижимости — сложная цель для парсинга

Сайты-агрегаторы объединяют сотни тысяч объявлений от застройщиков и частных лиц, снабжая их фильтрацией по десяткам параметров и визуализацией на карте. За кажущейся простотой фронтенда скрываются мощные headless-бэкенды, которые с самого начала проектировались так, чтобы защитить наиболее ценные данные от автоматизированного сбора.

• Динамический контент. Основная выдача и данные карты загружаются через внутренние API с токенами, сгенерированными на лету. Прямое копирование HTML не даст результата.
• Гео-зависимое поведение. Один и тот же URL может отдавать разные выборки в зависимости от IP-адреса пользователя: алгоритмы смещают выдачу в сторону локального рынка, а при запросе с нехарактерной локации включают дополнительную проверку.
• Многослойный anti-scrape. Помимо классических ограничений по частоте запросов (rate limiting) применяются JavaScript-челленджи, капчи, анализ поведенческих паттернов (движения мыши, тайминги) и динамические изменения структуры DOM.

Наш опыт в разработке систем парсинга и мониторинга цен показывает, что без предварительного анализа архитектуры каждой конкретной площадки можно месяцами биться в закрытые двери. Ниже мы раскроем самые критичные узлы — карты и фильтры.

Карты и гео-фильтры: основные препятствия

Большинство агрегаторов для визуализации использует собственные реализации карт на базе библиотек типа Mapbox GL JS или закрытые API поверх Яндекс.Карт / Google Maps. При попытке автоматизировать работу с картой нужно учитывать несколько ключевых моментов:

Плиточная подгрузка и bounding box

Данные объектов не передаются сразу для всей области — они подгружаются порциями по мере перемещения карты. Каждый сдвиг или зум генерирует запрос с параметрами viewport (широта, долгота, zoom, границы bounding box). Простой парсер, эмулирующий такие запросы, быстро наткнётся на лимит, если координаты bounding box будут повторяться с одного IP. Более того, платформы накладывают ограничения на размер области: нельзя запросить «всю Москву» одним bounding box — сервер просто обрежет выборку или вернёт пустой результат.

Геокодирование и временные привязки

При использовании фильтров (радиус от метро, район, координаты) запускается цепочка геокодирования — преобразования адреса в координаты. Эти запросы кешируются на стороне агрегатора, но сессионно: если скрипт работает без сохранения cookie и без подмены IP, кеш не срабатывает, и каждый вызов порождает дорогостоящий запрос к геокодеру. Системы защиты быстро реагируют на аномально высокую частоту подобных вызовов с одного идентификатора.

Локализованные выдачу и цены

Значения цен, контактных данных и доступности объектов могут изменяться в зависимости от региона, определённого по IP. Например, объект в Казани с IP-адресом, зарегистрированным в Москве, может отображаться с московскими же коэффициентами или вовсе не попадать в выборку из-за региональных ограничений. Без использования гео-прокси получить репрезентативную картину рынка в масштабах страны невозможно.

Для стабильного преодоления этих барьеров мы в ESK Solutions рекомендуем архитектуру с распределённой сетью резидентовых гео-прокси, интегрированных на уровне сессий парсера. Подобные решения также востребованы в узких нишах — например, при создании SaaS-платформ аналитики недвижимости, где необходимо обновлять данные по тысячам локаций.

Гео-прокси: принцип работы и критерии выбора

Обычные датацентровые прокси с диапазонами IP, принадлежащими хостинг-провайдерам, для агрегаторов недвижимости практически бесполезны: крупнейшие площадки поддерживают чёрные списки таких подсетей. Резидентные прокси (жилые IP) и мобильные прокси дают гораздо более высокий процент успешных запросов, но требуют тонкой настройки для обхода гео-зависимых фильтров.

Типы прокси-серверов

• Residential (жилые). Адреса из пулов реальных интернет-провайдеров. Высокое доверие, но ограниченная доступность для целевых городов.
• Mobile (мобильные). IP операторов сотовой связи. Часто позволяют получить максимально локальный гео-таргетинг и обходить капчи.
• ISP-прокси. Статические адреса, зарегистрированные как принадлежащие провайдерам, но размещённые на датацентровом оборудовании. Компромиссный вариант, если важно постоянство IP для удержания сессий.

Гео-таргетинг прокси

Для парсинга казанской недвижимости прокси должен находиться в Казани или, как минимум, в том же регионе (Татарстан). Современные прокси-провайдеры позволяют выбирать ротацию на уровне города. Однако важно понимать, что даже при точном совпадении города IP может быть расценён как подозрительный из-за резких смен локаций в рамках одной сессии. Поэтому архитектура парсера должна поддерживать долгоживущие сессии с последовательной сменой IP только в пределах одного города.

Пример выбора: для охвата 50 городов с частотой обновления раз в сутки потребуется пул из 150–200 резидентных IP с возможностью гео-привязки, а также платформа оркестрации задач — та, что мы нередко закладываем при проектировании облачных сервисов для парсинга. Без централизованного управления прокси и очередями запросов проект рискует превратиться в неуправляемый зоопарк скриптов.

Архитектура парсера с гео-проксированием

Перейдём к технической реализации. Сбор данных с агрегаторов недвижимости мы обычно укладываем в многоуровневую архитектуру:

Уровень управления заданиями

Координирует, какие города и категории объектов (жилая, коммерческая, новостройки) обрабатываются в текущий момент. Планировщик раскладывает задания по worker’ам с учётом географической аффинности прокси. Это снижает число переключений локации и продлевает жизнь пулу.

Уровень сессий и браузерной эмуляции

Поскольку почти все картографические интерфейсы работают через JavaScript, мы применяем headless-браузеры (Playwright/Puppeteer) с подменой геолокации через эмуляцию Sensor API и подстановкой координат в параметры viewport. Для каждого worker’а поднимается изолированная сессия, использующая свой прокси-адрес. При этом критично управлять fingerprint’ом браузера: WebGL vendor, Canvas, разрешение экрана, часовой пояс должны соответствовать целевому региону. Это как раз та задача, которую решает полноценная заказная веб-разработка под нестандартные интеграции.

Уровень обхода антискрейпинга

Помимо прокси, мы внедряем:

• Интеллектуальные задержки. Запросы эмулируют поведение реального пользователя: паузы между зумами карты, случайный порядок просмотра объявлений, прокрутка до конца страницы.
• Подмену и ротацию заголовков. Каждая сессия получает уникальный User-Agent и Accept-Language, соответствующие региону.
• Решение капч. Интеграция с сервисами автоматического распознавания (если капча всё же появляется), но основная цель — не допускать её возникновения за счёт качественного трафика.
• Парсинг внутренних API. Картографические плитки и списки объектов часто отдаются в JSON-формате при правильной эмуляции токенов. Мы анализируем сетевой трафик браузера и воспроизводим нужные запросы напрямую, минуя рендеринг, что в разы ускоряет сбор.

Хранение и постобработка

Собранные данные очищаются, дедуплицируются и обогащаются гео-координатами для последующей загрузки в аналитические системы. Здесь же разворачивается мониторинг успешности прокси: если процент отказов для определённого города превышает порог, менеджер прокси запрашивает ротацию адресов.

Итоговая схема, хотя и требует первоначальных инвестиций в проектирование, окупается стабильностью потока данных. Для бизнесов, рассматривающих запуск собственного продукта на базе таких данных, мы предлагаем цикл от прототипа парсера до готового сервиса сбора и мониторинга цен с полностью управляемой облачной инфраструктурой.

Часто задаваемые вопросы

Можно ли парсить агрегаторы без гео-прокси, используя только датацентровые IP?

Технически — да, если объём запросов минимален и вас не интересует корректная региональная привязка. Однако на практике уже после нескольких десятков обращений к карте с хостингового IP большинство крупных агрегаторов включает дополнительную верификацию или капчу. Для регулярного мониторинга такой подход непригоден.

Как часто нужно ротировать прокси для одного города?

Это зависит от агрессивности защиты конкретного сайта. В среднем, при сборе раз в сутки по одному городу можно использовать один и тот же IP в течение нескольких дней, если запросы естественно распределены по времени. При более высокой частоте (раз в час) ротация должна происходить не реже, чем каждые 5–10 сессий, чтобы не накапливать «усталость» адреса.

Что делать, если карта требует авторизации или API-ключа?

Многие площадки требуют регистрации для доступа к расширенным данным. В этом случае сессионные прокси должны поддерживать долгоживущие cookie и не разрывать сессию после каждого запроса. Иногда проще эмулировать зарегистрированного пользователя через headless-браузер и подменять токены авторизации. При проектировании корпоративных решений мы дополнительно подключаем CRM-интеграции для автоматической загрузки полученных лидов.

Законен ли парсинг агрегаторов недвижимости?

Законодательство разных стран трактует автоматизированный сбор общедоступных данных по-разному. В большинстве юрисдикций разрешён сбор фактологической информации (цены, характеристики объектов) при условии соблюдения robots.txt, отсутствия обхода технических средств защиты и недопущения перегрузки серверов. Мы всегда рекомендуем клиентам проводить юридический аудит целевого ресурса и получать письменное заключение перед стартом проекта.

Универсального «серебряного» решения для парсинга всех агрегаторов не существует — каждый проект требует комбинации гео-прокси, эмуляции окружения и интеллектуальной маршрутизации запросов. Именно такой комплексный подход мы закладываем в основу каждого внедрения, чтобы вы получали чистые данные без блокировок.