Парсинг статей и контента для автонаполнения 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 проходит проверку на валидность и соответствие схеме инфоблока.
Извлечение контента: три подхода
| Подход |
Принцип |
Когда применять |
| CSS-селекторы |
Селектор под конкретный сайт (.post-content) |
До 5 источников, стабильная вёрстка |
| Алгоритмы (Readability) |
Анализ DOM по эвристикам плотности текста |
5+ источников, разнородная вёрстка |
| Гибридный |
Readability + кастомные правила для ошибок |
10+ источников, максимальная точность |
Readability на PHP справляется за 2 секунды против 15 минут на ручное написание селектора для каждого источника — выигрыш в 450 раз на 10 источниках. На практике гибридный подход — единственный, который работает для 10+ источников. Чистая автоматика теряет важные блоки (таблицы, списки), чистые селекторы не масштабируются.
Пошаговый процесс парсинга статей
- Сбор URL. Парсер обходит страницы-списки (пагинация, категории, sitemap.xml) и собирает URL статей. Сохраняет в очередь — таблицу parser_queue с полями url, status, created_at.
- Загрузка и извлечение. Для каждого URL из очереди: загрузка HTML, извлечение контента, парсинг метаданных. Результат — структурированный массив, сохраняемый в промежуточную таблицу parser_articles.
- Модерация (опционально). Администратор просматривает спарсенные статьи в интерфейсе, одобряет или отклоняет. Для полной автоматизации этот шаг заменяется фильтрацией по правилам.
- Импорт. Одобренные статьи загружаются в инфоблок через CIBlockElement::Add(). Изображения сохраняются через CFile::MakeFileArray().
Маппинг в инфоблок
| Извлечённые данные |
Поле инфоблока |
Обработка |
| Заголовок h1 / title |
NAME |
Обрезка до 255 символов, очистка HTML |
| Первые 300 символов текста |
PREVIEW_TEXT |
strip_tags() + обрезка по границе предложения |
| Полный HTML статьи |
DETAIL_TEXT |
Очистка через HTMLPurifier |
| Первое изображение |
PREVIEW_PICTURE |
Скачивание + ресайз |
| URL источника |
PROPERTY_SOURCE_URL |
Без изменений |
| Дата публикации |
ACTIVE_FROM |
Парсинг через strtotime() |
| md5(url) |
XML_ID |
Для дедупликации |
| Автор |
PROPERTY_AUTHOR |
Извлечение из meta или byline |
| Теги / ключевые слова |
PROPERTY_TAGS |
Множественное свойство типа «строка» |
Как защитить парсер от блокировки?
Контентные сайты защищаются слабее, чем маркетплейсы, но базовые меры присутствуют:
- robots.txt — проверяем Disallow для парсируемых разделов. Игнорирование robots.txt — дополнительный юридический риск.
- Rate limiting — 1–2 запроса в секунду безопасны для большинства сайтов. Агрессивный парсинг (10+ rps) приведёт к блокировке.
- JavaScript-рендеринг — SPA-сайты требуют headless-браузера. Для статичных сайтов достаточно cURL.
- Cloudflare / WAF — определяют ботов по fingerprint. Решается через headless-браузер с реалистичными заголовками.
Автоматизация в cron
Рекомендуемое расписание 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+ лет, и ни один проект не обходится без правильного выбора парсера.
Какие проблемы решает парсинг?
- Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
- Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
- Агрегация поставщиков — пять прайсов в разных форматах (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 с очередью — чтобы не забить канал
- Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
- 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 недель |
| Поддержка и адаптация парсеров |
по подписке |
Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.