Парсер объявлений о недвижимости: архитектура личного проекта

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

Зачем вообще нужен парсер недвижимости

В реальном поиске жилья проблемы повторяются почти у всех, и за годы общения с разными людьми — от друзей до клиентов — я вынес из этого один вывод: рынок намеренно или случайно остаётся непрозрачным.

• объявления дублируются на нескольких площадках, причём часто с разными ценами и фото;
• цены и условия меняются без предупреждения — вчерашняя «трёшка за 7 млн» уже снята или подорожала;
• часть объектов уже неактуальна, но всё ещё висит в выдаче, создавая ложное ощущение выбора;
• фильтры на сайтах не всегда позволяют сравнивать рынок по-настоящему удобно: где-то нет выборки по району, где-то нельзя отфильтровать по типу продавца;
• ручной мониторинг занимает слишком много времени и убивает желание искать дальше.

Парсер нужен не ради «собрать всё подряд», а ради двух вещей: сэкономить время и сделать рынок прозрачнее. Если собрать объявления в одну базу, сразу появляются полезные сценарии, которых нет на отдельно взятых площадках: сравнение цен по районам, отслеживание динамики, ранний поиск новых объектов, фильтрация по качеству объявления и подсветка подозрительных карточек. Это та самая разница между «я посмотрел десять сайтов» и «я вижу всю картину целиком».

Из чего состоит архитектура личного проекта

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

1. Получение списка страниц и карточек.
2. Извлечение данных из HTML или встроенного JSON.
3. Очистка и нормализация.
4. Дедупликация.
5. Сохранение в базу.
6. Обновление и уведомления.
7. Аналитика и витрина для пользователя.

Такой подход намного устойчивее, чем «один скрипт, который всё делает». В личном проекте это особенно важно: сначала вы проверяете гипотезу на одном источнике, а потом без боли расширяете систему. Каждый этап можно отлаживать отдельно, менять реализацию и логировать ошибки, не ломая остальное.

Базовая схема данных

Для объявлений о недвижимости почти всегда нужен один и тот же минимальный набор полей. Я обычно начинаю с таблицы, которая покрывает 90% сценариев анализа и сравнения:

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

Как выбрать источник и не утонуть в сложности

Лучший путь для личного проекта — начинать не со «всех площадок сразу», а с одного конкретного источника и одного сценария поиска. Когда я впервые запускал парсер, то выбрал одну региональную доску объявлений, где искал квартиру в аренду. Это позволило быстро проверить гипотезу: могу ли я вообще стабильно собирать данные и стоит ли игра свеч.

Что проверить перед стартом

• есть ли у сайта страницы поиска со стабильной структурой — например, обычные URL с параметрами, а не бесконечная лента, которая подгружается только при прокрутке;
• подгружается ли контент сервером или через JavaScript — от этого зависит, нужен ли headless-браузер или достаточно HTTP-запроса;
• есть ли встроенный JSON с данными — часто сайты отдают готовые структурированные данные для внутреннего API, и это сильно упрощает извлечение;
• как устроена пагинация — можно ли перейти на следующую страницу по прямой ссылке или нужно эмулировать клики;
• насколько часто меняется верстка — если площадка активно развивается, селекторы придётся обновлять чаще;
• можно ли получить нужные поля без сложной эмуляции браузера — иногда достаточно распарсить HTML, а иногда без Selenium не обойтись.

Если на странице уже есть готовые данные в JSON, это почти всегда проще и надёжнее, чем парсить HTML-верстку. Такой подход часто позволяет уменьшить количество ошибок и ускорить сбор: вы забираете сразу структурированные поля, а не выковыриваете их из вложенных div-ов с нестабильными классами.

Архитектура сбора данных: практический вариант

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

1. Сбор ссылок

Сначала собираются ссылки на карточки из страницы выдачи. Это самый лёгкий слой, но именно он часто ломается первым, если сайт меняет пагинацию или загрузку результатов. Поэтому я обычно делаю сбор ссылок отдельной функцией, которая на вход получает URL страницы поиска, а на выходе отдаёт массив URL карточек. Если что-то падает, проблема локализована именно здесь.

2. Загрузка карточек

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

3. Очистка и нормализация

На этом этапе всё приводится к единому формату, чтобы дальше данные можно было сравнивать и анализировать. Типичные преобразования:

• «12,3 м²» превращается в число 12.3;
• «10 этаж из 17» разбирается на два отдельных поля: floor = 10, floors_total = 17;
• «₽» и пробелы убираются из цены, и она становится integer;
• адрес приводится к стандартному виду: город, улица, дом, район — насколько возможно;
• даты переводятся в единый формат ISO 8601, чтобы потом легко сортировать и сравнивать.

Нормализация часто занимает больше кода, чем сам парсинг, но без неё аналитика превращается в лотерею.

4. Дедупликация

Для недвижимости это критично. Один и тот же объект может появляться:

• на нескольких площадках;
• в нескольких вариантах текста;
• с обновлённой ценой;
• под новым ID после редактирования.

Обычно сравнивают комбинацию признаков: адрес, площадь, комнаты, цена, координаты, фото и текст описания. Чем больше признаков, тем выше точность, но тем сложнее логика. Я начинал с простого сравнения по адресу и площади, а потом добавлял fuzzy-сравнение описаний и хэши фото, чтобы отсеивать дубли даже при частичных расхождениях.

5. Сохранение и обновление

Данные лучше хранить не только как «последнюю версию», но и как историю изменений. Тогда можно увидеть:

• как часто менялась цена;
• сколько дней объявление было активно;
• когда объект исчез с рынка;
• как быстро появляются новые варианты в конкретном районе.

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

Минимальный стек для личного проекта

Для MVP не нужен тяжёлый enterprise-контур. Обычно достаточно такого набора:

Если проект начинается как личный инструмент, не стоит сразу усложнять архитектуру микросервисами. Лучше сначала сделать устойчивый вертикальный срез: «запрос → сбор → очистка → сохранение → уведомление». Это позволяет быстро получить результат и обратную связь, а потом уже выделять части в отдельные сервисы, если нагрузка вырастет.

Что ломает парсер чаще всего

За время работы с разными площадками я выделил несколько типовых проблем, которые рано или поздно встречаются каждому, кто пишет парсер недвижимости.

Изменение верстки

Это главный враг любого парсера. Один лишний div, новый класс или перенос цены в другой блок — и селектор перестаёт работать. В моей практике бывало, что парсер молча возвращал пустые поля, и я замечал это только через несколько дней. Чтобы этого избежать, я добавляю проверки на наличие ключевых полей и алерты, если их нет.

Антибот-защита

Сайты могут ограничивать частоту запросов, блокировать подозрительные сессии, требовать cookies или усложнять выдачу. На практике помогает аккуратный режим работы, умеренная частота запросов и стабильные сессии. Иногда приходится эмулировать поведение обычного пользователя: сохранять cookies, передавать корректные заголовки и не делать слишком много запросов подряд.

Неоднородные данные

У одного объявления есть координаты, у другого — только район. У одного указана полная цена, у другого — цена за месяц и комиссия. Обработку таких случаев нужно закладывать сразу: парсер не должен падать, если какого-то поля нет, а логика нормализации должна быть гибкой и предусматривать варианты.

Дубли и «мусор»

Проблема не только в одинаковых объектах. Иногда объявления содержат:

• устаревшую цену;
• неполный адрес;
• рекламный текст без полезных данных;
• фейковые характеристики;
• дубли с разных площадок.

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

Как строить надёжный парсер

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

Принцип 1. Собирать только нужное

Если для задачи не нужны фото или длинные описания, не стоит их тащить в основной поток. Чем меньше полей, тем стабильнее сбор. В личном проекте это особенно важно: вы не знаете, какие поля окажутся критичными, но лучше начать с минимального набора и добавлять по мере необходимости, чем сразу писать парсер для всего подряд и потом отлаживать капризные селекторы.

Принцип 2. Делать инкрементальное обновление

Не пересобирайте весь массив каждый раз. Гораздо эффективнее:

• брать новые страницы;
• сравнивать с уже сохранёнными объявлениями;
• обновлять только изменившиеся записи;
• отдельно хранить историю изменений.

Такой подход экономит ресурсы и позволяет часто запускать парсер, не нагружая ни свой сервер, ни источник.

Принцип 3. Логировать всё

Без логов в парсинге невозможно понять, где именно случилась проблема: на уровне загрузки, парсинга, очистки или сохранения.

Минимум, что стоит логировать:

• время запроса;
• статус ответа;
• количество найденных карточек;
• ошибки по каждому полю;
• факт обновления записи;
• причину пропуска объекта.

Я обычно пишу логи в структурированном формате (JSON или key-value), чтобы потом можно было легко анализировать их скриптом.

Принцип 4. Делать обработку ошибок мягкой

Если одно объявление сломано, это не повод останавливать весь прогон. Лучше пропустить проблемную карточку и сохранить остальные. Для этого я оборачиваю парсинг каждой карточки в try/catch и логирую ошибку, но продолжаю цикл. Так один капризный селектор не остановит сбор всех данных.

Правильная логика обновления данных

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

Полезные статусы

• новое;
• активное;
• изменено;
• снято с публикации;
• подозрительное;
• дубликат.

Эти статусы можно хранить отдельным полем или вычислять на основе истории. Важно понимать, что статус «снято» не всегда означает, что объект продан — иногда просто истекло объявление или продавец передумал.

Что считать изменением

• изменилась цена;
• появилась/пропала планировка;
• сменился текст;
• обновилась дата публикации;
• объект переехал в другой раздел.

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

Юридические и этические нюансы

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

Практический минимум:

• проверять правила сайта и ограничения на автоматический сбор — иногда в ToS прямо запрещён парсинг, и это нужно учитывать;
• не перегружать сервер частыми запросами — я обычно ставлю задержку 2–5 секунд между карточками и не запускаю парсер чаще, чем раз в несколько часов;
• не собирать лишние персональные данные — для аналитики рынка не нужны имена продавцов или телефоны, их можно отбрасывать ещё на этапе извлечения;
• не публиковать чувствительную информацию без необходимости;
• хранить только те данные, которые реально нужны для сценария.

Если задача — аналитика рынка, а не копирование контента, лучше сразу проектировать систему так, чтобы она работала с агрегированными и обезличенными данными. Это снижает юридические риски и делает проект более устойчивым.

Пошаговый план запуска MVP

1. Выберите один источник и один тип поиска.
2. Определите набор полей, без которых проект не имеет смысла.
3. Проверьте, откуда проще извлекать данные: HTML или JSON.
4. Реализуйте сбор ссылок на карточки.
5. Сделайте парсер одной карточки.
6. Добавьте нормализацию чисел, дат и адресов.
7. Настройте дедупликацию.
8. Сохраните данные в базу.
9. Добавьте историю изменений.
10. Подключите уведомления о новых объектах.

Этот план я всегда рекомендую тем, кто хочет быстро получить рабочий прототип и не застрять в деталях. Каждый шаг можно выполнить за вечер-два, и уже через неделю у вас будет первая версия, которая реально экономит время.

Чек-лист качества парсера

• ☐ Парсер не падает при частично пустых карточках.
• ☐ Данные сохраняются в едином формате.
• ☐ Дубликаты распознаются хотя бы по базовым признакам.
• ☐ Ошибки логируются.
• ☐ История цен хранится отдельно.
• ☐ Пагинация обрабатывается полностью.
• ☐ Новые объявления определяются быстро.
• ☐ Сбор можно запускать по расписанию.
• ☐ Есть понятный способ ручной проверки выборки.
• ☐ Система не зависит от одного хрупкого селектора.

Перед тем как назвать парсер готовым, я прохожусь по этому списку. Если хоть один пункт не выполнен, это повод вернуться к коду и устранить слабое место.

Типовые ошибки новичков

Пытаться собрать всё сразу

Самая частая ошибка — начать с многостраничного монолита. В итоге сложно понять, что именно сломалось. Я всегда советую сначала собрать минимальный вертикальный срез и только потом добавлять источники и поля.

Игнорировать нормализацию

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

Не хранить историю

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

Слепо доверять объявлениям

На рынке недвижимости много неточностей. Данные нужно проверять, особенно если вы строите аналитику цен или оценку ликвидности. Например, цена может быть занижена намеренно, чтобы привлечь внимание, или площадь указана без учёта балкона. Поэтому я всегда добавляю проверки на выбросы и сверяю показатели с контрольными точками.

Как проект эволюционирует из скрипта в сервис

Обычно рост выглядит так:

• сначала это личный скрипт для себя;
• потом появляется удобный экспорт (CSV, Google Sheets);
• затем фильтры и уведомления (например, Telegram-бот);
• позже — агрегатор нескольких источников;
• после этого — аналитика цен и ликвидности;
• на следующем этапе — интеграции с CRM и внешним API.

Именно на этом этапе разница между «скриптом» и «продуктом» становится очевидной. Скрипт просто собирает данные. Продукт помогает принимать решение. Когда я дошёл до интеграции с риелторскими CRM, мой парсер перестал быть личным инструментом — он начал приносить пользу и другим людям, которые тоже устали от ручного мониторинга.

FAQ

Какой формат хранения лучше для парсера недвижимости?

Для старта подойдёт SQLite или PostgreSQL. Если данных становится больше и нужна история изменений, лучше сразу смотреть в сторону PostgreSQL. Он поддерживает более сложные запросы, оконные функции и индексы, которые понадобятся для аналитики.

Что важнее: парсить HTML или JSON?

Если на странице есть встроенный JSON с нужными полями, это почти всегда надёжнее и проще. HTML-парсинг больше зависит от верстки и ломается при каждом редизайне. JSON обычно стабильнее, потому что это внутренний формат данных.

Как понять, что объявление — дубль?

Сравнивают адрес, цену, площадь, число комнат, фото и текст. Один признак недостаточен, лучше использовать набор правил. Например, если совпадают адрес, площадь и количество комнат, но разные цены, это может быть одно и то же объявление с обновлённой ценой.

Нужно ли хранить историю цен?

Да. Для недвижимости это один из самых полезных слоёв данных: он показывает динамику, скорость продажи и реакцию рынка. Без истории вы не увидите, что квартира подешевела на 5% за неделю, а это может быть сигналом для торга.

Можно ли сразу делать парсер для нескольких площадок?

Технически можно, но для личного проекта это часто ошибка. Лучше сначала довести до надёжности один источник, а потом масштабировать архитектуру. Когда вы поймёте, как обрабатывать изменения верстки, дубли и ошибки на одном сайте, добавление второго будет делом нескольких дней.

Вывод

Парсер объявлений о недвижимости — это не просто сборщик ссылок, а полноценная система для сокращения рутины и получения более честной картины рынка. Если сразу заложить нормальную архитектуру, аккуратную нормализацию, дедупликацию и историю изменений, личный проект быстро вырастет из «скрипта для себя» в полезный инструмент для поиска, аналитики и автоматизации. Именно так у меня и произошло: начав с простого парсера для собственного поиска жилья, я пришёл к платформе, которая помогает людям принимать взвешенные решения о недвижимости — и это оказалось не менее увлекательно, чем разработка игр.