Если контент сайта редактируют только разработчики и страниц немного - отдельная система управления контентом не нужна: текст можно хранить прямо в репозитории рядом с кодом. Если контент публикует нетехническая команда, объём растёт, а редакторов больше одного-двух - без отдельной платформы сайт быстро упрётся в разработчика как в единственный канал публикации. Граница проходит не через размер компании, а через два конкретных признака: кто редактирует контент и как часто.
В проектах веб-разработки для SaaS и B2B-сайтов мы регулярно видим один и тот же паттерн: команда выбирает CMS в первую неделю проекта, ещё до того как понятно, кто и как часто будет публиковать контент. Через полгода выясняется, что редактор в CMS открывает раз в квартал только сам разработчик, а ежемесячная подписка на SaaS-платформу тем временем продолжает списываться. Реже встречается обратная ситуация: контент годами живёт в файлах прямо в коде, а когда в команду приходит маркетолог, любое изменение текста превращается в тикет для разработчика и ожидание релиза.
Дальше - конкретный разбор того, что такое Content Collections в Astro, чем они принципиально отличаются от Headless CMS, и какие два вопроса на самом деле определяют, нужна ли вашему сайту отдельная система управления контентом.
Боль здесь не абстрактная. Компания либо переплачивает за инфраструктуру, которой не пользуется, либо разработчик становится бутылочным горлышком для любой правки текста - опечатки, обновления цен, нового кейса в блоге. Оба сценария стоят реальных денег: в первом случае - счёт за подписку, во втором - часы разработчика и задержка публикации, которая срывает маркетинговый план.
Content Collections: встроенный в Astro механизм хранения структурированного контента - Markdown или MDX-файлов - прямо в репозитории проекта, с типобезопасной схемой и без отдельной базы данных или API.
Headless CMS: система управления контентом, которая хранит и редактирует контент отдельно от кода сайта и отдаёт его через API - Sanity, Contentful, Strapi, Payload и подобные платформы.
Что такое Astro Content Collections на самом деле
Content Collections - это не облегчённая версия CMS, а способ обращаться с Markdown и MDX-файлами как с типизированными данными. Контент лежит в папке src/content/ в том же репозитории, что и код сайта, а не в отдельной базе данных на стороне вендора.
Схема каждой коллекции описывается через Zod - библиотеку валидации типов для TypeScript. Разработчик один раз задаёт, какие поля обязательны у статьи блога - заголовок, дата публикации, теги, - и дальше редактор получает ошибку сборки, если поле пропущено или указано неверного типа, ещё до деплоя.
Запрос контента из компонента выглядит как обычный вызов функции getCollection('blog'), а не HTTP-запрос к внешнему API. Это устраняет сетевой запрос на этапе сборки и убирает зависимость от доступности стороннего сервиса в момент деплоя.
Главное следствие такой архитектуры - версионирование. Каждое изменение текста проходит через тот же git-репозиторий, что и код: откат, история правок и код-ревью для контента работают ровно так же, как для любого пул-реквеста. Официальная документация Astro описывает это как встроенный слой типобезопасности поверх файловой структуры, а не отдельный продукт.
Два вопроса, которые определяют, нужна ли вам система управления контентом
Решение редко зависит от размера компании или бюджета - чаще от двух конкретных параметров: кто физически редактирует контент и как часто это происходит.
Первый вопрос - кто редактирует. Если контент правят только разработчики - через пул-реквест, в своей среде разработки, с ревью кода, - Content Collections полностью закрывают задачу и не требуют ничего сверх того, что уже есть в проекте. Если правки вносит маркетинг, копирайтер или CEO без доступа к git, каждая правка через разработчика создаёт очередь, и она растёт вместе с командой.
Второй вопрос - частота обновлений. Сайт с 5-10 статичными страницами, который обновляется раз в месяц или реже, не создаёт достаточной нагрузки, чтобы оправдать отдельный слой CMS: MDX-файл и пул-реквест решают задачу быстрее, чем логин в админ-панель стороннего сервиса. Блог с несколькими публикациями в неделю от разных авторов - другая история: очередь пул-реквестов на контент начинает конкурировать с очередью на фичи, и это уже архитектурная проблема, а не вопрос вкуса.
Когда хватает кода без всего
Небольшой B2B-сайт или маркетинговый лендинг, где весь контент пишет и правит инженерная команда, - типовой случай, где Content Collections закрывают задачу полностью и бесплатно.
Технической команде из двух-трёх человек, которая уже работает в git, не нужно осваивать интерфейс ещё одного SaaS-сервиса ради пяти статических страниц. MDX-файл открывается в том же редакторе кода, что и компонент, использует те же переменные окружения и деплоится тем же пайплайном, что и остальной сайт - без отдельного билд-шага под контент.
В типовом проекте сайта с нуля для раннего SaaS - несколько продуктовых страниц, блог с редкими публикациями, страница цен - настройка Content Collections вместе со схемой занимает разработчику меньше рабочего дня. Для сравнения: подключение и настройка полноценного Headless CMS с ролями редакторов и вебхуками деплоя обычно занимает от трёх до пяти дней даже на готовой платформе.
Когда без Headless CMS не обойтись
Как только редактировать контент должен кто-то без доступа к git - маркетолог, продакт-менеджер, CEO без технического бэкграунда, - Content Collections перестают закрывать задачу, независимо от размера сайта.
Headless CMS даёт нетехническому редактору интерфейс, в котором не видно ни строчки кода: форму с полями, предпросмотр и кнопку публикации. Sanity, Contentful, Strapi и Payload решают эту задачу по-разному - по цене, модели развёртывания и глубине визуального редактора. Разбор конкретных различий и когда какая платформа выигрывает - в статье Sanity vs Contentful vs Strapi: выбор Headless CMS для B2B-сайта.
Официальный гайд Astro по подключению CMS подтверждает тот же принцип: фреймворк не диктует выбор конкретной платформы, интеграция подключается по мере необходимости, а не по умолчанию для каждого проекта.
Отдельный случай - команда, которая хочет держать контроль над данными и не готова платить SaaS-подписку за каждого редактора, но при этом редакторам всё равно нужен интерфейс без кода. Для такого сценария self-hosted вариант вроде Payload CMS часто оказывается компромиссом между полным контролем разработчика и удобством редактора - разбор архитектуры и реальной стоимости владения в статье Payload CMS: когда выбирать вместо Strapi и Sanity.
Скрытая цена решения - в обе стороны
Оба варианта ошибки стоят реальных денег, просто по-разному распределённых во времени.
Слишком рано внедрили CMS
Подписка на Headless CMS начинается от нескольких десятков долларов в месяц на growth-тарифах и растёт вместе с числом пользователей и объёмом контента. Для команды из двух разработчиков, которые сами пишут все тексты, это - постоянный счёт за функциональность, которой физически не пользуется никто, кроме них самих.
К подписке добавляется архитектурная цена: Headless CMS - это ещё один внешний API, от доступности которого зависит сборка или рендер сайта. Каждый дополнительный сервис в цепочке - это ещё одна точка отказа и ещё один набор токенов доступа, за ротацией которых нужно следить.
Слишком долго откладывали CMS
Обратная ошибка менее заметна на старте, но дороже на длинной дистанции. Когда контент сайта живёт в коде дольше, чем команда остаётся чисто технической, разработчик становится единственным каналом публикации - и любое изменение текста конкурирует за его время с разработкой фич.
В типовом B2B-проекте, где маркетинг растёт быстрее инженерной команды, очередь правок контента через пул-реквесты начинает занимать от нескольких часов до целого рабочего дня разработчика в неделю - время, которое не создаёт нового функционала, а тратится на то, что интерфейс редактора решил бы за минуты. Дальнейшая поддержка сайта в такой конфигурации становится дороже именно из-за этой очереди, а не из-за сложности самого кода.
Реальный кейс - цифры
В типовом проекте запуска маркетингового сайта для B2B SaaS с командой из трёх инженеров и без отдельного контент-менеджера настройка Content Collections вместе со схемой блога, кейсов и страниц продукта занимает 4-6 часов работы разработчика - без ежемесячных расходов на CMS.
Через 8-10 месяцев роста, когда в команду приходит первый маркетолог без доступа к git, типичный сценарий - миграция части контента (блог, кейсы, лендинги под кампании) на Headless CMS, а описание продукта и юридические страницы остаются в Content Collections, потому что их по-прежнему редактируют только разработчики. Гибридная схема, когда часть контента остаётся в коде, а часть переезжает в CMS, встречается в подобных проектах чаще, чем выбор одного варианта на весь сайт целиком.
Для кого какой вариант подходит
Content Collections без какой-либо CMS подходят техническим стартапам и продуктовым командам, где весь контент пишут и правят инженеры или технически подкованный фаундер, а число статичных страниц измеряется единицами и первыми десятками.
Headless CMS оправдан, как только в процесс публикации входит хотя бы один человек без доступа к git - маркетолог, контент-менеджер, копирайтер на аутсорсе, - или число публикаций превышает несколько в неделю. Компаниям с 15+ сотрудниками и отдельной маркетинговой командой отдельная CMS в подавляющем большинстве случаев уже оправдана к моменту, когда вопрос вообще встаёт всерьёз.
Часто задаваемые вопросы
Нужна ли сайту система управления контентом, если сайт маленький?
Не всегда. Если сайт - это 5-10 страниц, которые обновляют только разработчики, а частота изменений - раз в месяц или реже, Content Collections в Astro закрывают задачу полностью: контент хранится в репозитории, деплоится вместе с кодом и не требует ни подписки, ни отдельного API. Отдельная CMS становится оправданной, когда в редактирование включается человек без доступа к git или объём публикаций растёт.
Чем Content Collections отличаются от Headless CMS?
Content Collections хранят контент прямо в репозитории проекта в виде Markdown или MDX-файлов со схемой на Zod - без базы данных и без API, контент версионируется вместе с кодом через git. Headless CMS хранит контент отдельно, на стороне вендора или на собственном сервере, и отдаёт его сайту через REST или GraphQL API, что даёт нетехническим редакторам отдельный интерфейс без доступа к коду.
Можно ли начать с Content Collections и потом перейти на Headless CMS?
Да, и на практике это распространённый путь. Content Collections хранят контент в обычных Markdown/MDX-файлах, поэтому перенос в Headless CMS - это в первую очередь задача маппинга полей под новую схему, а не переписывание архитектуры сайта с нуля. Многие команды переносят только часть контента - например блог и кейсы, - оставляя статичные страницы продукта в Content Collections.
Сколько стоит содержать сайт без CMS против сайта с Headless CMS?
Content Collections не добавляют прямых расходов - контент разворачивается вместе с остальным сайтом на существующей инфраструктуре хостинга. Headless CMS добавляет отдельный счёт: от бесплатных self-hosted тарифов вроде Strapi и Payload, где расходы уходят в инфраструктуру сервера, до 50-100 и более долларов в месяц на growth-тарифах управляемых SaaS-платформ вроде Sanity, растущих вместе с числом редакторов и объёмом контента.
Кто должен принимать решение - разработчик или маркетинг?
Решение стоит принимать совместно, потому что критерии касаются обеих сторон: разработчик оценивает архитектурную сложность и стоимость поддержки, а маркетинг - потребность в независимости от разработчика при публикации. Если решение принимает только инженерная команда, велик риск недооценить, насколько быстро отсутствие CMS превратится в узкое место для контент-плана.
Если вы выбираете архитектуру для нового сайта или уже упёрлись в очередь правок контента через разработчика - опишите задачу команде Exceltic.dev. Разберём, какой у вас объём контента и какая команда редакторов, и предложим архитектуру - с Headless CMS или без неё.