Headless CMS: как устроена и когда подходит вместо обычной

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

Что такое headless CMS

Слово «headless» переводится как «безголовая». «Головой» в классической CMS называют слой отображения — шаблоны, которые превращают контент в страницы сайта. Headless CMS эту часть убирает: в ней остаётся только бэкенд, где контентом управляют, а показывать его будет кто-то другой.

В обычной CMS редактор правит текст, и он сразу появляется на странице, собранной шаблоном той же системы. В headless CMS редактор правит текст в админке, а показывает его другое приложение: сайт на JavaScript-фреймворке, мобильное приложение, личный кабинет клиента. Связь между ними — программный интерфейс, API.

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

Headless CMS отвечает за то, что сказать. Как это показать, решает отдельный фронтенд — и таких фронтендов может быть несколько.

Как устроена headless CMS

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

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

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

Чем headless отличается от обычной и decoupled CMS

Между классической и headless CMS есть промежуточный вариант — decoupled. У такой системы витрина есть, но пользоваться ею необязательно: контент можно забирать по API и показывать во внешнем фронтенде.

Классическая CMS тоже умеет отдавать данные наружу. Например, модуль REST API расширяет функциональные возможности «1С-Битрикс: Управление сайтом», и через программный интерфейс можно связать сайт с приложением. Но витрину такая система по-прежнему строит своими шаблонами, и это отличие в архитектуре, а не в наличии API. Сравнение популярных классических систем — в статье о том, какую CMS выбрать для сайта.

Факт. Модуль REST API расширяет функциональные возможности «1С-Битрикс: Управление сайтом». Программный интерфейс у классической CMS есть, но витрину она по-прежнему строит своими шаблонами.

Когда headless CMS подходит?

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

• Несколько каналов — один контент нужен на сайте, в мобильном приложении, в личном кабинете или на экранах в точках продаж.
• Портал из нескольких фронтендов — у сервиса публичная часть, кабинет клиента и кабинет партнёра, и все берут данные из одного места.
• Многоязычный проект — одна база материалов и отдельные витрины под рынки с разными шаблонами.
• Нестандартный интерфейс — калькуляторы, конфигураторы, интерактив, которые неудобно строить шаблонами классической CMS.
• Своя команда фронтенда — разработчики хотят работать в привычном фреймворке, а не в шаблонизаторе CMS.

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

Когда headless CMS не нужна?

Честная граница простая. Если у компании один сайт, один канал и нет собственных разработчиков, headless CMS почти наверняка лишняя. Корпоративный сайт, сайт-визитка, лендинг или каталог услуг прекрасно живут на классической CMS, где предпросмотр, формы, меню и поиск работают из коробки.

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

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

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

Модель контента: без неё headless не работает

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

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

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

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

Как поисковики видят сайт на headless CMS?

Сама headless CMS поисковикам не видна: они видят только фронтенд. Вопрос в том, как фронтенд отдаёт страницы. Если сайт собирает их в браузере, Google описывает риск прямо: у некоторых JavaScript-сайтов исходный HTML не содержит самого контента, и поисковику нужно выполнить скрипты, чтобы его увидеть.

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

У Яндекса для таких сайтов есть настройка в Вебмастере: «Индексирование -> Рендеринг страниц JavaScript». Справка предупреждает, что при выполнении JavaScript робот может создавать дополнительную нагрузку на сервер, и советует запретить рендеринг, если на сайте реализован SSR или пререндеринг.

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

Из чего складывается стоимость владения

Сравнивать headless и классическую CMS по цене лицензии бессмысленно: многие headless-системы бесплатны или имеют бесплатный тариф. Основные расходы лежат в другом месте.

Первое — фронтенд. Шаблоны, которые в классической CMS идут из коробки или из готового решения, здесь пишут с нуля: меню, хлебные крошки, формы, поиск, страница 404, карта сайта, мета-теги. Второе — размещение и обновления двух частей вместо одной. Третье — предпросмотр и удобство редакторов: без отдельной настройки редактор не видит, как материал будет выглядеть на сайте.

Четвёртое — люди. Классический сайт может поддерживать администратор с базовыми навыками. Headless-проект требует разработчика, который понимает и API, и фронтенд-фреймворк, и сборку. Если такой человек уходит, поддержка останавливается.

С чего начать

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

Если каналов несколько, следующий шаг — модель контента и прототип одного типа материала во всех каналах. Это покажет, сколько работы уйдёт на фронтенд, и даст честную оценку бюджета до выбора конкретной системы.

Мы проектируем и разрабатываем порталы и сервисы, где контент идёт в несколько каналов, и помогаем решить, нужна ли проекту headless-архитектура или хватит классической CMS.

Источники

• Общие сведения о поисковой оптимизации сайтов, использующих JavaScript — Центр Google Поиска
• Динамическая отрисовка как временное решение — Центр Google Поиска
• Индексирование страниц с JavaScript — Справка Яндекс Вебмастера
• Рендеринг в Интернете — web.dev
• Возможности REST API — курс «Администратор. Модули», 1С-Битрикс