Headless CMS предлагают как современную замену обычным платформам, хотя задача у неё другая. Разбираем, что это за подход и когда он действительно нужен.
Коротко
- Контент отдаётся по API.
- Полезно при нескольких точках вывода.
- Требует разработчиков постоянно.
- Для сайта компании обычно избыточно.
В чём суть подхода
Обычная CMS
- Хранит контент
- И сама формирует страницы
- Шаблоны внутри системы
- Результат — готовый сайт
Headless
- Хранит контент
- Отдаёт его по API
- Отображение — отдельное приложение
- Результат — данные, а не страницы
Отсюда и название: у системы нет «головы» — той части, что показывает страницы посетителю. Это не улучшенная версия обычной CMS, а разделение задач: удобно, когда один и тот же контент нужен в нескольких местах, и лишняя сложность, когда место одно.
Когда это оправдано
| Ситуация | Почему подход помогает |
|---|---|
| Сайт и мобильное приложение | Один контент, два вывода |
| Несколько сайтов на одной базе | Правка в одном месте |
| Витрины на разных языках и регионах | Общее хранилище |
| Контент нужен внешним системам | API уже есть |
| Своя команда разработки | Есть кому поддерживать |
| Высокие требования к скорости | Больше контроля над выводом |
Первые три строки объединяет одно: контент используется больше чем в одном месте. Это и есть настоящее основание для такого выбора — всё остальное обычно достижимо и на обычной платформе более коротким путём.
Что усложняется
| Что | Как это ощущается |
|---|---|
| Нужны разработчики постоянно | Любая правка вывода — через них |
| Предпросмотр сложнее | Редактор не видит результат сразу |
| Больше составных частей | Больше мест, где ломается |
| Дороже поддержка | Две системы вместо одной |
| Меньше готовых решений | Формы, поиск, корзину делают руками |
| Труднее найти исполнителя | Уже круг специалистов |
Вторая строка сильнее всего влияет на повседневную работу. В обычной CMS редактор видит страницу такой, какой её увидит посетитель; в headless предпросмотр нужно специально разрабатывать, и до этого контент правят «наугад».
Что важно для поиска
Решить, где формируются страницы
На сервере или в браузере.
Проверить, что видит робот
Содержимое, а не пустой каркас.
Не терять теги и разметку
Их легко забыть в приложении.
Сохранить адреса страниц
Осмысленные и постоянные
Настроить карту сайта
Её нужно генерировать самому.
Проверить скорость на телефоне
Приложения бывают тяжёлыми.
Второй шаг обязателен: именно здесь чаще всего теряют трафик. Если содержимое дорисовывается в браузере, робот может увидеть пустую страницу — про это в статьях про JavaScript-сайты и SEO и SSR, SSG и гидратацию.
Когда это избыточно
| Ситуация | Что разумнее |
|---|---|
| Один сайт компании | Обычная CMS |
| Нет своей команды разработки | Обычная CMS |
| Контент ведёт один человек | Обычная CMS |
| Нужен быстрый запуск | Готовая платформа |
| Причина выбора — «современно» | Пересмотреть причину |
Последняя строка — та, из-за которой подход чаще всего выбирают напрасно. Современность архитектуры не даёт бизнес-результата сама по себе, а поддержку усложняет заметно: спрашивать стоит, какую конкретную задачу это решает у вас.
Какие вопросы задать подрядчику
| Вопрос | Зачем |
|---|---|
| Какую задачу это решает у нас | Проверить основание |
| Кто будет поддерживать через год | Круг исполнителей узкий |
| Как редактор увидит предпросмотр | Иначе правки наугад |
| Где формируются страницы | Влияет на индексирование |
| Что будет при отказе хранилища | Появилась новая зависимость |
| Сколько стоит владение в год | Две системы вместо одной |
Первый вопрос обычно и заканчивает разговор. Если внятного ответа про вашу задачу нет, значит подход выбран по привычке исполнителя — а платить за усложнение будете вы. Как выбирать исполнителя — в статье про выбор студии разработки.
Частые вопросы
Что такое headless CMS?
Система, которая хранит контент и отдаёт его по API, но не формирует страницы: отображением занимается отдельное приложение. Это разделение задач, а не улучшенная обычная CMS.
Когда такой подход оправдан?
Когда контент используется больше чем в одном месте: сайт и приложение, несколько сайтов на одной базе, витрины для разных регионов, внешние системы.
Что усложняется?
Нужны разработчики постоянно, предпросмотр приходится разрабатывать отдельно, частей больше, поддержка дороже, а готовых решений для форм и поиска меньше.
Нужна ли она обычному сайту компании?
Как правило нет. Если сайт один, своей команды разработки нет и контент ведёт один человек, обычная CMS решает задачу проще и дешевле.
Сделаем сайт, который приносит заявки
Спроектируем структуру под запросы, соберём и запустим — с учётом SEO с первого дня.
Обсудить разработку
