Пользовательский CMS в 2026 году всё чаще становится стратегическим активом: он позволяет управлять контентом так, как требует именно ваша модель бизнеса, а не «как задумал вендор». Когда продукт растёт, стандартные CMS начинают мешать: сложные согласования, нестандартные типы данных, мультиканальность, интеграции и требования безопасности превращают «настройку» в бесконечный проект.
Эта статья — практическое руководство для разработчиков и основателей, которые хотят создать пользовательский CMS осознанно: с правильной архитектурой, понятными ролями, качественным редакторским опытом и надёжным жизненным циклом. Мы разложим путь на этапы, покажем типовые развилки и дадим чек‑листы, чтобы вы могли быстро перейти от идеи к работающему продукту.
Key Takeaways
- Начинайте не с технологий, а с модели контента, ролей и сценариев публикации — это определит архитектуру и стоимость владения.
- Разделяйте «ядро контента» и «доставку» (headless/гибридный подход), чтобы ускорить развитие каналов (web, mobile, e‑mail, партнёрские витрины).
- Сразу проектируйте RBAC, аудит, версии и превью — иначе редакторы и комплаенс «сломают» релизный цикл.
- Интеграции делайте через API и события, а не прямые связи; это снижает риск и упрощает масштабирование.
- Деплой, наблюдаемость и безопасность — часть продукта; используйте облачные паттерны и автоматизацию с первого спринта.
Зачем компании создают пользовательский CMS, если есть готовые решения?
Пользовательский CMS оправдан, когда контент — это не «страницы», а бизнес‑объекты с правилами, согласованиями и интеграциями. Готовые CMS часто закрывают базовые сценарии, но становятся дорогими и рискованными при сложных ролях, мультиканальности, строгой безопасности и нестандартных моделях данных. Кастомный подход даёт контроль, но требует дисциплины в проектировании.
H3: Типовые триггеры, что пора строить своё
- Контент — часть продукта: тарифы, каталоги, базы знаний, регламенты, партнерские материалы, которые обновляются ежедневно и влияют на выручку.
- Нужны сложные workflow: многоступенчатое согласование, юридическая проверка, региональные правила, «четыре глаза».
- Мультиканальность: один источник данных для сайта, приложений, чат‑ботов, e‑mail и внутренних порталов.
- Интеграции с CRM/ERP/PIM, аналитикой и поиском становятся критичными, а «плагины» не закрывают требования.
- Требования безопасности и аудита выше среднего: журнал действий, неизменяемые логи, сегментация доступа, SSO.
H3: Когда НЕ стоит делать кастомный CMS
Если вам нужен маркетинговый сайт с типовыми страницами и редкими обновлениями, кастомный CMS почти всегда избыточен. То же касается команд без выделенного владельца продукта и бюджета на поддержку: стоимость владения — это не только разработка, но и безопасность, обновления, поддержку редакторов и развитие. В таких случаях разумнее начать с готовой платформы и отложить кастомизацию.
Если вы выбираете между фреймворками для бэкенда, полезно сопоставить подходы и экосистему (ORM, миграции, админка, безопасность). Для ориентира смотрите материал «Сравнение фреймворков: Laravel vs Symfony в 2026», а практическую разработку можно вести на стеке, который уже хорошо поддерживается вашей командой.
С чего начать: требования, роли и карта сценариев
Начинайте с описания пользователей, прав и сценариев публикации, а не с «какую БД взять». Сформируйте список ролей, объектов контента и жизненных циклов (черновик → ревью → публикация → архив). Затем зафиксируйте нефункциональные требования: безопасность, SLA, масштабирование, интеграции и аудит — они определят архитектуру и бюджет.
H3: Мини‑бриф для фаундера и техлида (10 вопросов)
- Какие каналы потребляют контент сегодня и какие появятся через 12–18 месяцев?
- Какие типы контента критичны (страницы, статьи, товары, документы, политики, кейсы, FAQ) и какие поля у каждого?
- Какие роли нужны: автор, редактор, юрист, локальный менеджер, админ, интегратор?
- Нужны ли версии, сравнение версий и откат? Как долго хранить историю?
- Какие согласования обязательны и какие исключения допустимы?
- Нужно ли SSO (SAML/OIDC) и какая система будет IdP?
- Какие интеграции обязательны в MVP (поиск, аналитика, CRM, PIM, DAM, рассылки)?
- Какие требования к локализации и региональным правилам?
- Какие ограничения по данным (персональные данные, коммерческая тайна) и где можно хранить?
- Кто владелец продукта CMS и кто отвечает за поддержку редакторов?
H3: Артефакты, которые экономят месяцы
Зафиксируйте модель контента в виде схем (ERD/JSON Schema), карту экранов админки и диаграмму состояний для публикации. Добавьте RACI‑матрицу по ролям и «политики доступа» (кто что может видеть/редактировать). Эти документы не должны быть идеальными, но должны быть единым источником решений, чтобы команда не спорила на каждом спринте.
Как выбрать архитектуру CMS: headless, гибрид или монолит?
Выбор архитектуры сводится к тому, где живёт представление контента и как он доставляется в каналы. Headless CMS отдаёт данные через API, а фронтенды рендерят сами; гибрид сочетает API и серверный рендеринг; монолит включает всё в одном приложении. Для B2B чаще выигрывает headless/гибрид из‑за интеграций и мультиканальности.
H3: Сравнение подходов (что выбрать в 2026)
| Подход | Плюсы | Минусы | Когда подходит |
| Монолитный CMS | Быстрый старт, единый стек, проще SEO при SSR | Сложнее масштабировать команды и каналы, больше связности | Небольшие продукты, один веб‑канал, ограниченные интеграции |
| Headless CMS | Мультиканальность, независимые фронтенды, API‑first | Нужно отдельно решать превью, редакторский UX, SEO‑пайплайн | Сайты + приложения + партнёрские витрины, развитые интеграции |
| Гибридный CMS | Компромисс: и API, и шаблоны/SSR, удобное превью | Сложнее архитектурно, больше компонентов для поддержки | Когда нужен и маркетинговый сайт, и API для продуктов |
H3: Практический ориентир — «контент как данные»
Если ваш контент должен жить дольше одного сайта, относитесь к нему как к данным: чёткие типы, связи, валидации, события изменения. Это упрощает интеграции и снижает риск «переписывать всё» при смене фронтенда. Для фронтенда в админке и превью удобно использовать современные JS‑библиотеки; см. обзор «Популярные библиотеки JavaScript в 2026: Vue, React, AngularJS».
Проектирование модели контента: типы, связи, версии
Модель контента — ядро кастомного CMS: она определяет, что редакторы могут создать и как это будет жить в системах. Начните с минимального набора типов и строго задайте поля, связи и правила валидации. Обязательно заложите версии и статусы, иначе публикация превратится в ручной хаос и «правки в проде».
H3: Контент‑типы: от «страниц» к доменным объектам
- Определите доменные сущности: «Продукт», «Функция», «Тариф», «Кейс», «Документ», «Вендор», «Региональная политика».
- Для каждого типа задайте обязательные поля, ограничения и подсказки редактору (placeholder, примеры, длина).
- Разделяйте «контент» и «презентацию»: храните смысловые поля, а не HTML‑разметку там, где это возможно.
- Подумайте о композиции: блоки/секции страницы как вложенные структуры, чтобы переиспользовать элементы.
H3: Версионирование и публикация без боли
Практичный минимум: храните черновик и опубликованную версию отдельно (или как разные ревизии с флагом). Добавьте сравнение изменений (diff) и возможность отката. Для юридически значимого контента полезны неизменяемые записи аудита: кто, когда и что изменил, включая изменения прав доступа.
H3: Пример (иллюстративный): B2B‑SaaS с тарифами и локализацией
Представим B2B‑SaaS, где тарифы отличаются по регионам и зависят от юридических условий. В кастомном CMS «Тариф» — это объект с правилами видимости, датами действия и связями с «Юр. документами». Редактор меняет тариф, юрист утверждает, а система автоматически публикует в нужные каналы и сохраняет версию для аудита.
Как спроектировать админку и редакторский опыт (UX) для CMS?
Админка — это рабочее место, поэтому её UX влияет на скорость выпуска контента сильнее, чем «красивый фронтенд». Постройте интерфейс вокруг задач: создать, найти, проверить, согласовать, опубликовать, откатить. Важно минимизировать ошибки: подсказки, валидации, превью, шаблоны и понятные статусы вместо «магии».
H3: Превью и «что увидит пользователь»
Сделайте превью обязательной частью потока: оно должно показывать контент так, как он будет выглядеть в конкретном канале и регионе. Для headless‑подхода часто используют «preview token» и отдельный режим рендера на фронтенде. Сразу продумайте, как превью работает с черновиками, A/B‑вариантами и правами доступа.
H3: Дизайн‑система и переиспользуемые компоненты
Чтобы редакторы не «ломали» верстку, используйте библиотеку компонентов и ограниченный набор блоков. На уровне веб‑платформы полезны Web Components: они позволяют создавать повторно используемые кастомные элементы с инкапсулированной функциональностью, как описывает MDN: https://developer.mozilla.org/ru/docs/Web/API/Web_components. Это особенно удобно для унификации виджетов превью и UI‑блоков в админке.
H3: Где уместен WYSIWYG, а где — структурированный ввод
- WYSIWYG — для длинных текстов, пресс‑релизов, статей, где важна разметка и скорость.
- Структурированные поля — для карточек продукта, тарифов, спецификаций, где важна консистентность и фильтрация.
- Гибрид — «текст + вставки блоков» (таблицы, callout, CTA), чтобы сохранить управляемость.
- В любом варианте добавьте правила: ограничения HTML, санитайзинг, подсветку ошибок и подсказки.
Какие функции обязательны в MVP кастомного CMS?
MVP кастомного CMS должен закрывать полный цикл публикации хотя бы для 1–2 ключевых типов контента и одного канала. Не пытайтесь повторить «всё как в enterprise‑платформе» — важнее надёжные основы: роли, статусы, валидации, версии, поиск, аудит и API. Остальное наращивается итеративно по боли редакторов.
H3: Минимальный функциональный набор (проверка здравого смысла)
- Аутентификация и управление пользователями (локально или через SSO).
- RBAC (роли/права) на уровне типов контента и отдельных записей.
- CRUD для 1–2 контент‑типов + валидации + обязательные поля.
- Workflow: черновик/на ревью/опубликовано/архив.
- Версии и история изменений + журнал действий (audit log).
- Поиск и фильтры в админке (по статусу, автору, дате, тегам).
- API для чтения (и, при необходимости, записи) + документация.
- Превью и безопасная публикация (с расписанием или ручным триггером).
H3: Пример (иллюстративный): база знаний для службы поддержки
Гипотетический сценарий: компания строит базу знаний, которая должна обновляться саппортом и продуктом, а публиковаться в веб‑центре помощи и внутри приложения. MVP включает типы «Статья» и «Категория», роли «Автор/Редактор», статусы, превью и API для приложения. Уже на этом этапе экономится время поддержки, потому что контент обновляется без релизов приложения.
API-first: GraphQL/REST, события и контрактная разработка
API — это «витрина» вашего CMS для всех каналов и интеграций, поэтому проектируйте его как продукт: версии, совместимость, лимиты, документация и тесты контрактов. REST проще для многих интеграций, GraphQL удобен для гибких выборок и фронтендов. Для масштабируемости добавляйте события (webhooks/очереди) при изменениях контента.
H3: Как не превратить API в хаос
- Вводите версионирование API (URI или заголовки) и политику депрекации.
- Определите контракты (OpenAPI/JSON Schema) и проверяйте их в CI.
- Стабилизируйте идентификаторы: не меняйте смысл полей без миграций и обратной совместимости.
- Разделяйте публичные и внутренние эндпоинты; включайте rate limiting и ключи доступа.
H3: Интеграции через API и почему это важно
Почти любой кастомный CMS быстро оказывается в центре интеграций: CRM, аналитика, поиск, DAM, PIM, рассылки. Поэтому полезно заранее использовать лучшие практики API‑интеграций: идемпотентность, ретраи, дедупликация событий, трассировка запросов. В качестве углубления смотрите «Лучшие практики интеграции систем на основе API: без ошибок».
H3: Событийная модель (пример)
Практичный паттерн: при публикации CMS генерирует событие ContentPublished с типом, ID, версией и регионом. Подписчики — поисковый индекс, CDN‑инвалидатор, сервис рассылок, витрина партнёра — получают событие и обновляются независимо. Так вы снижаете связанность и избегаете «публикация упала из‑за одной интеграции».
Безопасность кастомного CMS: угрозы, RBAC, аудит, комплаенс
Безопасность CMS — это защита не только данных, но и репутации: любой несанкционированный доступ превращается в публичный инцидент. Минимум — строгий RBAC, безопасная аутентификация, журнал действий, защита API и санитайзинг пользовательского ввода. Для B2B также важны сегментация контента по регионам/тенантам и контроль экспорта данных.
H3: Контроль доступа: роли, политики и «наследование»
Не ограничивайтесь ролями «admin/editor». Опишите политики доступа: кто может создавать, кто — публиковать, кто — видеть черновики, кто — менять схемы. В сложных организациях полезен подход policy-based access (атрибуты: регион, подразделение, тип контента), чтобы избежать взрыва ролей и ручных исключений.
H3: Аудит и расследование инцидентов
- Логируйте: входы, изменения прав, публикации, удаления, экспорт данных.
- Храните контекст: кто, откуда (IP/устройство), что изменил, старое/новое значение (или ссылку на diff).
- Защитите логи от подмены: отдельное хранилище, ограниченный доступ, ретеншн‑политики.
- Сделайте отчётность: быстрый поиск по событиям и выгрузка для комплаенса.
H3: Защита контента и редактора
Главные риски CMS — XSS через редактор, утечки токенов превью, SSRF при загрузке внешних ресурсов, ошибки в правах доступа и небезопасные интеграции. Ограничивайте HTML, используйте санитайзинг и строгие CSP‑политики, изолируйте загрузки файлов, проверяйте MIME‑типы. Для API применяйте короткоживущие токены и принцип наименьших привилегий.
Технологический стек: как выбрать язык, фреймворк, БД и фронтенд
Выбор стека для кастомного CMS должен опираться на компетенции команды и требования к интеграциям, безопасности и скорости разработки. Часто выигрывают зрелые фреймворки с админ‑возможностями, миграциями и экосистемой. Важно разделить бэкенд (модель, права, workflow, API) и фронтенд админки (формы, превью, компоненты).
H3: Бэкенд: практичные варианты
Для быстрого старта часто выбирают Django, Laravel, Symfony, Node.js или ASP.NET — в зависимости от команды и окружения. Если вы строите на Python, оцените актуальные библиотеки и подходы из материала «Будущее разработки на Python: доминирующие библиотеки и фреймворки 2026». Для разработки на заказ и комплексных систем полезна страница услуги разработки ПО, чтобы понимать типовые процессы и зоны ответственности.
H3: Хранилище данных: реляционное + поиск + файлы
- Реляционная БД (PostgreSQL/MySQL) — для сущностей, связей, прав и транзакций.
- Поисковый индекс (например, Elasticsearch/OpenSearch) — для полнотекстового поиска и фильтрации в админке и на витринах.
- Объектное хранилище — для медиа (изображения, PDF), с версионированием и политиками доступа.
- Кэш (Redis) — для ускорения выдачи и хранения токенов/сессий (в зависимости от модели auth).
H3: Фронтенд админки: SPA, SSR и компонентный подход
Админка чаще всего — SPA (React/Vue) с формами, таблицами и сложными состояниями. Для превью удобно иметь SSR/SSG‑витрину или отдельный preview‑фронтенд. Не забывайте про доступность и производительность: редакторы работают по 8 часов в день, и «тяжёлая админка» становится реальной потерей времени.
Разработка по шагам: от прототипа до production
Надёжный путь — итеративная разработка: сначала прототип модели контента и админки, затем MVP с полным циклом публикации, потом масштабирование на новые типы и каналы. Каждый шаг должен добавлять измеримую ценность редакторам и бизнесу. Параллельно выстраивайте CI/CD, тестирование и наблюдаемость, чтобы не «платить долгом» позже.
H3: Шаг 1 — прототип контент‑модели и форм
Соберите 1–2 ключевых контент‑типа и сделайте формы ввода с валидациями и подсказками. На этом этапе полезно провести «редакторскую сессию»: дайте будущим пользователям заполнить 10–15 материалов и фиксируйте, где они ошибаются или зависают. Результат — уточнённые поля, статусы и требования к превью.
H3: Шаг 2 — workflow, версии, аудит и права
Дальше добавьте статусы, роли, журнал действий и версии — это «скелет» CMS. Протестируйте сценарии: автор создаёт черновик, редактор правит, юрист утверждает, админ публикует, затем требуется откат. Если этот путь занимает больше пары минут или слишком легко ошибиться, исправляйте UX и правила сейчас, пока типов контента мало.
H3: Шаг 3 — API, превью и публикация
Сделайте read‑API для потребляющего канала (например, сайта) и настройте превью для черновиков. Затем реализуйте публикацию: либо запись «published snapshot», либо промоут ревизии. На этом этапе важно продумать кэширование, инвалидацию и задержки — иначе редакторы будут видеть «опубликовал, но не обновилось».
H3: Шаг 4 — интеграции и автоматизация
Подключайте интеграции по мере зрелости: поиск, аналитика, DAM, CRM, рассылки. Делайте это через события и очереди, чтобы сбои внешних систем не блокировали публикацию. Если вы строите комплексный продукт с несколькими системами, заранее планируйте интеграционный слой и ответственность команд.
Производительность и масштабирование: что учесть заранее
CMS нагружается не только пользователями сайта, но и редакторами, интеграциями, индексаторами и задачами публикации. Поэтому производительность нужно проектировать: кэширование, фоновые задачи, очереди, пагинация, лимиты API и оптимизация запросов. Для практик ускорения веб‑части и бэкенда полезен материал «Методы повышения производительности веб‑приложений в 2026».
H3: Горячие точки в CMS и как их лечить
- Списки в админке: используйте пагинацию, индексирование, серверные фильтры и ограничение выборок.
- Полнотекстовый поиск: вынесите в отдельный индекс, обновляйте по событиям публикации.
- Публикация: переносите тяжёлые операции (генерация страниц, ресайз изображений) в фоновые воркеры.
- API для витрин: применяйте CDN/edge‑кэш и инвалидацию по ключам (тип+ID+версия).
- Медиа: используйте объектное хранилище и отдачу через CDN, а не через приложение.
H3: Мульти‑тенантность и региональность (если вы B2B)
Если CMS обслуживает несколько брендов/регионов/клиентов, продумайте multi-tenancy заранее: изоляция данных, ключи шифрования, лимиты, отдельные пространства контента. Иногда достаточно «пространств» (spaces) на уровне прав и фильтров, но для строгих требований может понадобиться физическая изоляция (отдельные схемы/БД). Это решение сложно поменять позже.
Деплой и инфраструктура: как вывести кастомный CMS в облако
Деплой CMS должен быть повторяемым и безопасным: инфраструктура как код, секреты, миграции, откаты, отдельные окружения и наблюдаемость. Для быстрых экспериментов и масштабирования удобно использовать контейнеризацию и управляемые платформы. Пример развертывания CMS на Django в Cloud Run описан в руководстве Google: Django CMS on Cloud Run — полезно как референс паттернов.
H3: Окружения и релизный цикл
Минимум — dev/stage/prod с отдельными базами и секретами. На stage должны быть максимально близкие настройки к production, включая интеграции и ограничения. Для релизов используйте миграции схемы, фича‑флаги и обратную совместимость API, чтобы не блокировать редакторов при выкладке.
H3: Наблюдаемость: логи, метрики, трассировка
- Метрики: время ответа API, ошибки 4xx/5xx, задержка публикации, длина очередей, время индексации.
- Логи: структурированные, с корреляционными ID, отдельные потоки для аудита и технических событий.
- Трассировка: распределённая, чтобы видеть цепочку «публикация → событие → индекс → витрина».
- Алерты: ориентируйтесь на пользовательские симптомы (публикация не доходит, превью недоступно), а не только на CPU.
H3: Где заказать разработку или усилить команду
Если вам нужно ускорить запуск или закрыть редкие компетенции (архитектура, безопасность, интеграции), полезно подключать внешнюю разработку. На практике чаще всего помогают команды, которые умеют проектировать продукт, а не только писать код. Для ориентира по услугам смотрите разработку custom CMS и, при необходимости, интеграцию систем.
Интеграции, аналитика и экосистема данных: как сделать CMS «центром правды»
Кастомный CMS часто становится узлом экосистемы данных: он связывает контент, продуктовые данные и каналы коммуникации. Чтобы это работало, определите источники истины (source of truth) и правила синхронизации. McKinsey отмечает, что обмен данными помогает компаниям быстрее находить возможности для роста и работать эффективнее: How to build a data ecosystem.
H3: Типовая карта интеграций вокруг CMS
- CRM: персонализация контента для сегментов, лид‑магниты, формы и UTM‑атрибуция.
- PIM/ERP: карточки товаров/услуг, цены, доступность, юридические атрибуты.
- DAM: хранение и права на медиа, версии файлов, лицензии.
- Поиск: индексирование опубликованных материалов и подсказки для редакторов.
- Аналитика: события публикации, качество контента, конверсии по страницам/блокам.
H3: Аналитика без хаоса тегов: шаблоны GTM
Если вы даёте маркетингу гибкость в аналитике, важно не потерять контроль. В Google Tag Manager есть механизм пользовательских шаблонов, который позволяет создавать собственные определения тегов и переменных: Google Tag Manager Templates. В контексте CMS это помогает стандартизировать события (просмотр блока, клик CTA) и снизить риск небезопасных вставок.
H3: Пример (иллюстративный): контент + продуктовые данные
Представим производителя оборудования: характеристики и наличие приходят из ERP, а описания, кейсы и документы — из CMS. Правильный дизайн: ERP остаётся источником цифр, CMS — источником текстов и медиа, а витрина собирает итоговую карточку через API. Это снижает конфликты данных и упрощает ответственность команд.
Миграция контента и запуск: как переехать без остановки бизнеса
Миграция — самый недооценённый этап: даже идеальный CMS провалится, если контент не переедет корректно и редакторы не смогут работать с первого дня. Планируйте миграцию как продукт: инвентаризация, маппинг полей, очистка, прогон на staging, контроль качества и «параллельный запуск». Для критичных разделов лучше использовать постепенный cutover.
H3: План миграции (практический чек‑лист)
- Инвентаризация: какие типы контента, объём, владельцы, актуальность.
- Маппинг: соответствие старых полей новой модели контента, правила преобразований.
- Очистка: дубликаты, устаревшие страницы, битые ссылки, медиа без владельцев.
- Инструмент миграции: скрипты с логами, повторяемостью и режимом dry‑run.
- Валидация: выборочная ручная проверка + автоматические проверки (схемы, ссылки, статусы).
- Параллельный период: старый CMS read‑only, новый — основной для правок.
- Cutover: переключение доменов/маршрутизации, мониторинг, план отката.
H3: Пример (иллюстративный): переезд маркетингового сайта на headless
Допустим, компания переезжает с монолитной CMS на headless, сохраняя старый сайт на время. Команда переносит сначала «длинный хвост» статей, затем ключевые лендинги с высоким трафиком, а после — формы и интеграции. Параллельный запуск позволяет сравнить рендер и метрики, не рискуя всем сайтом в один день.
Чек‑лист внедрения: что сделать в ближайшие 30–90 дней
Ниже — практичные шаги, которые можно превратить в план работ. Старайтесь держать фокус: сначала один поток публикации end‑to‑end, затем расширение. Параллельно выстраивайте безопасность, наблюдаемость и интеграции как обязательные свойства системы, а не «потом доделаем».
H3: 30 дней — фундамент
- Собрать мини‑бриф: роли, сценарии, каналы, обязательные интеграции.
- Зафиксировать модель контента для 1–2 типов и правила валидации.
- Сделать прототип админки: формы, списки, поиск по полям.
- Определить архитектуру (headless/гибрид) и контракт API (черновой OpenAPI/Schema).
- Согласовать требования безопасности: SSO/2FA, RBAC, аудит, политика хранения медиа.
H3: 60 дней — MVP end‑to‑end
- Реализовать статусы, workflow, версии и журнал действий.
- Сделать превью для одного канала + безопасные preview‑токены.
- Поднять read‑API и подключить один потребляющий фронтенд/витрину.
- Настроить CI/CD, миграции БД, окружения stage/prod, базовые метрики.
- Провести редакторское тестирование: 10–20 реальных материалов, фиксация проблем UX.
H3: 90 дней — масштабирование и интеграции
- Добавить события публикации и подписчиков (поиск, CDN‑инвалидация, аналитика).
- Подключить DAM/хранилище медиа и политики доступа.
- Расширить модель на 2–3 новых типа контента, не ломая API‑контракты.
- Ввести правила качества: обязательные поля для SEO, проверки ссылок, контент‑линтер.
- Подготовить план миграции и постепенного cutover со старой системы (если есть).
