Next.js + Payload CMS против WordPress: разбор на 2026

Положение дел на 2026: что говорят цифры, а не мнения

WordPress не умирает. По данным W3Techs на 21.07.2026 он стоит на 41,2% всех сайтов и занимает 59,1% среди сайтов с известной CMS. Ближайший конкурент кратно меньше — это не рынок, где лидер шатается.

Изменилось направление. Пик доли — 43,6% в январе 2025, к снимку 27 мая 2026 — 41,9%: минус 1,7 процентного пункта за 16 месяцев (Search Engine Journal). Разовое колебание счётчика — шум, но помесячный ряд у того же источника даёт пять переходов подряд вниз, ни одного отскока, и последний шаг самый крупный. Оговорка: майский снимок сделан 27 мая, остальные помесячные, так что размер последнего шага частично зависит от даты замера.

Здесь важна методическая рамка. Обе доли выше — это один и тот же счётчик W3Techs на разные даты по выборке Tranco top-10M, а не две конкурирующие метрики. Всегда смотрите дату снимка: без неё любая доля рынка — риторика, а цифры из датасетов с другой выборкой с этими несопоставимы.

Долю забирают конструкторы, а не фреймворки

Год к году (май 2026) прибавили Wix +0,6 п.п., Shopify +0,4, Squarespace +0,2, Webflow +0,1 (SEJ). Все четыре — конструкторы и платформы для магазинов, а не фреймворки. Почему конкретный заказчик уходит именно туда, счётчики долей не показывают, и приписывать этому одну причину было бы домыслом.

Что видно точно: Next.js в этот счётчик вообще не попадает — он не CMS, а Payload не выделяется в W3Techs заметной долей. Так что тезис «все переходят на Next.js» цифрами не подтверждается: падение WordPress и выбор кастомного стека — это разные сюжеты.

Четыре оси, по которым принимается решение

Доля рынка отвечает только на вопрос «исчезнет ли экосистема» — не исчезнет. На вопрос «что строить нам» она не отвечает, поэтому дальше решение раскладывается на четыре измеримые оси:

Ни одна из осей не решается фразой «WordPress популярнее». По каждой есть цифры за 2025–2026 — их и разбираем дальше.

Производительность и Core Web Vitals: где теряются секунды

Core Web Vitals — три метрики Google, по которым он оценивает реальный опыт посетителей: LCP (за сколько секунд появляется главный элемент экрана), INP (отзывчивость на клики) и CLS (не прыгает ли вёрстка). Сайт «проходит CWV», если все три в зелёной зоне у 75% реальных визитов.

По Web Almanac 2025 все CWV на мобильных проходят 45% WordPress-сайтов. Средний уровень по вебу — 48% на мобильных и 56% на десктопе. Разрыв в 3 п.п. укладывается в обычный разброс между срезами, так что громкий вывод здесь неуместен. Защитимый вывод скромнее и всё равно неприятен: WordPress не опережает средний веб, хотя это управляемая платформа, а не длинный хвост самописных сайтов.

Место среди платформ и механизм отставания

Данные — HTTP Archive Core Web Vitals Tech Report за апрель 2026. Это отдельный замер со своим срезом: вычитать его из данных Web Almanac нельзя, ростом эта пара не является. Совпадает в обоих отчётах одно — WordPress последний среди крупных платформ.

Разбивка по метрикам показывает, где теряется время: CLS «good» — 84%, вёрстка у WordPress не прыгает, а LCP «good» — только 53% (Web Almanac 2025). Цепочка такая: страница собирается на PHP в момент запроса → медленный TTFB (время до первого байта) → браузер поздно начинает грузить картинку первого экрана → плохой LCP. Страничное кэширование закрывает именно этот участок — вопрос лишь в том, настроено ли оно и переживает ли сброс. Клиентский JS тут почти ни при чём: ядро WordPress его грузит мало.

Чего мы вам не покажем: сравнения «WordPress vs Next.js в процентах»

Такого измерения из первоисточника не существует. Циркулирующие в сети проценты противоречат друг другу и опубликованы без методики; в таблицах HTTP Archive по CWV Next.js нет вообще. Само сравнение методологически кривое: у Next.js выборка смещена в сторону новых проектов, а у WordPress в неё попадает весь длинный хвост дешёвых сайтов на shared-хостинге. Поэтому аргумент дальше — про механизм, а не про процент.

Механизм, за счёт которого выигрывает Next.js

Страница не собирается заново на каждый запрос. SSG отдаёт заранее собранный HTML. ISR работает не по расписанию: посетитель всегда получает готовую страницу из кэша, а когда срок её свежести истёк, первый пришедший запрос отдаёт ту же страницу и параллельно запускает её фоновую пересборку; отдельно есть явный сброс по тегу или адресу — например, из вебхука CMS в момент публикации.

В Next.js 16 поверх этого появилась модель Cache Components: кэширование строго opt-in через директиву"use cache", всё непомеченное выполняется на запросе. Отличие от плагина кэширования не в идее, а в том, что режим каждой страницы задан в коде и виден на ревью, а не зависит от настроек, которые можно случайно сбросить. Гарантии хорошего LCP это само по себе не даёт: картинки и шаблон способны съесть выигранное.

Сколько стоит десятая доля секунды

Ускорение сайта на 0,1 секунды дало ритейлу +8,4% конверсии — это «Milliseconds Make Millions» Deloitte и Google, 30+ млн сессий у 37 брендов. Оговорка: исследование про скорость вообще, а не про переход с WordPress на headless. Публичного кейса миграции WordPress → Payload с измеренными LCP и конверсией не существует — все цифры такого рода в блогах агентств опубликованы без методологии.

Безопасность: 11 334 уязвимости за год и почему ядро WordPress тут ни при чём

За 2025 год в экосистеме WordPress зафиксировано 11 334 новых уязвимости — на 42% больше, чем в 2024-м. Разбивка переворачивает привычный аргумент: 91% из них — в плагинах, 9% — в темах, а в самом ядре за весь год нашли 6 штук, все низкого приоритета(Patchstack, State of WordPress Security in 2026). С ядром всё в порядке; опасно то, что к нему прикручено.

Окно реакции меньше вашего регламента обновлений

46% уязвимостей 2025 года раскрыты публично без исправления — почти о половине дыр узнаёшь раньше, чем появляется способ их закрыть. У самых активно атакуемых взвешенная медиана времени до первой эксплуатации — 5 часов, около половины высокоопасных отрабатывают в первые сутки; в 2018-м то же окно измерялось 63 днями (Patchstack). Регламент «обновляем плагины раз в месяц в плановое окно» не работает арифметически.

В том же отчёте рушатся два самых дорогих мифа. «Платные плагины качественнее»: в premium и freemium — 1 983 уязвимости, 59% высокого риска, а известных эксплуатируемых втрое больше, чем у бесплатных. «Нас защитит хостинг»: в пентестах хостеры отразили лишь 12% атак на WordPress-специфичные уязвимости (Patchstack) — сказывается неконсистентная настройка WAF, фильтра трафика перед сайтом. Читать надо точно: это доля отражённых атак, а не доля хостеров с защитой; WAF не заменяет обновление. И это при том, что поток новых плагинов растёт быстрее, чем его успевают проверять: по 38,7% плагинов авторы не ответили на замечания ревью (make.wordpress.org).

Вторая сторона: чем рискует JS-стек

Приводить цифры по WordPress и ни одной по JS — подтасовка. В декабре 2025 в React Server Components нашли CVE-2025-55182 «React2Shell» с CVSS 10.0: неаутентифицированное выполнение произвольного кода на сервере одним POST-запросом. Через два дня она попала в каталог CISA KEV — подтверждённая эксплуатация в реальных атаках. Payload 3 работает внутри Next.js и наследует все его CVE, плюс имеет свои: 13 проверенных advisories, из них 3 критических.

Отдельный класс риска — цепочка поставки. 2025-й стал худшим годом в истории npm: червь Shai-Hulud, первый самореплицирующийся вредонос в экосистеме, крал токены и облачные ключи и сам публиковал заражённые версии пакетов; его вторая волна задела 796 пакетов и слила секреты у более чем 500 разработчиков. А боевой проект на Next.js тянет сотни npm-пакетов в lock-файле — не десяток осознанно выбранных зависимостей.

Итог: какая поверхность исчезает, а какая появляется

Защитимая формулировка — не «Payload безопаснее», а «поверхность атаки меняет состав». Исчезает источник тех самых 91%: публичные плагины третьих лиц как массовый класс (каталог Payload на порядки меньше, и ставите вы единицы, осознанно), исполнение PHP на проде, массовые волны сканирования по сигнатурам WordPress. Появляется цепочка поставки, CI-раннер с боевыми секретами и радиусом компрометации шире одного сайта, а также собственные CVE фреймворка и CMS — включая критические, которые чинятся деплоем, а не кнопкой «Обновить». Плагин WordPress закрывается за минуту из админки, Next.js требует пересборки, так что окно уязвимости здесь потенциально даже длиннее.

Не меняется главное — обязанность обновляться быстро; меняется лишь то, что вы обновляете и каким процессом. Нет регламента обновлений, аудита зависимостей и дисциплины CI — смена стека купит не безопасность, а другой список задач.

Оговорка, без которой цифры некорректны: годовая статистика держится на одном вендоре, который продаёт защиту именно WordPress, то есть считает то, от чего защищает, — кросс-валидации у неё нет. И знаменатели несопоставимы: слева вся экосистема с десятками тысяч плагинов, справа один фреймворк и одна CMS.

Контроль над платформой: кто может отключить вам обновления

Обновления безопасности для плагинов и тем WordPress приходят на сайт из одного места — с серверов wordpress.org. Этот канал уже отключали, и прецедент задокументирован.

Хроника: как отключают целого хостера

• 25.09.2024 — хостинг-провайдер WP Engine заблокирован на wordpress.org. У его клиентов перестали приходить обновления плагинов и тем, хотя в конфликте они не участвовали.
• 12.10.2024 — плагин ACF (2 млн+ установок) принудительно перехвачен и переименован без согласия владельца.
• 10.12.2024 — федеральный суд выдал предварительный запрет: восстановить доступ WP Engine в течение 72 часов.

Важно не само отключение, а то, чем оно закончилось: откат потребовал судебного решения, а не переговоров. У клиента, лишившегося обновлений безопасности, механизма влияния не было — оставалось ждать исхода чужого иска.

В ходе процесса выяснилась ещё одна деталь: wordpress.org принадлежит лично Мэтту Мулленвегу, а не некоммерческой WordPress Foundation. Канал доставки патчей для всей платформы находится в частном владении одного человека. Дело при этом не закрыто: discovery завершён 14.05.2026, даты суда нет, ожидание — конец 2026 / начало 2027.

Лучший индикатор риска — то, что делает сама экосистема. FAIR Package Manager под эгидой Linux Foundation, анонсированный 05.06.2025, формулирует цель прямо: убрать единственную точку отказа в поставке ядра, плагинов и тем. Рядом — зеркало API wordpress.org от AspirePress с плагином AspireUpdate, позволяющим выбрать альтернативный источник обновлений.

Другая сторона медали: Payload тоже сменил владельца

Payload куплен Figma 17.06.2025, сумма не раскрыта. Обещано, что продукт останется open-source и «в ближайшем будущем для пользователей ничего не меняется». Одно последствие уже видно: страница payloadcms.com/cloud на 21.07.2026 не содержит ни цен, ни регистрации — только баннер про Figma. Managed-хостинг от вендора фактически недоступен, остаётся self-host.

Но риск устроен иначе. Payload распространяется по лицензии MIT, код лежит в открытом монорепо: 43 723 звезды (снимок 21.07.2026). Обновления вы ставите как обычные npm-пакеты — npm тоже централизованный реестр, и это честно стоит признать. Разница в другом: версии зафиксированы в lockfile, обновление — отдельный шаг вашей сборки, а не команда, приходящая на живой сайт извне; реестр зеркалируется штатными средствами, а MIT-код можно форкнуть.

У WordPress канал доставки патчей встроен в работающий сайт, он один и находится в частном контроле — и прецедент его отключения для целого хостера уже был.

Опыт редактора: Gutenberg против админки Payload

Спор «где удобнее редактору» упирается во вкус. Полезнее два измеримых вопроса: какую долю правок редактор делает сам и может ли он при этом сломать вёрстку или разметку так, что заметит поисковик, а не он. По первому WordPress выигрывает, по второму проигрывает.

В каталоге WordPress — 64 078 плагинов, почти любой блок ставится без разработчика. Цена — произвольные отступы и колонки, разъезжающиеся на мобильном, плюс сторонний код в каждом плагине.

В Payload структура контента описана в конфиге: редактор видит конкретные поля и произвольный блок вставить не может, новый пишут разработчики, плагинов в каталоге — около 160. Небольшой редакции новостей и карточек это плюс; сценарию «сами собираем лендинги под акции» — минус.

Рутина редакции: что из коробки, а что заказывать

Мультиязычность: ядро против платного плагина

В ядре WordPress мультиязычности нет, оба стандарта платные: у WPML три тарифа — 39 / 99 / 199 в год, у Polylang Pro — от 99 € за сайт. В Payload локализация в ядре и бесплатна: переводится не документ, а поле, все языки лежат внутри одного документа.

Три оговорки лучше узнать до старта. Решение «это поле переводим» принимается один раз: обратное переключение меняет структуру данных, и переводы теряются. Локаль переводит, но не фильтрует — где перевода нет, запрос вернёт язык по умолчанию (обсуждение в репозитории). Переводческого воркфлоу нет: в WordPress это строчка в счёте за лицензию, в Payload — в смете на разработку.

Роли и согласование: главная слабость Payload

Здесь WordPress выигрывает всухую: у Contributor нет права публиковать, поэтому связка «автор пишет → Pending Review → редактор публикует» работает без плагинов. В Payload роли — обычные поля пользователя, права описываются функциями доступа, а статуса ровно два: черновик и опубликовано.

Многошаговый процесс в WordPress тоже упирается в плагины, но там покупают готовое, а в Payload заказывают разработку. Отыгрывается Payload правами на уровне поля — SEO-блок сеошнику, цена категорийному менеджеру — и блокировкой документа: в ядре WordPress двое авторов затирают правки друг друга.

Где Payload объективно хуже для редакции

1. Ролей и многошагового согласования нет: любой промежуточный статус и календарь — разработка.
2. Нет переводческого воркфлоу: при нескольких языках и внешних переводчиках лицензия WPML дешевле разработки.
3. Поиск в админке слабый: искать по тексту — перечислять поля в коде и индексировать вручную.
4. Предпросмотр — доработка фронтенда, а черновики и версии выключены по умолчанию: если о них не сказали на старте, редакция обнаружит пропажу в худший момент.

Интеграции и API-first: один кодбейз, один TypeScript, ноль сетевых хопов

Payload живёт внутри Next.js, а не рядом

CMS и фронтенд обычно два проекта с HTTP между ними. Payload 3.x ставитсявнутрь Next.js: в /app появляется route-группа(payload) с админкой и API (docs). Отсюда один репозиторий, сборка и деплой. Обратная сторона — привязка к Next.js: версию придётся держать в поддерживаемом окне.

Local API: те же операции, но без сети

Payload даёт REST, GraphQL и Local API: первые два по HTTP, третий — в Node на сервере, в том же процессе.

const payload = await getPayload({ config })
const { docs } = await payload.find({
  collection: 'products',
  where: { slug: { equals: slug } },
})
const product = docs[0] // типизирован как Product

HTTP-запросов к CMS здесь нет: payload.findидёт в базу напрямую, без сериализации в JSON и сетевой латентности — «you don't need to deal with server latency or network speed whatsoever» (Local API). Оговорка: измерений «Local API против REST» у Payload нет — только качественное утверждение; цифры из блогов не используем.

Следствие типизации: между базой и компонентом нет DTO-слоя, поэтому обращение к переименованному полю — ошибка сборки, а не пустое место на странице. Типы не обновляются сами:generate:types — часть сборки. REST и GraphQL остаются: мобильное приложение или CRM получают данные по API, а не парсят HTML.

Магазин и обмен с 1С: где кастом дорожает

Аргумент «один кодбейз» упирается в магазин с учётом в 1С. «Обмен с сайтом» — протокол, а не выгрузка файла: сайт обязан поднять точку1c_exchange.php и отработать шесть режимов с разбором CommerceML 2 (спецификация 1С).

В готовых платформах это уже куплено: у Битрикса двусторонний обмен в поставке с редакции «Малый бизнес» за 47 000 ₽ (редакция), у WooCommerce те же задачи закрывают бесплатные модули — обмен с 1С и оплата ЮKassa с чеками по 54-ФЗ и маркировкой. В кастоме этого слоя нет: e-commerce-плагин Payload официальный, но beta (docs), единственный платёжный адаптер — Stripe, не работающий с РФ; адаптеров под ЮKassa в npm нет. Готовой связки Payload ↔ 1С найти не удалось — это отсутствие находок, а не доказанное отсутствие.

Компромисс — headless WooCommerce: витрина на Next.js на бесплатном Store API (docs), механика магазина на модулях. Полностью кастомный магазин оправдан, когда модель товара нестандартна, учёт вынесен в 1С, а бюджет закладывает обмен, оплату, чеки и склад «с нуля» с сопровождением.

База данных остаётся вашей

Payload работает на MongoDB, PostgreSQL или SQLite (docs). На Postgres контент лежит реляционной схемой: таблица товаров с колонками, а не мета-поля в общей таблице. Обратная сторона: схему генерирует сам Payload, поэтому уход с него — ручная работа со схемой, а изменения полей требуют миграций в CI (migrations).

Порог входа: Node.js ≥ 20.9.0 и совместимый Next.js (installation), плюс база, файловое хранилище, почта и CDN (deployment) — на дешёвом shared-хостинге не появится.

SEO под Яндекс и Google: что правда, а что миф

Миф про JavaScript

«Яндекс не индексирует JavaScript» — неправда: ещё в 2015 годуон объявил, что использует JS и CSS при обходе сайтов. Но оговорка никуда не делась: раздел справки Вебмастера «Индексирование страниц с JavaScript» на июль 2026 всё ещё имеет статус β. Не «legacy», не «стабильно» — бета.

Там же — прямая рекомендация: «Запретите рендеринг, если на сайте реализован SSR (Server-Side Rendering) или пререндеринг». Дефолтная настройка — «На усмотрение робота»: Яндекс не гарантирует, что зайдёт исполнять ваш JS, и предупреждает, что робот при выполнении JavaScript может создавать дополнительную нагрузку на ваш сервер.

Корректный вывод: SSR — режим, который Яндекс сам называет предпочтительным. Next.js отдаёт HTML с сервера по умолчанию. WordPress тоже отдаёт HTML сервером и здесь ничего не проигрывает. Проигрывает третий вариант — SPA на React без SSR, когда браузеру приходит пустой <div id="root">. Отговаривать заказчика надо именно от него, и это не спор WordPress против Next.js.

Где разница реальна, а где её нет

Разница не в скорости: официального документа Яндекса, где скорость загрузки прямо названа фактором ранжирования, мы не нашли — утверждения «скорость решает» принадлежат SEO-агентствам, а не первоисточнику. С ИКС то же самое: Яндекс описывает индекс качества через размер аудитории, удовлетворённость и доверие, формулу не публикует и оставляет за собой право её менять. Связывать ИКС с выбором CMS оснований нет.

Реальная разница в том, где живёт техническое SEO. Canonical, hreflang, sitemap, robots, разметка Schema.org на Next.js описываются в коде приложения: они версионируются, проходят ревью и выкатываются вместе с остальным кодом. В WordPress то же самое живёт в настройках SEO-плагина — стороннего расширения со своим циклом обновлений и своими конфликтами с соседями.

Главный риск — не платформа, а миграция

Немецкое агентство 4eck Media перешло на Strapi + Nuxt и к декабрю 2025 свернуло проект: органическая видимость упала более чем на 90%— источник вторичный, пересказ в блоге агентства. Это аргумент не против headless, а против плохо сделанного переезда: поисковик не знает, что «это тот же сайт», он видит новые URL без 301-редиректов, потерянные canonical и исчезнувшую разметку. Поэтому SEO-контур миграции планируется до первой строки кода фронтенда, а не после запуска.

Российская специфика: хостинг, 152-ФЗ, санкции и реестр отечественного ПО

Предыдущие разделы сравнивали технологии, этот — юрисдикции. Всё, о чём пойдёт речь, бьёт по инфраструктуре, а не по коду CMS: WordPress на зарубежном хостинге и Next.js на Vercel нарушают локализацию персональных данных одинаково.

Vercel: почему облако авторов Next.js не подходит заказчику из РФ

Vercel — дефолт большинства гайдов по деплою Next.js. Для российского юрлица он отпадает по трём независимым причинам.

Первая — договорная: в Terms of Service, раздел 14.1 пользователь гарантирует, что не является объектом санкций OFAC, Совбеза ООН и ЕС. Вторая — платёжная: оплата российской картой нестабильна, рабочий сценарий для юрлица — платёжные посредники. Третья — сетевая: в Vercel Community висит незакрытый тред от 04.12.2025 о недоступности кастомного домена из РФ при работающем *.vercel.app.

Оговорка: официального заявления о блокировке нет ни от РКН, ни от Vercel — корректно говорить «нестабильно и частично недоступно», а не «заблокирован». Для продакшена и этого достаточно: SLA на «нестабильно» не выдают. Отдельный слой риска — Cloudflare, часто стоящий перед сайтом независимо от CMS: с 09.06.2025 у части крупных операторов фиксируются замедление и обрывы соединений к сайтам за ним.

Хостинг и 152-ФЗ: реестр РКН и запрет зарубежных баз

По 406-ФЗ с 01.02.2024 оказание услуг хостинга в РФ провайдерами вне реестра РКН запрещено. РКН 07.04.2025 предупредил о восьми провайдерах вне реестра, среди них Hetzner и DigitalOcean. Оговорка: блокируются сайты самих провайдеров, а не размещённый у них контент.

С персональными данными перемена принципиальнее. 23-ФЗс 01.07.2025 заменил обязанность локализации прямым запретом: запись, накопление и хранение ПДн россиян в зарубежных базах «не допускаются».

Источник сумм: 420-ФЗ, штрафы с 30.05.2025.

Для корпоративного сайта это значит вот что. Любая форма заявки — уже сбор ПДн, значит база и хостинг обязаны быть в РФ. С 01.09.2025 согласие на обработку должно бытьотдельным документом: вшивать его в оферту или пользовательское соглашение нельзя — это переделка форм, а не юридическая формальность. Google Analytics создаёт риск нарушения ч.5 ст.18 — прямого запрета этого сервиса в законе нет, это вывод из общей нормы; рекомендуемая замена — Яндекс Метрика.

Next.js + Payload в РФ разворачивается штатно

Ни одно из ограничений выше не касается самой связки: Payload — MIT и self-host, Next.js — обычное Node-приложение.

Когда нужен не WordPress и не Payload, а 1С-Битрикс

Есть проекты, где спор о стеке закрывает регламент. Реестр российского ПОобязателен при госзакупках по 44-ФЗ, на значимых объектах КИИ и при закупках по 223-ФЗ с нацрежимом. Ни WordPress, ни Payload под критерий реестра не подходят в принципе: он требует исключительных прав у российского правообладателя. «1С-Битрикс: Управление сайтом» в реестре числится.

Цена вопроса по официальному прайсу: Старт 7 100 ₽, Стандарт 20 500 ₽, Малый бизнес 47 000 ₽, Бизнес 96 500 ₽, Энтерпрайз 1 950 000 ₽; продление — 25% от цены лицензии в год. Это не «дорого» и не «дёшево» — обязательная статья расходов, если проект попадает под нацрежим, и лишняя, если нет.

Стоимость владения за 3 года, а не цена старта

Цена разработки — одна строка из пяти: есть ещё хостинг, поддержка, лицензии и разбор инцидентов. Считать нужно 36 месяцев: на этом горизонте эксплуатация сопоставима с бюджетом разработки, а на годовом выигрывает тот, у кого дешевле старт.

Оговорка, без которой дальше нельзя: методологического исследования TCO сайта за три года по рынку РФ в открытом доступе нет — отраслевые рейтинги ценовых срезов по стекам не публикуют, а российская методика UMIcount обрывается на 2020 годе. Дальше — собственная модель, у каждого компонента своя ссылка и дата замера.

Старт и инфраструктура: вилки перекрываются

«Нижняя граница Next.js начинается там, где кончается WordPress» на прайсах 2026 года не воспроизводится: вилки перекрываются полностью. Разброс внутри каждой строки объясняется объёмом работ, а не стеком.

Инфраструктура почти сравнялась: Payload требует Node-рантайма, то есть VPS вместо shared — Selectel VDS 650 ₽/мес против Beget «Start» 590 ₽, шестьдесят рублей разницы в месяц.

Поддержка: главная строка на дистанции

Рынок продаёт базовый пакет от 3 000 ₽/мес, комплексный с SLA за 8 000–20 000 ₽, развитие от 25 000 ₽(25.09.2025). За 36 месяцев даже средний вариант даёт величину порядка всей разработки, верхний — кратно больше. Половину споров закрывает оговорка того же источника: тарифы одинаковы для любых платформ, разделения цен на WordPress и кастом нет. Платят за часы и SLA; публичных данных «WordPress дороже в поддержке» не существует.

Разная не цена, а структура работ: у WordPress это обновление сторонних плагинов и тем, у Payload — npm-зависимости и миграции схемы. Дешевле не по определению, а только если процесс автоматизирован.

Статья, которой у кастомной сборки нет вообще, — премиум-плагины: Yoast SEO Premium $118,80/год, WP Rocket €49 и подобные, около 21 385 ₽ в год по курсу ЦБ на 21.07.2026. Платить нужно ежегодно, иначе прекращаются обновления.

36 месяцев: сводный счёт

Это модельный расчёт по опубликованным вилкам, а не измеренная выборка: суммы сложены из прайсов разных источников и дат. Считается корпоративный сайт без магазина — именно его тарифицируют процитированные источники. Поддержка намеренно одинакова в обеих колонках: цена не зависит от платформы. Низ Next.js поднят с 50 000 до 250 000 ₽ — столько же стоит кастомная разработка вообще. Домен, SSL, контент, SEO и доработки не входят: для обеих колонок они одинаковы.

По нижней границе WordPress дешевле — 237 792 против 381 400 ₽: путь на Next.js в 1,6 раза дороже даже на трёхлетнем горизонте. В этом сценарии у WordPress нет ни платных лицензий, ни дорогого хостинга, и компенсировать разницу на старте нечем: сайт простой, поддержка по базовому тарифу.

Разрыв разворачивается только на верхней границе и всего на 5% — когда нужны индивидуальный дизайн, полный набор плагинов и дорогая поддержка. Пять процентов за три года меньше годового роста цен на разработку, поэтому честная формулировка не «Next.js дешевле во владении», а «в верхнем сценарии разница уходит за пределы точности расчёта». Чем проще сайт, тем сильнее решает цена старта — и тем меньше выбор платформы обосновывается деньгами.

Headless WordPress: очевидный компромисс и его цена

Возражение разумное: не менять CMS, оставить WordPress бэкендом, а фронт написать на Next.js. Вариант рабочий — но платят в другой валюте.

Как устроено и что работает

Контент отдаётся по API: REST встроен в ядро с 4.7, стандарт де-факто — WPGraphQL, 30 000 установок. Редакция остаётся в Gutenberg, архив и роли не мигрируют, фронт получает скорость Next.js. Для крупной редакции это ценность.

Мостом к Next.js должен был стать Faust.js от WP Engine, но в феврале 2025 команда Faust перестала быть продуктовой командой WP Engine, продукт стал «Toolkit for Next.js», App Router депрекирован. EOL не объявлен.

Что ломается

Превью черновиков. Штатная кнопка Preview не работает; решение WP Engine дошло до 1.0.0 лишь 15 декабря 2025.

Темы и плагины фронта. Формы (Contact Form 7 — 10 000 000 установок), конструкторы и страничный кэш завязаны на рендер темы, которого больше нет. Блоки приходят сериализованными: рендер каждого пишет фронт.

SEO и ACF — через плагины-мосты. Разрыв нагляден: при Yoast 10 000 000 и ACF 2 000 000 установок у их мостов 10 000 и 10 000. Комментарии и поиск не рендерятся: всё, что в WP работало само, пишется заново или заменяется сервисами.

Чего headless не решает

Инсталляция остаётся живой PHP-системой, которую надо обновлять, и обязана публиковать/wp-json/ — это её транспорт. В июле 2026 критическая RCE нашлась именно там: wp2shell (CVE-2026-63030): обход аутентификации в/wp-json/batch/v1, патчи — 6.8.6, 6.9.5, 7.0.2. Лечится только патчем; массовой эксплуатации пока не подтверждено.

Цена

Два хостинга, два CI/CD, два домена. Бэкенд — $10–30/мес, до $30–100 под трафик, фронт — Vercel Pro $20/мес за место; итого ≈$50–120/мес против одного хостинга.

Дороже денег — цепочка обновлений: WPGraphQL → мосты ACF и Yoast → Content Blocks → FaustWP → Next.js, каждое звено со своими ломающими изменениями; FaustWP выпустил пять релизов за пять недель.

Кому подходит

Большой редакции с тысячами материалов, укоренившейся в Gutenberg, и когда WP нужен как бэкенд под несколько фронтов. Не подходит как способ «освободить маркетинг»: эффект обратный, изменения начинают зависеть от разработчиков.

Честно: когда WordPress — правильный выбор и где Next.js + Payload проигрывает

Четыре ситуации, где WordPress объективно лучше

Короткий горизонт жизни. Лендинг под кампанию на год-полтора, своего разработчика нет: правит маркетолог, подрядчика зовут почасово — 2 000 ₽/ч у студии. Старт на WordPress дешевле, а экономия Next.js отыгрывается на длинной дистанции, которой здесь нет.

Функционал нужен через две недели. Мультиязычность, фильтруемый каталог, выгрузка заявок в рассыльщик — на WordPress это готовые плагины из официального каталога, на Payload задачи в спринте: в каталоге сообщества около 160 плагинов и ни одной темы, фронтенд пишут на React руками.

Широкий рынок исполнителей. IT-функции нет, подрядчика меняют раз в пару лет по цене, а не по резюме. hh.ru по России (21.07.2026): 236 вакансий с «WordPress» против 119 с «Next.js».

Массовый e-commerce. Несколько сотен позиций, стандартная логика — корзина, промокоды, эквайринг, — программиста нет. WooCommerce держит 4,53 млн магазинов из 13,6 млн отслеживаемых по StoreLeads: сила именно в массовом сегменте.

Оговорка: цены — из прайсов студий, hh показывает спрос работодателей, а не число свободных исполнителей, доли рынка вендор считает по своей методике. Это порядок величины.

Bus factor: если подрядчик исчезнет

За Payload три вещи. MIT и открытое монорепо: код не отзовут, обновления — npm-пакеты с версиями в lockfile. Стандартная база: PostgreSQL или MongoDB читается любым SQL-клиентом. Стандартный стек: преемник — TypeScript/React-разработчик, рынок сопоставим с PHP-шным: 799 вакансий по PHP против 790 по React (hh.ru, 21.07.2026).

Против — преемнику входить не только в React, но и в конкретику проекта: кэширование Next.js, миграции, Payload Config, а это недели. И уйти к вендору нельзя: payloadcms.com/cloud на 21.07.2026 без цен, только self-host.

Преимущество WordPress не в числе знающих технологию, а в глубине рынка вниз: типовой WP-сайт за выходные подхватит исполнитель любого сегмента, вплоть до новичка-фрилансера. Сколько на рынке людей с опытом именно Payload, не знает никто — данных по срезу нет. Но подхватывают WP-сайт вместе с наследством: конструктор и сорок плагинов идут с тем же комом техдолга. Практически bus factor определяет не стек, а то, что лежит у заказчика: репозиторий, доступы, дамп БД, README. Без этого он равен единице везде.

Что WordPress делает хорошо

Автообновления работают: через два месяца после релиза WordPress 7.0 стоит на 61,05% установокс отчётностью на wordpress.org. В 7.0 «Armstrong» приехали AI Client и Abilities API в ядре и редизайн админки (wordpress.org). А претензии по безопасности и скорости адресованы плагинам, темам и хостингу, а не ядру.

Где Payload объективно хуже

Миграции схемы БД. По документации: на Postgres при добавлении поля или коллекции базу вручную приводят в соответствие с Payload Config, иначе — ошибки чтения и записи. В WordPress схему меняют плагины сами.

Порог входа и хостинг. Node.js, TypeScript, React Server Components, кэширование Next.js — уровень разработчика, а не панели управления. Shared-хостинг не подойдёт: нужен Node-рантайм.

Зрелость. 906 открытых issue, версия 4.0 не выпущена и меняет ядровые примитивы.

Переезд с WordPress пишут руками. Универсального импортёра нет: гайд Payload предлагает писать свой скрипт — конфигураций WordPress слишком много для одного инструмента.

Миграция с WordPress: план по шагам и где на нём теряют деньги

Шаг 0. Критерий, а не вкус

Мигрировать стоит при трёх условиях сразу: сайт живёт годы, а не сезон; есть живой поисковый трафик, который страшно потерять; есть планы на интеграции — CRM, 1С, каталог, личный кабинет. Если хотя бы одного условия нет, дешевле привести в порядок текущий WordPress: почистить плагины, обновить PHP, заняться картинками.

Отдельно проверьте, не связаны ли вы 44-ФЗ или требованиями к КИИ: если Реестр российского ПО действительно ваше требование, разговор будет про Битрикс, а не про миграцию.

Шаги 1–4. Инвентаризация, схема, перенос, медиа

Выгружаете полный список URL и переписываете плагины — не названия, а что каждый реально делает: формы, редиректы, микроразметку и кастомные поля придётся воспроизводить руками. Тогда же фиксируете baseline скорости: LCP, CLS, INP и отдельно TTFB — в Core Web Vitals он не входит, но именно он у WordPress тянет LCP вниз. Без замера «до» доказать эффект «после» нечем.

Дальше описываете коллекции, поля и права доступа в Payload Config, а сгенерированные типы кладёте в git — на них опирается весь фронтенд. Перенос контента идёт скриптом через Local API: универсального импортёра не существует, это всегда индивидуальная работа под конкретный набор плагинов, и в смете она должна стоять отдельной строкой.

Где физически лежат медиафайлы — решается до первого деплоя. На платформе с эфемерной файловой системой локальное хранение отпадает: документация Payload формулирует прямо — «any files uploaded to your server only last until the server restarts» (Payload). На VPS с постоянным диском оно работает, но объектное хранилище (в РФ — Yandex Object Storage) проще бэкапить и переживать переезд.

Шаг 5. SEO-контур — здесь теряют деньги

Самый рискованный шаг. Нужны: карта 301-редиректов 1:1 со старых URL на новые, canonical, sitemap, robots, микроразметка, title и description. Оценки потерь видимости при некорректном переносе в публикациях агентств даны без методологии — это иллюстрация масштаба риска, а не измеренная вероятность.

Шаги 6–7. Прод-контур и переключение

Хостинг и база — в РФ, у провайдера из реестра РКН: любая форма заявки означает сбор персональных данных со всеми требованиями к локализации. По технике: payload migrate запускается в CI до сборки. Для serverless-варианта заранее проверьте пул соединений к Postgres: его исчерпание — известная проблема. Переключение идёт по DNS, старый сайт какое-то время живёт рядом; дальше контроль индексации в Яндекс.Вебмастере и Search Console и сравнение скорости с baseline.

Критерий приёмки формулируется до старта

Не «стало красиво», а: позиции сохранены плюс измеренный прирост LCP и TTFB. Публичного кейса миграции WordPress → Payload с раскрытыми цифрами скорости и конверсии не существует, а числа из блогов агентств опубликованы без методологии. Честная опора — только собственные замеры до и после.

Короткие ответы

WordPress умирает? Стоит ли рассматривать его в 2026 году? Не умирает: по данным W3Techs он остаётся самой распространённой CMS, ближайший конкурент кратно меньше. Но доля снижается замер за замером без отскока: направление изменилось. Рассматривать стоит там, где он объективно лучше: короткий срок жизни сайта, готовый функционал нужен сейчас, широкий рынок исполнителей, e-commerce на WooCommerce.

Насколько дороже сайт на Next.js + Payload и когда разница окупается? На старте кастом на Next.js заметно дороже простого кастома на WordPress — это порядок величины из прайсов студий, не независимое исследование. Главная строка на дистанции — поддержка: за три года она сопоставима со стоимостью всей разработки. Универсальной точки окупаемости нет: сайт живёт год — считайте старт, три и больше — эксплуатацию.

Правда ли, что Яндекс плохо индексирует сайты на React и Next.js?Нет. Яндекс давно исполняет JavaScript, а справка Вебмастера рекомендует: «Запретите рендеринг, если на сайте реализован SSR или пререндеринг». Next.js отдаёт HTML с сервера по умолчанию — ровно предпочтительный для Яндекса режим, как и WordPress. Проблемным остаётся SPA на React без SSR, когда роботу приходит пустой <div id="root">.

Можно ли разместить Next.js + Payload на российском хостинге и что требует 152-ФЗ? Можно: Payload под MIT и разворачивается на своём сервере, Next.js — обычное Node-приложение; подойдут Timeweb, Selectel, Yandex Cloud или обычный VPS. Требований три: хостинг у провайдера из реестра РКН, база с персональными данными россиян — физически в РФ, согласие на обработку — отдельным документом. Vercel российскому юрлицу не подходит по договорным, платёжным и сетевым причинам одновременно.

Сможет ли контент-менеджер вести сайт на Payload так же, как на WordPress?Вести — да, расширять — нет. Редактор видит только те поля и блоки, что описаны в конфиге: вставить произвольный блок нельзя, зато и сломать вёрстку он не может. Небольшой команде, которая публикует новости и карточки, так проще. Для сценария «сами по выходным собираем лендинги под акции» это минус: каждый новый блок — работа разработчика, а каталог плагинов Payload несопоставимо беднее, чем у WordPress.

Что будет с Payload после покупки компанией Figma — не попадём ли мы в вендор-лок? Одно последствие уже видно. На payloadcms.com/cloud на 21.07.2026 нет ни цен, ни регистрации: managed-хостинг у вендора взять негде, остаётся self-host. Но профиль риска другой, чем у WordPress: MIT-лицензия, открытое монорепо, обновления — обычные npm-пакеты с версиями из lockfile, а не команда извне на живой сайт. Реальные привязки — зависимость от Next.js и то, что схему Postgres генерирует сам Payload: уход означает ручную работу со схемой.

Что делать дальше

1. Проверьте, попадает ли проект под нацрежим. 44-ФЗ, значимые объекты КИИ, 223-ФЗ с нацрежимом — если да, разговор про Битрикс из Реестра российского ПО, а не про Payload. Закрывайте этот вопрос первым: он отменяет все остальные.
2. Сверьте задачу с тремя условиями миграции. Горизонт жизни — годы, живой поисковый трафик, планы на интеграции. Нет хотя бы одного — дешевле привести в порядок текущий WordPress: плагины, версия PHP, картинки.
3. Снимите baseline до любых работ. LCP, CLS, INP и TTFB — по нему у WordPress чаще всего и проседает LCP. Без замера «до» эффект «после» доказать нечем.
4. Проведите инвентаризацию плагинов. Список URL и список плагинов с пометкой, что каждый делает: формы, редиректы, микроразметка, кастомные поля. Часть окажется мёртвым грузом, остальное придётся повторять руками — это отдельная строка сметы, а не «в рамках переноса контента».
5. Спланируйте SEO-контур до первой строки фронтенда. Карта 301-редиректов 1:1, canonical, sitemap, robots, микроразметка, title и description. Именно здесь чаще всего теряют органику.
6. Заложите прод-контур и шероховатости. Хостинг и база в РФ у провайдера из реестра РКН, объектное хранилище под медиа, payload migrate в CI до сборки. Отдельно — выход Payload 4.0 с редизайном админки: редакторов придётся переучивать.
7. Зафиксируйте критерий приёмки до старта. Не «стало красиво», а: позиции сохранены плюс измеренный прирост LCP и TTFB против baseline из шага 3.</parameter>

</invoke>