Миграция с Bitrix и WordPress на современный стек — без потери SEO

§ 01Когда миграция оправдана, когда нет

Первое правило: не мигрируйте, потому что «Bitrix устарел» или «все переходят на Next.js». Миграция — это дорогой и рискованный процесс. Он оправдан, когда текущий стек реально мешает бизнесу, а не потому что на нём некрасиво писать код.

Мигрируем, если:

• Скорость загрузки тянет вниз SEO и конверсию. Core Web Vitals в красной зоне, LCP больше 4 секунд, и никакими оптимизациями плагинов это не чинится. У WordPress с 20 плагинами и сложной тенаш часто невозможно вытащить LCP ниже 3 секунд без радикальных изменений архитектуры.
• Каждая доработка стоит как новый сайт. Добавить новое поле в карточку товара — 150 тысяч. Изменить логику расчёта скидок — 300. Интегрировать новую платёжку — ещё 200. Все вокруг разработки ведут себя, как будто вы ограблены. Это признак того, что система так устроена, что любое изменение дорого по природе.
• Безопасность рушится. Регулярные уязвимости в плагинах WordPress (как правило, полностью автоматизированные боты сканируют интернет и используют всё подряд). Взлом или фишинг через дыры — реальный сценарий. Старые Bitrix-версии не получают обновлений и становятся дырами в периметре.
• Командная работа невозможна. Двое разработчиков не могут параллельно работать над сайтом без конфликтов. Нет нормального git-флоу, нет тестовой среды, деплои происходят по FTP через PuTTY. Это не просто неудобно — это замедляет разработку в разы.
• Ваши текущие разработчики уходят и их невозможно заменить. Битрикс-разработчики уже редкость (и дорогие), а самописные движки 10-летней давности поддерживает только тот, кто их писал.

Не мигрируем, если:

• Сайт работает, трафик идёт, конверсия в порядке, команда справляется. Перейти на новое ради нового — выкинуть деньги.
• Сайт временный или для одноразовой кампании. Смысла в миграции нет.
• Бизнес собирается закрыть направление в ближайший год.
• Стоимость миграции превышает годовые затраты на поддержку текущего решения в 3 раза и больше.

Спорные случаи

WordPress-блог, где за последние 2 года не было изменений — не мигрируем, контентная часть нормально живёт даже на WP. WordPress-магазин на WooCommerce с 10 тысячами товаров — мигрируем практически всегда, скорость и масштабируемость — основные причины. Bitrix в корпоративном сайте с редакторской работой — смотрим на объём контента и частоту правок.

Подробнее о том, как устроена разработка с нуля на современном стеке и диапазоны цен — в статье сколько стоит сделать сайт.

§ 02Аудит старого сайта: чек-лист из 20 пунктов

Перед любой миграцией нужен детальный аудит текущего состояния. Без него вы не знаете, что именно мигрируете, и всплывающие нюансы растянут проект в 2–3 раза.

Мой чек-лист, по которому прохожу каждый переезд:

1. Список всех публичных URL сайта (сбор через Screaming Frog, ahrefs или аналог).
2. Количество страниц по типам: товары, категории, посты блога, статические страницы.
3. Структура URL: с ID или ЧПУ, с slashes или без, с расширением или без.
4. Версия CMS и плагинов, список кастомизаций.
5. Используемые интеграции: 1С, МойСклад, CRM, платёжки, сервисы доставки.
6. Кастомные поля и их использование в шаблонах (ACF в WP, highload-блоки в Bitrix).
7. Текущий объём базы данных, скорость запросов.
8. Серверная конфигурация: хостинг, PHP-версия, лимиты.
9. Текущие Core Web Vitals (до).
10. Текущие позиции по 30–50 ключевым запросам.
11. Источники трафика (органика, прямые, реклама, соцсети) и их объём.
12. Перечень всех форм на сайте и куда они отправляются.
13. Настройки robots.txt, sitemap.xml, canonical.
14. Микроразметка Schema.org (что есть, что отсутствует).
15. Мультиязычность: как реализована, какие URL используются.
16. Пользовательский контент: комментарии, отзывы, заявки — где хранятся.
17. Изображения: сколько штук, средний размер, форматы (JPG/PNG/WebP).
18. Админка: сколько пользователей, какие роли, нестандартные настройки.
19. Резервные копии: есть ли, где хранятся, работают ли восстановления.
20. Список открытых вопросов: что разработчик делает «руками», что автоматизировано, какие есть костыли.

Результат аудита — документ на 10–20 страниц, который становится базой для плана миграции. Обычно аудит занимает 3–5 рабочих дней. Сложные системы (Bitrix-магазины на миллион позиций) — до двух недель.

§ 03301-редиректы без потери SEO

Самая критичная часть миграции. Потеря URL-структуры — это потеря годами накопленного ссылочного веса и позиций. При переезде большая часть URL должна остаться, а где неизбежно меняется — настраиваться 301-редирект со старого на новый.

Что нужно сохранить 1-в-1

Все URL, которые имеют внешние ссылки: с других сайтов, из соцсетей, из СМИ, из каталогов. Они приводят вам пользователей и передают авторитет. Проверьте через Ahrefs или Linkpad — у популярных страниц десятки входящих ссылок каждый.

Все URL в топ-100 Яндекса и Google по каким-либо запросам. У них уже есть ранжирующий вес, его нельзя терять.

Все URL, на которые ведут внутренние ссылки из вашего же контента. Если в блоге 50 статей ссылаются на /services/seo, перенос этого URL без редиректа сломает все внутренние ссылки.

Когда URL меняется — строгое правило

Каждый старый URL должен вести на семантически соответствующий новый URL через 301-редирект. Не на главную страницу (это потеря веса), не на 404 (это потеря трафика), а на конкретную релевантную страницу.

Пример: был /catalog/smartphone/iphone-12-pro-max-black/, стал /store/iphones/iphone-12-pro-max/. 301 редирект со старого на новый. Поисковик через 2–4 недели понимает, что это тот же ресурс, переклеивает вес, позиции сохраняются.

Массовая генерация редиректов

Для больших сайтов (тысячи URL) редиректы генерируются скриптом из данных аудита. В Nginx или Apache это list файл с правилами, в Next.js — запись в next.config.js или middleware.

После генерации обязательно проверьте минимум 50 случайных редиректов вручную. Ошибки в скрипте могут запустить «бесконечные» редиректы или редиректы в 404 — оба варианта катастрофа для SEO.

Что делать с полностью исчезающими URL

Если страница удалена и её содержимое никуда не переезжает — 410 Gone. Это правильный ответ, который говорит поисковику «страница удалена окончательно». 301 на главную в этом случае хуже — размывает её значение для алгоритмов.

Проверка после запуска

Google Search Console и Яндекс.Вебмастер через неделю-две после миграции покажемт ошибки краулинга. Ошибка-4xx — что-то не редиректится или редиректится неправильно. Ошибка-5xx — на новом сайте сломан ответ. Исправляется по мере появления.

Подробная проверка после миграции — отдельная тема, она пересекается с тематикой почему сайт не в топе Яндекса.

§ 04Полный переезд vs headless-архитектура

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

Полный переезд

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

Когда работает: сайт небольшой (до 50 страниц), старая CMS сильно ограничивает, команда готова переучиться на новую админку. Срок миграции — 3–6 недель для корпоративных сайтов, 6–12 для магазинов.

Риск: короткий период, когда что-то может сломаться или пропустить при переносе. Митигируется подробным планом и поэтапным тестированием.

Headless-миграция

Старая CMS остаётся как хранилище контента и админка для редакторов. Перед ней ставится новый фронтенд (Next.js, Astro, SvelteKit), который берёт данные через REST или GraphQL API существующей CMS и отдаёт пользователям красивый быстрый интерфейс.

Когда работает: у вас большой объём контента и обученные редакторы, которым не хочется переучиваться. Есть нормальный REST API у CMS (Bitrix умеет, WordPress через WP REST API). Важно быстро улучшить скорость и UX, не переделывая backend.

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

Гибрид

Часть сайта (публичные разделы, блог, статьи) — headless через новый фронт. Часть (каталог, корзина, оплата) — полностью переписана на новом стеке. Старая админка для контент-редакторов, новая — для менеджеров магазина.

Когда работает: у вас магазин, где контент-часть (страницы компании, блог) и e-commerce-часть требуют разных решений. Контент оставляем на знаконаш CMS, коммерцию переписываем.

Выбор подхода — один из главных решений в миграционном проекте. Мы обычно обсуждаем это на первом созвоне и показываю, какой вариант подходит под объём и тип сайта. Все три подхода в деталях — на странице услуги по рефакторингу и миграции.

§ 05Риски простоя и как их свести к нулю

Даунтайм сайта — это прямые потери выручки для магазинов, потеря трафика для контентных проектов, потеря доверия для всех. Хорошая миграция должна проходить с нулевым или почти нулевым простоем.

Параллельный запуск

Новый сайт разрабатывается на поддомене вроде new.example.ru. Команда тестирует его месяц на реальных данных. Редакторы пробуют админку, менеджеры — заказы. За 1–2 недели до миграции вы переключаете 10% трафика через DNS round-robin или балансировщик на новый сайт, смотрите на ошибки. Если всё ок, повышаете до 50%, потом 100%. Старый сайт остаётся выключенным, но доступным для отката.

Этот подход называется blue-green deployment. Простой — несколько минут на переключении DNS. Откат — в любой момент.

Синхронизация данных

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

Решается через синхронизатор: скрипт, который смотрит новые записи в старой базе и повторяет их в новой. Или через короткий ночной простой (1–2 часа), когда сайт недоступен, копируется финальный срез базы, поднимается новая версия.

Мониторинг после переключения

Первые 24 часа после миграции — самые критичные. В это время сидим на мониторинге: логи ошибок, статус 4xx/5xx в Яндекс.Метрике, алерты из Sentry, отклик от клиентов в поддержку. Любая аномалия фиксится немедленно.

Частые проблемы первых суток: редиректы не сработали, кэш на CDN держит старое, email не отправляется (новые SMTP-настройки), платежи проваливаются (webhook на старый URL). Всё решаемое, но надо быть готовым.

План отката

Письменный план: при каких условиях откатываемся, кто принимает решение, как технически откат происходит. Решение принимается по метрикам, не по ощущениям. Если за первые 24 часа количество ошибок превышает порог, трафик падает больше чем на 30%, заказы проваливаются — откатываемся, разбираемся, мигрируем снова.

С нормальным blue-green деплоем откат занимает 5–10 минут. Это не аварийная операция, а плановый сценарий.

Выбор подрядчика для миграции — отдельная тема. Мало кто умеет делать 301-редиректы правильно, многие берутся и проваливают. Подробно про то, как проверять навыки подрядчика перед миграционным проектом, — в статье как выбрать разработчика. Плюс после миграции часто приходится дочищать SEO — об этом в почему сайт не в топе Яндекса.

Частые вопросы

То, что чаще всего спрашивают клиенты перед миграцией.