Коллекции CMS: отделяем сайт от контента

Четверг, 14:40. Маркетолог сети сервисных центров с двадцатью двумя филиалами открывает редактор страниц, чтобы добавить на сайт только что открывшийся филиал. Список филиалов собран прямо в странице из двадцати двух карточек; чтобы появилась двадцать третья, нужно скопировать карточку, переписать текст и вставить её так, чтобы не сбить порядок. На той же неделе у другого филиала сменился телефон, и, поскольку номер набран отдельно на главной, на странице контактов и на региональном лендинге, править приходится в трёх местах. Всё это выглядело как правка на двадцать минут. Уходит три часа, и на одной странице остаётся старый номер. Цифры условные, ситуация — нет.

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

Почему правка текста превращается в работу дизайнера?

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

Вторая цена невидима: никто не знает, сколько копий одного и того же факта существует на сайте. Если телефон филиала набран на трёх страницах, знание об этих трёх страницах хранится в голове одного человека и уходит вместе с ним. Через год сайт превращается в массив текста, инвентаризовать который невозможно, и ответ на вопрос «мы это обновили?» находится только ручной проверкой.

Решение формулируется просто: описать контент один раз как структурированные записи, а странице оставить единственную инструкцию — показать такие-то записи в таком-то макете. Это можно сделать отдельной headless-системой, а можно там же, где живёт сайт. Выбор сводится к цене интеграции против независимости, и критерии выбора между встроенным решением и сторонним инструментом работают и здесь. В малом и среднем бизнесе чаще выигрывает вариант «в одном месте»: на одну систему, один вход и один процесс публикации меньше.

Что попадает в коллекцию, а что остаётся на странице?

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

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

Контент	Повторяемость	Кто обновляет	Где хранить
Данные филиалов	Одинаковые поля у каждого	Операционный отдел	Коллекция
Карточки услуг	Одинаковые поля у каждой	Маркетинг	Коллекция
Каталог товаров	Сотни записей, внешний источник	ERP / коммерция	Коллекция с внешней подпиткой
Лендинг акции	Один экземпляр, короткая жизнь	Маркетинг	Страница
Рассказ о компании	Один экземпляр, меняется редко	Руководство	Страница

Как спроектировать схему полей, чтобы она не рассыпалась через полгода?

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

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

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

Откуда берётся контент: ручной ввод, ERP или таблица?

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

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

Для промежуточных случаев удобным мостом остаётся таблица. Маркетинг готовит записи в привычном инструменте, а задание синхронизации регулярно переносит файл в коллекцию; правила настройки синхронизации таблицы с системой учёта действуют и тут: односторонний поток, фиксированные заголовки колонок и постоянный идентификатор в каждой строке. Без идентификатора каждый импорт создаёт дубли.

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

Какой бы путь вы ни выбрали, уважайте ограничения системы-источника: ночная выгрузка целиком, небольшие пакеты изменений в течение дня и растущая пауза перед повторной попыткой. Если игнорировать лимиты API и управление квотами, первый крупный импорт весь день будет получать отказы.

Как из одного макета получаются страницы списка и карточки?

Здесь коллекция окупается. Страница списка — это один макет: сколько колонок, какие поля видны, по чему сортировка, есть ли фильтр. Страница карточки — второй: заголовок, изображение, длинный текст, блок контактов, связанные записи. Оба макета собираются один раз, и даже когда записей станет сто, поддерживать вы будете по-прежнему две страницы.

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

Та же логика выходит за пределы публичных страниц. В каталоге, открытом дилерам, список товаров приходит из коллекции, а оформление заказа — отдельное приложение; когда вы собираете дилерский портал заказов, разделение «контент в коллекции, операции в приложении» позволяет обновлять одно, не трогая другое. В Rocketly каркас страницы собирается в редакторе секций Site Studio: обложка, список возможностей, блок вопросов и ответов, форма выстраиваются по порядку, у каждой секции есть варианты раскладки, а важные секции блокируются от правок без прав.

Как не выпустить в продакшн незаконченный перевод?

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

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

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

Как изменение в коллекции выходит в продакшн и как откатывается?

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

В Rocketly публикуется не ваш черновик, а замороженная копия момента: в подходе «Версия и замороженный снимок» версия получает номер, и её содержимое больше не меняется, поэтому вы продолжаете работать в черновике, а посетитель видит прежнюю версию до нажатия кнопки публикации. Если изменение оказалось неудачным, откат в один клик возвращает предыдущую версию и заодно снимает отложенную публикацию, чтобы два решения не затирали друг друга. Ограничить круг публикующих помогает политика ревью и согласования: вы задаёте, чьё одобрение обязательно до выхода версии.

У коллекций с внешней подпиткой возникает ещё один вопрос: если запись изменилась одновременно в системе-источнике и на сайте, чья версия побеждает? Это классический конфликт, и без записанного заранее правила он оборачивается тихой потерей данных; самый надёжный подход к правилу «кто побеждает» в двусторонней синхронизации — задавать его не на коллекцию, а на отдельное поле. Цена всегда из ERP, маркетинговый текст всегда с сайта.

Заменяет ли запись коллекции запись в CRM?

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

Практический вывод: форма на сайте не должна писать напрямую в CRM. В Rocketly в схеме «Формы подключаются к CRM» отправка сначала попадает в отдельный ящик заявок сайта, оттуда сопоставлением полей уходит в сценарий, и только после этого создаётся запись; перед выпуском можно прогнать сухой запуск и убедиться, что сопоставление верное. К каким типам записей вообще имеет доступ приложение, выбирается поштучно в области данных CRM, а изменения области пишутся в журнал аудита. Если коллекцию наполняет внешний сервис, ограничьте его доступ так же строго: рекомендации по области действия и хранению API-ключей применимы и к контентной подпитке, потому что при общем ключе одна утечка открывает сразу два контура.

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

Как поисковые системы видят страницы, собранные из коллекции?

Карточки, сгенерированные из коллекции, могут оказаться самыми ценными страницами сайта: каждая отвечает конкретной услуге, филиалу или товару и закрывает узкий запрос. Чтобы это сработало, нужны три вещи. Первая — рендеринг на сервере, то есть заголовок и описание находятся в HTML до того, как браузер выполнит JavaScript. Вторая — у каждой записи свой постоянный адрес. Третья — заголовок и описание выводятся из полей записи.

Третий пункт кажется мелочью, но в нём весь выигрыш: задайте шаблон вида «{название} — филиал в городе {город}», и сто записей дадут сто разных заголовков автоматически. В Rocketly видимость в поиске означает, что публичные страницы рендерятся на сервере, а заголовок, описание, canonical, hreflang и микроразметка приходят внутри HTML; у каждого опубликованного сайта появляются свои sitemap.xml и robots.txt, а признак индексирования задаётся постранично.

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

По каким метрикам понятно, что разделение сработало?

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

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

С чего начать: порядок работ на две недели

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

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

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

Частые вопросы

Нужно ли уметь программировать, чтобы собрать коллекцию?

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

Перенос существующего сайта на коллекции значит собрать его заново?

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

Можно ли использовать одну коллекцию на нескольких страницах?

Да, в этом и смысл. Одну и ту же коллекцию филиалов можно показать списком с картой на странице контактов и карточками с фильтром на региональной странице; запись одна, поэтому обновление действует в обоих местах сразу.

Замедлится ли страница списка, когда записей станет много?

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