Парсинг каталога товаров для 1С-Битрикс: автоматизация наполнения

Поставщик не дал фид или API. Каталог нужно наполнить тысячами позиций, а HTML-страницы — единственный источник. Типичная ситуация: заказчик хочет перенести товары с сайта конкурента или поставщика в 1С-Битрикс. Без автоматического парсинга не обойтись — ручной ввод 10 000 позиций займёт недели. Мы накопили опыт на 100+ проектах: от простых статических страниц до динамических SPA с защитой от ботов. Гарантируем стабильную работу парсера и полную документацию, чтобы вы могли поддерживать его силами своего штата.

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

Проектирование инфоблока под парсинг

Перед запуском парсера критично спроектировать инфоблок. Типичные ошибки: хранить все характеристики в одном текстовом поле, не привязывать товары к разделам, игнорировать XML_ID. Правильная схема:

• Разделы инфоблока (b_iblock_section) — воспроизводят структуру категорий источника
• XML_ID элемента — уникальный идентификатор со стороны источника (URL или внутренний ID)
• Свойства — под каждую группу характеристик своё свойство или Highload-блок для вариативных атрибутов
• Торговые предложения (CATALOG_TYPE = 3) — если источник имеет вариации товара

Важность сохранения XML_ID

XML_ID — единый идентификатор элемента для внешних систем (документация 1С-Битрикс). Без XML_ID каждый повторный парсинг создаёт дубликаты. Платформа использует XML_ID как внешний ключ для обновления элементов. Если источник меняет URL или ID, обновляем маппинг вручную. Мы храним историю всех XML_ID в отдельной таблице parser_progress — это позволяет откатить изменения и не терять данные.

Настройка парсинга категорий

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

Алгоритм:

1. Получить список категорий с источника (sitemap.xml или рекурсивный обход навигации)
2. Построить граф зависимостей parent→child
3. Создавать разделы от корня вниз, записывая map source_id → bitrix_section_id
4. Сохранять маппинг в отдельной таблице или файле для следующих запусков

Парсинг товарных карточек

После построения структуры — обход товарных страниц. Каждый товар создаётся через CIBlockElement::Add() или обновляется через CIBlockElement::Update() при совпадении XML_ID.

Обязательные поля при создании элемента:

IBLOCK_ID, NAME, XML_ID, CODE (ЧПУ), ACTIVE, IBLOCK_SECTION_ID, DETAIL_TEXT, PREVIEW_TEXT, PROPERTY_VALUES (массив свойств) 

Генерация CODE — частая точка ошибок. Используйте CUtil::translit() с флагом замены конфликтующих символов. Добавляйте суффикс из XML_ID если транслит даёт дубли.

Обход защиты при парсинге каталога

Большинство каталогов пагинированы по 20–100 товаров на страницу. Парсер должен:

• Определять общее число страниц (из тега пагинации или заголовка X-Total-Count)
• Сохранять прогресс в файл или БД — чтобы при падении продолжить с нужной страницы
• Соблюдать задержки между запросами (1–3 сек)

Для JS-рендеренных каталогов (фильтрация через AJAX) — headless Chrome через Puppeteer. Иногда проще найти XHR-запрос к API каталога в Network DevTools и обращаться к нему напрямую. Puppeteer обрабатывает динамический контент в 5 раз быстрее, чем Simple HTML DOM с имитацией браузера.

Типичная ошибка — не учитывать защиту от ботов. Многие сайты используют Cloudflare или капчу. Парсер должен имитировать поведение реального пользователя: задержки, случайные User-Agent, пул прокси. В особо сложных случаях подключаем сервисы распознавания капчи.

Кейс из нашей практики: наполнение каталога стройматериалов

Задача: перенести 18 000 SKU с сайта производителя (статический HTML, 2 уровня категорий, таблицы характеристик). Наш клиент хотел избежать ручного ввода.

Реализация:

• PHP + Symfony DomCrawler для парсинга HTML
• PostgreSQL-таблица parser_progress для хранения состояния
• Батчевая запись по 50 элементов, пауза 500 мс между батчами
• Изображения: скачивание через \Bitrix\Main\IO\File, привязка через CFile::SaveFile()
• Общее время парсинга 18 000 товаров: ~14 часов в фоне

Результат: каталог наполнен за 2 рабочих дня вместо 3–4 недель ручного труда. Экономия по сравнению с ручным вводом — более $900–1.3k.

Что входит в работу

Таймлайн работ

Итого: 6–10 рабочих дней в зависимости от сложности источника и объёма данных. Стоимость рассчитывается индивидуально после анализа. Получите консультацию — изучим задачу и подготовим оценку. Свяжитесь с нами, чтобы обсудить вашу задачу. Закажите разработку парсера — сэкономьте время и бюджет.