Введение: “мы сделаем как в больших компаниях” — и угробим бюджет
Headless CMS + статический сайт (JAMstack, SSG, все эти умные буквы) звучит как мечта: быстро, безопасно, “SEO будет летать”, “админка удобная”, “фронт на современном”. И владелец бизнеса уже видит себя техно-магнатом.
А потом внезапно выясняется: вы не Netflix. Вы ИП/ООО, у вас менеджер, который “чуть-чуть поправить текст”, маркетолог, которому “лендинг нужен вчера”, и бухгалтерия, которая не понимает, почему сайт теперь стоит как подержанная Camry.
Я не против headless. Я против цирка, когда архитектуру выбирают не под бизнес, а чтобы разработчик мог похвастаться в чате.
Что такое headless CMS + статический сайт по-человечески
Headless CMS — это админка, где вы храните контент (тексты, картинки, товары), а сайт забирает его через API.
Статический сайт — страницы заранее собираются и раздаются как файлы (часто через CDN), поэтому он реально может быть очень быстрым.
В теории: скорость, безопасность, гибкость.
В практике: ещё один слой технологий, ещё один счёт, ещё одна точка отказа.
Когда это оправдано
1) У вас контент-производство как процесс, а не “раз в год обновили прайс”
Если вы постоянно публикуете статьи, кейсы, посадочные, у вас редакторы и согласования — headless CMS может стать нормальным “складом контента”. Особенно если нужны роли, статусы, ревью.
Но важное: процесс должен быть. Если у вас хаос — headless не лечит хаос, он его просто делает дороже.
2) Вам нужна мультиплатформа: сайт + приложение + ещё что-то
Один контент — в разные каналы: сайт, мобильное приложение, терминалы, партнёрские витрины. Тут headless CMS логичен: один источник данных, много витрин.
3) Нужны нестандартные интерфейсы и контроль над фронтом
Если у вас сложный дизайн, кастомные блоки, интерактив, и вы не хотите драться с ограничениями шаблонов — да, headless + фронт на React/Vue/whatever может быть разумным.
4) У вас есть техподдержка, а не “сын знакомого сделал”
Самый важный критерий: кто это обслуживает. Статика + headless — это:
- сборка,
- деплой,
- интеграции,
- токены доступа,
- вебхуки,
- версии,
- иногда отдельный поиск.
Если поддержка “по настроению” — это не архитектура, это лотерея.
Когда это цирк (и почему вы заплатите дважды)
1) Вам нужно “просто сайт услуг” и правки 2 раза в месяц
Для типового сайта услуг headless CMS статический сайт — это как покупать погрузчик, чтобы донести пакет из магазина. Можно. Но вы точно не туда инвестируете.
2) Маркетинг должен быстро тестировать и менять страницы
Статика часто означает: поменяли контент → пересобрали → задеплоили.
Если у вас 10 правок в день (акции, офферы, формы, блоки), вы очень быстро начнёте ненавидеть “современный стек”.
Да, есть инкрементальные сборки, preview, всякие оптимизации. И всё это снова: настройка, деньги, специалисты.
3) Вам втюхали headless ради “безопасности”
Безопасность — аргумент хороший, но часто им прикрывают банальное: “я не хочу возиться с WordPress”.
Если сайт простой, можно сделать безопасно и на привычных системах: обновления, доступы, бэкапы, WAF. Это дешевле, чем городить космолёт.
4) Вы не посчитали TCO — стоимость владения
Любимая ошибка бизнеса: считать только разработку. А надо считать:
- лицензии/подписки headless CMS,
- хостинг/CI/CD,
- поддержка (часы разработчика),
- доработки (а они будут),
- стоимость “быстрых правок”.
Если вам важны деньги: headless — не “экономия”, headless — “инвестиция”. Иногда умная, иногда тупая.
Практическая польза: как принять решение без самообмана
Я использую простой фильтр “3 вопроса”:
- Кто и как часто меняет контент?
Если контент меняется часто и не разработчиком — нужна удобная админка и предпросмотр, иначе будет вечный бардак. - Насколько критична скорость вывода изменений?
Если промо/реклама завязаны на часы — статика без отлаженного пайплайна будет тормозом. - Кто отвечает за поддержку 12–24 месяца?
Если ответа нет — всё, стоп. Не надо.
Бонус: если вам нужно “SEO”, то помните: поиску плевать на ваш стек. Ему важны структура, контент, скорость, индексация, внутренние ссылки. Статический сайт генератор CMS — это инструмент, а не святая вода.
Типичные ошибки и решения
Ошибка 1: “Сделаем headless, и маркетолог сам всё будет делать”
Решение: делегирование работает только при нормальной модели контента и интерфейсе. Иначе маркетолог будет орать, а разработчик — “это не баг, это фича”.
Ошибка 2: “Возьмём дешёвую headless CMS, дальше само”
Решение: дешёвая CMS часто означает дорогую интеграцию и ограничения. Считайте не подписку, а полную стоимость внедрения и поддержки.
Ошибка 3: “Нам не нужен предпросмотр, мы и так понимаем”
Решение: без preview вы получите бесконечные “почему на сайте не так” и правки по кругу. Предпросмотр — мастхэв.
Ошибка 4: “Соберём на SSG, а поиск/формы/заказы потом”
Решение: “потом” всегда дороже. Если есть лидогенерация и заявки — сразу продумайте формы, CRM, спам-защиту, уведомления, аналитику.
Вывод
Headless CMS + статический сайт — оправдано, когда у вас контент как система, мультиканальность, сложный фронт и есть поддержка.
Цирк — когда вам нужен обычный сайт, но кто-то захотел поиграть в “современный стек” за ваш счёт.
Выбирайте не “модно”, а “управляемо”: сколько стоит правка, кто её делает, и как быстро бизнес может запускать новые деньги на сайт.
