Если вы добавляете в программный продукт блог, журнал изменений или центр помощи, первая развилка — архитектурная. Вам нужна CMS, которая сама отрисует страницы, или та, что отдаст контент через API и не будет лезть в ваш фронтенд?
В этом и вся разница между традиционной CMS и headless. Всё остальное — цены, плагины, хостинг — следует из этого выбора.
Что делает традиционная CMS
Традиционная, или монолитная, CMS вроде WordPress объединяет в одной системе три вещи: интерфейс редактирования, базу данных контента и слой отрисовки, который превращает контент в HTML. Вы выбираете тему, редакторы пишут посты, а CMS отдаёт готовые страницы со своего сервера.
Эта модель отлично работает, когда сайт и есть продукт: онлайн-журнал, сайт ресторана, сайт-визитка компании. Вы получаете работающий сайт без строчки фронтенд-кода и зрелую экосистему плагинов, а редакторы без технических навыков могут поменять почти всё.
Издержки появляются, когда CMS должна жить внутри более крупного продукта:
Слой отрисовки чужой, а не ваш. Ваш блог выглядит как тема, а не как ваше приложение. Чтобы подогнать его под дизайн-систему, приходится воевать с шаблонизатором.
Это второй стек, который нужно обслуживать. PHP-приложение со своей базой данных, обновлениями и патчами безопасности, которое стоит рядом с вашим настоящим продуктом.
Контент застревает в одном представлении. Одну и ту же статью справки трудно отдать и на веб-страницу, и во встроенный в приложение виджет, и в поисковый индекс, потому что её писали как страницу, а не как данные.
Что делает headless CMS
Headless CMS оставляет интерфейс редактирования и базу данных контента, а слой отрисовки убирает. Контент выходит структурированным JSON через API, и ваше приложение отрисовывает его вашими компонентами на вашем домене.
На практике получить контент — это вызвать SDK из серверного кода:
const posts = await kookee.blog.list({ limit: 10 });
const article = await kookee.help.getBySlug('getting-started');Ваш фреймворк — Next.js, Astro, Nuxt, SvelteKit, любой, что умеет получать JSON, — превращает это в HTML так же, как отрисовывает остальной продукт.
Компромисс понятен: вы один раз пишете фронтенд, а взамен полностью управляете разметкой, стилями, маршрутизацией и производительностью. Для SaaS-команды, у которой уже есть дизайн-система и работающий фронтенд, это обычно выгодная сделка: фронтенд здесь — тонкий слой поверх компонентов, которые у вас уже есть.
Сравнение, которое важно на деле
Большинство сравнений «headless против традиционной» перечисляют абстрактные плюсы и минусы. Для SaaS-продукта выбор решают четыре вопроса.
Кому принадлежит дизайн?
Традиционная CMS: теме, а вы настраиваете то, что она разрешает. Headless: вам, полностью. Если блог и центр помощи должны выглядеть как ваш продукт — та же навигация, та же типографика, та же тёмная тема, — без костылей туда приводит только headless.
Где должен появляться контент?
Традиционная CMS выдаёт страницы. Headless CMS выдаёт данные, а данные можно отправить куда угодно: на маркетинговый сайт, в панель журнала изменений внутри приложения, в чат поддержки, который отвечает по статьям справки, в RSS-ленту, в мобильное приложение. Если в вашей дорожной карте есть что-то кроме «сайта», контент в виде структурированных данных окупается сразу.
Кто обслуживает инфраструктуру?
Традиционную CMS на своём сервере вы латаете вечно. На облачной headless-платформе редактор, базу данных, API и CDN обслуживает поставщик, а у вас остаётся только фронтенд-код в существующем репозитории. Его развёртывают, ревьюят и откатывают так же, как остальное приложение.
Что будет с SEO?
Это самое частое возражение против headless: «если контент приходит из API, увидит ли его Google?» Задача давно решена. При серверной отрисовке или статической генерации краулер получает обычный HTML по вашему адресу. Источник контента поисковикам не виден, важен домен, который отдаёт HTML, и в случае headless это ваш домен. Это однозначно лучше, чем держать блог на поддомене поставщика, где наработанный вами авторитет достаётся чужому сайту.
Где выигрывает каждая
Выбирайте традиционную CMS, если:
сайт — это самостоятельный контент без приложения вокруг;
никто в команде не пишет фронтенд и не хочет;
тема, которая подходит на 90%, вас устраивает.
Выбирайте headless CMS, если:
контент живёт внутри продукта со своим фронтендом или рядом с ним;
один и тот же контент идёт в несколько мест: на сайт, в приложение, в поиск, в ленты;
вы хотите выпускать контент на своём домене, в своём дизайне и через свой конвейер развёртывания.
Золотая середина: headless с запасным выходом
Слабое место headless — первый день: пока нет фронтенда, у вас есть API и нечего показать. Некоторые платформы закрывают этот разрыв готовым порталом — публичным сайтом с доской обратной связи, дорожной картой, журналом изменений и центром помощи, который работает ещё до того, как вы написали хоть строчку кода.
Kookee устроен именно так: у каждого проекта сразу есть необязательный портал по публичному адресу, и вы заменяете его раздел за разделом своими страницами по мере того, как пишете их на API. Портал работает с первого дня, а SDK потом даёт интерфейс, который целиком ваш, без переноса контента между системами.
Что выбрать SaaS-продукту
Для чисто контентных сайтов традиционная CMS по-прежнему хороший выбор по умолчанию. Для SaaS-продуктов схема уже устоялась: контент пишут в панели управления, отдают в JSON и отрисовывают собственным фронтендом продукта на его собственном домене. Вы сохраняете дизайн-систему, SEO работает на ваш домен, а контент остаётся переносимыми данными, а не запертыми страницами.
Решить можно на практике: попробуйте headless на одном разделе. Выведите пять последних постов своими компонентами. Если на это уйдёт полдня — а с типизированным SDK обычно так и выходит, — ответ у вас есть.