Переезд сайта без потери SEO: чек-лист миграции

Определите тип и границы переезда

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

Если возможно, разделите независимые изменения. Google рекомендует менять по одной значимой вещи за этап: например, сначала домен, затем CMS или дизайн. Это упрощает диагностику. Когда бизнес требует единого запуска, документируйте компоненты отдельно и назначьте владельца каждой группы риска.

Снимите исходную точку

До разработки соберите список всех известных URL: sitemap, внутренний краул, аналитика, Search Console, Яндекс Вебмастер, обратные ссылки и серверные логи. Источники не совпадут. Именно объединение помогает найти старые страницы, которые уже исчезли из навигации, но продолжают получать трафик или ссылки.

Для каждого URL сохраните код ответа, canonical, indexability, Title, H1, описание, входящие внутренние ссылки, органические показы и клики, конверсии и внешние ссылки. Отметьте критичные страницы: главная, направления с доходом, сильные статьи, документы с обратными ссылками и технические файлы.

Сделайте скриншоты или выгрузки важных шаблонов и зафиксируйте дату. После релиза без исходной точки сложно доказать, что именно потерялось: текст, canonical, схема, форма или источник данных. Базовый пошаговый SEO-аудит даёт структуру такой проверки.

Составьте карту URL

Каждый ценный старый URL получает наиболее близкий новый эквивалент. Не направляйте все удалённые страницы на главную: это не сохраняет намерение пользователя и создаёт слабое соответствие. Если точной замены нет, выберите близкий раздел только при реальной полезности; окончательно удалённый материал должен возвращать 404 или 410.

Минимальные колонки карты: старый URL, новый URL, тип страницы, текущий код, целевой код, причина решения, трафик, внешние ссылки, владелец и статус теста. Карта должна проходить автоматические проверки: уникальность старых URL, допустимость целей, отсутствие циклов, цепочек и переходов на 4xx/5xx.

На новом сайте сразу используйте конечные URL во внутренних ссылках. Редирект нужен для старых адресов и внешних переходов, а не как постоянная часть новой навигации. Обновите canonical, hreflang при наличии языковых версий, структурированные данные и ссылки на изображения.

Проверьте новый сайт до запуска

Тестовый стенд закрывают от случайного индексирования, но перед production-релизом нужно убрать временные ограничения. Составьте отдельный пункт приёмки для robots.txt, noindex и авторизации. Одна забытая строка может закрыть весь новый сайт.

1. Пройдите новый сайт краулером со стартовых страниц и по списку будущих URL.
2. Проверьте 200 на целевых страницах, 404 на несуществующих и отсутствие неожиданных 5xx.
3. Сравните Title, H1, описания, основной контент, изображения и alt.
4. Проверьте self-canonical и отсутствие ссылок на тестовый домен.
5. Проверьте обычные HTML-ссылки, меню, хлебные крошки и пагинацию.
6. Валидируйте JSON-LD и фактическое соответствие разметки странице.
7. Проверьте формы, цели, согласие на аналитику и ключевые пользовательские сценарии.
8. Протестируйте мобильную версию, скорость и доступность основных шаблонов.

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

Чек-лист дня запуска

1. Заморозьте контентные изменения на короткое окно, чтобы карта URL не устарела во время переключения.
2. Сделайте резервную копию конфигурации, файлов и базы в пределах ответственности команды.
3. Включите новый сайт и проверьте главную, robots.txt, sitemap и контрольные страницы.
4. Активируйте 301 со старых URL на конечные новые адреса.
5. Проверьте выборку карты из разных типов и уровней глубины.
6. Запустите быстрый краул нового домена и старого списка URL.
7. Отправьте sitemap в поисковые панели после подтверждения его доступности.
8. Проверьте аналитику и реальные формы без записи тестовых данных в рабочую статистику, если это можно отделить.

Для смены домена подтвердите права на старую и новую версии в поисковых системах и используйте предусмотренные ими инструменты переезда, когда они применимы. Сохраняйте доступ к старой инфраструктуре и журналам: обработка происходит по URL и не завершается мгновенно.

Контроль после запуска

Первые часы отвечают на вопрос «работает ли сайт», следующие дни и недели — «как поисковые системы обрабатывают изменение». Следите за 5xx, 404, циклами, временем ответа, доступностью robots.txt и sitemap. Каждый день проверяйте критичные URL и формы, затем уменьшайте частоту по мере стабилизации.

В поисковых данных отслеживайте обход, индексирование, показы, клики, выбранные canonical и смену фактических URL. В аналитике сравнивайте органические посадочные и конверсии с сопоставимым периодом, учитывая сезонность. Значительный переезд может вызывать временные колебания: важна не нулевая волатильность, а отсутствие технической причины, которая её усиливает.

Храните реестр инцидентов: время, симптом, затронутые URL, причина, исправление и результат повторной проверки. Это не бюрократия, а защита от повторов. Настройте мониторинг контрольной группы страниц, а позиции снимайте в одинаковых условиях.

Критерии отката и исправления вперёд

Не каждое падение требует отката. Если новая система отвечает стабильно, карта корректна, а поиску нужно время на обработку, возврат может создать второй переезд и усилить неопределённость. Исправляйте вперёд локальные проблемы: пропавший canonical, сломанный шаблон, неверный редирект.

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

Частые ошибки

• Одновременно менять домен, CMS, дизайн, структуру и контент без раздельного контроля.
• Строить карту URL только по текущему меню.
• Редиректить все старые страницы на главную.
• Оставлять noindex, пароль или Disallow: / с тестового стенда.
• Создавать цепочки и циклы редиректов.
• Оставлять старые URL в новой внутренней навигации.
• Публиковать sitemap до проверки кодов, canonical и доступности.
• Удалять редиректы вскоре после переезда.
• Не проверять аналитику и формы в день запуска.
• Считать миграцию завершённой сразу после переключения DNS.