Миграция SEO при переходе SPA на SSR и обратно: подробный чек‑лист — новый поисковый интент

Цель проверки: что мы хотим защитить при миграции

Главная цель аудита при миграции между SPA и SSR — минимизировать риск потери видимости в поиске и сохранить текущие позиции страниц. Это включает проверку индексации, отображения контента поисковым ботам, корректности редиректов и сохранение URL‑структуры и семантики.

Второстепенные, но важные цели — обеспечить согласованную работу метаданных, структурированных данных и каноникализации, а также не допустить ухудшения скорости и UX на критичных страницах. Отдельно проверяем поведение при отказе JavaScript, кеширование и работу сервисов, влияющих на ранжирование.

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

Зоны аудита: где концентрировать проверки

Аудит делится на зоны по функционалу и влиянию на индексацию: рендеринг (как бот видит страницу), доступность URL (статусы, редиректы), метаданные (title, description, OG), структурированные данные, карта сайта и robots.txt, внутренняя перелинковка и каноникализация, производительность и сервис‑воркеры.

Каждая зона требует своих инструментов и критериев: рендеринг проверяем эмуляцией ботов и серверным рендером, доступность — логами сервера и ответами HTTP, структурированные данные — валидатором schema.org, скорость — Lighthouse и реальными метриками пользователей. Игнорирование любой зоны повышает риск потери поискового трафика.

Особое внимание уделяем нескольким критическим точкам: динамические загрузки контента (lazy loading), клиентские редиректы, различия в контенте при SSR и при рендеринге на клиенте, а также взаимодействие с кеширующими уровнями (CDN, reverse proxy).

• Рендеринг и видимость контента
• HTTP‑ответы и редиректы
• Метаданные и Open Graph
• Структурированные данные и микроразметка
• Карта сайта, robots.txt, hreflang
• Скорость, Core Web Vitals
• Кэширование и заголовки
• Логи сервера и ошибки индексации

Критерии и конкретные проверки по каждой зоне

Рендеринг: откройте страницу в режиме 'Fetch as Google' и в Chrome DevTools без JS. На SSR ключевой контент должен присутствовать в HTML‑ответе. Для SPA проверяйте предрендер или динамическую отправку контента через SSR/пререндер. Критерий успеха — бот видит основной контент и заголовки в исходном HTML или при рендеринге сервером.

HTTP и редиректы: все старые URL, которые останутся в индексе, должны корректно редиректиться 301 на новые. Проверьте цепочки редиректов: длина не более одной‑двух ступеней. Ответы 200 для рабочих страниц, 404/410 для намеренно удалённых. Критерий — отсутствие «мягких 404» и циклических редиректов.

Метаданные и микроразметка: title и meta description должны рендериться корректно при SSR и/или при первичном ответе. Структурированные данные должны быть валидны и соответствовать видимому контенту. Критично: отсутствие или расхождение schema.org может привести к потере сниппета.

• Проверить исходный HTML/рендер на наличие основного контента
• Проверить все важные URL на статус‑коды и корректные 301
• Проверить метаданные в исходном ответе сервера
• Провалидировать структурированные данные

Инструменты и команды: набор тестов, которые нужно запустить

Набор инструментов должен включать: Chrome DevTools (рекомендуется — режим без JS и проверка рендеринга), curl/wget для просмотра исходного HTML, Lighthouse для скорости и CWV, Google Search Console для ошибок индексации и coverage, анализ серверных логов для понимания поведения бота.

Для динамических проверок пригодятся headless‑браузеры (Puppeteer, Playwright) чтобы автоматизировать рендеринг и сравнение DOM между SSR и клиентским рендером. Screaming Frog или аналог помогут просканировать сайт и выявить проблемы с метаданными, статусами и ссылочной структурой.

Используйте инструменты проверки микроразметки (Rich Results Test), валидаторы sitemap и robots.txt. Для проверки кеширования и заголовков — curl -I и мониторинг CDN/прокси‑заголовков. Важно фиксировать все проверки в чек‑листе и сохранять результаты для отката и анализа.

• Chrome DevTools (Disable JS, View Source, Lighthouse)
• curl -I / curl -L для редиректов и заголовков
• Google Search Console: Coverage, URL inspection
• Puppeteer/Playwright для headless рендеринга
• Screaming Frog / аналог для массовой проверки
• Rich Results Test и валидатор sitemap

Критичные ошибки, которые чаще всего приводят к падению трафика

Отсутствие контента в исходном HTML при SSR‑имитации: если бот получает пустой или неполный HTML и не выполняет JS, страницы не индексируются или индексация проходит неправильно. Особенно опасно для страниц с важной SEO‑структурой (категории, карточки товаров).

Неправильные редиректы и изменение URL‑структуры без 301: смена URL без корректных перенаправлений или с циклическими редиректами приводит к потерям трафика и «распылу» веса ссылок. Это классическая и наиболее критичная ошибка при миграции.

Различия в метаданных и разметке между SSR и клиентским рендером: если мета‑теги, canonical или структурированные данные отличаются в зависимости от рендеринга, поисковая система может индексировать не тот вариант, что влияет на сниппеты и релевантность.

• Пустой/неполный HTML для бота
• Неправильные или отсутствующие 301‑редиректы
• Несоответствие метаданных и canonical
• Кеширование старых ответов на CDN
• Дублирование контента из‑за неправильной маршрутизации

Приоритизация задач: как распределить усилия

Приоритизация должна опираться на два фактора: влияние на трафик (pages with organic value) и трудоёмкость исправления. Первые в очереди — критичные страницы с основным трафиком (страницы категорий, карточки, разделы бренда). Эти же страницы требуют проверки готовности SSR и корректности редиректов.

Исправления, требующие минимального времени, но дающие высокий эффект (quick wins) — корректировка заголовков/description в исходном HTML, исправление 301 для основных URL, отключение сервис‑воркера на время миграции, если он кэширует старый вариант. Больше ресурсоёмких задач — переработка архитектуры рендеринга, тестируем по этапам.

Распределите задачи по категориям: критичные — исправить до релиза; важные — исправить в первые 2–4 недели после релиза; мониторинг и оптимизации — пострелизный цикл. Для каждой задачи укажите критерий завершения и метрику — например, восстановление трафика или исчезновение ошибок в GSC.

• Критичные (до релиза): редиректы, исходный контент, метаданные
• Важные (первые недели): структурированные данные, sitemap, hreflang
• Нормализуемые (после запуска): оптимизация скорости, дополнительные тесты
• Мониторинг: логирование, GSC, аналитика

Пошаговый чек‑лист: до, во время и после миграции

До запуска (обязательные шаги): подготовьте карту редиректов 1:1, проверьте исходный HTML ключевых страниц, валидируйте метаданные и структурированные данные, приготовьте бэкап sitemap и robots.txt. Отключите или адаптируйте сервис‑воркер, чтобы он не кэшировал старые ответы при релизе.

Во время запуска: мониторьте серверные логи на 5xx и массовые 4xx, проверяйте работу 301 редиректов на выборке страниц, следите за Crawl budget и пиком запросов бота, фиксируйте изменения в GSC. Запускайте тестовый обход (screaming) и headless‑рендеринг для случайной выборки URL.

После запуска (первые 4–6 недель): ежедневный мониторинг ключевых страниц, сравнение показателей видимости и трафика, исправление обнаруженных «мягких» ошибок и обновление sitemap. Планируйте итерации по приоритетам: критические баги — незамедлительно, оптимизации — в спринтах.

• До релиза: карта редиректов, проверка исходного HTML, отключение SW
• Во время: логирование ошибок, тестовые обходы, мониторинг 301/200
• После: ежедневный мониторинг GSC, аналитики, корректировки

Контрольные метрики и что считать тревожным сигналом

Основные метрики для наблюдения: покрытие в Google Search Console (увеличение ошибок), изменение числа проиндексированных страниц, количество отображаемых в поиске URL по ключевым запросам, органический трафик на критичных страницах, CTR сниппетов и позиции по приоритетным ключевым фразам.

Тревожные сигналы: резкое падение проиндексированных страниц, рост 5xx и 4xx в логах, значительное снижение трафика на страницах с высоким весом, исчезновение структурированных сниппетов, неожиданные массовые редиректы. Такие сигналы требуют немедленной проверки и отката проблемных изменений.

Набор детальных событий для алертов: появление новых блокирующих ошибок в GSC, массовая потеря ссылочной массы из‑за неправильных 301, превышение целевых задержек сервера и ухудшение Core Web Vitals на страницах с большим трафиком. Настройте дашборды и оповещения по этим метрикам.

Технические рекомендации и типовые предотвращения проблем

Кэширование и заголовки: для SSR важно корректно выставлять Cache‑Control и Vary, чтобы бот и пользователи получали свежий HTML. Если используется CDN, убедитесь, что инвалидация работает для изменённых маршрутов и редиректов. На время миграции можно уменьшить TTL для HTML‑ответов.

Обработка User‑Agent и динамический рендеринг: избегайте сервера, который отдает разный контент в зависимости от User‑Agent без чёткой необходимости. Если используется динамический рендеринг для ботов, задокументируйте логику и убедитесь, что ответы идентичны видимому пользователю. Любая разница должна быть минимальна и объяснима.

Service Worker и клиентский роутинг: временно отключите или используйте режим обновления, чтобы не кэшировались старые файлы маршрутизации. Проверьте корректность canonical при клиентской навигации (history API), чтобы избежать создания дубликатов и неправильной каноникализации.

• Проверить Cache‑Control и TTL для HTML
• Документировать и тестировать динамический рендеринг
• Отключить/адаптировать Service Worker на время миграции
• Убедиться в корректной каноникализации при client‑routing

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