Постачальник не надав фід чи API. Каталог потрібно наповнити тисячами позицій, а HTML-сторінки — єдине джерело. Типова ситуація: замовник хоче перенести товари з сайту конкурента або постачальника в 1С-Бітрікс. Без автоматичного парсингу не обійтись — ручне введення 10 000 позицій займе тижні. Ми накопичили досвід на 100+ проєктах: від простих статичних сторінок до динамічних SPA із захистом від ботів. Маємо 5 років досвіду парсингу та понад 100 реалізованих проектів. Гарантуємо стабільну роботу парсера та повну документацію, щоб ви могли підтримувати його силами свого штату.
Наш сервіс пропонує парсинг товарів, наповнення каталогу, імпорт товарів в 1С-Бітрікс, автоматичний імпорт, синхронізацію каталогу, бітрікс інтеграцію парсингу, парсинг з зовнішнього сайту, а також роботу з інфоблоком Бітрікс та XML_ID Бітрікс.
Парсинг — це не просто скачування 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 — це дозволяє при повторному парсингу не створювати дублі, а оновлювати існуючі розділи.
Алгоритм:
- Отримати список категорій з джерела (sitemap.xml або рекурсивний обхід навігації)
- Побудувати граф залежностей parent→child
- Створювати розділи від кореня вниз, записуючи map
source_id → bitrix_section_id - Зберігати маппінг в окремій таблиці або файлі для наступних запусків
Парсинг товарних карток
Після побудови структури — обхід товарних сторінок. Кожен товар створюється через 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 тижнів ручної праці. Автоматичний парсинг скорочує час наповнення каталогу у 8 разів порівняно з ручним введенням. Економія порівняно з ручним введенням — понад $900–1.3k.
Що входить в роботу
| Deliverable | Опис |
|---|---|
| Аналіз джерела | Визначення структури, захисту, об'єму |
| Проєктування інфоблоку | Створення розділів, властивостей, HL-блоків |
| Розробка парсера | PHP-скрипти з урахуванням пагінації та захисту |
| Обробка зображень | Скачування, оптимізація, прив'язка |
| Тестовий прогін | Перевірка на 10% даних, виправлення помилок |
| Документація | Опис архітектури, інструкція з запуску |
| Підтримка | 1 місяць гарантії на стабільну роботу |
Таймлайн робіт
| Етап | Строк |
|---|---|
| Аналіз структури джерела, проєктування інфоблоку | 4–8 годин |
| Парсер категорій + синхронізація розділів | 1 день |
| Парсер товарних карток (текст, властивості) | 2–3 дні |
| Обробка зображень | 4–8 годин |
| Налагодження, обробка помилок, логування | 1 день |
| Тестовий прогін на реальному об'ємі | 1 день |
Разом: 6–10 робочих днів залежно від складності джерела та об'єму даних. Вартість розраховується індивідуально після аналізу. Орієнтовна вартість базового проекту — від 15 000 грн. Отримайте консультацію — оцінимо проєкт. Зв'яжіться з нами, щоб обговорити вашу задачу. Замовте розробку парсера — зекономте час та бюджет.
Поширені запитання
Скільки часу займає парсинг каталогу?
Залежить від об'єму та складності джерела. Для 10 000 товарів з одного рівня категорій — 6–8 робочих днів. Якщо потрібна обробка зображень і складні характеристики, строк може зрости до 12 днів. Ми завжди даємо точну оцінку після аналізу.
Які дані можна спарсити?
Будь-які: назви, описи, ціни, характеристики, зображення, файли, відео. Якщо дані приховані за JS або вимагають авторизації, використовуємо headless браузер. Головне — щоб структура була стабільною.
Як уникнути дублів при повторному парсингу?
Використовуємо XML_ID — унікальний ідентифікатор з боку джерела. При повторному запуску парсер оновлює існуючі елементи, а не створює нові. Мапінг зберігаємо в окремій таблиці.
Що робити, якщо сайт-джерело змінює структуру?
Ми проєктуємо парсер з урахуванням можливих змін: використовуємо селектори з fallback, логуємо помилки, налаштовуємо сповіщення про збої. При зміні структури достатньо скоригувати XPath або CSS-селектори — код парсера не переписується повністю.
Чи потрібен свій сервер для парсингу?
Для середніх об'ємів (до 10 000 товарів) достатньо звичайного хостингу з PHP 8.1 та cron. Для великих каталогів краще виділений сервер або хмара — щоб не блокувати роботу сайту.
