Что на самом деле меняется при переносе сайта
Для бизнеса миграция может выглядеть как замена CMS, хостинга или дизайна. Для Google это набор изменений отдельных URL: старый документ исчезает, появляется новый адрес, меняются внутренние ссылки, canonical, языковые версии, контент и скорость ответа сервера.
Если поисковая система не видит однозначного соответствия, накопленные сигналы не исчезают мгновенно, но могут дольше переобрабатываться или распределиться между неправильными страницами. Поэтому перенос проектируется как работа с картой URL и данными, а не как последний технический пункт перед релизом.
Инвентаризация до первого изменения
Сначала нужен снимок текущего состояния. Без него после запуска невозможно отличить нормальные колебания от реальной потери страниц, запросов или конверсий.
Полный список URL
Страницы из sitemap, внутреннего обхода, Search Console, аналитики, рекламных кабинетов и внешних ссылок.
Ценность каждой страницы
Показы, клики, обращения, выручка, внешние ссылки и роль в пользовательском пути.
Технические сигналы
HTTP-статус, canonical, robots, hreflang, schema, метаданные и текущая индексируемость.
Контент и файлы
Тексты, изображения, документы, товары и данные, которые нельзя потерять при смене системы.
Контрольная выборка
Набор важных страниц разных типов для проверки до и сразу после запуска.
Карта URL — центральный документ миграции
Для каждого старого адреса заранее определяется результат. Если содержание сохраняется, он ведет на максимально близкую новую страницу. Если несколько материалов действительно объединены, допускается один релевантный итоговый URL. Если замены нет, сервер должен честно вернуть 404 или 410.
Нельзя отправлять сотни удаленных товаров и статей на главную страницу только ради отсутствия ошибок. Такой редирект не отвечает исходному намерению пользователя и может восприниматься как soft 404.
Один старый URL → один новый URL
Базовый сценарий для сохраненной страницы или товара.
Несколько URL → одна страница
Допустимо только при реальном объединении одинакового или близкого содержания.
URL без замены
Возвращает 404/410 и удаляется из новых внутренних ссылок и sitemap.
Неизменный URL
Остается 200, получает self-canonical и актуальный контент без лишнего редиректа.
Как должны работать постоянные редиректы
Для постоянной смены адреса Google рекомендует серверный 301 или 308. Редирект должен срабатывать за один переход: старый URL сразу ведет на окончательный новый, без цепочки через промежуточные версии, HTTP или другой вариант домена.
Старые редиректы стоит сохранять не менее года, а для пользователей и внешних ссылок часто разумно оставлять дольше. Одновременно собственные внутренние ссылки, профили, рекламные кампании и важные внешние упоминания нужно обновлять на конечные адреса.
Canonical, hreflang, sitemap и внутренние ссылки
Редирект — только один сигнал. На новых страницах canonical должен указывать на новый индексируемый URL, RU/UA-версии — взаимно ссылаться через hreflang, а sitemap — содержать только конечные canonical-страницы со статусом 200.
Навигация, хлебные крошки, карточки, статьи и футер также должны вести сразу на новые URL. Если сайт продолжает массово ссылаться на старые адреса, обход становится медленнее, а архитектура — противоречивой.
Canonical
Self-referencing на конечной странице без старого домена или тестового окружения.
Hreflang
Взаимные языковые пары с корректными URL и языковыми кодами.
Sitemap
Только индексируемые страницы 200; старые и редиректные адреса исключены.
Robots и noindex
Защита staging не должна случайно перейти в production.
Schema и метаданные
Название, изображение, автор, товар или услуга соответствуют видимому содержанию новой страницы.
Почему перенос и полный редизайн лучше разделять
Google рекомендует по возможности менять по одному крупному фактору за раз. Если одновременно сменить домен, CMS, URL, структуру и смысл страниц, при просадке будет трудно определить причину.
Практичный порядок зависит от проекта, но принцип один: сначала сделать сопоставление проверяемым. Например, сохранить структуру при смене домена, дождаться обработки основных URL, а затем развивать дизайн и контент. Для большого сайта можно начать с стабильного раздела и проверить процесс на ограниченной группе страниц.
Что дополнительно проверить у интернет-магазина
В e-commerce риск выше из-за количества товаров, категорий, фильтров и связей с внешними системами. Здесь недостаточно проверить главную и несколько карточек.
Товары и варианты
Стабильные идентификаторы, URL вариантов, остатки, цены, изображения и структурированные данные Product.
Категории и фильтры
Полезные посадочные сохраняются, а бесконечные комбинации параметров не создают дубли.
Удаленные товары
Выбирается релевантная замена, сохранение информационной страницы или корректный 404/410 — без массового редиректа на категорию.
Фиды и реклама
Merchant Center, товарные фиды, рекламные URL и UTM-шаблоны обновлены вместе с сайтом.
Заказ и интеграции
Корзина, оплата, доставка, CRM, уведомления и аналитика проверены сквозным тестовым заказом.
Запуск и контроль после миграции
Перед переключением новая версия проходит технический обход, а контрольные страницы сравниваются со старой системой. После запуска проверяются статусы старых URL, canonical, robots, языковые пары, sitemap и реальные пользовательские сценарии.
В Search Console отслеживаются индексирование новых страниц, ошибки, показы, клики и запросы. В собственной аналитике — посадочные страницы, обращения и заказы. Временные колебания возможны, пока Google повторно обходит URL, поэтому оценивать нужно не один день, а динамику по типам страниц.
Первые часы
Критические URL, формы, заказ, оплата, редиректы и отсутствие production-noindex.
Первые дни
Ошибки обхода, серверные ответы, логи, sitemap и сохранение конверсий.
Первые недели
Индексация, запросы, CTR, внешние ссылки и страницы, которые не переносят сигналы ожидаемым образом.
Когда перенос стоит отдать исполнителю
Помощь особенно полезна, если сайт уже получает органический трафик, содержит сотни URL, работает на двух языках, меняет домен или платформу и связан с CRM, оплатой, доставкой или рекламными фидами.
Хороший результат миграции — не обещание «позиции точно не изменятся». Это проверяемая карта соответствий, технически корректный запуск, сохраненные данные и мониторинг, который позволяет быстро увидеть и исправить проблему.