Парсинг статей та контенту для автонаповнення 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