Headless WordPress + React: для каких задач

Классический WordPress объединяет в себе всё: и хранение контента, и рендеринг страниц. Headless разделяет эти роли: WordPress остаётся «головой» только для контент-менеджеров, а пользователь открывает сайт, собранный на React или Next.js. Подход даёт большую гибкость и хорошую скорость, но требует двух стеков разработки вместо одного. Кому это нужно — рассмотрим по пунктам.

01Что такое headless WordPress по сути

В обычной установке WordPress на каждый запрос: принимает URL → собирает страницу из шаблона → рендерит в HTML → отдаёт браузеру. Тема, плагины и редактор — всё в одной системе.

В headless-конфигурации цепочка другая. Контент-менеджер работает в админке WordPress как обычно, но сам сайт пользователь получает с отдельного фронтенда, который запрашивает данные через REST API (/wp-json/) или WPGraphQL. Фронт может быть на Next.js, Nuxt, SvelteKit, Astro — любом фреймворке, который умеет рендерить страницы на сервере или статически.

То есть «голова» (frontend) и «тело» (CMS) разделены. Отсюда и название.

02Когда headless действительно нужен

В реальности под задачи малого и среднего бизнеса полноценный headless оправдан в нескольких сценариях.

Высокие требования к скорости

Когда нужны «зелёные» Core Web Vitals на сложном сайте с большим количеством интерактива, Next.js с SSR/ISR закрывает задачу лучше, чем оптимизированный WordPress с плагинами. Это особенно заметно на проектах, где важна не средняя скорость, а её стабильность под нагрузкой и в регионах.

Сайт-приложение

Если у вас не статичный сайт, а интерактивный продукт — личный кабинет, расчёт стоимости в реальном времени, конфигуратор, маркетплейс с фильтрами, — React даёт удобный инструмент для сложного UI. WordPress в этом случае хранит контент о товарах, условиях, статьях.

Несколько каналов из одной CMS

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

Интеграция с фронтендом, который пишет существующая команда

Если у вас уже есть продуктовая команда на React/Next.js, и им проще брать данные из WordPress по API, чем разбираться в темах и плагинах — headless снимает конфликт стеков.

03Когда headless не нужен

Гораздо чаще headless оказывается избыточным. Признаки, что вам он не нужен:

• Это сайт услуг, корпоративный сайт, лендинг или небольшой магазин до 500 SKU. Классический WordPress справится дешевле и быстрее в разработке.
• В команде нет фронтендщика на React/Next.js — каждая правка кнопки будет идти через разработчика, а не через визуальный редактор.
• Контент-менеджер привык к Elementor/Gutenberg и хочет видеть результат «как на сайте» прямо в редакторе. В headless WYSIWYG-предпросмотр работает иначе.
• Сайт зависит от десятка WordPress-плагинов с фронтенд-частью (формы, слайдеры, конструкторы блоков) — на headless их придётся переписывать.

Если перечисленное про вас — обычный оптимизированный WordPress закроет задачу в разы дешевле.

04Плюсы подхода

• Скорость и Core Web Vitals. Статическая генерация (SSG) и ISR в Next.js дают TTFB в десятки миллисекунд и стабильно высокие метрики.
• Безопасность. Фронтенд и WP-админка часто живут на разных доменах: атаковать админку из открытого интернета сложнее.
• Свобода фронтенда. UX и визуальные эффекты ограничены только возможностями React, а не плагинами темы.
• Масштабируемость. Статика и CDN держат любые пики трафика без апгрейда сервера.
• Один источник контента для нескольких витрин.

05Минусы и подводные камни

• Два стека вместо одного. Нужны и PHP-разработчик/админ WP, и JS/React-разработчик. Это удваивает компетенции в команде.
• Цена разработки выше. Headless-проект обычно в 1,5–2 раза дороже сопоставимого классического сайта на WordPress.
• Превью контента. Контент-менеджер не видит изменения «как на сайте» сразу, без отдельной настройки preview-режима.
• Плагины с фронтендом. WooCommerce, Contact Form 7, Elementor — на headless не работают в привычном виде, нужны замены.
• SEO-нюансы. На стороне Next.js всё хорошо при SSR/SSG, но плагины SEO (Yoast, RankMath) часть тегов формируют в шаблонах WP — их данные нужно вытаскивать через API и подставлять во фронт. См. отдельно про JavaScript-фреймворки и SEO.
• Сложность поддержки. Когда что-то ломается, причина может быть и в WP, и в API, и во фронте, и в CDN. Логи и наблюдаемость становятся обязательны.

06Типовые архитектуры

На практике в headless WordPress чаще всего встречаются три варианта.

Next.js + WPGraphQL

Самый популярный стек. WPGraphQL даёт удобный API, Next.js рендерит на сервере (SSR) или статически (SSG) и переразвёртывает страницы по событиям (ISR). Подходит для большинства задач: контентные сайты, блоги, корпоративный сегмент.

WordPress + Astro/Nuxt/SvelteKit

Если фронт-команда привыкла к другому стеку — подключают аналогичную связку. Принцип тот же: контент берут из wp-json/wp/v2/ или WPGraphQL.

Гибрид: classic + headless-разделы

Часть сайта (блог, услуги) живёт на классическом WP, отдельный поддомен с интерактивной частью (личный кабинет, маркетплейс) — на Next.js, который тянет данные из той же базы. Хороший компромисс, если headless нужен только под конкретный модуль.

07Как принять решение

Перед тем как уходить в headless, ответьте себе на три вопроса:

1. Что конкретно мешает в классическом WordPress сейчас — скорость, интерактив, мультиканальность или просто «модно»?
2. Есть ли у вас (или у подрядчика) компетенция в React/Next.js и опыт продакшен-эксплуатации таких сайтов?
3. Готовы ли вы к тому, что любая правка контента, выходящая за рамки текста и картинок, требует разработчика?

Если на все три «да» — headless оправдан. Если хотя бы одно «нет» — почти всегда выгоднее сделать или переделать сайт на классическом WordPress и заняться его оптимизацией.

Headless WordPress — это инструмент, а не маркер «современности». Он хорош там, где нужен сложный фронт, и неудобен там, где хватает обычной CMS.

Официальная документация по теме — Справка Яндекс.Вебмастера.