-
Реестр
Старые URL и их назначение
-
Карта
Подходящие новые страницы
-
Запуск
Редиректы и интеграции
-
Контроль
Обход, переходы и обращения
При переезде на другой домен сохраняют связь между старыми и новыми страницами: составляют карту URL, включают постоянные перенаправления, обновляют внутренние ссылки и сообщают поисковикам об изменении. Перенести файлы и переключить DNS недостаточно. Даже при той же CMS у сайта меняется публичный адрес, а вместе с ним ссылки, интеграции и условия обработки старого трафика.
Чем смена домена отличается от смены хостинга
При обычном переносе на другой сервер URL могут остаться прежними. Тогда основная работа связана с данными, доступностью, сертификатом и настройками окружения. При смене домена старые внешние ссылки продолжают вести на прежний адрес. Сервер должен объяснить, куда переместилась каждая важная страница, а новый сайт — последовательно использовать свои адреса.
Если меняется только инфраструктура, начните с инструкции по смене хостинга. Если одновременно меняются CMS, дизайн, структура и домен, разделите работы на проверяемые этапы. Это уменьшает число возможных причин ошибки. Полный редизайн во время доменного переезда не запрещён, но усложняет тестирование и оценку последствий.
Соберите исходный реестр
Объедините адреса из sitemap, обхода сайта, аналитики, поисковых кабинетов и внешних ссылок. В реестр включают страницы, изображения и документы, которые получают самостоятельные переходы. Sitemap не обязательно содержит старые адреса с трафиком. Если взять только его, часть посетителей после запуска попадёт на ошибки, хотя основные разделы будут работать.
Для каждого старого URL укажите новое назначение и причину решения. Страница переносится без изменений, объединяется с другой, заменяется подходящим материалом или окончательно удаляется. Решение о перенаправлении принимают по содержанию и задаче посетителя. Не направляйте все удалённые товары на главную ради отсутствия 404 в отчёте.
| Старый адрес | Новый адрес | Проверка |
|---|---|---|
| /catalog/model-a/ | /equipment/model-a/ | Та же модель и комплектность |
| /price.pdf | /files/price.pdf | Актуальный файл и доступность |
| /old-event/ | Нет замены | Осознанное удаление, ответ 404 или 410 |
Это учебные строки, не готовое правило для чужого сайта. Реальная карта учитывает параметры, языковые версии, завершающие слэши и исторические пути. Если адреса можно преобразовать одним правилом, всё равно сохраните контрольные исключения. Категория с изменённым названием или карточка, перемещённая вручную, часто не укладываются в общую формулу.
Подготовьте новый домен
Проверьте также срок регистрации обоих доменов и доступ к их управлению. Потеря старого домена прервёт перенаправления независимо от качества новой структуры.
Проверьте сертификат, доступность нужных хостов и ответы сервера. Для главной, категории, карточки и статьи задайте ожидаемые HTTP-статусы. Убедитесь, что noindex тестового окружения не попал в рабочий ответ. Проверьте канонические адреса, sitemap, hreflang и товарные фиды. Во всех этих местах должен использоваться согласованный новый домен.
Отдельный список нужен для интеграций: формы, платежи, CRM, вебхуки, почтовые шаблоны и внешняя авторизация. Новый домен может отсутствовать в списке разрешённых адресов сервиса. Тогда страница откроется, но подтверждение оплаты или отправка заявки сломается. Тестовый заказ и доставка обращения входят в приёмку переезда наравне с поисковыми настройками.
Запустите перенаправления без цепочек
Старый URL должен вести сразу на окончательный новый. Проверьте варианты http, https, www и адрес без www. Если сначала исправляется протокол, затем хост, а потом путь, получится несколько переходов. Настройка на прокси и в приложении должна быть согласованной: исправление только одного слоя не устраняет всю цепочку.
Используйте массовую проверку редиректов: в каждой строке старый адрес и ожидаемый новый. Результат покажет фактическую цель и промежуточные ответы. Для большого реестра нужна отдельная пакетная проверка; бесплатный инструмент предназначен для контрольных групп, а не обхода всего каталога за один запрос.
Перенаправление не заменяет обновление внутренних ссылок. Меню, хлебные крошки, рекомендации и ссылки в статьях должны вести напрямую на новые URL. После запуска проверьте также ссылки в письмах, рекламе и профилях компании. Для значимых внешних площадок можно запросить обновление адреса, сохраняя редиректы для остальных переходов.
Сообщите поисковикам и наблюдайте
Подтвердите права на старый и новый сайты в кабинетах. Используйте предусмотренную процедуру переезда там, где она применима к вашему случаю, и передайте новую sitemap. Это дополняет рабочие перенаправления, а не заменяет их. Не удаляйте старую инфраструктуру сразу после отправки уведомления: по старым ссылкам продолжат приходить люди и роботы.
Сравнивайте трафик двух доменов совместно. Во время обработки один может терять показы, пока другой их получает. Отдельно смотрите важные страницы и типы запросов, а не только общую посещаемость. Сезонность, отключённая реклама и изменения ассортимента способны повлиять на цифры независимо от переезда. Сохранённая исходная база помогает отделить эти причины.
План первых проверок
- Сразу после запуска: доступность, сертификат, редиректы, формы и оплата.
- После обновления кешей: canonical, sitemap, ссылки и фиды.
- При первых новых обходах: ошибки URL, выбранные канонические страницы, доступ роботов.
- В следующих отчётах: переходы и обращения по группе важных посадочных.
Назначьте ответственного за исправления и согласуйте условия отката. Откат должен учитывать новые заказы и обращения, появившиеся после запуска: восстановление старой копии базы может их потерять. Переключение домена назад тоже требует согласованной схемы адресов. Поэтому аварийный план готовят до публикации, а не после обнаружения первой ошибки.
Переезд нельзя принять только по скриншоту главной. Итоговый документ должен содержать карту URL, результаты выборки, список обновлённых интеграций и оставшиеся исключения. Если часть старых страниц удалена намеренно, это фиксируют отдельно. Для сложного каталога такую работу разумно начать с аудита структуры и технических ограничений, чтобы не обнаружить несовместимые правила уже на новом домене.
