Headless CMS: когда традиционная CMS становится тормозом

К нам обратился клиент с интернет-магазином на WordPress и WooCommerce. Магазин работал уже четвёртый год, и за это время на нём накопилось 47 активных плагинов - от SEO и аналитики до кастомных форм и модулей доставки. Средняя загрузка страницы - 6 секунд. Контент-команда из трёх человек не могла публиковать материалы самостоятельно: любое изменение на сайте требовало участия разработчика, потому что вёрстка была завязана на конкретную тему, а плагины конфликтовали друг с другом при каждом обновлении. Мы предложили пересобрать фронтенд на Nuxt, а контент перевести в headless CMS. Через шесть недель магазин грузился за 1,2 секунды, контент-менеджеры публиковали статьи и карточки товаров без привлечения разработчика.

Это не единичный случай. Мы видим этот паттерн у компаний, которые переросли свою CMS, но продолжают добавлять плагины вместо того, чтобы пересмотреть архитектуру. В определённый момент WordPress перестаёт быть удобным инструментом и превращается в ограничение.

Что headless на самом деле означает

В классической CMS - WordPress, Joomla, Drupal - бэкенд и фронтенд живут вместе. Вы редактируете контент в админке, CMS сама генерирует HTML и отдаёт его браузеру. Тема определяет внешний вид, плагины добавляют функциональность. Всё в одном пакете.

Headless CMS работает иначе. CMS хранит контент и отдаёт его через API - обычно REST или GraphQL. Отдельно стоящий фронтенд (написанный на Nuxt, Next.js, Astro или любом другом фреймворке) запрашивает данные из API и рендерит страницы самостоятельно. CMS «обезглавлена» - у неё нет собственного фронтенда.

На практике это значит:

• Контент-команда работает в удобном редакторе CMS, не касаясь кода
• Разработчики строят фронтенд на современном стеке без ограничений тем и плагинов
• Один и тот же контент можно отдавать на сайт, в мобильное приложение, на цифровой экран - куда угодно
• Обновление фронтенда не ломает контент, обновление контента не ломает фронтенд

Почему WordPress-сайты упираются в потолок

WordPress занимает более 40% веба, и для большинства задач это оправданный выбор. Проблемы начинаются, когда сайт вырастает за пределы типового использования.

Вот что мы регулярно находим при аудитах:

• Раздутые плагины. 30–50 активных плагинов - норма для коммерческого WordPress-сайта. Каждый плагин загружает свои скрипты и стили на каждую страницу, даже если он используется только на одной. Мы видели сайты, где один плагин контактных форм добавлял 400 КБ JavaScript на страницы, где формы не было
• Зависимость от тем. Большинство коммерческих тем WordPress (Avada, Divi, Elementor-based) загружают собственный фреймворк поверх WordPress. Это удобно для редактирования, но означает, что каждая страница несёт лишние 500–800 КБ кода, который нельзя убрать без потери функциональности
• Производительность. WordPress генерирует HTML при каждом запросе, обращаясь к базе данных. Без правильно настроенного кэша время ответа сервера на shared-хостинге - 800 мс и выше. С кэшем - лучше, но кэш решает только часть проблемы
• Площадь атаки. Каждый плагин - потенциальная уязвимость. В 2024 году Wordfence зафиксировал более 7 000 уязвимостей в плагинах WordPress. Чем больше плагинов, тем шире поверхность для атаки и тем чаще нужно обновлять

Это не значит, что WordPress - плохой инструмент. Это значит, что у него есть граница применимости, и когда вы её пересекаете, проблемы начинают накапливаться быстрее, чем вы их решаете.

Headless-варианты, которые стоит рассмотреть

Рынок headless CMS зрел за последние несколько лет, и сейчас есть четыре основных варианта, которые мы рекомендуем в зависимости от задачи:

Strapi - наш выбор по умолчанию для проектов среднего масштаба. Он self-hosted, данные остаются у клиента, моделирование контента гибкое. Для команд, которые хотят полный контроль без ежемесячных платежей за SaaS, это наиболее практичный вариант.

Contentful - подходит для крупных мультиязычных проектов с распределёнными командами. Устоявшийся продукт с хорошей документацией, но ценник растёт быстро при увеличении объёмов.

Sanity - сильная сторона в структурированном контенте и кастомных рабочих процессах. Студия полностью кастомизируется на React. Если нужен нестандартный редакторский интерфейс - Sanity даёт максимум гибкости.

Storyblok - лучший визуальный редактор среди headless CMS. Маркетологи и контент-менеджеры видят результат в реальном времени, без превью-ссылок. Хорошо интегрируется с Nuxt через официальный SDK.

WordPress тоже может работать как headless CMS через WP REST API или WPGraphQL. Это разумный промежуточный шаг: редакторы продолжают работать в знакомом интерфейсе, а фронтенд перестраивается отдельно. Но вы по-прежнему несёте сложность WordPress на бэкенде - обновления, безопасность, хостинг.

Как на самом деле выглядит миграция

Переход на headless - не переключение тумблера. Это проект со своими этапами, рисками и сроками. Вот как он выглядит на практике:

1. Аудит текущего контента (1–2 недели). Прежде чем что-то переносить, нужно понять, что у вас есть. Сколько типов контента, сколько записей, какие связи между ними. На WordPress это обычно посты, страницы, товары WooCommerce, кастомные типы записей, таксономии и метаданные. Мы экспортируем всё и строим карту контента.

2. Моделирование контента в новой CMS (1 неделя). Структура контента в headless CMS проектируется осознанно, а не наследуется от плагинов. Вы определяете типы контента, поля, связи и правила валидации. Это ключевой этап - ошибки в модели контента дорого исправлять позже.

3. Миграция данных (1–2 недели). Написание скриптов для переноса контента из WordPress в новую CMS. Изображения, тексты, мета-теги, связи между записями. Автоматизировать стоит - ручной перенос при сотнях записей нереалистичен.

4. Сборка фронтенда (2–4 недели). Фронтенд строится на выбранном фреймворке. Для наших проектов это обычно Nuxt с SSR или SSG. Компоненты, маршрутизация, интеграция с API, формы, поиск - всё собирается заново, но уже без ограничений тем WordPress.

5. Редиректы и SEO (2–3 дня). Каждый старый URL должен перенаправлять на новый. Потеря даже части индексированных страниц без 301-редиректов - это провал в трафике, который восстанавливается месяцами. Мы генерируем полный список старых URL, сопоставляем с новыми и настраиваем редиректы на уровне сервера или фреймворка.

6. Тестирование и запуск (1 неделя). Проверка контента, форм, аналитики, скорости загрузки, мобильного отображения. Мониторинг после запуска - индексация, позиции, трафик.

Итого: 6–10 недель для среднего проекта. Для крупного интернет-магазина с тысячами товаров - 3–4 месяца.

Что обычно ломается: внутренние ссылки в контенте (они ведут на старые URL), шорткоды WordPress (они не работают вне WordPress), интеграции с формами и платёжными системами (нужно пересобирать). Всё это решаемо, но нужно учитывать в плане.

Когда headless - это перебор

Не каждому сайту нужен headless. Для ряда случаев WordPress с хорошим хостингом и минимумом плагинов - оптимальный вариант:

• Сайт-визитка на 5–10 страниц. Небольшой корпоративный сайт с контактами, услугами и блогом на 20 статей. Здесь WordPress с качественной темой, кэшированием и нормальным хостингом будет грузиться за 1,5–2 секунды. Headless добавит сложность, которая себя не оправдает
• Один человек управляет всем. Если вы сами и автор контента, и разработчик, и администратор - headless добавляет вторую систему для обслуживания. WordPress проще для одиночного оператора
• Ограниченный бюджет без технического ресурса. Headless-архитектура требует разработчика для настройки и поддержки фронтенда. Если бюджет не позволяет поддерживать два слоя - это не тот момент для миграции
• Блог без коммерческих задач. Персональный блог, портфолио фотографа, информационный ресурс с простой структурой. WordPress или даже статический генератор на Markdown справятся лучше

Вопрос не в том, «WordPress хуже headless». Вопрос в том, решает ли текущая архитектура задачи бизнеса или создаёт дополнительные. Если WordPress работает, не ломается и не замедляет команду - менять его ради моды бессмысленно.

Производительность и SEO после миграции

Вот реальные цифры с проектов, где мы переводили сайты с WordPress на headless с Nuxt:

Разница в TTFB (Time to First Byte) - ключевая. WordPress генерирует HTML при каждом запросе, обращаясь к PHP и MySQL. Nuxt с SSG отдаёт предварительно собранные страницы из CDN. Nuxt с SSR - рендерит на Node.js-сервере, что тоже быстрее, чем стек WordPress.

Для SEO headless-миграция при правильном исполнении нейтральна или положительна. Ключевые моменты:

• Все старые URL должны корректно перенаправляться (301-редиректы)
• Мета-теги, Open Graph, canonical-ссылки, sitemap, robots.txt - всё нужно реализовать заново
• Структурированные данные (Schema.org) - JSON-LD вставляется напрямую в компоненты Nuxt, без плагинов
• SSR или SSG обязательны - SPA без серверного рендеринга индексируется плохо, несмотря на заявления Google о рендеринге JavaScript

На одном из проектов мы наблюдали рост органического трафика на 35% за три месяца после миграции. Контент не менялся - изменилась только скорость и техническое здоровье сайта. Core Web Vitals перешли из красной зоны в зелёную, что повлияло на позиции.

Вопрос стоимости

Честный разбор затрат, потому что headless - это не экономия на старте:

Начальные затраты выше. Разработка фронтенда с нуля стоит дороже, чем настройка темы WordPress. Для среднего коммерческого сайта разница - от 30% до 80% от стоимости классического WordPress-проекта. Если WordPress-сайт обходится в 3 000–5 000 евро, headless-версия того же масштаба - 5 000–9 000 евро.

Текущее обслуживание дешевле. Нет ежемесячных обновлений 47 плагинов. Нет конфликтов при обновлениях. Нет регулярных патчей безопасности для сторонних модулей. Фронтенд на Nuxt обновляется по расписанию проекта, а не потому, что очередной плагин стал уязвимым.

Хостинг. WordPress требует PHP и MySQL - это VPS или managed WordPress-хостинг, от 20–50 евро в месяц за нормальную производительность. Статический фронтенд на Nuxt можно развернуть на Vercel, Netlify или Cloudflare Pages - бесплатно или за 10–20 евро в месяц. Headless CMS (если SaaS) добавляет свои расходы: от 0 до 300 евро в месяц в зависимости от выбора и масштаба. Strapi self-hosted - стоимость вашего сервера.

Когда ROI оправдан:

• Контент-команда тратит время на ожидание разработчика вместо публикации - потеря эффективности, которая стоит денег каждую неделю
• Медленный сайт теряет конверсии - даже 1% улучшения конверсии при обороте 100 000 евро в месяц окупает миграцию за первый квартал
• Частые поломки при обновлениях плагинов - каждый час простоя и каждый вызов разработчика для экстренного исправления имеют цену
• Планируется мобильное приложение или мультиканальная стратегия - headless CMS готова к этому сразу, WordPress потребует дополнительной доработки

Для интернет-магазина с оборотом выше 50 000 евро в месяц вложение окупается обычно за 4–6 месяцев. Для информационного сайта без прямой монетизации - сложнее обосновать, если текущий WordPress работает удовлетворительно.

Итог

Headless CMS - не волшебное решение и не обязательный следующий шаг для каждого сайта. Это архитектурный подход, который решает конкретные проблемы: производительность, независимость контент-команды, масштабируемость, безопасность. Если эти проблемы у вас есть - headless их решает. Если нет - WordPress с грамотной настройкой работает не хуже.

Мы помогаем разобраться, нужна ли миграция вообще, и если да - проводим её без потери трафика и позиций. Это часть нашей услуги веб-разработки. Если сайт уже на headless и нужна поддержка - это входит в сервис поддержки проектов.