Что реально значит «headless»
В традиционной CMS та же система, что позволяет редактору написать пост в блог, также рендерит HTML-страницу, которую видит посетитель — «тело» (фронтенд) прикреплено к «голове» (управлению контентом).
Headless CMS оставляет только половину, отвечающую за управление контентом: редакторы по-прежнему получают привычный интерфейс для создания и организации контента, но вместо рендеринга страницы система отдаёт этот контент через REST или GraphQL API, чтобы любой фронтенд мог его забрать и показать как угодно.
Что вы получаете и чем жертвуете
Главный плюс — свобода фронтенда: один и тот же контент может питать веб-приложение на React, мобильное приложение и интерфейс смарт-ТВ из одного источника, а фронтенд-команда не ограничена тем, какой язык шаблонов поддерживает CMS.
Компромисс в том, что headless CMS по умолчанию не даёт редакторам визуального превью итоговой страницы (то, что они видят в редакторе, — не то, что видит посетитель, если не построить отдельную функцию превью), и в проекте теперь две системы, которые нужно поддерживать и защищать, вместо одной.
Когда этот компромисс реально стоит того
Он окупает свою сложность, когда контенту реально нужно попадать больше чем в один фронтенд (веб плюс мобильное приложение, например), когда фронтенд-команда хочет конкретный фреймворк, который CMS нативно не поддерживает, или когда проекту нужно масштабировать доставку контента независимо от конкретной технологии рендеринга.
Для простого проекта с одним сайтом, одним редактором контента и одним фронтендом традиционная CMS обычно проще в повседневной поддержке — headless это реальный архитектурный апгрейд под конкретный набор потребностей, а не строгое улучшение традиционной CMS во всех случаях.