Уявіть: новинний сайт на Бітрікс з 10 000 відвідувачів на добу, але контент оновлюється раз на тиждень. Редактори витрачають 20 годин на тиждень на копіювання статей із 15 джерел. У результаті — падіння позицій у видачі на 30% за квартал. Ми впроваджуємо парсинг новин Бітрікс, який автоматично збирає новини, фільтрує дублі та публікує їх в інфоблоці. На одному з проєктів це скоротило часові витрати з 15 до 1 години на тиждень — автоматизація в 15 разів краща за ручне копіювання — і збільшило індекс цитування на 45%. Крім того, такий підхід повністю виключає людські помилки при копіюванні та економить до 40 000 грн на місяць на зарплаті редакторів. Економія на редакторах: до 40 000 грн щомісяця, вартість автоматизації від 15 000 грн. Середня вартість впровадження — 25 000 грн, а потенційна економія за півроку — до 240 000 грн. Ми реалізуємо автонаповнення 1С-Бітрікс новинами, RSS парсер для Бітрікс, імпорт новин у Бітрікс, дедуплікацію новин, категоризацію контенту в Бітрікс, кроновий парсер Бітрікс, обробку RSS-фідів, 1С-Бітрікс парсинг, новинну стрічку сайту, автоматичне наповнення Бітрікс та Бітрікс парсинг RSS.
Згідно зі специфікацією RSS Board, стандарт RSS 2.0 підтримує всі необхідні поля для автоматичної публікації.
Як вибрати джерело даних для парсингу?
Новинні стрічки доступні в кількох форматах. Порівняння за ключовими параметрами:
| Джерело |
Надійність |
Складність |
Юридичні ризики |
| RSS/Atom-фіди |
Висока |
Низька |
Мінімальні |
| API агрегаторів |
Висока |
Середня |
Середні (потребують ліцензій) |
| HTML-сторінки |
Низька |
Висока |
Високі |
RSS/Atom — оптимальний старт. Вони стандартизовані, легко парсяться і не потребують спеціальних дозволів.
Організація процесу імпорту
Парсер новин для Бітрікс складається з трьох шарів.
Збирач (Fetcher). Отримує RSS-фіди за списком URL. Використовує file_get_contents з контекстом або cURL з таймаутами. Кожен фід парситься через SimpleXMLElement або бібліотеку SimplePie. Для продуктивності застосовуємо асинхронний парсинг через Guzzle, що в 5 разів кращий за послідовний.
$xml = simplexml_load_string($rssContent);
foreach ($xml->channel->item as $item) {
$title = (string)$item->title;
$link = (string)$item->link;
$date = strtotime((string)$item->pubDate);
$desc = (string)$item->description;
}
Обробник (Processor). Санізує HTML-теги, завантажує зображення, конвертує часові мітки, визначає категорію за ключовими словами. Парсер на SimplePie працює в 2 рази швидше за кастомний варіант на cURL.
Імпортер (Importer). Створює елементи в інфоблоці через CIBlockElement::Add(). Перевіряє дублі за XML_ID (URL статті або GUID).
Як зберігати та обробляти контент?
Рекомендований мапінг RSS→інфоблок:
| Поле RSS |
Поле інфоблоку |
Тип |
title |
NAME |
Рядок |
link |
PROPERTY_SOURCE_URL |
Посилання |
description |
PREVIEW_TEXT |
HTML/текст |
content:encoded |
DETAIL_TEXT |
HTML |
pubDate |
ACTIVE_FROM |
Дата |
guid / link |
XML_ID |
Рядок (дедуплікація новин) |
category |
IBLOCK_SECTION_ID |
Прив'язка до розділу |
enclosure / media:content |
PREVIEW_PICTURE |
Файл |
XML_ID — обов'язкове поле. Використовуйте md5-хеш від URL статті — це гарантує унікальність.
Сирий HTML з RSS непридатний для публікації. Типові проблеми:
- Зовнішні зображення — завантажуйте в
/upload/ при імпорті.
- Сторонні скрипти та iframe — використовуйте
strip_tags() з whitelist або HTMLPurifier.
- Відносні посилання — перетворюйте в абсолютні, підставивши домен джерела.
- Кодування — детектуйте через
mb_detect_encoding() і конвертуйте в UTF-8.
Що краще: cron чи агенти Бітрікс?
Крон у 3 рази кращий за стандартні агенти Бітрікс для тривалих завдань — агенти обриваються при перевищенні часу виконання, а крон виконується до кінця. Cron-задача викликає PHP-скрипт:
$_SERVER['DOCUMENT_ROOT'] = '/home/bitrix/www';
require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
CModule::IncludeModule('iblock');
Приклад конфігурації cron для парсингу кожні 30 хвилин
*/30 * * * * /usr/bin/php /home/bitrix/www/parser.php
Частота: термінові новини — кожні 15–30 хвилин, галузеві — 1–2 години, аналітика — 1–2 рази на добу.
Як налаштувати парсинг новин на Бітрікс за 5 кроків?
- Виберіть джерела RSS/API.
- Напишіть збирач на SimplePie або cURL.
- Налаштуйте обробник: очищення HTML, завантаження картинок, мапінг категорій.
- Реалізуйте імпортер з перевіркою XML_ID.
- Налаштуйте cron та систему логування помилок.
Контроль якості та категоризація
Окрім XML_ID, використовуйте:
- Фільтр за датою — не імпортувати новини старші N днів.
- Мінімальна довжина опису — відкидати записи коротші за 100 символів.
- Стоп-слова — фільтрувати нерелевантні тематиці ключові слова.
- Ліміт на джерело — не більше N новин на добу з одного фіду.
Найпростіший варіант категоризації контенту в Бітрікс — мапінг «джерело → розділ інфоблоку». Більш гнучкий — класифікація за ключовими словами:
$rules = [
'Технології' => ['AI', 'блокчейн', 'стартап', 'застосунок'],
'Фінанси' => ['акції', 'курс', 'інвестиції', 'IPO'],
];
Для 10+ категорій підключайте зовнішні класифікатори (OpenAI, Yandex GPT).
Юридична сторона
Публікація чужих новин «як є» порушує авторські права. Варіанти:
- Публікація заголовка + 2–3 речень з посиланням (цитування).
- Автоматичний рерайт через LLM — юридично спірно.
- Використання фідів з відкритою ліцензією (Creative Commons, держджерела).
Що входить у роботу
- Аудит поточного каталогу — структура інфоблоків, перевірка дублів.
- Розробка парсера — збирач, обробник, імпортер.
- Інтеграція з cron — розклад, логування.
- Дедуплікація та фільтри.
- Документація та навчання редакторів.
- Підтримка 30 днів після релізу.
Досвід та експертиза
Ми займаємося розробкою на Бітрікс понад 7 років (7+ років досвіду), реалізували 200+ проєктів автоматизації. Наші інженери сертифіковані 1С-Бітрікс. Використовуємо CommerceML, REST API, Bizproc — повний стек. Більше 7 років на ринку, 200+ успішних проєктів. Для складних проєктів впроваджуємо багатопотоковий парсинг через Guzzle та черги повідомлень RabbitMQ, використовуємо принципи SOLID та патерн Repository для абстрагування сховища даних, забезпечуємо асинхронну обробку через cron та систему кешування Redis. Зв'яжіться з нами, щоб обговорити архітектуру парсера для вашого сайту — ми підготуємо пропозицію за 1-2 дні. Отримайте консультацію з автоматизації новинного розділу.
З чого почати розробку парсера для 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, обробляємо пагінацію.
Як влаштований пайплайн автонаповнення?
Чотири етапи. Кожен може зламатися по-своєму.
-
Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.
-
Нормалізація. Тут основна робота:
- Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
- Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
- Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
- Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі
-
Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.
-
Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.
Моніторинг цін конкурентів: необхідність та реалізація
Окрема підсистема зі своєю специфікою:
| Параметр |
Як влаштовано |
| Частота |
Від разу на день до кожних 2 годин — залежить від волатильності ринку |
| Зіставлення |
За артикулом, EAN, нечітке порівняння назв через відстань Левенштейна |
| Зберігання |
Своя таблиця vendor_price_monitor з історією, не інфоблоки |
| Алерти |
Telegram/email при відхиленні ціни конкурента більш ніж на X% |
| Автоправила |
«Тримати ціну на 3% нижче мінімальної серед конкурентів, але не нижче собівартості + 15%» |
Результат — дашборд: ваш товар 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–2 джерел за 2–3 дні для оцінки якості даних |
| Основний парсер |
Повний збір даних з одного джерела (статичний/динамічний) |
| Модуль імпорту в Бітрікс |
Нормалізація, завантаження, оновлення, адмінка мапінгу |
| Моніторинг цін |
Якщо потрібно – система збору та алертів (до 10 конкурентів) |
| Документація |
Опис архітектури, інструкція з оновлення селекторів |
| Підтримка |
Гарантія 3 місяці на безперебійну роботу, правка при зміні верстки донора |
Скільки часу займає розробка парсера?
Процес і терміни:
-
Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
-
Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
-
Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
-
Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
-
Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.
Орієнтовні терміни для різних типів завдань
| Задача |
Терміни |
| Парсер одного сайту (статичний HTML) |
3–5 днів |
| Парсер SPA-сайту (Puppeteer/Playwright, обхід захисту) |
1–2 тижні |
| Модуль імпорту CSV/XML в Бітрікс |
1–2 тижні |
| Система моніторингу цін (5–10 конкурентів) |
2–4 тижні |
| Комплексна система автонаповнення |
4–8 тижнів |
| Підтримка та адаптація парсерів |
за підпискою |
Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.