Парсинг сайтов со сложной структурой

“Сложная структура” — это не про красивый дизайн и не про количество страниц. На практике это означает: много типов страниц, вариативность, бесконечная подгрузка, фильтры с комбинаторным взрывом, региональность, “пустой HTML” и частые изменения. Такой сайт нельзя стабильно собрать “одним скриптом”. Нужна система: стратегия → обход → качество → поддержка.

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

Признаки сложной структуры (что действительно усложняет сбор)

1. Много шаблонов страниц: каталог, карточка, статья, акция, поиск, бренды, теги.
2. Вложенные категории (3–6 уровней) и нет единого каталога.
3. Фильтры дают тысячи комбинаций (комбинаторный взрыв).
4. Бесконечная прокрутка и динамическая подгрузка (SPA).
5. Вариации объектов: цвет/размер/комплектация, разные цены и наличие.
6. Гео влияет на цену/наличие/доставку (разные витрины).
7. “Пустой HTML”: контент приходит из API в виде JSON.
8. Частые обновления верстки и структуры данных.
9. Мультиязычность или мультивитрина (разные домены/поддомены).
10. Канонические URL, дубль-страницы, параметры, редиректы.
11. Контент меняется внутри дня (цены, наличие, статусы).
12. Разные режимы доступа (гость/авторизованный) — при этом закрытые зоны без официального доступа не рассматриваем.

Аудит источника: с чего начать

Перед тем как писать код, сделайте короткий аудит. Это экономит больше всего времени и денег.

1. Цель и поля: что именно нужно бизнесу (и что точно не нужно).
2. Карта страниц: какие типы страниц существуют, где находятся данные.
3. Доступные каналы: есть ли официальный API, sitemap, RSS, выгрузки.
4. Ограничения частоты (rate limit): насколько “чувствителен” источник к нагрузке.
5. Идентификаторы объектов: есть ли стабильный ID (SKU/article/news_id).
6. Дубли: откуда берутся, есть ли каноникал, параметры, зеркала.
7. Поддерживаемость: как часто меняется структура, есть ли признаки “быстрого дрейфа”.

Результат аудита — не “технический отчет на 50 страниц”, а понятная стратегия: что собирать, откуда, как обходить и как проверять качество.

Стратегии получения данных (от лучших к тяжелым)

Сложный сайт почти всегда требует выбора стратегии. Ниже — типовая иерархия.

1) Официальный API / выгрузка

Когда выбирать: есть доступ, покрывает нужные поля.
Плюсы: стабильность, меньше поломок, дешевле поддержка.
Минусы: не всегда доступен или не дает нужные поля.

2) sitemap / RSS

Когда выбирать: нужно полное покрытие URL или новостной поток.
Плюсы: отличный “реестр” страниц, удобен для инкремента.
Минусы: мало данных — всё равно придется извлекать поля со страниц/запросов.

3) JSON-запросы (данные приходят из API сайта)

Когда выбирать: SPA/пустой HTML, данные грузятся отдельными запросами.
Плюсы: меньше зависимости от верстки, быстрее и дешевле, чем рендер.
Минусы: схемы запросов меняются при релизах фронтенда — нужен мониторинг качества.

4) HTML-парсинг (SSR)

Когда выбирать: контент уже в HTML, структура относительно стабильна.
Плюсы: проще в реализации, если страницы “классические”.
Минусы: ломается при изменениях шаблонов, часто требует много правил.

5) headless browser (точечно)

Когда выбирать: без рендера контент не получить.
Плюсы: “видит” страницу как пользователь.
Минусы: дорого, медленно, больше нестабильности; лучше использовать точечно, а не на весь обход.

Практическое правило: headless browser — крайний инструмент, а не стандарт.

Проектирование обхода: краулер и “границы”

Сложность чаще всего не в извлечении полей, а в обходе.

Как не утонуть в фильтрах

Фильтры часто дают бесконечное число страниц. Поэтому:

• обходите категории и листинги, а фильтры используйте только по бизнес-необходимости;
• фиксируйте “разрешенный набор” комбинаций (например, топ-бренды/топ-атрибуты), а не всё подряд;
• избегайте перебора сортировок и пагинаций “в лоб”.

Инкремент вместо полного обхода

Сложный сайт почти всегда требует инкремента:

• что новое;
• что изменилось;
• что пропало.

Это снижает нагрузку и стоимость.

Очереди и приоритеты

Сделайте приоритеты:

• важные категории и хиты — чаще;
• хвост — реже;
• “маяки” — для контроля, что источник не сломался.

Ограничения нагрузки

Даже без обсуждения “обходов” базовая этика и устойчивость требуют:

• лимитов скорости;
• пауз и “умного повторения”;
• остановки при росте ошибок.

Dedup URL и каноникал

Сложные сайты часто имеют:

• параметры в URL,
• зеркала страниц,
• редиректы.

Без dedup вы будете собирать одну сущность много раз и “портить” статистику.

Нормализация и качество данных

Схема данных и версии

Нужна четкая схема: типы, обязательные поля, справочники. При изменениях — новая версия схемы.

Raw и clean слои

• raw: сохраняем исходный HTML/JSON (для аудита и восстановления);
• clean: нормализованные поля в таблицах/JSON.

Quality gates

Минимальные проверки, которые стоит автоматизировать:

• доля пустых полей (coverage);
• выбросы в числах (цена, вес, рейтинг);
• доля дублей;
• резкие изменения распределений (drift);
• рост ошибок/таймаутов.

Если этих ворот нет, сбор ломается “тихо”, и вы узнаете об этом из отчета через неделю.

Таблица №1: сложность → что усложняет → как решают

Сложность	Что усложняет	Как решают
Фильтры	комбинаторный взрыв	фиксировать разрешенные комбинации, обходить категории
Вариации	один объект = много вариантов	модель “родитель-вариант”, отдельные ключи
Гео	разные цены/наличие	фиксировать регион/контекст как часть измерения
SPA	“пустой HTML”	искать источники данных в JSON/API
Мультиязычность	разные витрины	отдельные контуры по языкам/доменам
Дубли URL	параметры, зеркала	canonical, dedup, нормализация URL
Частые релизы	структура меняется	мониторинг качества + быстрые фиксы
Бесконечная прокрутка	нет явной пагинации	stop-условия, стабильные маркеры, инкремент
Нестабильные селекторы	DOM меняется	уменьшать зависимость от DOM, использовать данные слоя
Большой объем	дорого обходить всё	инкремент, приоритеты, “маяки”

 

Таблица №2: симптом → причина → решение

Симптом	Причина	Решение
В HTML нет данных	SPA	переход на JSON/API слой
Появились дубли	параметры/каноникал	нормализация URL + дедуп
Сломалось после релиза	изменилась схема/шаблон	алерт на качество + обновление правил
Пропали страницы	изменилась карта сайта	пересобрать карту из sitemap/категорий
Резко выросли пустые поля	дрейф источника	quality gates + остановка авто-процесса
Сбор стал дорогим	headless везде	сократить headless, оставить точечно
Не хватает покрытия	обход неполный	аудит карты страниц, добавить источники URL
Скачет цена/наличие	гео/контекст	фиксировать контекст измерения
Ошибки на “поиске”	дорогие эндпоинты	ограничить/исключить поиск и фильтры
Падает качество matching	разные идентификаторы	использовать стабильные ID/справочники

 

Пайплайн решения

Сбор → Валидация → Нормализация → История → Выгрузка/BI → Алерты → Поддержка

• История нужна почти всегда: иначе вы не видите динамику и не отличаете шум от тренда.
• Алерты нужны не только бизнесу, но и системе: “качество упало”, “поля пустые”, “схема изменилась”.

Как оценивать сроки и стоимость

Стоимость сложного сайта растет не линейно, а скачками. Обычно влияют:

• количество типов страниц и полей;
• необходимость обхода фильтров/вариаций;
• гео-контекст;
• частота обновления и требования к истории;
• требования к качеству (валидация, SLA, алерты);
• необходимость поддержки изменений.

Практический способ снизить риск — сделать MVP:

• 1–2 категории,
• один тип карточки,
• минимальный набор полей,
• история и quality gates.

После MVP масштабирование становится управляемым.

Пошаговый план внедрения

1. Цель и список полей (минимизация).
2. Аудит источника (карта страниц, каналы, ограничения).
3. MVP-обход и первый датасет.
4. Схема данных, raw/clean, версии.
5. Quality gates и мониторинг дрейфа.
6. Масштабирование: категории, варианты, регионы, частоты.
7. Поддержка: регламент обновлений и контроль качества.

Чек-лист перед стартом

• цель и поля зафиксированы;
• есть карта типов страниц;
• выбран канал данных (API/sitemap/JSON/HTML/headless);
• определены границы обхода (без комбинаторного взрыва);
• есть стратегия инкремента;
• настроены dedup и canonical;
• схема данных описана и версионируется;
• есть raw и clean слои;
• quality gates настроены (пустые поля, выбросы, дубли);
• определены частота и история;
• есть алерты на поломки и регламент поддержки.

Как может помочь ParsingMaster

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

Пришлите 5–10 URL разных типов страниц и список полей — предложим подход и оценку.