Наповнення каталогу 1С-Бітрікс товарами з Яндекс.Маркет — типова задача для інтернет-магазинів. Проблема в тому, що у Маркета немає публічного API для масового вивантаження карток. Партнерський Content API дає доступ лише продавцям до власних даних. Для стороннього інтегратора єдиний шлях — парсинг, але з серйозними технічними обмеженнями: JavaScript-рендеринг, капча, блокування по IP та fingerprinting. Плюс правові ризики, оскільки це порушує користувацьку угоду. Згідно з Wikipedia, веб-скрейпінг може порушувати умови використання. Наша команда (понад 7 років у розробці на Бітрікс та інтеграціях) реалізувала понад 30 подібних проєктів — від простих каталогів до великих маркетплейсів. Ми маємо сертифікацію 1С-Бітрікс та гарантуємо стабільну роботу парсера. У цій статті описуємо перевірений підхід, який дозволяє стабільно збирати дані та імпортувати їх в інфоблоки з мінімальними ризиками.
Дані, які парсяться
Картка товару на Яндекс.Маркеті містить назву, опис, характеристики (пари «ключ-значення»), динамічні ціни продавців, зображення (1–15 фото), відгуки, рейтинг та категорію. Для каталогу 1С-Бітрікс найчастіше потрібні назва, опис, характеристики та зображення — ціни парсити немає сенсу через високу мінливість.
Який підхід до парсингу найефективніший?
Яндекс.Маркет — односторінковий додаток. Дані підвантажуються через внутрішні API та рендеряться на клієнті. Простий HTTP-запит поверне порожню оболонку. Застосовуємо два підходи:
- Headless-браузер (Puppeteer, Playwright) — повільно (3–5 сек на сторінку), але надійно.
- Перехоплення внутрішніх API — у 10–20 разів швидше, але формат відповіді може змінюватися.
Комбінація: headless для первинного аналізу та отримання токенів, потім прямі запити для масового вивантаження. За нашими оцінками, комбінований підхід краще чистого headless у 3-5 разів за швидкістю для каталогів понад 5000 товарів.
Обхід захисту Яндекс.Маркета
Яндекс блокує автоматичні запити за допомогою SmartCaptcha, fingerprinting та rate limiting. Для стабільного парсингу обов'язково використовувати ротацію резидентних проксі, рандомізацію затримок (2–10 сек), ротацію User-Agent та обробку капчі. Без ротації проксі один IP блокується за годину.
Як мапувати дані в інфоблок?
Структура Маркета не збігається з інфоблоком. Потрібен шар трансформації:
Таблиця мапінгу
| Яндекс.Маркет | Інфоблок Бітрікс | Примітка |
|---|---|---|
title |
NAME |
Обрізання до 255 символів |
description |
DETAIL_TEXT |
HTML → очищення тегів або збереження |
specs[] |
PROPERTY_* |
Мапінг за назвою характеристики |
images[] |
DETAIL_PICTURE + MORE_PHOTO |
Завантаження та збереження локально |
categoryPath |
IBLOCK_SECTION_ID |
Мапінг через таблицю відповідностей |
modelId |
XML_ID |
Унікальний ідентифікатор для дедуплікації |
Характеристики Маркета — плоский список, а властивості інфоблока типізовані. Потрібна таблиця мапінгу: «Вага, г» → PROPERTY_WEIGHT (число), «Колір» → PROPERTY_COLOR (список).
Важливість проміжного шару
Завантаження повинно проходити через проміжне сховище (окрема таблиця або JSON-файли). Скрипт імпорту через API інфоблоків:
CIBlockElement::Add($arFields); CIBlockElement::SetPropertyValuesEx($elementId, $iblockId, $propertyValues); Прямий імпорт з парсера небезпечний: якщо парсер зламався на середині — в каталозі залишаться частково заповнені картки. Для каталогів понад 5 000 товарів використовуйте \Bitrix\Iblock\ElementTable::add() — D7 API швидше та підтримує батчеві операції.
Покроковий план реалізації
- Аналіз цільових сторінок: визначення структури даних та токенів.
- Розробка парсера: вибір підходу (headless + перехоплення), налаштування проксі та капчі.
- Створення проміжного сховища та скрипта мапінгу.
- Імпорт в інфоблоки 1С-Бітрікс з дедуплікацією.
- Налаштування інкрементального оновлення за розкладом.
Кейс з практики: автоматизація наповнення каталогу на 2000 товарів
На одному з проєктів клієнт мав каталог сантехніки на 2000 позицій. Раніше менеджери вручну копіювали дані з Яндекс.Маркета, витрачаючи до 3 тижнів на місяць. Ми реалізували парсер з комбінованим підходом: headless для нових моделей і прямі API-запити для оновлення існуючих. Час наповнення скоротився до 2 днів при повному реімпорті та до 4 годин при інкрементальному оновленні. Мапінг характеристик автоматизовано через динамічну таблицю відповідностей.
Підтримання актуальності
Для каталогів до 1 000 товарів підходить повний реімпорт раз на тиждень (2–4 год). Для 1 000–10 000 — інкрементальний обхід щоденно (4–8 год). Для понад 10 000 — комбінація інкрементального та тригерного оновлення.
Таблиця стратегій оновлення
| Розмір каталогу | Стратегія | Частота | Час |
|---|---|---|---|
| до 1 000 | Повний реімпорт | Щотижня | 2–4 год |
| 1 000–10 000 | Інкрементальний | Щоденно | 4–8 год |
| понад 10 000 | Інкрементальний + тригер | За розкладом | 8–24 год |
Що входить в роботу
При замовленні парсингу Яндекс.Маркета для 1С-Бітрікс ми надаємо:
- Розробку парсера з ротацією проксі, обробкою капчі та захистом від блокувань.
- Створення таблиці мапінгу характеристик.
- Скрипти первинного імпорту та інкрементального оновлення.
- Документацію, доступи, навчання співробітників.
- Підтримку на етапі запуску.
Наш досвід
Ми працюємо на ринку веб-розробки понад 7 років, реалізували понад 30 проєктів парсингу для 1С-Бітрікс та маємо сертифікацію 1С-Бітрікс (рівень «Сайти бізнесу»).
Парсинг порушує користувацьку угоду Яндекса. На практиці претензії рідкісні, але використовувати описи та фото «як є» ризиковано. Рекомендуємо рерайт описів та перевірку ліцензій зображень.
Замовлення парсингу
Якщо вам потрібне стабільне рішення для наповнення каталогу Бітрікс даними з Яндекс.Маркета — зв'яжіться з нами. Оцінимо проєкт, підберемо стратегію, запропонуємо терміни (від 2 до 6 тижнів залежно від обсягу). Вартість розраховується індивідуально. Ми реалізували понад 30 таких інтеграцій. Отримайте консультацію — обговоримо деталі.