Миграция с WordPress на Next.js: пошаговый гайд без потери SEO

Миграция с WordPress на Next.js - это перенос сайта с PHP-движка на React-фреймворк с рендерингом на сервере или статической сборкой, при котором контент, URL-структура и SEO-сигналы переносятся в новую архитектуру без потери позиций. Правильная миграция сохраняет 100% трафика к 30-му дню и обычно даёт прирост 10-30% к 90-му дню за счёт более быстрого сайта. Ключевой риск - не сам переезд на новый стек, а потеря того, что WordPress делал незаметно: авто-генерация sitemap, канонические теги, редиректы, структура категорий.

В проектах веб-разработки Exceltic.dev регулярно видим одну и ту же картину: компания решает переехать с WordPress на Next.js из-за скорости и безопасности, но недооценивает объём ручной работы по SEO-инфраструктуре. WordPress через Yoast или Rank Math закрывает десятки технических задач автоматически - без плагинов Next.js их придётся написать самостоятельно. По данным разбора миграции на dashweb.agency, при качественно составленной карте редиректов сайты не теряют трафик к 30-му дню и получают рост 10-20% к 90-му дню, 30-50% к 180-му. При некачественной карте редиректов - обратный эффект: падение на месяцы.

Дальше - пошаговый план: что теряется при наивном переезде, как устроен аудит перед миграцией, какую архитектуру собирать на Next.js и какие метрики Core Web Vitals реально меняются после переезда.

Почему компании уходят с WordPress на Next.js

WordPress работает на PHP: каждый запрос страницы означает запрос к базе данных и рендеринг на лету, если не настроено кэширование на уровне сервера. При росте трафика или количества плагинов время ответа сервера растёт, а вместе с ним - LCP.

Next.js - это React-фреймворк с поддержкой статической генерации (SSG), серверного рендеринга (SSR) и инкрементальной статической регенерации (ISR), который отдаёт готовый HTML без обращения к базе данных на каждый запрос.

Три конкретные причины миграции повторяются в проектах чаще остальных. Первая - производительность: на shared-хостинге с 15-20 активными плагинами Time to First Byte часто превышает 800 мс, тогда как статически сгенерированная страница Next.js на CDN отдаётся за 50-200 мс. Мы разбирали механику замедления подробнее в статье о том, почему WordPress тормозит сайт.

Вторая причина - безопасность. Каждый установленный плагин - это отдельная точка входа для эксплойтов, и число новых уязвимостей в экосистеме WordPress растёт из года в год: подробный разбор в статье об уязвимостях в плагинах WordPress. У статического Next.js-сайта просто нет базы данных и админ-панели, которые можно взломать.

Третья причина - стоимость владения. Managed WordPress хостинг с приемлемой производительностью (WP Engine, Kinsta) стоит 30-300 долларов в месяц в зависимости от трафика, плюс лицензии платных плагинов. Next.js на Vercel в большинстве сценариев маркетингового сайта укладывается в бесплатный тариф или несколько десятков долларов при высокой нагрузке.

Что теряется при наивной миграции

Наивная миграция - это перенос контента без карты соответствия URL и без аудита технических SEO-сигналов, которые WordPress генерировал автоматически. Дальше - конкретные точки потери, которые не видны, пока не начнётся падение трафика через 2-4 недели после запуска.

URL-структура. WordPress по умолчанию строит URL по шаблону /category/post-slug/ или /post-slug/ в зависимости от настроек постоянных ссылок. Next.js не имеет встроенной логики URL - если новая структура роутинга не совпадает со старой хотя бы для части страниц, эти страницы теряют накопленный SEO-вес без 301-редиректа.

Редиректы. WordPress-плагины (Yoast, Redirection) хранят карту редиректов в базе и применяют её на уровне PHP. При переезде эта карта не переносится автоматически - её нужно выгрузить, проверить на актуальность и перенести в next.config.js или в middleware явным списком.

Плагины и функциональность. Формы (Contact Form 7, Gravity Forms), калькуляторы, галереи, встроенные виджеты бронирования - весь функционал плагинов работает на PHP-хуках, которых в Next.js не существует. Каждый такой плагин нужно либо заменить SaaS-виджетом, либо написать заново как React-компонент.

Изображения и медиа. WordPress хранит медиатеку в /wp-content/uploads/ с автоматической генерацией нескольких размеров под каждое изображение. При переносе в Next.js изображения либо мигрируют в public/, либо переезжают в CDN (Cloudinary, Vercel Blob) - в обоих случаях нужно сохранить старые пути или настроить редиректы на новые, иначе внешние ссылки на изображения из Google Images и соцсетей начнут отдавать 404.

Технические SEO-сигналы. Sitemap.xml, robots.txt, канонические теги, Open Graph разметка, schema.org микроразметка - в WordPress это генерируется плагином при каждой публикации. В Next.js все эти элементы нужно собрать вручную через generateMetadata и файловые конвенции (sitemap.ts, robots.ts).

Аудит перед переездом: что инвентаризировать

Аудит перед миграцией - это полная инвентаризация URL, контента и технических сигналов старого сайта, выполненная до начала разработки на новом стеке. Без этого шага карта редиректов строится по памяти и почти всегда получается неполной.

Порядок инвентаризации, который снимает большую часть рисков из предыдущего раздела:

1. Экспорт всех URL. Прогнать сайт через Screaming Frog или Sitebulb и получить полный список индексируемых страниц, включая пагинацию, теговые страницы и архивы по датам.
2. Выгрузка данных Google Search Console. Забрать минимум 12 месяцев данных: топ-500 запросов по показам, страницы с наибольшим трафиком, текущие индексируемые URL. Это приоритетный список страниц, которые нельзя потерять.
3. Карта контент-типов. Зафиксировать все Custom Post Types, таксономии и ACF-поля - в Next.js под каждый тип понадобится своя модель данных.
4. Список плагинов с функциональностью. Не просто список названий, а что именно каждый плагин делает на фронтенде - формы, попапы, чат-виджеты, расчёт стоимости.
5. Инвентаризация медиафайлов. Сколько изображений, в каком формате, какой общий вес - это определяет, переносить ли медиатеку как есть или проводить конвертацию в WebP/AVIF при миграции.

Более подробный чек-лист с разбивкой по часам мы собрали в статье аудит сайта перед миграцией.

Архитектура нового стека на Next.js

Архитектура миграции с WordPress на Next.js строится вокруг трёх решений: где живёт контент, как рендерится страница и где размещается сайт. Дальше - обоснование для каждого.

Контент: Headless CMS или MDX. Headless CMS - это система управления контентом без собственного фронтенда, которая отдаёт данные через API, а не рендерит HTML сама. Для сайта с частыми публикациями (блог, база знаний) есть смысл перенести контент в Sanity, Contentful или Strapi - редакторы получают привычный интерфейс, разработчики получают контроль над рендерингом. Для сайта с редкими изменениями контента (5-10 страниц, лендинги) часто достаточно MDX-файлов прямо в репозитории - это проще в поддержке и не требует отдельной подписки на CMS. Разбор конкретных Headless CMS есть в статье Sanity vs Contentful vs Strapi.

Рендеринг: SSG или ISR. Для контентных страниц, которые не меняются ежеминутно, статическая генерация (SSG) даёт лучший результат по Core Web Vitals - HTML собран заранее, сервер не выполняет никакой логики на запрос. Для страниц с часто обновляемыми данными (цены, наличие) подходит инкрементальная статическая регенерация - страница обновляется в фоне по расписанию, не блокируя пользователя.

Хостинг: Vercel или self-hosted. Vercel - это платформа-разработчик Next.js, поэтому деплой и edge-кэширование настроены без дополнительной конфигурации. Self-hosted вариант (Node.js-сервер за Nginx, Docker) оправдан, если у компании уже есть требование по хранению данных в конкретном регионе или собственная инфраструктура.

Почему выбор пал именно на Next.js, а не на Astro для этого сценария - разбирали отдельно, включая сравнение по Core Web Vitals и кривой обучения команды, в статье Next.js vs Astro для маркетингового сайта.

Пошаговый процесс миграции

Дальше - последовательность, которая на практике снижает риск потери трафика до близкого к нулю при соблюдении порядка шагов.

Шаг 1. Настроить проект и модель контента

Создать Next.js-проект (App Router), описать типы контента (посты, страницы, категории) под структуру, зафиксированную на этапе аудита. Если контент переезжает в Headless CMS - на этом шаге настраивается схема полей и импорт из экспорта WordPress (WXR-файл конвертируется в JSON через wordpress-export-to-markdown или аналогичный скрипт).

Шаг 2. Перенести контент и медиа

Импортировать посты и страницы, сохранив исходные даты публикации (важно для сигналов свежести контента). Изображения либо переносятся в public/ с оригинальными путями, либо загружаются в CDN с сохранением алиасов на старые URL.

Шаг 3. Собрать SEO-инфраструктуру

Настроить generateMetadata для каждого типа страниц, сгенерировать sitemap.xml и robots.txt через файловые конвенции Next.js, добавить JSON-LD разметку (Article, BreadcrumbList, FAQPage при наличии вопросов на странице). Пример конфигурации generateMetadata для страницы поста:

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug);

  return {
    title: post.seoTitle,
    description: post.seoDescription,
    alternates: { canonical: `https://example.com/blog/${post.slug}/` },
    openGraph: {
      title: post.seoTitle,
      description: post.seoDescription,
      images: [post.ogImage],
      type: 'article',
    },
  };
}

Шаг 4. Построить карту редиректов

Сопоставить каждый URL из аудита с новым адресом. Если структура не поменялась - редирект не нужен, но это стоит подтвердить явно, а не предполагать. Список редиректов подключается через redirects() в next.config.js или через middleware для динамических правил:

module.exports = {
  async redirects() {
    return [
      {
        source: '/category/wordpress-tips/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      {
        source: '/wp-content/uploads/:path*',
        destination: '/media/:path*',
        permanent: true,
      },
    ];
  },
};

Шаг 5. Протестировать на staging-домене

Прогнать staging-версию через Screaming Frog, сверить с исходным списком URL, проверить, что ни одна страница из топ-500 по показам в Search Console не отдаёт 404 или 500. Проверить canonical-теги, hreflang (если есть мультиязычность) и корректность Open Graph превью.

Шаг 6. Запустить и отследить первые недели

Переключить DNS, отправить новый sitemap.xml в Google Search Console, вручную запросить переиндексацию для 10-20 самых трафиковых страниц. В первые 2-4 недели ежедневно проверять отчёт “Покрытие” в Search Console на предмет новых ошибок 404 или неожиданных исключений из индекса.

Более полный разбор поведения SEO-сигналов на этапе запуска - в статье SEO при миграции сайта. Общие принципы сохранения SEO-эквити при смене домена или структуры URL описывает и руководство Google по переезду сайта.

Core Web Vitals до и после миграции

Core Web Vitals - это набор метрик Google, измеряющих реальную скорость и стабильность страницы для пользователя: LCP (загрузка основного контента), CLS (визуальная стабильность) и INP (отклик на взаимодействие). Пороговые значения “хорошо” по данным web.dev: LCP до 2.5 секунд, CLS до 0.1, INP до 200 мс.

В типовом проекте миграции сайта с 200-500 страницами контента с WordPress на shared-хостинге на Next.js с деплоем на Vercel показатели меняются в следующих диапазонах:

• LCP: с 3.5-5.5 секунд до 1.2-2.2 секунд - за счёт исчезновения запроса к базе данных на каждый рендер и статической отдачи HTML через CDN.
• CLS: с 0.15-0.3 до 0.02-0.08 - за счёт явного указания размеров изображений через next/image вместо динамически подгружаемых виджетов и рекламных блоков.
• INP: с 300-500 мс до 100-180 мс - за счёт меньшего количества стороннего JavaScript (трекеры, виджеты плагинов), который в WordPress часто накапливается бесконтрольно.

PageSpeed Insights по мобильному трафику в таких проектах обычно поднимается с диапазона 35-55 до 85-98. Точные цифры зависят от количества медиа на странице и объёма стороннего JavaScript (чаты, аналитика, пиксели), который переносится вместе с сайтом - каждый лишний скрипт съедает часть выигрыша от смены стека.

Типичные ошибки при переезде

Часть ошибок повторяется в проектах миграции независимо от размера сайта. Разберём самые частые.

Забыли про пагинацию и архивы по датам. Screaming Frog находит только связанные ссылками страницы - URL пагинации категорий и архивов по месяцам часто не индексируются вручную и выпадают из карты редиректов, если полагаться только на краулер без сверки с логами сервера или Search Console.

Перенесли изображения без сохранения путей. Если старые URL картинок из /wp-content/uploads/2024/03/ не редиректят на новое расположение, теряется трафик из Google Images и разрываются внешние ссылки на изображения с других сайтов.

Не проверили canonical-теги на staging. Частая ошибка - staging-домен остаётся проиндексированным или canonical по умолчанию указывает не на финальный домен, из-за чего Google после запуска короткое время путает основную и тестовую версию.

Выключили редиректы через несколько месяцев. 301-редиректы нужно держать активными минимум 6-12 месяцев после запуска - Google учитывает старые URL постепенно, и часть внешних ссылок с других сайтов физически не обновится никогда.

Перенесли контент, но не проверили внутреннюю перелинковку. WordPress-плагины (Yoast, Rank Math) часто строят автоматические блоки “похожие статьи”. После переезда на Next.js такие блоки нужно либо воссоздать логикой на основе тегов и категорий, либо расставить ключевые внутренние ссылки вручную - без них передача SEO-веса между страницами проседает.

Для кого актуальна эта миграция

Миграция с WordPress на Next.js оправдана для компаний с маркетинговым или контентным сайтом от 15-20 сотрудников, где WordPress уже упирается в производительность или стоимость поддержки, а команда готова взять на себя разработку через код вместо визуального редактора.

Хуже подходит сценарий, где нетехнические сотрудники ежедневно правят контент напрямую в визуальном редакторе без участия разработчиков - для таких команд Headless CMS с удобным UI поверх Next.js закрывает потребность, а чистый MDX в репозитории создаёт новое узкое место.

Часто задаваемые вопросы

Сколько времени занимает миграция с WordPress на Next.js?

Для сайта на 50-100 страниц с типовым набором контента (блог, лендинги, несколько форм) миграция обычно занимает 4-8 недель, включая аудит, разработку, тестирование и наблюдение за индексацией после запуска. Сайты с нестандартной функциональностью плагинов (калькуляторы, личные кабинеты, сложные фильтры каталога) требуют больше времени на воссоздание логики на React, а не на перенос контента.

Что будет с позициями в Google сразу после переезда?

При корректной карте редиректов и сохранённых технических сигналах краткосрочная просадка обычно минимальна или отсутствует - Google переобрабатывает 301-редиректы в течение нескольких дней-недель. Более заметное падение возникает, если часть URL остаётся без редиректа или canonical настроен неправильно - тогда часть страниц временно выпадает из индекса до ручного исправления.

Нужно ли полностью отказываться от WordPress или можно оставить его как источник контента?

Оба варианта рабочие. Часть компаний оставляет WordPress в headless-режиме и забирает контент через REST API или WPGraphQL, сохраняя привычный интерфейс редактирования для маркетинг-команды. Другие полностью переносят контент в отдельную Headless CMS или MDX, чтобы убрать зависимость от PHP-инфраструктуры и связанные с ней риски безопасности.

Какой хостинг выбрать для Next.js после переезда с WordPress?

Vercel - самый быстрый путь для команд без выделенного DevOps-ресурса: деплой из Git, edge-кэширование и превью для каждого пул-реквеста настроены из коробки. Self-hosted вариант на собственном сервере или в Docker-контейнере имеет смысл, если у компании есть требования по размещению данных в конкретном регионе или уже есть инфраструктура, которую дешевле переиспользовать.

Можно ли мигрировать сайт по частям, а не полностью сразу?

Да, и для больших сайтов это снижает риск. Практика - вынести на Next.js сначала блог или отдельный раздел через reverse-proxy (например, правило в Nginx или Vercel rewrites, которое отправляет /blog/* на новый Next.js-сервис, а остальной трафик оставляет на WordPress), затем постепенно переносить остальные разделы. Это требует аккуратной настройки маршрутизации на уровне DNS или прокси, но позволяет откатить отдельный раздел без риска для всего сайта.

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

• Проведите аудит текущего сайта: полный список URL, данные Search Console за 12 месяцев, инвентаризация плагинов и медиа.
• Определитесь с моделью контента - Headless CMS для частых публикаций, MDX для статичного набора страниц.
• Постройте карту редиректов до начала разработки, а не после запуска.
• Держите старый и новый сайт доступными параллельно на staging минимум до полной сверки технических сигналов.

Если вы сейчас оцениваете переезд с WordPress на Next.js и хотите избежать типовых потерь трафика - опишите команде Exceltic.dev объём сайта и список ключевой функциональности на плагинах. Разберём карту рисков миграции и дадим честную оценку сроков.