Headless CMS для Nuxt: @nuxt/content, Strapi или WordPress

Вопрос «какую headless CMS поставить к Nuxt» я слышу на каждом втором проекте. И каждый раз ответ разный: зависит от того, кто правит контент, насколько часто, сколько типов страниц и есть ли бюджет на отдельный бэкенд. В 2026 году выбор стал богаче, но и запутаннее. Разберу честно, без маркетинга.

Я Евгений Волков, fullstack-разработчик, и для evolkov.tech я выбрал @nuxt/content: блог живёт прямо в репозитории в markdown-файлах, без отдельного сервера. У клиентских проектов другой контекст, и там выбор другой. Ниже разложу по полочкам все основные варианты headless CMS для Nuxt: когда каждый из них имеет смысл, а когда нет.

Что такое headless CMS и чем она отличается от WordPress-монолита

Классический WordPress это монолит: бэкенд (PHP, MySQL, медиатека) и фронтенд (шаблоны, темы) живут в одном приложении. Ты ставишь тему, пишешь в редакторе, нажимаешь «Опубликовать». WP сам генерирует HTML и отдаёт браузеру. Просто, но ограниченно.

Headless CMS делает одно: хранит контент и отдаёт его через API. Никаких шаблонов, никакого встроенного рендеринга. Nuxt на фронтенде делает запрос (REST или GraphQL), получает данные в JSON и сам решает, как нарисовать страницу. Контент и отображение полностью разделены.

Зачем это нужно. Во-первых, скорость. Nuxt SSR и prerender рендерит страницы на сервере и отдаёт краулеру готовый HTML, поэтому SEO работает без JavaScript в браузере. Во-вторых, гибкость фронта: не подстраиваешься под ограничения темы, делаешь ровно тот дизайн и ту логику, которую нужно. В-третьих, контент-модель проектируешь под свою задачу, а не под то, что придумал авторов плагина.

Платить приходится сложностью. Два отдельных приложения: два деплоя, два хостинга, два места, где что-то может сломаться.

Зачем headless именно с Nuxt

Nuxt особенно выгоден в связке с headless, потому что решает основную проблему: SEO.

Фронтенд, который строит страницы из API-данных, по умолчанию рискует стать SPA без серверного рендеринга: поисковик увидит пустую страницу. Nuxt закрывает это через SSR или prerender: он запрашивает данные из CMS на сервере (или на билде), строит HTML и отдаёт краулеру готовый результат. Яндекс и Google оба получают полный текст.

Второй плюс: useFetch и useAsyncData в Nuxt удобно работают с любым API без дополнительных настроек. GraphQL-клиент или REST подключается в несколько строк. Реактивность Vue обновит компоненты, когда данные придут, без лишнего кода.

Третий плюс: @nuxt/content это вообще встроенный движок для контента, без внешних сервисов. Об этом ниже.

Есть ещё один аргумент, который редко упоминают. Когда фронт и бэкенд разделены, можно независимо кешировать каждый слой. Nuxt-фронт с routeRules: { prerender: true } отдаёт статику с CDN за миллисекунды. Strapi или WordPress при этом могут стоять на более медленном хостинге, и это не скажется на времени первого байта для пользователя. На монолитном WordPress такой разделённой стратегии нет: скорость фронта зависит от скорости PHP-рендеринга.

// nuxt.config.ts: prerender всех страниц блога, SSR для динамики
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { prerender: true },
    '/account/**': { ssr: true },
  },
})

Это позволяет получить лучшее из двух миров: статический CDN-HTML для краулера и SEO, живой сервер для авторизованных пользователей.

Варианты headless CMS для Nuxt: обзорная таблица

@nuxt/content: когда отдельная CMS не нужна вообще

@nuxt/content это модуль, встроенный в экосистему Nuxt. Никакого отдельного сервера, никакой базы данных. Контент лежит в папке content/ в репозитории: markdown-файлы, YAML, JSON, CSV. Nuxt читает их на сборке или в рантайме, отдаёт через встроенный API, и ты строишь страницы прямо из этих данных.

Этот самый блог на evolkov.tech работает именно так. Пишу статью в .md-файле, коммичу в Git, деплой подхватывает изменения автоматически.

// pages/blog/[slug].vue
const { data: article } = await useAsyncData(route.path, () =>
  queryCollection('blogRu').path(route.path).first()
)

Вот и всё. Никакого API-ключа, никакого внешнего сервиса, никакого useFetch к стороннему хосту.

Отдельный плюс @nuxt/content в том, что контент версионируется вместе с кодом. Откат к предыдущей версии статьи делается через git revert. Ветка для ревью нового материала это обычный pull request. Для небольших команд, где контент и код пишет один человек, это удобнее любой CMS с историей версий внутри базы данных.

Когда брать: блог, документация, маркетинговый сайт, личное портфолио, лендинг. Если контент пишет разработчик и не нужен нетехнический редактор.

Strapi + Nuxt: когда нужна полноценная админка

Strapi это open-source headless CMS на Node.js, MIT-лицензия, self-hosted. Ставишь на свой VPS, запускаешь, и получаешь REST и GraphQL API плюс веб-интерфейс для редактора. В 2026 году актуальна версия v5, которая принесла упрощённую структуру API (более плоский JSON), новый Plugin SDK и экспериментальную AI-генерацию типов контента.

Принцип работы: в Strapi Content Type Builder создаёшь типы данных (статья, страница, товар), определяешь поля. Strapi сам создаёт таблицы в базе (PostgreSQL, MySQL, SQLite) и генерирует REST/GraphQL-эндпоинты. Редактор входит в админку и правит контент через обычный UI.

Nuxt подключается к Strapi через REST или GraphQL.

// composables/useStrapi.ts
const config = useRuntimeConfig()

export const fetchArticles = () =>
  $fetch(`${config.public.strapiUrl}/api/articles?populate=*`, {
    headers: { Authorization: `Bearer ${config.public.strapiToken}` },
  })

# Запрос статей через GraphQL
query {
  articles(sort: "publishedAt:desc", pagination: { limit: 10 }) {
    data {
      id
      attributes {
        title
        slug
        excerpt
        publishedAt
      }
    }
  }
}

Есть официальный модуль @nuxtjs/strapi, который упрощает интеграцию до пары строк конфига.

// nuxt.config.ts: подключение через официальный модуль
export default defineNuxtConfig({
  modules: ['@nuxtjs/strapi'],
  strapi: {
    url: process.env.STRAPI_URL || 'http://localhost:1337',
    prefix: '/api',
    version: 'v5',
  },
})

Strapi запускается рядом с Nuxt на одном VPS или на отдельном сервере. Для небольших проектов удобен вариант «всё на одной машине»: Caddy проксирует api.example.com на порт 1337 (Strapi) и example.com на порт 3000 (Nuxt). При росте трафика Strapi выносится на отдельный инстанс, а Nuxt масштабируется независимо.

Когда брать: проект с нетехническим редактором, сложная модель данных (несколько типов контента со связями), нужны роли и права. Типичный кейс: корпоративный сайт, блог с несколькими авторами, каталог.

WordPress headless + Nuxt: когда клиент уже на WordPress

WordPress headless: WordPress в роли CMS-бэкенда, Nuxt в роли фронтенда. Никаких тем, никаких PHP-шаблонов. WordPress хранит контент и отдаёт его через REST API (встроен в WP 4.7+) или GraphQL (через плагин WPGraphQL). Nuxt делает запрос и рендерит страницу.

В 2026 году это рабочая и даже mainstream-архитектура. WPGraphQL 2.x принёс автоматические persisted queries и кеширующие директивы, WordPress 6.7 имеет зрелый REST API. Если у клиента уже есть работающий WP-сайт с накопленным контентом, мигрировать его в Strapi сложнее, чем кажется: нужно перегнать все посты, категории, медиафайлы и пересобрать типы данных вручную. Иногда проще оставить WP как бэкенд и просто поменять фронтенд.

// Пример: получение постов через WP REST API
const { data: posts } = await useAsyncData('posts', () =>
  $fetch('https://backend.example.com/wp-json/wp/v2/posts?_embed&per_page=10')
)

# Через WPGraphQL
query GetPosts {
  posts(first: 10) {
    nodes {
      id
      title
      slug
      date
      excerpt
      featuredImage {
        node {
          sourceUrl
        }
      }
    }
  }
}

Подводные камни три, и они реальные. Первый: превью черновиков. В обычном WP нажал «Предпросмотр» и увидел черновик. В headless нужна отдельная схема с аутентификацией и спецэндпоинтом. Второй: некоторые WP-плагины (формы, SEO-подсказки внутри редактора) работают только в связке со стандартным WP-фронтом. Третий: производительность REST API под нагрузкой требует настройки кеша на уровне WP (object cache) и уровне Nuxt.

Когда брать: клиент уже ведёт сайт на WP и не хочет переучиваться. Контент накоплен. Нужна скорость Nuxt-фронта без смены привычной админки. Или важны конкретные WP-плагины, которых нет в Strapi.

Strapi или WordPress headless: прямое сравнение

Это самый частый вопрос, который я получаю. Поэтому дам прямой ответ.

Мой вывод после нескольких проектов с обоими: Strapi выбираю на новых проектах с нуля, когда нужна чистая архитектура. WordPress headless выбираю, когда клиент уже сидит в WP-admin и переезд потребует больше времени, чем решит проблем. Это не вопрос качества, это вопрос контекста.

Как я подхожу к выбору CMS под конкретный проект

Первый вопрос всегда один: кто будет править контент? Если разработчик, берём @nuxt/content и не тратим время на отдельный сервер. Если нетехнический человек, нужна нормальная админка.

Второй вопрос: есть ли уже накопленный контент или работающая система? Если клиент ведёт сайт на WordPress три года, там 500 статей и редактор обучен, headless WordPress с Nuxt-фронтом может быть лучшим решением, чем полный переезд на Strapi.

Третий вопрос: какой масштаб и бюджет на DevOps? Strapi и WordPress требуют собственного хостинга, обновлений, бэкапов. Sanity и Contentful снимают эту нагрузку, но берут деньги за объём. Для небольших проектов managed-облако может оказаться дешевле своего сервера, если считать время разработчика.

Четвёртый вопрос: нужны ли специфические возможности? Directus незаменим, если уже есть готовая БД и нужно просто обернуть её в API. Sanity берут за реальный-тайм редактор и GROQ. Payload берут, когда хочется code-first CMS на TypeScript без admin-UI, встроенного как черный ящик.

Пример из практики: для собственного сайта (evolkov.tech) я выбрал @nuxt/content, потому что контент пишу сам, markdown удобен, и тащить отдельный Strapi ради личного блога было бы инженерным оверкиллом. Для клиентского интернет-магазина ASYADROP выбрал Strapi 5: там редактор добавлял дропы в каталог сам через UI без участия разработчика. Разные задачи, разные инструменты.

Если строите сайт или веб-приложение на Nuxt и не уверены, какая архитектура подойдёт, я помогу разобраться. Моя работа в сфере разработки веб-приложений включает и выбор стека, и реализацию под ключ. Для более простых задач есть создание сайта, где иногда хватает @nuxt/content без внешних сервисов.

Подробнее про то, как вообще выглядит разработка на Nuxt, читайте в статье про стек. Про то, что вообще такое веб-приложение и чем оно отличается от сайта, я разложил в отдельном материале. А SEO-специфика под Nuxt (sitemap, canonical, hreflang) подробно разобрана в гайде про SEO для Nuxt.

FAQ

Что такое headless CMS? Headless CMS это система управления контентом без встроенного фронтенда. Она хранит и отдаёт контент через API (REST или GraphQL), а фронтенд на Nuxt, Next или любом другом стеке забирает данные и рисует страницу сам. В отличие от WordPress-монолита, где бэкенд и шаблоны живут вместе, здесь фронт и бэкенд полностью разделены.

Strapi или WordPress headless: что лучше? Зависит от контекста. Strapi лучше на новых проектах с чистого листа и нетехническим редактором. WordPress headless лучше, когда редактор уже умеет работать в WP-админке, контент накоплен или нужны WP-плагины. Strapi даёт чистоту, WordPress даёт готовность и знакомую среду.

Нужна ли CMS для сайта на Nuxt? Не обязательно. @nuxt/content с markdown в репозитории закрывает задачу без отдельного сервиса, когда контент небольшой и пишет его разработчик. CMS нужна, когда контент правит нетехнический редактор или страниц много.

Можно ли использовать WordPress как бэкенд для Nuxt? Да. WordPress в режиме headless отдаёт контент через REST API или GraphQL (WPGraphQL). Nuxt забирает данные и рендерит страницы. Основные сложности: превью черновиков и аутентификация требуют дополнительной настройки.

@nuxt/content vs Strapi: в чём разница? @nuxt/content это локальный движок внутри Nuxt (файлы в репозитории, без сервера). Strapi это отдельное Node.js-приложение с собственной БД, REST/GraphQL API и веб-интерфейсом для редактора. @nuxt/content для разработчиков, Strapi для нетехнических редакторов.

Сколько стоит разработка headless-сайта на Nuxt? Сайт на @nuxt/content стартует от 30 000 ₽. Полноценный сайт со Strapi или WordPress headless от 60 000 ₽ и выше, в зависимости от сложности. Точную цену называю после брифа.

Directus vs Strapi: что выбрать? Directus для надстройки над существующей SQL-базой. Strapi для проектирования модели с нуля. На новом проекте Strapi удобнее.

Когда стоит взять Sanity или Contentful? Когда не хочется заниматься инфраструктурой бэкенда и есть бюджет на SaaS. Sanity за гибкость и real-time редактор, Contentful за enterprise-зрелость и большие команды.