Чтобы настроить редирект 301, нужно определить старый и новый URL, добавить правило перенаправления на уровне веб-сервера или CMS, а затем проверить код ответа и адрес назначения. Сервер должен возвращать статус 301 Moved Permanently и сразу направлять пользователя на конечную доступную страницу.
В статье разберём, когда нужен постоянный редирект, как подготовить карту перенаправлений, какие правила использовать для Apache и Nginx, как работать с CMS и как проверить результат. Отдельно рассмотрим ошибки, из-за которых возникают циклы, цепочки редиректов и проблемы с индексацией.
Что такое 301 редирект и когда он нужен
301 редирект — это постоянное перенаправление с одного URL на другой. Получив такой ответ, браузер открывает новый адрес, а поисковая система понимает, что исходная страница окончательно перемещена.
Постоянное перенаправление помогает сохранить доступ к контенту после изменения URL и передать новому адресу накопленные сигналы старой страницы. Передача и обновление данных в поисковых системах происходят не моментально, поэтому после настройки возможен переходный период.
Редирект 301 обычно используют в следующих ситуациях:
- изменился адрес страницы или структура каталога;
- сайт переехал на другой домен;
- выполняется переход с HTTP на HTTPS;
- нужно выбрать единственный вариант домена — с www или без www;
- объединяются дублирующие или близкие по смыслу страницы;
- удалённый материал заменён полноценной актуальной страницей;
- исправляются URL после смены CMS.
Перенаправлять удалённую страницу на главную только ради сохранения трафика не следует. Если релевантной замены нет, корректнее вернуть код 404 или 410. Новый URL должен решать ту же задачу пользователя или содержать максимально близкий по смыслу материал.
Для временного переноса используют код 302 или 307. Например, временный редирект подходит для краткосрочного обслуживания страницы или тестирования маршрута. Код 301 выбирают, когда старый адрес больше не планируется возвращать.
Что подготовить перед настройкой
Одиночное перенаправление можно настроить сразу после проверки двух URL. При переносе раздела или всего сайта сначала нужна карта редиректов — таблица соответствий между исходными и конечными адресами.
| Старый URL | Новый URL | Причина | Статус проверки |
|---|---|---|---|
| /catalog/old-product/ | /catalog/new-product/ | Изменение адреса | Не проверен |
| /services/audit/ | /services/seo-audit/ | Новая структура | Не проверен |
Для каждого старого URL нужно подобрать один конечный адрес. Новый URL должен:
- открываться с кодом 200;
- не перенаправлять посетителя ещё раз;
- соответствовать содержанию исходной страницы;
- использовать итоговый протокол и вариант домена;
- не быть закрытым от индексации, если страница должна участвовать в поиске.
Перед изменением конфигурации сохраните резервную копию файла или настроек. Для большого списка сначала проверьте правила на тестовом окружении либо на ограниченной группе URL. Если постоянный редирект ошибочно попадёт в кеш браузера или промежуточной системы, исправление сложнее проверить.
Заранее определите единый формат адресов: HTTPS, основной домен, наличие или отсутствие завершающего слеша, регистр символов. Несогласованные правила могут перенаправлять запросы по кругу.
Где можно настроить постоянное перенаправление
Способ настройки зависит от веб-сервера, CMS, панели хостинга и архитектуры проекта. При наличии доступа к серверной конфигурации перенаправление лучше выполнять до генерации страницы: такой маршрут требует меньше лишней обработки.
| Способ | Когда подходит | Что учитывать |
|---|---|---|
| Apache и файл .htaccess | Сайт работает на Apache, разрешено переопределение настроек | Ошибка в синтаксисе может привести к недоступности сайта |
| Конфигурация Nginx | Есть доступ к конфигурационным файлам сервера | После изменения требуется проверка и перезагрузка конфигурации |
| CMS или модуль | Нет прямого доступа к веб-серверу либо нужен удобный интерфейс | Важно исключить конфликт с серверными правилами и кешированием |
| Панель хостинга | Хостинг предоставляет отдельный инструмент перенаправлений | Нужно проверить фактический код ответа, а не полагаться на название функции |
| Код приложения | Маршрутизация управляется самим приложением | Ответ должен отправляться до HTML и содержать корректный статус 301 |
JavaScript-переход и HTML-перенаправление через meta refresh не заменяют серверный 301 редирект. Они зависят от загрузки и выполнения страницы, могут ухудшать пользовательский опыт и неоднозначно обрабатываться поисковыми системами.
Как настроить редирект 301 пошагово
Общий порядок одинаков для любого стека: зафиксировать пару URL, выбрать уровень настройки, добавить правило, проверить конфигурацию и протестировать полный маршрут. Ниже приведены типовые варианты. Домены и пути в примерах нужно заменить на адреса проекта.
Настройка в Apache через .htaccess
Файл .htaccess обычно находится в корневой директории сайта. Перед редактированием скачайте его копию. Для работы правил перенаправления должен быть доступен модуль mod_rewrite, а сервер должен разрешать соответствующие директивы.
Редирект одной страницы:
RewriteEngine On
RewriteRule ^old-page/?$ https://example.ru/new-page/ [R=301,L]
В шаблоне RewriteRule внутри .htaccess путь указывают без начального слеша. Символ ? после слеша разрешает запрос как с завершающим слешем, так и без него. Флаг R=301 задаёт статус, L прекращает обработку следующих правил для совпавшего запроса.
Переход на HTTPS и единый домен без www можно задать так:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^example\.ru$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [R=301,L,NE]
Если сервер находится за CDN, балансировщиком или обратным прокси, условие HTTPS может определяться иначе. Неправильная проверка протокола способна создать бесконечный цикл, поэтому конфигурацию нужно согласовать со схемой инфраструктуры.
Правила для конкретных старых страниц размещайте с учётом общего перенаправления домена и протокола. Цель — направить запрос сразу на итоговый HTTPS-адрес, а не создавать переход вида HTTP → HTTPS → новый URL.
Настройка в Nginx
В Nginx правила задаются в конфигурации виртуального хоста. Для редиректа всего HTTP-трафика на HTTPS подходит отдельный блок server:
server {
listen 80;
server_name example.ru www.example.ru;
return 301 https://example.ru$request_uri;
}
Переменная $request_uri сохраняет путь и строку параметров исходного запроса. Для перенаправления одной страницы внутри блока HTTPS-сайта можно использовать точное совпадение:
location = /old-page/ {
return 301 https://example.ru/new-page/;
}
При переезде на другой домен старый виртуальный хост должен отвечать редиректом на новый:
server {
listen 80;
server_name old-example.ru www.old-example.ru;
return 301 https://new-example.ru$request_uri;
}
Для запросов к HTTPS-версии старого домена также нужен серверный блок и действующий сертификат. Иначе соединение завершится ошибкой раньше, чем пользователь получит перенаправление.
После редактирования Nginx сначала проверьте синтаксис конфигурации штатной командой сервера, а затем примените изменения. Перезапуск без предварительной проверки может сделать сайт недоступным.
Настройка через CMS или панель управления
В CMS перенаправления обычно создаются через встроенный менеджер URL, SEO-модуль или отдельное расширение. Общая последовательность выглядит так:
- Откройте раздел управления редиректами.
- Укажите старый путь без домена, если интерфейс ожидает относительный URL.
- Введите полный или относительный новый адрес согласно подсказке CMS.
- Выберите тип «301» или «постоянный».
- Сохраните правило и очистите кеш сайта.
- Проверьте ответ внешним запросом и в браузере.
Не создавайте одинаковое перенаправление одновременно в CMS и на веб-сервере. Дублирующие правила усложняют диагностику и могут сформировать цепочку. Также проверьте, не генерирует ли CMS автоматический редирект после изменения адреса материала.
Массовый перенос раздела или сайта
Если структура старых и новых URL совпадает, допустимо использовать шаблонное правило. Например, все страницы из каталога /old-section/ можно перенести в /new-section/ с сохранением оставшейся части пути.
Шаблон нельзя применять без выборочной проверки. Внутри старого раздела могут находиться страницы, для которых нет эквивалента, либо отдельные URL могут переезжать в другие разделы. Сначала задают точечные исключения, затем более широкое правило.
При полной смене структуры надёжнее использовать карту соответствий. Автоматическое перенаправление всех старых адресов на главную или на корень нового раздела не заменяет постраничное сопоставление.
Как проверить работу редиректа
Проверка должна подтвердить не только открытие новой страницы, но и технически правильный маршрут. Браузер может скрыть промежуточные переходы или использовать закешированный ответ.
- Запросите старый URL и проверьте первый код ответа. Ожидаемый результат — 301.
- Проверьте заголовок Location. В нём должен находиться корректный конечный адрес.
- Откройте адрес из Location. Конечная страница должна вернуть 200.
- Убедитесь, что между старым и новым URL нет промежуточных перенаправлений.
- Повторите тест для HTTP и HTTPS, www и версии без www, URL со слешем и без него, если такие варианты использовались.
- Проверьте несколько страниц каждого шаблона, а при небольшом объёме — весь список.
Для проверки из командной строки можно выполнить:
curl -I http://example.ru/old-page/
В ответе должны присутствовать статус 301 и заголовок Location. Команда с параметрами -I -L позволяет увидеть прохождение маршрута до конечной страницы, хотя для подробной диагностики удобнее просматривать каждый ответ отдельно.
После массового переноса обновите внутренние ссылки, XML-карту сайта, canonical и другие элементы, где указан старый URL. Внутренние ссылки должны сразу вести на конечные страницы: редирект предназначен прежде всего для старых внешних адресов и сохранённых переходов, а не для постоянной навигации внутри сайта.
Следите за отчётами о сканировании и индексации в инструментах поисковых систем, логами сервера и динамикой ошибок 404. Старые URL не нужно закрывать в robots.txt: поисковому роботу требуется получить ответ 301 и увидеть новый адрес.
Типичные ошибки при настройке
Цепочка редиректов. Запрос проходит несколько этапов: страница A направляет на B, затем B — на C. Исправьте первое правило так, чтобы A сразу перенаправляла на C. Это сокращает задержку и упрощает обработку адресов.
Циклическое перенаправление. Страница A ведёт на B, а B возвращает пользователя на A, либо правило HTTPS неверно определяет исходный протокол. Браузер сообщает о слишком большом количестве перенаправлений. Нужно проверить порядок и условия правил.
Редирект на нерелевантную страницу. Перенос любого удалённого URL на главную не помогает пользователю найти ожидаемый материал. Выбирайте смысловой аналог, а при его отсутствии возвращайте корректный код удаления.
Новый адрес возвращает ошибку. Редирект на 404, 500 или закрытую страницу не решает задачу переноса. Сначала опубликуйте и проверьте конечный документ, затем включайте правило.
Использование 302 вместо 301. В панели управления тип перенаправления может быть выбран по умолчанию. После сохранения обязательно проверьте фактический HTTP-статус.
Потеря пути или параметров. При переносе домена важно сохранить URI, если структура не меняется. Для отдельных страниц нужно решить, должны ли переноситься UTM-метки, фильтры и другие параметры. Бесконтрольное сохранение служебных параметров способно создавать множество вариантов URL.
Слишком широкое регулярное выражение. Неточное правило захватывает не только старые страницы, но и новые адреса, файлы или административные разделы. Проверяйте начало и конец шаблона и сначала тестируйте несколько разных URL.
Удаление правил сразу после переезда. Старые адреса могут долго оставаться во внешних ссылках, закладках, документах и поисковых данных. Сохраняйте перенаправления, пока исходные URL продолжают получать запросы и имеют ценность для пользователей или поиска.
Частые вопросы
Можно ли настроить 301 редирект без доступа к серверу?
Да, если CMS или панель хостинга поддерживает постоянные перенаправления. После настройки необходимо проверить, что система действительно возвращает код 301, а не выполняет переход через JavaScript или HTML.
Передаёт ли 301 редирект позиции старой страницы?
Постоянный редирект помогает поисковым системам связать старый и новый URL и перенести сигналы, но не гарантирует сохранение прежних позиций. Результат зависит от релевантности новой страницы, технической корректности переноса и других факторов ранжирования.
Нужно ли оставлять старую страницу доступной?
Нет. Старый URL должен отвечать статусом 301 и заголовком Location, а контент должен открываться только по новому адресу. Одновременная доступность одинакового материала по двум URL создаёт дубли.
Сохраняются ли UTM-метки и другие параметры?
Это зависит от правила и веб-сервера. При переносе домена с сохранением request URI параметры обычно передаются. Для точечных правил поведение нужно проверить отдельно и при необходимости явно настроить.
Можно ли сделать редирект для адреса с символом #?
Сервер не получает фрагмент URL после символа #, поэтому обычный серверный редирект не может определить его значение. Перенаправление на основе фрагмента требует клиентской логики и не является стандартной заменой HTTP-редиректу.
Когда изменения появятся в поисковой выдаче?
Срок зависит от частоты обхода страниц, масштаба переноса и состояния сайта. Поисковой системе нужно повторно просканировать старые URL, обработать ответы 301 и обновить данные о новых страницах.
Если перенос затрагивает много страниц, домен или структуру каталога, настройку стоит проводить вместе с техническим аудитом. В рамках SEO-продвижения сайта специалисты Granat могут проверить карту адресов, правила перенаправления, индексацию и внутренние ссылки.
