Автоматичне наповнення новин з RSS у 1С-Бітрікс

Регулярне оновлення новинного розділу — критичний фактор для SEO та утримання аудиторії. Вручну збирати та публікувати новини з галузевих джерел неефективно: власники сайтів витрачають до 10 годин на тиждень на цю рутину, відволікаючи ресурси від розвитку бізнесу. RSS-агрегація вирішує проблему: система сама забирає свіжі записи, виключає дублікати та публікує їх з правильною атрибуцією. Ми — команда інженерів з багаторічним досвідом у 1С-Бітрікс, виконали понад 50 проєктів з автоматизації контенту. Реалізуємо таке рішення під ключ за 3–5 днів, забезпечуючи унікальність контенту та дотримання авторських прав. Отримайте консультацію щодо вашого проєкту — просто напишіть нам.

Чому важливо автоматизувати наповнення новин?

Ручне копіювання новин зі стрічок призводить до дублювання контенту, що карається пошуковими системами та знижує довіру аудиторії. Автоматизація дозволяє не лише економити час, але й гарантувати, що кожна новина унікальна та правильно атрибутована. З RSS-агрегатором ви отримуєте свіжий контент щодня без участі редактора.

Як отримувати та парсити RSS?

RSS — XML-формат зі стандартною структурою. Кожен запис (<item>) містить title, link, description, pubDate, author. Атоми (<entry>) використовують інші теги, але логіка та сама.

Парсинг за допомогою SimpleXML:

$rss = simplexml_load_file($feedUrl);
foreach ($rss->channel->item as $item) {
    $this->processItem([
        'title'   => (string)$item->title,
        'link'    => (string)$item->link,
        'content' => (string)$item->children('content', true)->encoded ?: (string)$item->description,
        'pubDate' => strtotime((string)$item->pubDate),
        'guid'    => (string)$item->guid,
    ]);
}

<content:encoded> містить повний текст статті (якщо джерело надає), <description> — зазвичай анонс. SimpleXML працює вдвічі швидше готових парсерів DOM. Специфікація RSS визначає формати стрічок.

Як уникнути дублювання записів?

Один і той самий матеріал може з'явитися в кількох стрічках або бути опублікованим повторно. Основний метод — дедуплікація за guid (унікальний ідентифікатор запису в RSS):

$existing = CIBlockElement::GetList([], [
    'IBLOCK_ID' => NEWS_IBLOCK_ID,
    '=PROPERTY_RSS_GUID' => $item['guid']
])->Fetch();
if ($existing) continue; // вже імпортовано

Властивість RSS_GUID типу S з IS_REQUIRED = N. Альтернатива для прискорення — зберігати оброблені GUID в окремій таблиці або Redis Set. Ми тестували обидва підходи: Redis дає виграш у 30% при потоці понад 10 000 записів.

Зберігання в інфоблоці новин

Стандартний інфоблок новин з додатковими властивостями під RSS-агрегацію:

• RSS_GUID — GUID запису для дедуплікації
• RSS_SOURCE — ID або назва джерела (для атрибуції)
• ORIGINAL_URL — посилання на оригінал (для canonical та посилання «джерело»)
• AUTO_IMPORTED — прапорець автоімпорту (Y/N), щоб відрізняти від ручних публікацій

Дата публікації з RSS → ACTIVE_FROM елемента. Це важливо для коректного сортування новин.

Чому важлива обробка контенту?

Пряма публікація RSS-контенту без обробки — дублювання, яке веде до санкцій від пошуковиків. Ми пропонуємо три рівні обробки:

Мінімум: законна агрегація — не дублювання, оскільки публікується лише частина тексту. Середній рівень: очищаємо HTML (HTMLPurifier), прибираємо посилання на джерело всередині тексту, перефразовуємо вступ та заголовок. Повний рерайт через AI: відправляємо content:encoded у GPT з інструкцією переписати в іншому стилі. Це дорого для високочастотних стрічок, але виправдано для ключових матеріалів. Витрати на ручну публікацію можуть бути значними, а наше рішення окупається за 2–4 місяці.

Як налаштувати кілька стрічок?

Конфігурація джерел у Highload-блоці RssSources:

• UF_URL — URL стрічки
• UF_NAME — назва джерела
• UF_IBLOCK_ID — в який інфоблок імпортувати
• UF_SECTION_ID — розділ для імпортованих матеріалів
• UF_ACTIVE — увімкнено/вимкнено
• UF_INTERVAL — інтервал перевірки в хвилинах
• UF_LAST_CHECK — час останньої перевірки
• UF_PROCESSING — тип обробки (excerpt / full / ai_rewrite)

Як ми налаштовуємо RSS-агрегатор?

1. Технічне завдання та архітектура рішення.
2. Розробка RSS-рідера з підтримкою RSS 2.0 та Atom.
3. Дедуплікація, зберігання в інфоблоці, прапорці атрибуції.
4. Адміністративний інтерфейс для керування джерелами.
5. Обробка контенту за обраною схемою.
6. Розклад агентів та моніторинг помилок.
7. Документація та передача доступів.

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

• Документація: схема даних, налаштування агентів, інструкція адміністратора.
• Доступи: дані для входу, SSH-ключі, реквізити API (за потреби).
• Навчання: показ інтерфейсу керування стрічками, відповіді на питання.
• Підтримка: гарантійне обслуговування протягом 30 днів після здачі.

Таймлайн робіт

Разом: 3–5 робочих днів. Додавання AI-рерайту — плюс 1–2 дні.

Оцінимо ваш проєкт за 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-селектори в парсері.

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