Справочник для тех, кто проектирует контентные проекты, подключает ИИ-агентов к Notion или просто хочет понимать, где живут данные, кто ими управляет и кто их показывает.
Когда я впервые увидел связку «Notion + сайт», у меня в голове всё смешалось. Кажется, что Notion — это и база, и редактор, и сайт. Но когда пришло время подключать ИИ-агента, который должен редактировать статьи и не ломать вёрстку, я понял: нельзя работать с системой, пока не понимаешь, какая её часть за что отвечает.
CMS, база данных и сайт — это три разные роли. Их часто путают, потому что в простых системах (WordPress, Tilda) они слиты в одну. В современных архитектурах они разделены — и это даёт ту самую гибкость, которая нужна агентам, мультиплатформенной выдаче и спокойной миграции.
Что это
Любой контентный проект — это три сущности, которые отвечают на три разных вопроса.
База данных — хранилище. Надёжное место для структурированных данных: страницы, свойства, связи между записями, метаданные. Сюда никто не заходит «просто посмотреть» — база общается с внешним миром только через API. PostgreSQL, Supabase, встроенная база Notion — всё это про хранение.
CMS — интерфейс управления. То, через что человек (или агент) создаёт, редактирует, организует контент. Notion, Directus, Strapi, WordPress — это редакторы, которые умеют говорить с базой и отдавать данные наружу в стандартном формате.
Сайт — витрина. То, что видит посетитель в браузере. Сайт забирает контент из CMS через API и рендерит его в HTML. Next.js, Astro, любой фронтенд — это слой показа.
В монолитных системах (классический WordPress, Tilda, ранние CMS) все три роли слиты в одну программу. В headless-архитектуре они разнесены по разным сервисам и общаются через API.
Ключевое правило: если вы меняете контент, не трогая сайт, — у вас разделение слоёв. Если для смены текста нужно лезть в админку, деплоить, чистить кеш — слои слиты.
Зачем нужно
Разделение на три слоя — это не академическая красота. Это конкретные практические выигрыши, которые экономят недели при росте проекта.
- Гибкость стека. Контент живёт в Notion, а рендерить его можно на Next.js, Astro или статическом генераторе. Меняется только витрина — данные те же.
- Мультиплатформенная выдача. Один и тот же контент отдаётся на сайт, в мобильное приложение, в Telegram-канал, в дайджест-рассылку. CMS — одна, потребителей — сколько угодно.
- Агенты работают с CMS, а не с сайтом. ИИ-агент создаёт черновики, заполняет свойства, переводит статус в «Опубликовано». Сайт сам подхватывает изменения. Агенту не нужны права на деплой, FTP или репозиторий — только доступ к CMS.
- Миграция без боли. Когда придёт время менять CMS (или фронтенд, или базу), вы меняете один слой. Остальные продолжают работать по договорённости через API.
- Разные люди для разных слоёв. Редактор работает в Notion и не лезет в код. Разработчик пишет код и не трогает контент. Это разделение ролей — оно становится возможным, только когда слои разделены архитектурно.
- Кеширование и производительность. Сайт забирает данные из CMS раз в минуту (или раз в час) и кеширует. CMS не нагружается каждым посетителем. База защищена от пиков трафика.
Как устроено
Общая схема взаимодействия:
flowchart LR
A["База данных"] --> B["CMS"]
B --> C["Сайт"]
A -->|прямой доступ через API| C
D["Человек / Агент"] --> BБаза данных и CMS часто находятся на одном сервере (так делает Notion — его «база» встроена в редактор). Сайт — это отдельный фронтенд, который читает данные через API. Человек и ИИ-агент работают только с CMS, не с сайтом напрямую.
Сравнение трёх ролей:
| Параметр | База данных | CMS | Сайт |
|---|---|---|---|
| Что делает | Хранит данные | Управляет контентом | Показывает пользователю |
| Кто работает | Сервер | Редактор / агент | Посетитель |
| Примеры | PostgreSQL, Supabase, встроенная БД Notion | Notion, Directus, Strapi, WordPress | Next.js, Astro, любой frontend |
| Доступ | Только через API | Интерфейс + API | Браузер |
| Работает без других | Да | Нужна база | Нужен контент |
Два основных типа CMS по отношению к сайту:
Монолитная CMS — CMS и сайт в одной программе. Редактор работает в админке, сайт отображает контент из той же системы. WordPress и Tilda — самые известные примеры.
Плюсы: быстрый старт, всё в одном месте, минимум настроек. Минусы: контент привязан к одному сайту, сложно масштабировать, агенту приходится работать с той же системой, что и посетителю.
Headless CMS — CMS отделена от сайта. Контент управляется в редакторе, а сайт (или мобильное приложение, или Telegram-бот) получает данные через API. Один контент — много потребителей.
Примеры: Notion (как headless CMS), Directus, Strapi, Contentful, Sanity.
Notion особенно интересен в роли headless CMS: редактор работает в знакомом интерфейсе блоков, свойства базы хранят метаданные (slug, описание, категория, статус), а сайт забирает страницы через Notion API и рендерит их.
Когда использовать
| Ситуация | Что подходит | Почему |
|---|---|---|
| Визитка, лендинг без регулярных обновлений | Монолитная CMS (Tilda) | Контент меняется раз в год, разделение слоёв не даст выигрыша |
| Блог одного автора | Headless CMS (Notion + Astro) | Редактор пишет в Notion, сайт собирается автоматически |
| Контент на сайт + в мобильное приложение + в рассылку | Headless CMS обязательно | Один контент, много потребителей, общая точка правды |
| ИИ-агент публикует материалы | Headless CMS с API | Агент работает с CMS, а не с деплоем сайта |
| Несколько авторов, разные роли (редактор, разработчик) | Headless CMS | Разделение полномочий становится архитектурным, а не организационным |
| Быстрый MVP за выходные | Монолитная CMS | Скорость запуска важнее гибкости |
Пример
Архитектура vorobeoffai.ru устроена так:
- CMS — Notion. Пять баз: Блог, Статьи, База знаний, Кейсы, Промпты. Контент редактируется в Notion — там же, где его пишет автор.
- База данных — встроенная в Notion. Свойства (slug, описание, категория, статус публикации, дата) хранят метаданные рядом с текстом. Отдельный сервер не нужен.
- Сайт — Astro. Сборщик запрашивает данные из Notion через API, рендерит статические страницы и складывает результат в
dist/. - Агент — работает с Notion как с CMS. Создаёт черновики, заполняет свойства, переключает статус на «Опубликовано». Сайт сам подхватывает изменения при следующей сборке.
Именно разделение на слои делает возможным такой контур: человек или агент работает с контентом, не касаясь деплоя, а деплой работает по своим правилам, не касаясь контента.
Ограничения
Ограничения
Что учитывать
Headless CMS требует разработчика на старте.
Монолитная запускается за час, headless — за день-два. Выигрыш появляется при росте, а не на первом сайте.
API между CMS и сайтом — единая точка отказа.
Если API лежит, сайт не обновится. Для статической генерации это терпимо, для динамического рендеринга на лету — критично.
Кеширование обязательно.
Без кеша каждый посетитель = запрос к CMS. Notion API имеет лимит 3 запроса в секунду — при средней нагрузке это упрётся в первые сутки.
Права доступа настраиваются отдельно для каждого слоя.
В монолитной CMS «админ = всё». В headless-архитектуре админ CMS ≠ админ сервера ≠ владелец API-ключа. Это безопаснее, но требует дисциплины.
Версионирование API — ваша головная боль.
CMS может выпустить новую версию API, и интеграция сломается. Подписывайтесь на changelog с первого дня.
Не всем проектам нужно разделение.
Для простой визитки Tilda достаточно, и никакая headless-архитектура не сделает её лучше. Сложность — это налог за гибкость, и его нужно оправдывать.
Антипаттерны
Антипаттерны
Чего не делать
Делать headless «на будущее» при простой визитке.
Вы получите лишний слой сложности без выигрыша. Монолит здесь честнее.
Подключать агента напрямую к сайту или репозиторию.
Агент должен работать с CMS. Иначе он получает права на деплой, рискует сломать вёрстку и не имеет нормального pre-flight-чеклиста.
Игнорировать rate limits CMS.
Notion API — 3 RPS, Directus — десятки, Strapi — свои. Без пауз и backoff ваш скрипт упрётся в 429 в первый же час активной работы.
Хранить контент только в CMS, без бэкапа.
CMS — это редактор и база в одном флаконе. Если сервис изменит тариф, закроет аккаунт или потеряет данные — восстанавливать нечего. Экспорт в markdown или JSON раз в неделю.
Смешивать слои «для скорости» в проде. Черновик-в-Notion
опубликованный-в-репозитории — это путь к рассинхрону. Выберите одну границу и держите её.
Считать, что headless автоматически быстрее монолита.
Headless даёт гибкость, а не скорость. Скорость достигается кешированием, CDN и статической генерацией — это ортогональные вопросы.
Чеклист
Чеклист
Проверка перед запуском
Границы слоёв описаны.
В архитектурной схеме явно нарисовано, где заканчивается база, где CMS, где сайт. Без этой схемы проект разваливается в первую же смену стека.
API между CMS и сайтом задокументирован.
Список endpoint’ов, формат запросов и ответов, лимиты, способ аутентификации — на одной странице.
Кеширование настроено.
Сайт не дёргает CMS на каждый запрос пользователя. Сборка раз в час или по событию — достаточно.
Права доступа разделены.
API-ключ для сайта ≠ API-ключ для агента ≠ API-ключ для разработчика. Утечка одного ключа не должна компрометировать весь проект.
Бэкап контента существует.
Экспорт из CMS в markdown или JSON раз в неделю. Проверено, что экспорт реально работает, а не «вроде бы где-то настроен».
Changelog CMS на мониторинге.
Подписка на обновления API. Breaking changes ловятся раньше, чем падает продакшн.
Агент работает только с CMS.
У агента нет доступа к репозиторию, серверу или домену. Только CMS и только в режиме «черновик».
Тестовая среда для миграций.
Прежде чем менять CMS или фронтенд, есть копия, на которой миграция прогоняется без риска для продакшна.
Ссылки
Ссылки
- Notion API — официальная документация справочник по всем endpoint’ам Notion API с примерами запросов и ответов.
- MDN: HTTP — справочник по протоколу что такое методы GET/POST/PUT/DELETE, заголовки, коды ответов.
- Astro: документация как собрать статический сайт, который тянет контент из внешнего API.