CMS, база данных и сайт решают разные задачи: данные нужно хранить, контентом — управлять, результат — показывать посетителю. Эти роли могут находиться в одном продукте или быть распределены между несколькими системами.
Понимание границ помогает выбрать архитектуру без лишней сложности и заранее определить, где находятся данные, кто отвечает за публикацию и как сайт получает контент.
Целевая архитектура контентной системы
flowchart LR
E["Редактор или агент"] --> CMS["CMS"]
CMS --> DS["Хранилище данных"]
CMS --> API["API контента"]
API --> SITE["Сайт или приложение"]
DS -->|"серверный запрос при необходимости"| SITE
SITE --> USER["Посетитель"]В этой схеме роли разделены логически:
- Хранилище данных сохраняет записи, свойства, связи и содержимое.
- CMS даёт редактору интерфейс и правила работы с контентом: создание, изменение, статусы, представления и права доступа.
- API передаёт разрешённые данные другим системам.
- Сайт получает данные и превращает их в страницы, интерфейсы и другие форматы для посетителя.
Схема показывает целевое разделение ролей. Эти слои могут быть реализованы одним продуктом или несколькими системами: CMS может включать хранилище и собственный API, а сайт может обращаться к базе данных с серверной стороны, если это допускают архитектура и модель безопасности.
Чем отличаются база данных, CMS и сайт
| Параметр | База данных или хранилище | CMS | Сайт |
| Основная роль | Сохраняет и выдаёт данные | Организует редакционную работу | Показывает результат посетителю |
| Основной пользователь | Серверное приложение, разработчик или администратор | Редактор, контент-менеджер или агент | Посетитель |
| Что содержит | Записи, поля, связи и ограничения | Контентные модели, формы, статусы, представления и права | Страницы, навигацию и пользовательский интерфейс |
| Способ доступа | Драйвер, протокол базы данных, серверный клиент или API платформы | Редакторский интерфейс и, если предусмотрено, API | Браузер, приложение или другой клиент |
| Может ли быть объединено с другими слоями | Да, платформа может скрывать хранилище внутри продукта | Да, CMS может включать хранилище и готовый сайт | Да, сайт может получать данные из CMS, API или базы с серверной стороны |
Фраза «база данных доступна только через API» слишком узкая. Например, серверное приложение может работать с PostgreSQL через драйвер или ORM — объектно-реляционное отображение. В управляемых платформах доступ часто дополнительно предоставляется через API.
Связанная и отделённая CMS
CMS и сайт в одном продукте
Редакторский интерфейс, хранение контента и механизм показа страниц поставляются как единая система. Такой вариант уменьшает число компонентов и обычно ускоряет запуск.
Компромисс проявляется позднее: шаблоны, модель контента и публикация могут сильнее зависеть от выбранного продукта. Степень этой зависимости определяется конкретной системой, поэтому её нужно проверять до внедрения.
CMS как отдельный источник контента
При отделённой архитектуре CMS отвечает за управление контентом, а сайт получает данные через API. Такой подход часто называют headless CMS, то есть CMS без обязательного собственного слоя отображения.
Один источник контента в такой модели можно подключить к нескольким клиентам: сайту, приложению или внутреннему интерфейсу. Для этого потребуется самостоятельно определить правила публикации, преобразование данных, кеширование, обработку ошибок и права доступа.
Как использовать Notion как источник контента
Модель Notion отличается от классической связки CMS поверх отдельной SQL-базы: база данных Notion — это коллекция страниц. Каждый элемент является отдельной страницей; свойства хранят структурированные метаданные, а содержимое страницы представлено блоками.
Для контентного проекта роли можно распределить так:
- Редактор создаёт страницу в базе Notion и заполняет её свойства.
- Статус, slug, категория и другие свойства описывают запись.
- Серверное приложение запрашивает записи источника данных через Notion API и при необходимости фильтрует их по статусу.
- Метод получения дочерних блоков возвращает только первый уровень. Чтобы собрать полное тело страницы, вложенные блоки обходят рекурсивно, а результаты получают с учётом курсорной пагинации.
- Сайт преобразует свойства и блоки в собственные компоненты и страницы.
В проверенной 8 сентября 2026 года документации Notion запрос записей описан через data source. API поддерживает фильтры по свойствам, в том числе по свойствам типа status. В документации последняя доступная версия API указана как 2026-03-11; перед реализацией нужно сверить версию и доступные методы API. Для получения дочерних блоков соединению требуется право чтения контента.
Как сайт получает и показывает данные
Next.js поддерживает на серверной стороне оба распространённых варианта:
- получение данных через
fetch, например из API CMS; - запрос к базе данных через ORM или серверный клиент.
Серверные компоненты позволяют выполнять такие запросы без включения учётных данных и серверной логики в клиентский пакет. При этом доступ всё равно нужно защищать средствами аутентификации и авторизации.
В документации Next.js 16.3.4 запросы fetch по умолчанию не кешируются. Некешированный запрос может задерживать отображение страницы. Поэтому для контентного сайта нужно явно выбрать стратегию: кешировать результат через use cache, передавать медленные части потоком или получать свежие данные при каждом запросе.
Наблюдаемый результат правильно собранной цепочки выглядит так: запись, удовлетворяющая заданному правилу публикации, проходит фильтр, сервер получает её свойства и полное тело, а сайт формирует страницу по ожидаемому URL. Записи, не удовлетворяющие этому правилу, на публичный сайт не попадают.
Когда разделение слоёв оправдано
Отделённая архитектура полезна, если выполняется хотя бы одно из условий:
- контент выходит на нескольких площадках;
- сайт и редакторский интерфейс развиваются независимо;
- с контентом работают автоматизации или агенты;
- требуются собственные правила публикации и проверки;
- смена интерфейса сайта не должна требовать миграции всего контента.
Единая система часто подходит лучше, если страниц мало, обновления редки, интеграций нет, а команда не планирует поддерживать отдельный API-слой.
Эталонный шаблон архитектурного решения
Перед выбором инструментов заполните короткий шаблон:
Источник истины для контента: <система>
Редакторский интерфейс: <CMS или встроенная админка>
Структурированные свойства: <slug, статус, категория, дата>
Тело материала: <формат и место хранения>
Правило публикации: <какой статус делает запись публичной>
Способ получения данных: <API, SDK, ORM или серверный клиент>
Кто имеет доступ: <роли людей, агентов и приложений>
Кеширование и обновление: <стратегия>
Поведение при ошибке источника: <fallback или отказ>
Канонический URL: <правило построения>
Проверка результата: <наблюдаемый признак успешной публикации>
План миграции: <как выгрузить данные и сохранить URL>Этот шаблон фиксирует границы системы до реализации. После заполнения становится видно, какие компоненты действительно нужны и где остаются неявные зависимости.
Чеклист быстрой проверки
Официальные источники
Проверено 8 сентября 2026 года:
- Введение в базы данных Notion
- Введение в Notion API
- Фильтрация записей источника данных
- Получение дочерних блоков
- Получение данных в Next.js
Следующий шаг
Agent-ready сайт — методология подготовки сайта для работы с ИИ-агентами
Если вы проектируете контентную систему, можно отдельно разобрать границы CMS, сайта, агентов и прав доступа для вашей команды.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
