Обычная система управления сайтом делает две работы сразу: хранит тексты и картинки и сама же показывает их посетителю в виде страницы. WordPress, Bitrix, Joomla устроены именно так. Headless CMS отрезает вторую часть. Она остаётся хранилищем контента с удобной админкой, а отдавать его наружу начинает через API - обычный запрос, в ответ на который приходят данные в формате JSON. Как эти данные превратятся в страницу, решает уже отдельное приложение: сайт на Next.js, мобильное приложение, экран в магазине или витрина маркетплейса.
Что это даёт на практике
Первый выигрыш - скорость. Когда витрина отделена от админки, страницы можно собирать заранее и отдавать пользователю уже готовыми, без обращения к базе данных при каждом визите. Для сайтов с большим каталогом разница в скорости заметна невооружённым глазом и хорошо видна в Core Web Vitals.
Второй - один источник контента для нескольких каналов. Описание услуги редактируется в одном месте, а появляется одновременно на сайте, в приложении и, например, в рассылке. Если у компании только сайт, этот плюс не работает вообще.
Третий - безопасность. Админка headless CMS часто живёт на отдельном домене или вообще в облаке провайдера, а публичный сайт представляет собой набор статических файлов. Взламывать там нечего: нет ни плагинов, ни формы входа на видном месте.
Чего headless CMS не даёт
- Готового визуального конструктора страниц. Контент-менеджер заполняет поля, а не двигает блоки мышкой по макету.
- Мгновенного предпросмотра из коробки. Предпросмотр настраивается отдельно и стоит времени разработчика.
- Экономии на старте. Проект на headless почти всегда дороже шаблонного сайта на WordPress, потому что витрину пишут с нуля.
- Независимости от подрядчика. Плагин к WordPress поставит любой фрилансер, а в кастомную витрину нужно сначала вникнуть.
Кому подходит
Headless оправдан, когда есть хотя бы один из признаков: большой каталог, где скорость напрямую влияет на продажи; несколько каналов, куда идёт один и тот же контент; нестандартная логика витрины, которую в готовой CMS пришлось бы обвешивать плагинами; строгие требования к безопасности и отказоустойчивости. В этих случаях дополнительная стоимость разработки окупается за счёт скорости, гибкости и меньших расходов на защиту сайта.
Сайту компании на двадцать страниц, который обновляется раз в месяц, headless не нужен. Там выигрыш в скорости измеряется долями секунды, а неудобство редактирования ощущается каждый раз. Обычная CMS с хорошим кешированием и оптимизированными картинками решит задачу дешевле и проще.
Как выбирать конкретное решение
На рынке есть облачные headless CMS с помесячной оплатой и решения, которые ставятся на свой сервер. Облачные быстрее стартуют, но стоимость растёт вместе с количеством пользователей и объёмом запросов. Свои требуют сервера и обновлений, зато контент физически остаётся у вас, что бывает важно для требований GDPR.
Перед выбором стоит задать три вопроса: кто будет наполнять сайт и насколько этот человек технический; сколько стоит перенести контент, если провайдер поднимет цены; есть ли у выбранного решения нормальный экспорт данных. Ответы на них влияют на итоговую стоимость владения сильнее, чем любые сравнительные таблицы функций.
Промежуточный вариант
Между классической и headless CMS есть компромисс, о котором редко говорят: оставить привычную систему как админку, но отдавать данные наружу через её собственный API, а витрину собрать отдельно. У WordPress такой интерфейс есть из коробки. Контент-менеджер продолжает работать в знакомом окружении, редакция ничему не переучивается, а сайт получает скорость статической выдачи.
У подхода своя цена: вы платите за два окружения вместо одного и отвечаете за синхронизацию между ними. Зато переход можно сделать постепенно, раздел за разделом, не останавливая работу сайта и не переливая сразу весь контент. Для компании, у которой уже есть наполненный сайт и живой поисковый трафик, это обычно самый безопасный маршрут: адреса страниц сохраняются, позиции не проседают, а бюджет растягивается на несколько этапов вместо одного большого проекта.