301 редирект: когда использовать, как настроить и проверить

301 редирект нужен тогда, когда URL изменился постоянно, а пользователи и поисковые роботы должны дальше попадать на новый адрес. Сервер отвечает кодом 301 Moved Permanently и передаёт новый URI в заголовке Location.

Типичные случаи — изменение структуры URL, перенос страницы в другой раздел, смена домена, переход с HTTP на HTTPS, объединение нескольких дублей в одну основную страницу или перенос старого материала на новый адрес.

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

Что на самом деле происходит при ответе 301

Запрос к старому адресу не отдаёт пользователю содержимое новой страницы непосредственно. Сначала сервер отвечает примерно так:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/

После этого браузер или другой HTTP-клиент делает новый запрос уже к адресу из Location.

Рабочий маршрут выглядит так:

https://example.com/old-page/
        ↓ 301
https://example.com/new-page/
        ↓ 200
контент новой страницы

В HTTP 301 означает, что ресурсу назначен новый постоянный URI. В большинстве обычных веб-страниц этого достаточно, но есть техническая особенность: исторически клиенту разрешено изменить метод POST на GET после 301. Если при постоянном перенаправлении принципиально важно сохранить метод запроса, для такой архитектуры существует 308 Permanent Redirect.

Для SEO принципиально другое: постоянные HTTP-редиректы являются для Google сигналом, что целевой URL следует рассматривать как новую каноническую версию. Яндекс также относит 301 и 308 к постоянным перенаправлениям.

Когда 301 редирект действительно нужен

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

Например:

• /services/seo-old/ заменён на /services/seo/;
• карточка товара переехала на новый постоянный URL;
• две статьи объединены в один более полный материал;
• сайт окончательно меняет домен;
• HTTP-версия заменяется HTTPS-версией;
• меняется структура каталога, но сами сущности сохраняются.

Во всех этих ситуациях старый URL можно сопоставить с конкретной новой точкой назначения.

Совсем другая ситуация — удалённая страница, для которой подходящей замены нет. Для URL без релевантного аналога вариант 404 ошибка обычно корректнее, чем автоматический 301 на главную или случайную категорию. Google прямо рекомендует возвращать 404 или 410, если контент исчез и сходной замены не существует.

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

Как 301 связан с обходом, индексированием и SEO

301 не является кнопкой «передать позиции». Он сообщает поисковой системе, что старый URL постоянно заменён новым.

Для Google постоянный серверный редирект относится к сильным сигналам канонизации: робот проходит по перенаправлению, а система индексирования может использовать целевой URL как канонический. При полноценном переезде домена Google также описывает перенос различных сигналов со старого сайта на новый.

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

Это не означает гарантированного сохранения видимости. Яндекс прямо предупреждает, что при смене главного адреса не гарантирует прежнее количество страниц в поиске, позиции или посещаемость. Google также допускает временные колебания при миграциях, особенно если одновременно меняются адреса, структура и содержимое.

Поэтому оценивать результат нужно не по наличию строки 301 в конфигурации, а по всей системе сигналов:

Проверка	Что должно происходить
Старый URL	отдаёт постоянный редирект
Location	указывает на правильный новый URL
Конечный URL	доступен и отдаёт нормальный конечный ответ
Внутренние ссылки	ведут уже на новые URL
Sitemap	содержит актуальные канонические адреса
Canonical новой страницы	не указывает обратно на старый URL
Robots / meta robots	не блокируют новую страницу
Поисковая индексация	со временем смещается к новому адресу

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

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

Быстрая проверка начинается не с браузера. Браузер автоматически проходит перенаправление, поэтому визуально можно увидеть только конечную страницу и не заметить, был ли между ними 301, 302 или длинная цепочка.

В терминале можно запросить заголовки:

curl -I https://example.com/old-page/

Ожидаемый фрагмент:

HTTP/2 301
location: https://example.com/new-page/

Затем проверяется конечный адрес:

curl -I https://example.com/new-page/

Нормальный сценарий для существующей страницы:

HTTP/2 200

Для просмотра всей цепочки можно использовать:

curl -IL https://example.com/old-page/

Но при аудите важно смотреть именно последовательность ответов, а не только последний URL.

Например, такая цепочка уже требует внимания:

http://example.com/old/
301 → https://example.com/old/
301 → https://www.example.com/old/
301 → https://www.example.com/new/
200

Формально пользователь доходит до нужной страницы, но для каждого перехода требуется новый запрос. Google рекомендует направлять URL сразу к конечной точке и избегать цепочек. В документации по миграциям указано, что Googlebot способен пройти до десяти переходов, но практическая рекомендация — держать цепочку максимально короткой, в идеале не более трёх переходов и меньше пяти.

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

После переезда дополнительно проверяют состояние URL в Google Search Console и Яндекс Вебмастере. Изменение индекса происходит не мгновенно: поисковому роботу требуется повторно обойти адреса и обработать новые сигналы.

Как настроить 301 на Nginx, Apache и WordPress

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

Nginx

Для переноса одного адреса:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

Для переноса всего старого домена с сохранением пути и параметров:

server {
    listen 80;
    server_name old.example.com;

    return 301 https://new.example.com$request_uri;
}

Официальная документация Nginx для простых перенаправлений также показывает использование return 301 вместо лишней сложной логики через if и rewrite.

После изменения конфигурации сначала проверяют синтаксис, затем применяют её и только после этого тестируют реальные URL.

Apache

В .htaccess при включённом mod_rewrite правило для одной страницы может выглядеть так:

RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

Для простого постоянного переноса не нужно создавать сложные регулярные выражения, если задача решается прямым соответствием.

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

WordPress

В WordPress функция wp_redirect() по умолчанию отправляет 302, поэтому для постоянного переноса статус нужно указывать явно. Для внутреннего адреса безопаснее использовать wp_safe_redirect().

Пример контролируемого перенаправления существующей страницы:

add_action('template_redirect', function () {
    if (is_page('old-page')) {
        wp_safe_redirect(home_url('/new-page/'), 301);
        exit;
    }
});

После wp_redirect() или wp_safe_redirect() выполнение PHP нужно завершать через exit;: сама функция WordPress этого автоматически не делает.

Для сотен и тысяч URL PHP-условия в теме обычно не лучший слой. Массовые постоянные маршруты удобнее собирать из карты перенаправлений и реализовывать централизованно на сервере, в специализированном модуле или в управляемом механизме CMS.

Массовые 301 редиректы: сначала карта, потом правило

Главная ошибка массовой миграции — начинать с регулярного выражения, не имея таблицы соответствий.

Сначала формируется карта:

/old-a/ → /new-a/
/old-b/ → /new-b/
/old-c/ → /new-c/

После этого URL делятся на группы:

1. точное соответствие «один старый → один новый»;
2. предсказуемое изменение структуры, которое можно описать правилом;
3. несколько старых страниц, реально объединённых в одну;
4. адреса без релевантной замены.

Только для второй группы имеет смысл строить массовое регулярное правило. Остальные лучше обрабатывать по явной карте.

Например, если:

/catalog/product-123/

стало:

/products/product-123/

и эта структура действительно одинакова для всего раздела, правило можно масштабировать.

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

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

Когда перенаправления затрагивают десятки или сотни URL, задача уже выходит за рамки одного правила в Nginx: услуги SEO-продвижения при миграции сайта нужны, чтобы заранее собрать карту старых и новых адресов, проверить цепочки, canonical, Sitemap и сохранить релевантные конечные страницы.

Пять ошибок, из-за которых правильный код 301 даёт плохой результат

Цепочка вместо прямого перехода

Было:

A → B → C → D

Должно быть, если D уже является постоянной конечной точкой:

A → D
B → D
C → D

Старые входящие маршруты лучше постепенно сокращать до конечного URL.

Циклическое перенаправление

Классическая ошибка:

A → B
B → A

Браузер завершит такой сценарий ошибкой слишком большого количества перенаправлений. Причиной часто становится пересечение правил HTTP→HTTPS, www→без-www и отдельных правил CMS.

Редирект на нерелевантную страницу

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

Новый URL сам делает редирект

Сопоставление:

old → new

может выглядеть правильным в таблице, но если new уже перенаправляет на new-2, фактический маршрут становится длиннее. Поэтому при подготовке карты проверяется не только значение целевого URL, но и его реальный HTTP-ответ.

Внутренние ссылки продолжают вести через старые адреса

301 позволяет старой ссылке работать, но это не причина сохранять её внутри сайта. После изменения URL стоит заменить ссылки в меню, шаблонах, статьях, Sitemap и других управляемых источниках на финальный адрес.

Практический сценарий: раздел сайта переехал на новые URL

Предположим, на сайте было 300 материалов в каталоге:

https://example.com/blog/topic-name/

После изменения структуры они должны находиться по адресу:

https://example.com/articles/topic-name/

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

Затем на тестовой группе, например нескольких URL разных типов, проверяется правило:

/blog/topic-name/
301 → /articles/topic-name/
200

После успешной проверки оно применяется ко всему подходящему разделу.

Дальше повторный краул должен показать:

• старые адреса возвращают постоянный редирект;
• каждая цель существует;
• нет циклов и лишних промежуточных переходов;
• внутренние ссылки уже ведут на /articles/;
• Sitemap содержит новые URL;
• canonical новых страниц указывает на актуальные адреса.

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

При смене целого домена одного 301 недостаточно рассматривать изолированно. Google рекомендует после настройки перенаправлений использовать Change of Address для соответствующего доменного переезда; инструмент не применяется для обычной смены HTTP на HTTPS или переноса отдельных внутренних страниц. В Яндекс Вебмастере для поддерживаемых сценариев переезда также предусмотрен отдельный инструмент.

И самое важное: редирект должен описывать реальное изменение адреса. Если сначала выбрать правильную конечную страницу, а уже потом написать правило и проверить фактическую HTTP-цепочку, 301 остаётся простой и предсказуемой частью технического SEO, а не источником новой путаницы.