Переезд WordPress на Next.js в 2026: когда стоит, сколько занимает, чего ожидать

Классический WordPress — это монолит: PHP-движок принимает запрос, забирает данные из БД MySQL, генерирует HTML по шаблону темы и отдаёт браузеру. Всё в одной системе, на одном сервере.

«Перевод на Next.js» (или, более правильно, «миграция на headless WordPress») означает разделение этой архитектуры на две независимые части. WordPress остаётся как админка — там контент-менеджеры пишут статьи, добавляют товары, редактируют страницы. Привычная админка, всё знакомо, никаких переобучений. А сайт, который видит пользователь, — это уже отдельное Next.js-приложение, которое забирает контент из WordPress через GraphQL или REST API.

Преимущества такой схемы: сайт работает в 3-5 раз быстрее (PageSpeed 90-100 на мобильных), безопаснее (фронт не имеет прямого доступа к БД), масштабируется через CDN, поддерживает омниканальность (один и тот же контент через API получают сайт, мобильное приложение, Telegram-бот, голосовой ассистент).

Недостатки: дороже разрабатывать и поддерживать, требует команды с React-опытом, сложнее предпросмотр контента для редакторов. В этой статье разберём, когда такой переезд реально оправдан, а когда — это инженерное излишество.

Headless-миграция оправдана, если совпадают хотя бы 2-3 из этих условий:

• Высокая нагрузка. Если сайт получает 10 000+ уникальных посетителей в день и часто «ложится» под пиковой нагрузкой — проблема в PHP-обработке, и переход на Next.js + CDN решает её радикально.
• Проблемы с Core Web Vitals. WordPress без серьёзной оптимизации даёт PageSpeed 50-70. Если позиции сайта падают из-за CWV, и вы дошли до предела оптимизации классического WP — следующий шаг Next.js.
• Кастомный UX. Сложные интерфейсы, которые тяжело реализовать на шаблонной системе WordPress: мультистраничные конфигураторы, 3D-каталоги, продвинутые анимации, реал-тайм взаимодействие.
• Команда фронтендеров уже есть. React/Next.js-разработчики на штате — это половина успеха headless-проекта. Если их нет, поддержка будет дорогой.
• Омниканальность. Помимо сайта планируется мобильное приложение, Telegram-бот, голосовой ассистент или другие точки выдачи контента. Headless позволяет переиспользовать админку и контент.
• Желание сохранить WordPress-админку. Контент-менеджеры её любят и продуктивны в ней. Headless — единственный способ сохранить админку и при этом получить современный фронт.

Множество проектов попадают в ловушку «модной архитектуры» и тратят деньги впустую. Не делайте headless если:

• Контентный сайт с малой посещаемостью. Блог на 500 посетителей в день, корпоративный сайт на 1000 — классический WordPress справляется отлично. Headless будет переплатой 2-3 раза.
• Бюджет до 500 тыс. ₽. Качественная headless-миграция начинается от 600-700 тыс. На меньшем бюджете получите наполовину сделанный проект с проблемами.
• Нет команды для поддержки фронта. Headless требует регулярных обновлений Next.js, поддержки CI/CD, мониторинга. Если в команде нет React-разработчика — поддержка будет либо дорогой, либо запущенной.
• Магазин на WooCommerce. WooCommerce сильно завязан на PHP-логику и WordPress hooks. Headless WooCommerce возможен, но сложен и менее стабилен. Для магазинов чаще выгоднее оставить классический WP с оптимизацией или мигрировать на Битрикс/Magento.
• Корпоративный сайт без планов на масштабирование. Если сайт уже сейчас удовлетворяет всем требованиям, и в ближайшие 2-3 года не планируется кратный рост — миграция не окупится.

Любой переезд — это риск, и headless-миграция не исключение. Главные «грабли»:

• Падение SEO-позиций. Самый частый и болезненный риск. Если что-то упустили — title, description, schema.org, редиректы — позиции просядут. Восстановление занимает 2-6 месяцев.
• Поломка превью контента. В классическом WordPress контент-менеджер пишет статью, нажимает «Предпросмотр» и видит результат. В headless нужно отдельно настраивать preview-режим, и это не всегда просто.
• Различия в ACF-полях. Если в WordPress используются Advanced Custom Fields с сложной структурой, придётся переписывать запросы и компоненты. Подводных камней много.
• Проблемы с формами и взаимодействиями. Если на сайте есть формы Contact Form 7 или Gravity Forms, в Next.js их нужно либо вызывать через API, либо переписывать целиком.
• Внешние плагины с шорткодами. Если используются плагины, генерирующие HTML через шорткоды, в headless они не сработают. Нужна замена или полное переписывание.
• Стоимость обновлений. После миграции каждое крупное обновление WordPress или Next.js требует тестирования и иногда правок. Бюджет на поддержку растёт.

Стоимость миграции зависит от размера сайта и сложности логики:

• Лендинг или мини-сайт (5-15 страниц). 200-350 тыс. ₽, срок 3-4 недели. Базовая миграция, 1-2 типа страниц, минимум кастомной логики. Обычно для проектов с акцентом на скорость.
• Корпоративный сайт + блог (20-50 страниц). 350-600 тыс. ₽, срок 1-2 месяца. Несколько типов страниц, блог с тегами и категориями, базовые формы.
• Сложный корпоративный сайт (50-200 страниц). 600-1 200 тыс. ₽, срок 2-4 месяца. Несколько типов контента, кастомные ACF-поля, сложная логика, мультиязычность.
• Портал с личным кабинетом. 1-2 млн ₽, срок 3-5 месяцев. Аутентификация пользователей, формы, личные данные, интеграция с внешними сервисами.
• Магазин (если всё-таки нужно). От 1.5 млн ₽, срок 4-6 месяцев. Учитывая сложность WooCommerce-headless.

Стоимость поддержки headless-сайта обычно в 1.5-2 раза выше классического WordPress — нужно поддерживать обе системы.

Дано: онлайн-журнал, 8 лет на классическом WordPress, около 200 статей, 30 000 уникальных посетителей в день. Проблемы: PageSpeed 38 на мобильных, INP 380 мс, постоянные жалобы от рекламодателей на медленный сайт, проседание в выдаче.

Что сделали:

1. WordPress оставили как админку. Установили WPGraphQL и WPGraphQL ACF.
2. Сделали Next.js 15 фронтенд с App Router. SSG для статичных страниц, ISR с revalidate=300 для свежих статей.
3. Воссоздали все 12 типов schema.org разметки, OpenGraph для всех страниц, sitemap.xml.
4. Перенесли все 240 редиректов 301 из старой системы.
5. Подключили Vercel для деплоя и CDN. Настроили автоматический ребилд по webhook из WordPress.
6. Реализовали preview-режим для редакторов через Vercel preview deployments.
7. Тестировали на staging 3 недели, потом ночью переключили DNS.

Результат через 3 месяца:

• PageSpeed: 38 → 96 на мобильных
• LCP: 4.2 сек → 1.1 сек
• INP: 380 мс → 80 мс
• Посещаемость: рост на 28% за счёт улучшения SEO-позиций
• Время на сайте: рост на 35%
• Стоимость рекламы: премиум-рекламодатели вернулись и платят на 40% больше за инвентарь

Стоимость проекта: 850 тыс. ₽, срок 10 недель. Окупаемость — 5 месяцев.