VorobeoffСправочник для тех, кто проектирует контентные проекты, подключает ИИ-агентов к 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 — официальная документация
- Документация: MDN: HTTP — справочник по протоколу
- Документация: Astro: документация
