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

Парсинг новостей Битрикс: где ломается автонаполнение

Автонаполнение инфоблока ломается не на этапе «взяли ленту и распарсили», а на эксплуатации: источник меняет формат, агенты Битрикс копят зависшие процессы, база растёт от дублей. Через месяц-два такой конвейер начинает требовать ручного вмешательства чаще, чем экономит время редакции.

Самая частая причина — дубли материалов. Лента отдаёт один и тот же текст с разными адресами, при повторном импорте создаётся новая запись, а не обновляется существующая. Без сверки по устойчивому признаку — хешу текста, внешнему идентификатору источника — инфоблок зарастает копиями, и поиск по сайту начинает выдавать три одинаковых новости.

Вторая точка отказа — кодировка источника. Часть лент приходит в однобайтовой кодировке, часть в UTF-8; при смешивании получаются «кракозябры» в заголовках и битые символы в анонсах. Проблема не в самом парсере, а в том, что нормализация кодировки не вынесена в отдельный шаг до записи в инфоблок.

Обрывы лент и зависшие агенты бьют по стабильности. Если источник отдаёт ответ медленнее таймаута или рвёт соединение на середине, агент Битрикс остаётся в рабочем состоянии и следующий запуск наслаивается на предыдущий. Нагрузка на базу растёт, импорт «залипает», а в логах — серия одинаковых ошибок без внятной причины.

Отдельно стоит рост нагрузки: каждый прогон без ограничений тянет полную ленту и пишет всё подряд. При накоплении десятков тысяч записей выборка по дате и разделам начинает тормозить, а индексы не покрывают реальные запросы вывода новостей.

Разбираем, как это закрывается: где ставить нормализацию, как строить проверку дублей и что делать с зависшими агентами, чтобы автонаполнение работало без ежедневного присмотра.

Что меняется после настройки автонаполнения

До настройки автонаполнения новостной раздел живёт рывками: редактор вручную переносит материалы из лент, публикация отстаёт от события на часы, а половина карточек уходит в архив неактуальной. После подключения конвейера цикл меняется — разбираем, что именно и в каких величинах.

Скорость публикации и свежесть

Поток из источников обрабатывается по расписанию: лента опрашивается, новые материалы попадают в очередь, нормализуются и уходят в публикацию. Задержка между появлением новости у источника и её выходом на сайте сокращается с часов до минут — раздел перестаёт отставать от повестки.

Доля ручной работы

Ручная модерация сохраняется там, где она создаёт ценность: редактор проверяет заголовок, теги, привязку к рубрикам и решает, публиковать или отклонить. Черновой перенос, чистка разметки, дедупликация и раскладка по разделам автоматизированы — на них уходит не время редакции, а работа конвейера.

Устойчивость к сбоям источников

Источник может отдать пустую ленту, изменить верстку или уйти в недоступность — конвейер не публикует мусор и не падает. Материал с неполными полями уходит в карантин, повторы отсекаются по отпечатку, а при недоступности источника очередь ждёт восстановления и догоняет пропущенное.

Что видно в цифрах

Доля материалов, уходящих в публикацию без правок редактора, растёт; время от появления новости до карточки на сайте падает; число пустых и дублирующих записей в разделе — к нулю. Свежесть контента перестаёт зависеть от загрузки редакции.

Схему разбора лент и правила публикации собираем под ваш раздел — на 1С-Битрикс это делается штатными средствами без внешних надстроек.

Способы сбора лент: сравнение подходов

Источник данных определяет не только формат, но и режим обновления: от него зависит частота опроса, нагрузка на сайт и устойчивость к сбоям. Ниже — рабочие варианты, между которыми реально выбирают при автонаполнении.

Сравнение подходов

Режим обновления и частота опроса

Частота опроса подбирается под темп публикаций источника, а не «чем чаще, тем лучше». Для новостной ленты разумный интервал — от 15 минут до часа: он ловит свежий материал, но не создаёт лишних запросов. Если источник отдаёт дату публикации, повторную вставку отсекает проверка по уникальному идентификатору или ссылке — дубли не попадают в базу.

Для источников с жёсткими лимитами запросов ставим очередь и обрабатываем ленты последовательно, с паузой между обращениями. При недоступности источника задача не падает, а переносится на следующий цикл — сайт продолжает работать на ранее собранных данных.

Разбор HTML-страниц требует отдельного контроля: селекторы выборки храним в конфигурации, чтобы правка вёрстки правилась в одном месте, а не в коде задачи. Для каждого источника ведём журнал: время последнего успешного сбора, число новых записей, ошибки — по нему видно, что лента перестала отдавать данные, до того как это заметит редактор.

Как мы внедряем парсинг: этапы работ

Процесс строим так, чтобы на выходе остался работающий контур автонаполнения, а не разовый скрипт: сначала разбираемся с источниками, потом проектируем обмен, затем настраиваем регулярный запуск и защиту от дублей.

1. Аудит источников. Собираем перечень лент и разделов, которые реально нужны редакции, проверяем доступность, стабильность отдачи и структуру материалов. Фиксируем, какие поля переносим — заголовок, анонс, дату, автора, изображения — и какие рубрики им соответствуют.
2. Схема обмена. Проектируем, как данные попадают в инфоблоки: сопоставление разделов, правила преобразования текста, привязка изображений, поведение при отсутствии обязательных полей. На этом шаге согласуем, что делать с материалом, который не прошёл проверку — отбрасывать или складывать в отдельный раздел для ручного разбора.
3. Настройка агентов. Реализуем регулярный обход источников с заданным интервалом, обработкой ошибок и повторными попытками при сбоях сети. Логируем каждый проход, чтобы было видно, сколько материалов пришло, сколько отклонено и по какой причине.
4. Проверка на дубли. Настраиваем сопоставление по внешнему идентификатору и контрольным признакам текста, чтобы повторный обход не создавал копии. Отдельно проверяем поведение при обновлении материала в источнике — правка должна обновлять существующую запись, а не плодить новую.
5. Тестовый прогон. Запускаем контур на ограниченном наборе источников, сверяем результат с ручной выборкой, смотрим нагрузку на сайт в момент обхода. Правки вносим до вывода на все ленты.
6. Передача регламентов. Отдаём описание источников, правила сопоставления рубрик, порядок добавления новой ленты и инструкцию по разбору отклонённых материалов. Редакция получает понятный набор действий без обращения к разработчику по каждой правке.

Такой порядок даёт предсказуемый результат: контур наполнения работает по расписанию, дубли не накапливаются, а сопровождение не требует постоянного участия инженера.

Что заказчик получает на руки

Передаём не «скрипт, который где-то крутится на сервере», а комплект, по которому обмен можно эксплуатировать, расширять и передавать другому подрядчику без раскопок в чужом коде.

• Конфигурация обмена — файлы настроек источников: список лент, периодичность опроса, маппинг полей источника на свойства инфоблока, привязка к разделам и типам новостей.
• Схема потоков данных — откуда забираем, где нормализуем, в какой инфоблок и с какой периодичностью попадает материал, где стоят точки ручной модерации.
• Правила обработки — дедупликация по канонической ссылке и заголовку, фильтры по рубрикам и стоп-словам, обрезка и очистка текста, поведение при неполном или битом фиде.
• Регламент сопровождения — что делать при смене формата ленты, как добавить новый источник, как откатить ошибочно залитый массив, за кем остаётся мониторинг очереди.
• Документация — описание структуры обмена, назначения каждого поля и параметра, инструкция для редактора: как поправить правило, не ломая соседние.
• Доступы и роли — какие учётные записи нужны обмену, какие права у редактора, что закрыто от публикации без подтверждения.
• Журнал и мониторинг — где смотреть статистику импорта, сколько материалов прошло и отсеялось, как приходит уведомление о сбое источника.

Всё это фиксируется в репозитории вместе с кодом, а не остаётся в переписке. Через месяц после запуска вы или ваш штатный разработчик открываете документацию и меняете правило сами — без обращения к нам. Опишите задачу: подберём источники, соберём конфигурацию обмена и вернёмся с оценкой и планом работ.

Кейс: автонаполнение новостной ленты без дублей

Заказчик — региональный отраслевой портал на 1С-Битрикс с редакцией из двух человек. Новости собирались вручную: редактор обходил десяток источников, копировал текст, чистил разметку и публиковал. В сутки выходило 8-12 материалов, при этом треть времени уходила на механическую работу, а лента всё равно отставала от событий на несколько часов.

Что было до

Публикации зависели от занятости редактора: в дни срочных задач лента вставала. Дубли появлялись постоянно — один и тот же сюжет приходил из нескольких лент с разными заголовками, и отследить повторы вручную не получалось. Часть материалов уходила в архив с битыми ссылками на изображения, потому что картинки оставались на стороне источника.

Что изменили

Настроили сбор из согласованных лент по расписанию, с приведением заголовков и текста к единому виду. Ключевой элемент — дедупликация: материал сверяется с уже опубликованным по канонической ссылке и отпечатку текста, поэтому повторный сюжет из другой ленты не создаёт вторую запись. Изображения переносятся в медиабиблиотеку портала при публикации, чтобы лента не зависела от источника.

Что стало

Ежедневный объём вырос до 40-60 материалов без расширения редакции, задержка от события до публикации сократилась до минут. Доля дублей упала практически до нуля, а редактор переключился на проверку и правку вместо копирования. Стабильность публикаций перестала зависеть от того, свободен ли человек в конкретный час.

1С-Битрикс в этой схеме остаётся системой публикации и хранения — логика сбора и проверок живёт отдельно и не мешает обновлениям платформы. Если у вас лента наполняется вручную и вы упираетесь в тот же потолок — опишите задачу, вернёмся с оценкой и планом.

Чем отличается разовый сбор от постоянного обновления?

Разовый сбор — это загрузка существующего массива: вы отдаёте список источников и глубину (например, материалы за последние два года), инженер настраивает разбор страниц, приводит поля к структуре инфоблоков и выполняет один прогон. На выходе — наполненный раздел, который дальше живёт сам: новые записи появляются только тогда, когда кто-то из редакции добавит их вручную. Такой режим закрывает стартовую задачу — сайт перестаёт выглядеть пустым, поисковые системы получают готовый архив материалов, а редакция работает с уже собранной базой, а не с нуля.

Постоянное обновление устроено иначе: тот же разбор, но запускаемый по расписанию опроса — раз в час, раз в сутки, в зависимости от того, как часто источник публикует новое. Ключевая часть здесь не сам сбор, а защита от дублей и мусора: каждая запись проверяется по канонической ссылке и хешу текста, повторные попадания отсекаются, обновлённые материалы перезаписываются, а не создаются заново. Без этого через месяц в инфоблоке окажется три копии одной новости с разными датами.

Разница проявляется в сопровождении. Разовый сбор — это работа с фиксированным результатом: источник поменял вёрстку, прогон сломался, но следующий запуск планируется вручную, и до него раздел просто не пополняется. Постоянное обновление — это сервис с журналом прогонов, оповещением о сбоях и адаптацией разбора под изменения источника. Архив материалов при этом остаётся целым: старые записи не перезаписываются, а дополняются новыми, поэтому откат к предыдущему состоянию возможен на любом этапе.

Практический критерий выбора простой. Если задача — быстро поднять раздел и дальше вести его силами редакции, достаточно разового сбора. Если поток новостей должен идти без ручного участия и вы готовы держать расписание опроса и мониторинг, нужен постоянный режим — он и даёт непрерывное наполнение без простоев.

Частые технические сомнения

Перед стартом заказчики обычно проверяют не «умеет ли парсер тянуть новости», а что будет с системой на дистанции: выдержит ли база, не сломается ли вёрстка, что при повторном запуске и что если источник лёг. Ниже — ответы на те сомнения, которые чаще всего всплывают на этапе оценки.

Совместимо ли это с текущей вёрсткой и шаблонами сайта?

Материал приходит в те же поля и типы свойств, что и при ручной публикации, поэтому шаблоны вывода, ЧПУ и разделы каталога не переписываются. Изображения подтягиваются в медиабиблиотеку с сохранением пропорций, а разметка чистится от чужого кода до вставки. Если структура источника меняется, правится только слой разбора — публичная часть остаётся нетронутой.

Что произойдёт при повторном запуске задачи?

Задача идемпотентна: каждая запись помечается идентификатором источника, и повторный проход пропускает уже загруженное. Прерванный импорт продолжается с последней обработанной позиции, а не с начала. Это снимает риск задвоенных публикаций и лишних обращений к внешнему сайту.

Как система ведёт себя, когда источник недоступен?

Сбой источника не роняет обмен: срабатывают повторы с нарастающей паузой, а после нескольких неудач задача помечается и уходит уведомление ответственному. Уже собранные материалы остаются в базе, ничего не теряется. Когда источник возвращается, импорт догоняет пропущенное по датам.

Обсудим вашу задачу автонаполнения

Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен от вас минимум вводных по пяти пунктам. Ниже — что именно снимаем на старте: этого достаточно, чтобы спроектировать сбор, нормализацию и публикацию под ваш контур.

• Перечень источников — конкретные ленты и разделы, которые наполняют сайт: открытые новостные потоки, отраслевые площадки, партнёрские рассылки, внутренние базы. По каждому источнику важно понять, отдаёт ли он данные машинно или только страницами, есть ли авторизация и лимиты на обращения.
• Требования к контенту — какие поля обязательны (заголовок, дата, автор, тело, изображения, теги), что делаем с дублями и повторами, нужна ли переработка текста под ваш стиль или публикуем как есть, какие темы отсекаем.
• Схема разделов — куда раскладывать материалы: привязка к инфоблокам, категориям и тегам, правила выбора раздела, нужна ли ручная модерация перед публикацией или материал уходит на сайт автоматически.
• Режим обновления — как часто проверяем источники, публикуем ли сразу или пачками по расписанию, что делаем при сбое источника и как откатываем ошибочно залитую запись.
• Доступы — учётные данные к источникам, права на запись в инфоблоки, тестовый контур для прогона, доступ к логам и мониторингу, чтобы сбои было видно до того, как они дошли до посетителей.

Если по части пунктов ясности нет — это нормально, разберём на созвоне и зафиксируем в техническом задании. Опишите задачу в свободной форме: какие источники, какой объём материалов в сутки и что уже есть на стороне сайта. Вернёмся с оценкой сроков и планом работ.