Как устроена фабрика контента для SEO-статей на Bitrix
Конвейер, который планирует, пишет и проверяет статьи для каталожного сайта — и редакционный контракт, который меняется по замечаниям человека, а не остаётся высеченным в камне.
Конвейер начинается с очереди задач
Первая ошибка при попытке автоматизировать контент для каталожного сайта — начать с промпта: «напиши статью про товар X». Промпт даёт текст. Он не даёт понимания, какая статья вообще нужна следующей, кто её проверит и что случится, если она не пройдёт проверку.
Работающий конвейер начинается с планировщика. У него есть очередь задач: какая статья готовится, для какого товара или категории, на каком этапе — от постановки до согласования редакцией. Планировщик не решает, как писать. Он решает, что писать дальше и в каком порядке — а это ровно та часть, которую тяжелее всего держать в голове, когда сайт большой.
Фактура сначала, текст потом
Прежде чем появляется хоть одно предложение статьи, собирается фактура: технические характеристики, диапазоны рабочих параметров, особенности конкретных моделей — всё сверяется по официальным карточкам производителя, каталогам и, если нужно, по подтверждению у дилера. Только после этого начинается написание.
Порядок важен. Если дать модели данные и текст одновременно, она с высокой вероятностью сгладит противоречия там, где их сглаживать нельзя — например, спишет расхождение в характеристиках на опечатку вместо того, чтобы это расхождение проверить. Разделение «сначала факты, потом текст» превращает статью в документ, который можно проверить, а не только прочитать.
Редакционный контракт — рабочий документ, который меняется
У системы есть общий редакционный контракт: как обосновывать финал статьи, как подавать особенности оборудования, что можно сравнивать между статьями, а что требует отдельного подтверждения. Контракт версионируется, потому что меняется практика.
Например, первая версия контракта требовала безличной подачи по умолчанию: «рекомендуется», «стоит обратить внимание». По замечанию — эта форма звучит отстранённо там, где уместнее голос эксперта. Контракт обновили: разрешили обоснованные «мы рекомендуем» и «при подборе учитываем», но заявления об опыте, гарантиях и результатах по-прежнему требуют подтверждения фактурой — формулировка сама по себе доказательством не считается.
Тем же обновлением добавили проверку на накопление отрицаний и противопоставлений: если текст держится на конструкциях «не то, а это» через абзац, читать его физически тяжелее, даже если каждое предложение по отдельности верное. Прямое объяснение механизма и результата получило приоритет — но не в ущерб предупреждениям, которые в тексте должны остаться.
Итог одного цикла правок — контракт с версией 1.0.0 стал версией 1.1.0. Небольшой номер, за которым стоит конкретное замечание и конкретное решение.
Проверки перед тем, как текст увидит редактор
Готовый текст проходит через несколько автоматических проверок, прежде чем попасть на согласование: уникальность, читаемость по независимой метрике и внутренняя диагностика качества — по сути, отдельный проход, который ищет то же самое, что искал бы придирчивый редактор: рыхлые формулировки, слабую аргументацию, нарушения контракта.
Если статья не проходит — она не уходит на согласование. Это просто более дешёвая точка для правки: дешевле поправить до того, как текст увидел человека, чем после.
Где заканчивается автономность
Публикация в CMS — шаг, который система намеренно не берёт на себя. Она не публикует то, что прошло автоматические проверки, автоматически. Она готовит статью, доводит её до состояния «готово к решению» — и решение всё равно принимает человек: посмотреть, согласовать, отправить в публикацию или вернуть на доработку.
Это разделение — признание того, что часть решений (в первую очередь — что вообще достойно публикации на сайте клиента) не должна автоматизироваться просто потому, что технически это возможно.