Headless CMS проваливается не из-за API, а из-за плохой модели контента

Headless CMS проваливается не из-за API, а из-за плохой модели контента

За неделю в репах: почти все боли у headless начинаются не в интеграции, а раньше — когда поле «заголовок» пытаются использовать и для SEO, и для карточки, и для заголовка письма. В итоге фронт быстрый, а контент-редакторы тонут в исключениях.

Проверка перед стартом простая:
— у каждого типа есть один главный сценарий использования;
— повторяемые блоки вынесены в компоненты, а не копируются руками;
— обязательные поля минимальны, иначе редакция начнёт обходить правила;
— slug, canonical, OG и alt хранятся отдельно, а не в одном «мета»;
— связи между сущностями понятны: статья, автор, рубрика, промо-блок.

Есть наблюдение которое стоит проверить: чем меньше «магии» в модели, тем дешевле миграция. Если поле можно переиспользовать без костылей — хорошо. Если для каждого экрана нужен свой уникальный JSON, через полгода это уже не headless, а склад исключений.

Для лендингов headless удобен, когда контент часто меняют без участия разработчика. Для контент-сайта он выигрывает, если есть много каналов публикации: сайт, приложение, email, виджеты. Для mid-стека важнее не «какой CMS», а умеет ли она нормально отдавать структуру, права и предпросмотр.

Начинать стоит не с выбора платформы, а с карты сущностей. Если модель контента ясна на бумаге, headless экономит время; если нет — просто ускоряет хаос.