301 редирект: как настроить и проверить

Автор: Редакция Торох Опубликовано: 14 ноября 2026 8 минут чтения

Постоянный редирект переносит посетителя и поисковый вес со старого адреса на новый. В руководстве — синтаксис правила, готовые примеры для Apache, nginx, WordPress, 1С-Битрикс и Tilda, способы проверки кода ответа и типичные ошибки, из-за которых редирект не работает.

Что такое 301 редирект и зачем он нужен

301 Moved Permanently — код состояния HTTP. Им сервер сообщает, что запрошенный адрес навсегда переехал на другой. В ответе передаётся заголовок Location с новым адресом: браузер открывает его автоматически, а поисковый робот запоминает связь между старой и новой страницей.

Для поисковых систем 301 — сигнал объединить два адреса в один. История страницы, внешние ссылки и накопленные сигналы постепенно переносятся на новый URL. Поэтому при переезде сайта, смене структуры и протокола используют именно постоянный редирект, а не временный.

Типичные задачи:

• переход с HTTP на HTTPS;
• склейка адресов с www и без www;
• смена домена или переезд на поддомен;
• новая структура URL после редизайна или смены CMS;
• объединение двух материалов в один;
• смена расширений (.html → адрес без расширения), регистра букв, лишнего слеша на конце;
• перенос содержимого раздела в каталог.

Важное ограничение: 301 уместен там, где у старого адреса есть полноценная замена. Если страница просто исчезла, корректнее отдать 404 или 410. Массовый редирект «всего на главную» поисковые системы часто трактуют как мягкую ошибку и не переносят вес на релевантную страницу.

Чем 301 отличается от 302 и других кодов

Разница между 301 и 302 — в сроке. При 302 старый адрес остаётся в индексе, новый считается временной копией. При 301 поисковик постепенно заменяет старый URL новым.

Отдельно про кэш: 301 браузеры запоминают надолго и могут не обращаться к серверу повторно. Если правило ошибочное, исправление увидят не все пользователи сразу — придётся чистить кэш браузера или ждать. Поэтому правило проверяют до публикации.

Как устроен редирект на уровне HTTP

Внешне это выглядит так:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/
Content-Type: text/html; charset=utf-8

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

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

1. Веб-сервер (nginx, Apache) — срабатывает до обработки скриптов, самый быстрый вариант.
2. CMS и фреймворки — плагины, компоненты, правила маршрутизации, обработчики событий.
3. Клиентские способы — <meta http-equiv="refresh"> и location.href в JavaScript. Сервер при этом отдаёт 200, и поисковый робот воспринимает такую переадресацию хуже.

Синтаксис зависит от уровня: в Apache используют директивы Redirect, RedirectMatch и RewriteRule, в nginx — return и rewrite, в PHP — функцию header() с кодом 301.

Пошаговая настройка

1. Составьте карту адресов. Таблица «старый URL → новый URL» в Excel или Google Таблицах, затем экспорт в CSV — так удобно вести десятки и сотни правил. Старые адреса берите из панелей вебмастера, старой карты сайта, логов сервера, экспорта прежней CMS.
2. Определите уровень. Один-два адреса проще закрыть средствами CMS. Смену домена, протокола, массовую смену структуры — правилами сервера.
3. Напишите правило. Сначала на тестовом окружении или на одном второстепенном URL, чтобы не сломать навигацию.
4. Проверьте ответ. Первый ответ должен быть 301, Location — вести на нужный адрес, цепочка — короткой, конечная страница — отдавать 200.
5. Обновите ссылки и карту сайта. Внутренние ссылки, меню, canonical и sitemap.xml должны указывать на новые адреса. Редирект — страховка для внешних ссылок, а не способ навигации внутри сайта.
6. Наблюдайте за результатом. Отслеживайте новые 404 и ошибки сервера, дополняйте карту правил по мере появления старых адресов.

Примеры для серверов и CMS

Apache и .htaccess

Директивы Redirect работают через mod_alias, RewriteRule — через mod_rewrite. Файл .htaccess размещают в корне сайта, а в конфигурации сервера должно быть разрешено переопределение настроек (AllowOverride All).

Постоянный редирект одного адреса:

Redirect 301 /old-page.html https://example.com/new-page/

Перенос целого раздела задаётся префиксом:

Redirect 301 /old/ https://example.com/new/

Шаблон с сохранением части адреса — группа $1 подставляет совпавший фрагмент:

RedirectMatch 301 ^/catalog/(.*)\.html$ https://example.com/products/$1/

Через mod_rewrite удобно объединять условия. Пример склейки протокола и www:

RewriteEngine On
RewriteBase /

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Перенос отдельной страницы тем же модулем:

RewriteRule ^old-page\.html$ /new-page/ [R=301,L]

Флаг [R=301,L] задаёт код ответа и означает «последнее правило». Строка запроса при RewriteRule сохраняется по умолчанию; если она не нужна, в конце замены ставят ?.

nginx

Склейка протокола и www на уровне серверных блоков:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Точное совпадение адреса задаётся блоком location =:

location = /old-page.html {
    return 301 /new-page/;
}

Массовые правила удобно держать в map, а внутри server оставить одну проверку:

map $uri $redirect_to {
    /old-1.html /new-1/;
    /old-2.html /new-2/;
    default     "";
}

if ($redirect_to != "") {
    return 301 $redirect_to;
}

Конструкция if в nginx считается нежелательной, но для одного return она безопасна. После правки конфигурации выполняют проверку (nginx -t) и перезагрузку.

WordPress

• Плагин Redirection — редиректы в админке, журнал 404, импорт из CSV. Для пары адресов хватает Simple 301 Redirects.
• Смена структуры постоянных ссылок в «Настройки → Постоянные ссылки» сама по себе не создаёт редиректы для старых записей: их нужно добавить отдельно.
• При смене домена сначала правят WP_HOME и WP_SITEURL в wp-config.php или в базе, затем ищут старые адреса в контенте.
• Без плагина правило можно прописать в .htaccess или в теме через wp_redirect() с кодом 301, но вызывать её нужно до вывода страницы, иначе появится ошибка «headers already sent».
• В Yoast SEO управление редиректами доступно в платной редакции; в бесплатной есть только базовые возможности.

1С-Битрикс

• Файл .htaccess в корне сайта — общие правила для Apache.
• urlrewrite.php — правила обработки адресов, если включены ЧПУ.
• Событие OnBeforeProlog в /bitrix/php_interface/init.php — когда правило нужно привязать к логике сайта:

AddEventHandler("main", "OnBeforeProlog", "myRedirect");

function myRedirect()
{
    $uri = $GLOBALS["APPLICATION"]->GetCurPage();
    if ($uri === "/old-page.php") {
        LocalRedirect("/new-page/", true, "301 Moved Permanently");
    }
}

Третий параметр LocalRedirect() задаёт код состояния, по умолчанию используется 302.

При смене домена адрес сайта меняют в настройках продукта (раздел с параметрами сайтов), затем правят .htaccess или конфигурацию nginx. В части редакций есть готовые средства управления редиректами в модуле SEO — проверьте состав своей версии перед настройкой вручную.

Tilda

• В настройках страницы можно указать адрес, куда перенаправлять посетителя; набор доступных опций зависит от тарифа. Это удобно, когда страница устарела, но на неё ведут внешние ссылки.
• Перенаправления на уровне домена (www, протокол) настраиваются в панели домена, а не в редакторе страниц.
• Массовых правил в Tilda нет: для десятков адресов удобнее вести редиректы на уровне сервера или прокси.

Как проверить 301 редирект

Самый надёжный способ — посмотреть ответ сервера в консоли:

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

В первой строке должен быть HTTP/1.1 301 Moved Permanently, ниже — Location с новым адресом. Чтобы пройти всю цепочку и увидеть коды всех шагов:

curl -ILs https://example.com/old-page.html | grep -Ei "^(HTTP|location)"

Другие способы:

• онлайн-сервисы проверки редиректов показывают всю цепочку, коды и финальный адрес;
• в браузере: DevTools → Network, включите сохранение журнала и посмотрите первый ответ — он должен быть 301, финальный — 200;
• учтите кэш: 301 запоминается браузером, поэтому проверяйте в приватном окне или через curl.

Хороший результат выглядит так: один переход, финальный URL отдаёт 200, canonical указывает на него же, страница в карте сайта обновлена.

Частые ошибки

• 302 вместо 301. Временный код не переносит вес и оставляет старый адрес в индексе.
• Цепочки. A → B → C замедляет загрузку и размывает сигналы. Правило должно вести сразу на конечный адрес.
• Цикл. A → B → A даёт ошибку «слишком много редиректов». Проверяйте условия и добавляйте исключения.
• Всё на главную. Массовый перенос удалённых страниц на главную не помогает: поисковые системы не считают её заменой.
• Потеря GET-параметров. В RewriteRule строка запроса сохраняется не всегда — проверьте, что метки и параметры не теряются.
• Правило не работает. Причины: не подключён модуль, запрещён AllowOverride, файл лежит не в том каталоге, правило перекрыто более ранним с флагом L.
• Заголовки уже отправлены. Редирект из шаблона после вывода HTML не сработает.
• Неполная склейка. Сделан переход на HTTPS, но не выполнен переход с www — получаются две версии сайта.
• Правило задевает ресурсы. Редирект стилей, скриптов и картинок ломает вёрстку; проверяйте, что условия не затрагивают каталоги с ресурсами.
• Редирект на 404. Новый адрес должен существовать и отдавать 200, иначе смысла в переносе нет.
• Забытые ссылки и карта сайта. Если внутренние ссылки ведут на старые адреса, каждый переход проходит через редирект и нагружает сервер.
• Проверка только глазами. Без взгляда на код ответа легко принять 302 или 200 с JavaScript за корректный 301.

Материал подготовлен редакцией справочника Торох и носит справочный характер: интерфейсы программ и настройки серверов зависят от версии. Нашли неточность? Напишите нам.