Нужно перенести старый SPA на SSR без потери URL: план миграции без просадки

Если нужно перенести старый SPA на SSR без потери URL, нельзя начинать с переписывания компонентов. Сначала нужна карта маршрутов, SEO-страниц, параметров, редиректов и данных, которые сейчас видят пользователи и поисковые системы.

Главное правило миграции: старые важные URL должны либо открываться с тем же содержанием, либо отдавать корректный 301 на новый адрес. SSR должен улучшить индексацию, а не создать новые дубли и 404.

Что проверить в первую очередь

• Соберите список всех индексируемых URL из sitemap, логов, Метрики и Search Console.
• Разделите страницы на публичные SEO-страницы, кабинет, фильтры и технические маршруты.
• Зафиксируйте текущие title, description, h1, canonical и структуру контента.
• Проверьте, какие данные нужны для серверного рендера каждой страницы.

Основные причины

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

• SPA-роутинг и серверный роутинг расходятся по правилам обработки URL.
• Фильтры и параметры создают дубли страниц без canonical.
• SSR-страница отдает контент только после клиентского запроса.
• Старые URL не включены в rewrite или redirect-карту.

Пошаговая диагностика

• Проверьте текущие URL через curl: какой HTML видит бот без JS.
• Сравните список URL из логов с роутами нового приложения.
• Найдите страницы с поисковым трафиком и проверьте их будущий HTML.
• Проверьте обработку 404, 301, trailing slash и регистра символов.
• Проверьте гидрацию: нет ли расхождения server/client HTML.

Как исправить

Исправление лучше делать небольшими шагами. Сначала зафиксируйте текущее поведение, затем внесите одну правку, проверьте контрольный сценарий и только после этого переходите к следующему месту. Так проще понять, какая именно правка решила проблему.

• Сделайте таблицу соответствия старых и новых URL.
• Настройте SSR-роуты для всех важных публичных страниц.
• Сохраните SEO-теги и контентную структуру там, где URL остается прежним.
• Добавьте 301 только там, где URL действительно меняется.
• Обновите sitemap и robots после тестовой проверки.

Безопасный план решения

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

Как проверить результат

• Старые важные URL открываются с 200 или корректным 301.
• HTML содержит title, h1 и основной контент до выполнения JS.
• Нет массовых 404, цепочек редиректов и дублей canonical.
• Метрика и логи показывают стабильную отдачу страниц после релиза.

Чего не стоит делать

• Не отключайте проверки, права, платежные статусы или защиту только ради быстрого исчезновения ошибки.
• Не правьте рабочую базу массовым запросом без выборки, бэкапа и понимания последствий.
• Не ориентируйтесь только на один успешный тест: проверьте повторный запуск, отмену, ошибку и нестандартные данные.
• Не оставляйте временные ключи, токены, debug-режим и лишний вывод в публичном доступе.

Как не допустить повторения

• Перед релизом прогоняйте список URL автоматической проверкой статусов.
• Не меняйте URL-структуру без необходимости и карты редиректов.
• Разделяйте клиентские страницы кабинета и публичные SEO-страницы.
• Сравнивайте HTML старой и новой страницы перед выкладкой.

Что подготовить перед исправлением

• Ссылку на проблемную страницу, кабинет, заказ, интеграцию или API-метод.
• Точное время ошибки и пример пользователя, товара, платежа или запроса.
• Скриншот, текст ошибки, лог веб-сервера, приложения или webhook-события.
• Краткое описание ожидаемого поведения: что должно было произойти вместо ошибки.

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

SSR всегда улучшает SEO?

Нет. SSR помогает, если сервер реально отдает контент и правильные мета-теги. Плохая миграция может дать больше 404 и дублей.

Можно ли оставить старые URL?

Да, и часто это лучший вариант. Если структура уже приносит трафик, менять ее стоит только при понятной причине.

Когда стоит обратиться за помощью

Для миграции нужны текущий список URL, доступ к проекту, данные аналитики и понимание, какие страницы критичны для поиска.

Итог

Миграция SPA на SSR должна начинаться с карты URL и проверки HTML, а не только с выбора фреймворка. Я могу подготовить план, роутинг, редиректы и проверку SEO-страниц перед запуском.