Парсинг даних з Яндекс.Маркет для 1С-Бітрікс

Наповнення каталогу 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 блокується за годину.

Як мапувати дані в інфоблок?

Структура Маркета не збігається з інфоблоком. Потрібен шар трансформації:

Характеристики Маркета — плоский список, а властивості інфоблока типізовані. Потрібна таблиця мапінгу: «Вага, г» → PROPERTY_WEIGHT (число), «Колір» → PROPERTY_COLOR (список).

Важливість проміжного шару

Завантаження повинно проходити через проміжне сховище (окрема таблиця або JSON-файли). Скрипт імпорту через API інфоблоків:

CIBlockElement::Add($arFields);
CIBlockElement::SetPropertyValuesEx($elementId, $iblockId, $propertyValues);

Прямий імпорт з парсера небезпечний: якщо парсер зламався на середині — в каталозі залишаться частково заповнені картки. Для каталогів понад 5 000 товарів використовуйте \Bitrix\Iblock\ElementTable::add() — D7 API швидше та підтримує батчеві операції.

Покроковий план реалізації

1. Аналіз цільових сторінок: визначення структури даних та токенів.
2. Розробка парсера: вибір підходу (headless + перехоплення), налаштування проксі та капчі.
3. Створення проміжного сховища та скрипта мапінгу.
4. Імпорт в інфоблоки 1С-Бітрікс з дедуплікацією.
5. Налаштування інкрементального оновлення за розкладом.

Кейс з практики: автоматизація наповнення каталогу на 2000 товарів

На одному з проєктів клієнт мав каталог сантехніки на 2000 позицій. Раніше менеджери вручну копіювали дані з Яндекс.Маркета, витрачаючи до 3 тижнів на місяць. Ми реалізували парсер з комбінованим підходом: headless для нових моделей і прямі API-запити для оновлення існуючих. Час наповнення скоротився до 2 днів при повному реімпорті та до 4 годин при інкрементальному оновленні. Мапінг характеристик автоматизовано через динамічну таблицю відповідностей.

Підтримання актуальності

Для каталогів до 1 000 товарів підходить повний реімпорт раз на тиждень (2–4 год). Для 1 000–10 000 — інкрементальний обхід щоденно (4–8 год). Для понад 10 000 — комбінація інкрементального та тригерного оновлення.

Що входить в роботу

При замовленні парсингу Яндекс.Маркета для 1С-Бітрікс ми надаємо:

• Розробку парсера з ротацією проксі, обробкою капчі та захистом від блокувань.
• Створення таблиці мапінгу характеристик.
• Скрипти первинного імпорту та інкрементального оновлення.
• Документацію, доступи, навчання співробітників.
• Підтримку на етапі запуску.

Наш досвід

Ми працюємо на ринку веб-розробки понад 7 років, реалізували понад 30 проєктів парсингу для 1С-Бітрікс та маємо сертифікацію 1С-Бітрікс (рівень «Сайти бізнесу»).

Парсинг порушує користувацьку угоду Яндекса. На практиці претензії рідкісні, але використовувати описи та фото «як є» ризиковано. Рекомендуємо рерайт описів та перевірку ліцензій зображень.

Замовлення парсингу

Якщо вам потрібне стабільне рішення для наповнення каталогу Бітрікс даними з Яндекс.Маркета — зв'яжіться з нами. Оцінимо проєкт, підберемо стратегію, запропонуємо терміни (від 2 до 6 тижнів залежно від обсягу). Вартість розраховується індивідуально. Ми реалізували понад 30 таких інтеграцій. Отримайте консультацію — обговоримо деталі.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.