Парсинг статей та контенту для автонаповнення 1С-Бітрікс

Парсинг статей та контенту для автонаповнення 1С-Бітрікс

Уявіть: редактор вручну копіює статті із зовнішніх джерел. На одну публікацію йде 4 години — аналіз структури, очищення форматування, завантаження зображень, SEO-узгодження. При обсязі 500 статей це 2000 людино-годин. Ми автоматизуємо цей процес: гібридний парсинг на основі Readability та кастомних CSS-селекторів скорочує час до 10 хвилин на статтю з точністю 95%+. Наша команда має 10+ років досвіду розробки на 1С-Бітрікс та понад 500 проєктів з автоматизації контенту. Економія ресурсів очевидна: замість місяців роботи — кілька годин на налаштування парсера. Замовте попередній аналіз ваших джерел — ми оцінимо складність і терміни.

Чому парсинг статей складніший за парсинг новин?

Новинний парсер працює з RSS-фідами — структурованими, передбачуваними даними. Парсинг статей — це робота з довільними HTML-сторінками, де кожен сайт-джерело має свою верстку, структуру навігації та спосіб представлення контенту. Розберемо ключові відмінності, які роблять парсинг статей нетривіальним завданням:

• Немає єдиного формату — кожне джерело потребує індивідуального парсера або універсального екстрактора.
• Складна структура контенту — стаття містить заголовки, списки, таблиці, вбудовані медіа, блоки коду. Все це потрібно зберегти.
• Обсяг тексту — стаття у 5 000–10 000 символів проти 500-символьної новини. Більше даних — більше точок відмови.
• Частота оновлення — статті публікуються рідше новин, але кожна одиниця контенту цінніша.

Які проблеми вирішує гібридний парсинг?

Гібридний підхід об'єднує алгоритмічний екстрактор (Mozilla Readability) та кастомні CSS-селектори для сайтів, де автоматика помиляється. Бібліотека andreskrey/readability.php (порт Readability на PHP) аналізує щільність тексту та виділяє основний вміст за 2 секунди. Для джерел, де Readability втрачає таблиці або списки, ми додаємо селектори-винятки. Результат: точність 95%+ на 10+ джерелах.

Порівняємо підходи: чистий Readability зберігає 80% структури, але втрачає 30% таблиць і 15% списків. Ручні селектори дають 99% точності, але потребують 15 хвилин налаштування на джерело. Гібридний метод дає 95% точності при 0,5 хвилини на джерело — у 30 разів швидше за селектори та у 2 рази точніше за чистий Readability для таблиць.

Як зберегти структуру та форматування при вилученні?

Після вилучення HTML потрібно привести його до формату, придатного для зберігання в DETAIL_TEXT інфоблоку Бітрікс. Використовуємо HTMLPurifier з кастомною конфігурацією, що дозволяє теги h2–h4, p, ul, ol, li, table, img, a, strong, em, blockquote, pre, code. Етапи очищення:

• видалення script, style, iframe, inline-стилів, data-атрибутів;
• нормалізація заголовків: вихідний h1 статті стає h2 у контексті сторінки Бітрікс;
• локалізація зображень: завантаження зовнішніх картинок у /upload/, заміна URL у HTML;
• врахування лінивого завантаження (data-src замість src).

Підсумковий HTML проходить перевірку на валідність та відповідність схемі інфоблоку.

Вилучення контенту: три підходи

Readability на PHP справляється за 2 секунди проти 15 хвилин на ручне написання селектора для кожного джерела — виграш у 450 разів на 10 джерелах. На практиці гібридний підхід — єдиний, який працює для 10+ джерел. Чиста автоматика втрачає важливі блоки (таблиці, списки), чисті селектори не масштабуються.

Покроковий процес парсингу статей

1. Збір URL. Парсер обходить сторінки-списки (пагінація, категорії, sitemap.xml) та збирає URL статей. Зберігає в чергу — таблицю parser_queue з полями url, status, created_at.
2. Завантаження та вилучення. Для кожного URL з черги: завантаження HTML, вилучення контенту, парсинг метаданих. Результат — структурований масив, що зберігається у проміжну таблицю parser_articles.
3. Модерація (опціонально). Адміністратор переглядає спарсені статті в інтерфейсі, схвалює або відхиляє. Для повної автоматизації цей крок замінюється фільтрацією за правилами.
4. Імпорт. Схвалені статті завантажуються в інфоблок через CIBlockElement::Add(). Зображення зберігаються через CFile::MakeFileArray().

Маппінг в інфоблок

Як захистити парсер від блокування?

Контентні сайти захищаються слабше, ніж маркетплейси, але базові заходи присутні:

• robots.txt — перевіряємо Disallow для сторінок, що парсяться. Ігнорування robots.txt — додатковий юридичний ризик.
• Rate limiting — 1–2 запити в секунду безпечні для більшості сайтів. Агресивний парсинг (10+ rps) призведе до блокування.
• JavaScript-рендеринг — SPA-сайти потребують headless-браузера. Для статичних сайтів достатньо cURL.
• Cloudflare / WAF — визначають ботів за fingerprint. Вирішується через headless-браузер із реалістичними заголовками.

Автоматизація в cron

# Збір нових URL з джерел — раз на добу
0 2 * * * php /home/bitrix/parsers/collect_urls.php

# Парсинг статей з черги — кожні 2 години
0 */2 * * * php /home/bitrix/parsers/parse_articles.php --limit=50

# Імпорт в інфоблок — щогодини
0 * * * * php /home/bitrix/parsers/import_articles.php

Розділення на три задачі дозволяє контролювати кожен етап незалежно та швидко локалізувати проблему при збої.

Що входить у роботу під ключ

• Аналіз джерел. Визначаємо 5–15 сайтів-донорів, розбираємо DOM, виявляємо особливості верстки.
• Розробка парсерів. Гібридні модулі на PHP (Readability + кастомні селектори).
• Маппінг та імпорт. Налаштування інфоблоків, властивостей, дедуплікації.
• Тестування. Перевірка на 50+ реальних статтях, коригування.
• Документація. Опис архітектури, інструкція з додавання нового джерела.
• Підтримка. Гарантія 3 місяці: виправляємо баги, адаптуємо під зміни верстки.

Оцінимо ваш проєкт — просто напишіть. Отримайте консультацію інженера Бітрікс з 10-річним досвідом. Орієнтовні терміни: від 3 днів для 5 джерел до 2 тижнів для 15+. Наша команда сертифікована за платформою 1С-Бітрікс. Гарантуємо стабільність рішення навіть при редизайнах сайтів-донорів.

З чого почати розробку парсера для 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-селектори в парсері.

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