Как настроить редирект на другой домен

Код ответа сервера сообщает браузерам и поисковым системам, почему пользователь перенаправлен. Для переезда на постоянной основе выбирают 301. Он означает, что прежний адрес окончательно заменён новым. Поисковые системы постепенно воспринимают новый домен как основной, а пользователи при повторном посещении могут сразу попадать на актуальный адрес.

Код 302 применяют, когда перенос временный: например, во время технических работ, тестирования новой версии или проведения ограниченной по времени кампании. Поисковый робот обычно продолжает считать исходный адрес главным. Код 307 также обозначает временное перенаправление, но строже сохраняет метод запроса. Он полезен в отдельных технических сценариях, однако при обычном переносе сайта чаще достаточно 301.

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

Перед настройкой составьте таблицу соответствий между старыми и новыми страницами. В идеальном варианте каждая значимая страница ведёт на наиболее близкую по смыслу новую страницу. Главную страницу старого домена направляют на главную нового, карточки товаров — на соответствующие карточки, статьи — на их обновлённые версии.

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

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

Самый надёжный способ — задать правило в конфигурации веб-сервера. На серверах Apache правила обычно размещают в файле настроек сайта или в файле .htaccess, если хостинг разрешает его использование. На Nginx перенаправление добавляют в блок конфигурации виртуального хоста. В обоих случаях правило должно срабатывать для старого домена и возвращать код 301 вместе с новым адресом.

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

Во многих панелях хостинга есть пункт «Перенаправления». Он подходит для простых случаев, когда нужно отправить весь домен или один каталог на другой адрес. При работе через панель убедитесь, что выбран постоянный тип, включено сохранение пути при необходимости и не создано несколько пересекающихся правил. После сохранения очистите кеш сайта и кеш прокси-сервиса, если он используется.

Редирект должен быть установлен до загрузки движка сайта. Перенаправление на уровне сервера обычно быстрее и устойчивее, чем решение внутри CMS. Оно продолжит работать даже при ошибках базы данных, отключённых плагинах или проблемах с шаблоном.

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

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

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

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

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

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

Если меняется только часть проекта, ограничьте область действия перенаправления. Так вы избежите ситуации, когда служебные страницы, почта, личный кабинет или другой сайт на том же сервере неожиданно начинают открываться на новом домене. Любое изменение сначала полезно проверить в тестовой среде или в период низкой посещаемости.