301-редирект сообщает браузеру и поисковому роботу, что страница навсегда переехала на другой адрес. На VPS его настраивают в конфигурации Nginx или Apache, а затем проверяют ответы сервера, цепочки перенаправлений и индексацию. В статье разобран практический план для сайта бизнеса в Беларуси: от подготовки карты старых URL до тестирования перехода на новый домен и контроля ошибок после запуска.
Когда нужен 301-редирект при переезде сайта?
301 применяют, когда старый адрес больше не должен использоваться. Например, компания переносит сайт с одного домена на другой, меняет структуру URL, объединяет две одинаковые страницы или переводит проект с HTTP на HTTPS. Для поисковой системы такой ответ означает окончательный переезд страницы, поэтому новый URL получает сигналы старого адреса. Это помогает сохранить накопленную видимость, если страницы действительно соответствуют друг другу.
Редирект нужно настраивать адресно. Старая страница услуги должна вести на новую страницу той же услуги, а карточка товара — на соответствующую карточку или близкий раздел каталога. Массовая переадресация всех URL на главную страницу ухудшает навигацию и не объясняет поисковику, куда переехал конкретный материал.
Техническая причина переезда тоже имеет значение. Если сайт переходит на HTTPS, нужно перенаправить каждый HTTP-адрес на его HTTPS-версию. Одновременно выбирают одну основную форму домена: с www или без www. Иначе один и тот же сайт может открываться по нескольким адресам, создавая дубли.
Что подготовить до настройки редиректов?
Сначала составьте таблицу соответствий. В левом столбце укажите старый URL, в правом — новый. В отдельной колонке удобно отметить тип страницы: главная, услуга, статья, категория или товар. Такая карта нужна разработчику и помогает не потерять важные адреса во время переезда.
| Старый адрес | Новый адрес | Что проверить |
|---|---|---|
| http://домен/услуга | https://домен/услуга | Открывается один финальный URL |
| старый-домен/каталог | новый-домен/каталог | Содержание раздела сохранилось |
| старый-домен/старая-статья | новый-домен/новая-статья | Тема материалов совпадает |
Перед изменением конфигурации сохраните копию файлов сайта и текущих настроек веб-сервера. Для VPS также нужен рабочий бэкап базы данных, файлов и конфигураций. Практический разбор резервного копирования есть в материале как настроить резервное копирование на VPS.
Проверьте DNS нового домена, сертификат и доступ к серверу. Если домен уже указывает на VPS, но сертификат выписан только для одного варианта имени, часть запросов завершится предупреждением браузера. Для HTTPS полезно заранее проверить автоматическое обновление сертификата: настройка бесплатного SSL на VPS помогает избежать внезапного окончания срока действия.
Как настроить 301 в Nginx?
В Nginx постоянное перенаправление задают директивой return 301. При переезде всего домена на новый адрес базовая схема выглядит так:
server {
listen 80;
server_name old.example.by www.old.example.by;
return 301 https://new.example.by$request_uri;
}Переменная $request_uri сохраняет путь и параметры запроса. Поэтому адрес /catalog/item перейдёт на такой же путь нового домена. Если структура сайта изменилась, одной общей строки недостаточно: для отдельных разделов задают специальные правила.
server {
listen 80;
server_name old.example.by;
location = /old-service {
return 301 https://new.example.by/services/service;
}
location / {
return 301 https://new.example.by$request_uri;
}
}Более точное правило ставят выше общего сценария. После редактирования конфигурации сначала проверьте синтаксис командой nginx -t. Если проверка прошла, примените настройки через перезагрузку Nginx. Перезапуск без проверки может временно остановить обработку запросов из-за одной лишней скобки или опечатки.
Для перенаправления с www на вариант без www или обратно создайте отдельный серверный блок. Не смешивайте несколько правил для одного и того же адреса: сначала браузер должен попасть на одну каноническую версию, затем сразу получить конечную страницу.
Как настроить 301 в Apache?
В Apache правила часто размещают в файле .htaccess, если для каталога разрешено его использование. Для переезда всего домена пример выглядит так:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old.example.by$ [NC]
RewriteRule ^(.*)$ https://new.example.by/$1 [R=301,L]Флаг R=301 задаёт постоянный редирект, а L останавливает обработку правил после срабатывания. Для переезда конкретной страницы используют отдельную строку:
Redirect 301 /old-service https://new.example.by/services/serviceПри работе с Apache проверьте, включён ли модуль переписывания URL, а также разрешены ли директивы из .htaccess. Если файл игнорируется, правило выглядит правильным, но сервер продолжает отдавать старую страницу или ответ 404.
Конфигурация зависит от схемы размещения. На одном VPS Apache может работать напрямую, а Nginx принимать внешние запросы и передавать их Apache. В таком варианте редирект нужно поставить на том уровне, где первым приходит запрос. Иначе правило в Apache не сработает для трафика, который Nginx уже обработал.
Как проверить редирект после изменения конфигурации?
Проверяйте не только главную страницу. Возьмите из карты URL старые адреса разных типов: страницу услуги, вложенную статью, файл изображения и адрес с параметрами. Каждый старый URL должен вернуть HTTP 301 и привести пользователя на один конечный адрес.
| Проверка | Ожидаемый результат |
|---|---|
| Старый URL | Ответ 301 |
| Новый URL | Ответ 200 и нужное содержимое |
| Цепочка из нескольких переадресаций | Один переход до финального адреса |
| Несуществующая страница | Корректный 404 или заранее выбранный релевантный URL |
| HTTP и HTTPS | Одна основная HTTPS-версия |
Проверить заголовки ответа можно через инструменты разработчика браузера или команду curl -I. В результате должны быть видны код 301 и заголовок Location с новым адресом. Если сначала приходит 302, затем 301, а потом ещё один 301, цепочку нужно сократить до одного перехода.
После запуска обновите внутренние ссылки, карту сайта и канонические адреса страниц. Внутренняя ссылка сразу на новый URL уменьшает лишние обращения к серверу. Старый домен при этом не отключают сразу: он нужен для обработки прежних ссылок, закладок и переходов из поисковой выдачи.
Серверная настройка также влияет на результат. Проверьте журнал Nginx или Apache, нагрузку VPS и ошибки 4xx/5xx. Если после переезда выросло число обращений к старым адресам, это повод дополнить карту перенаправлений, а не перенаправлять весь трафик на главную. Для регулярного контроля состояния сервера пригодится мониторинг VPS для малого бизнеса.
Какие ошибки приводят к потере трафика?
- Использование 302 вместо 301 при окончательном переезде. Временный ответ сообщает другой сценарий и не подходит для постоянной смены адреса.
- Цепочка редиректов: старый URL ведёт на промежуточный адрес, а затем ещё на два. Каждый лишний переход увеличивает время загрузки и усложняет обход сайта.
- Переадресация всех страниц на главную. Посетитель теряет нужный материал, а поисковик не видит точного соответствия старого и нового URL.
- Потеря пути и параметров запроса. Если правило ведёт только на новый домен, ссылки на вложенные страницы начинают открывать неправильный раздел.
- Перенаправление уже нового URL на него самого. Такая петля вызывает ошибку «слишком много перенаправлений».
- Изменение правил без резервной копии конфигурации. При ошибке восстановление займёт больше времени, особенно если VPS обслуживает почту и несколько сайтов.
Перед публикацией правил сохраните карту URL, конфигурацию веб-сервера и резервную копию сайта. Затем настройте 301 на уровне Nginx или Apache, проверьте выборочные адреса через заголовки HTTP и просмотрите журналы VPS. Если домен, структура страниц и сервер меняются одновременно, разделите работы на этапы: так проще понять, какое именно изменение вызвало ошибку.
