Headless CMS

В классической CMS хранилище контента и его отображение — одно целое: шаблон живёт внутри системы, и вёрстка привязана к её движку. Headless разрывает эту связь. Остаётся только «тело» — база, редакторский интерфейс, роли, версионирование, медиатека, — а «голова», то есть слой отображения, выносится наружу. Фронтенд запрашивает данные по REST или GraphQL и волен быть чем угодно: Next.js-сайтом, приложением на Flutter, экраном на киоске, витриной в Telegram Mini App.

Коммерчески headless выигрывает в двух ситуациях. Первая — контент нужен больше чем в одном месте: сайт, приложение, партнёрская выдача, карточки для маркетплейса. Держать четыре копии описаний товаров в четырёх системах дороже, чем один источник правды с API. Вторая — требования к скорости и к интерфейсу выше среднего: собственный фронтенд позволяет добиться нужных Core Web Vitals и нестандартных сценариев покупки, не воюя с чужим шаблонизатором. В России роль headless часто играет и связка «1С или собственная учётная система как источник данных плюс отдельный фронтенд».

Ловушка — считать headless по умолчанию более современным и потому более правильным. Вы платите за него дважды: фронтенд теперь разрабатывается отдельно (плюс к смете), а всё, что в коробочной CMS шло из коробки — предпросмотр, редиректы, sitemap, формы, поиск по сайту, — приходится реализовывать руками. Для корпоративного сайта на 30 страниц с одним каналом публикации headless чаще всего проигрывает обычной CMS и по срокам, и по стоимости владения. Разумный критерий: если каналов один и он останется одним ближайшие два года, headless не нужен.

Смежные термины

• APIAPI — зафиксированный набор правил, по которым одна программа запрашивает данные или действия у другой: адреса методов, формат запроса и ответа, авторизация и лимиты, описанные так, чтобы обе стороны могли меняться независимо.
• SSR и CSRSSR и CSR — два способа получить HTML: при серверном рендеринге страница собирается на сервере и приходит готовой, при клиентском браузер получает пустой каркас и дорисовывает содержимое JavaScript-ом уже после загрузки.
• МонолитМонолит — приложение, которое собирается и разворачивается одним куском: весь код лежит в общем репозитории и выполняется в одном процессе, работает с одной базой и выкатывается целиком, что даёт простоту разработки ценой связанности.
• Core Web VitalsCore Web Vitals — три метрики скорости и стабильности страницы от Google: LCP (отрисовка главного элемента) должен укладываться в 2,5 секунды, INP (отклик на действие) — в 200 миллисекунд, CLS (сдвиг вёрстки) — в 0,1.
• PWAPWA — сайт, который ведёт себя как приложение: устанавливается на домашний экран прямо из браузера, работает офлайн за счёт service worker и умеет присылать push-уведомления, но не требует публикации в App Store и Google Play.

Услуги по теме

• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• Разработка интернет-магазинаМагазин — это не витрина, а операционный инструмент: каталог, оплата, доставка, склад и заказы должны работать вместе. Собираем так, чтобы им можно было управлять без разработчика.

Почитать подробнее

• На чём делать сайт в 2026: Tilda, WordPress, Битрикс или Next.jsКонструктор, CMS или собственная разработка — выбор зависит не от вкуса, а от сценария и горизонта планирования. Разбираем стоимость владения за три года, потолки платформ и цену переезда, если вы ошиблись на старте.
• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.