<b>Headless CMS ломается не на выборе движка, а на плохой модели контента</b>

<b>Headless CMS ломается не на выборе движка, а на плохой модели контента</b>

Headless часто берут ради скорости фронта и свободы интеграций. Но дальше начинается типовая ошибка: в CMS переносят структуру старого сайта 1:1, как будто поля «заголовок / текст / картинка» решают задачу.

За неделю в репах повторяется одно и то же:
— контент-типов слишком мало, и один тип пытаются натянуть на лендинг, блог и каталог;
— слишком много связей, из-за чего редактору сложно публиковать без помощи разработчика;
— нет правил для локализаций, превью и обязательных полей.

Хорошая headless-модель строится от сценария публикации:
— один контент-тип = одна задача;
— переиспользуемые блоки выделяются отдельно;
— поля валидируются не только по типу, но и по смыслу;
— фронтенд получает стабильный API-контракт, а не набор случайных сущностей.

Если в проекте есть редакторы, сразу проверяйте три вещи: как они создают страницу, как собирают блоки и как видят результат до публикации. Без этого headless превращается в дорогой JSON-склад.

<i>Правило простое: сначала схема контента, потом выбор CMS, и только потом верстка.</i>