301-редирект

Происхождение и история термина

Код в протоколе HTTP. «301-редирект» — профессиональное название ответа HTTP с кодом 301. Научной работы, которая «вводит» 301-редирект, нет: это элемент протокола HTTP, и его смысл задают спецификации IETF. Действующая семантика описана в RFC 9110 «HTTP Semantics» (июнь 2022 года, стандарт STD 97; редакторы R. Fielding, M. Nottingham, J. Reschke) в разделе 15.4.2 ^[1]. RFC 9110 заменил ряд прежних документов, в том числе RFC 7231 и RFC 7538 ^[1].

Почему появились 307 и 308. RFC 9110 сам описывает историю путаницы с методами. В HTTP/1.0 коды 301 и 302 были определены как сохраняющие метод запроса, но ранние браузеры по-разному повторяли POST после перенаправления: одни снова отправляли POST, другие — более безопасный GET. Практика сошлась на смене метода на GET; позднее для однозначного сохранения метода добавили 307 и 308, а описания 301 и 302 скорректировали, разрешив перенаправлять POST как GET ^[1].

Код 308 (Permanent Redirect) ввёл RFC 7538 (апрель 2015 года, автор J. Reschke). Во введении документа сказано, что существующие коды не покрывают все сочетания «постоянный/временный» и «можно/нельзя менять POST на GET», поэтому спецификация добавляет недостающий вариант: «this specification adds the status code 308, defining this missing variant» ^[2]. RFC 9110 отмечает, что 308 «much younger (June 2014) than its sibling codes» и может распознаваться не везде ^[1].

SEO-трактовка: спор о «потере веса». Долгое время оптимизаторы спорили, теряет ли страница часть ссылочного веса (PageRank) при перенаправлении. По данным Search Engine Land, в 2010 году издание сообщало о «some PageRank dilution» при 301 и других 30x-редиректах ^[18]. 26 июля 2016 года сотрудник Google Гэри Илш (Gary Illyes) написал: «30x redirects don't lose PageRank anymore» ^[18]. Это свидетельство 2016 года — историческое; актуальная позиция приведена в документации Google о переезде сайта: «301 and other permanent redirects don't cause a loss in PageRank» ^[4].

Суть и механизм

Как проходит перенаправление

1. Клиент (браузер или поисковый робот) запрашивает старый адрес.
2. Сервер отвечает кодом 301 и заголовком Location с предпочтительным новым адресом (спецификация предписывает этот заголовок словом SHOULD — «следует»); в теле ответа обычно короткая гипертекстовая заметка со ссылкой на новый адрес ^[1].
3. Клиент может автоматически повторить запрос по адресу из Location ^[1]. Относительный адрес в Location разрешается относительно исходного; если в Location нет фрагмента (#…), он наследуется от исходной ссылки ^[1].
4. Новый адрес отвечает 200 OK — или очередным редиректом, и тогда возникает цепочка.

Условный пример обмена (пример, адреса вымышленные):

GET /old-page HTTP/1.1
Host: example.com

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

В реальном ответе из справочника MDN рядом с кодом 301 сервер передаёт заголовок cache-control с собственным сроком хранения ^[17].

Что 301 говорит клиенту

RFC 9110 формулирует смысл кода так: ресурсу «has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs» ^[1]. Спецификация предполагает, что программа, умеющая редактировать ссылки, могла бы навсегда заменить старый адрес новым, но отмечает, что на практике это предложение обычно игнорируется ^[1].

Две важные оговорки из RFC 9110:

• Смена метода. «For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request» — если это нежелательно, вместо 301 используют 308 ^[1]. MDN уточняет, что по стандарту Fetch браузер, получив 301 на POST, повторяет запрос методом GET ^[17].
• Кеширование. «A 301 response is heuristically cacheable» — то есть кешируется, если определение метода или явные директивы кеширования не говорят иного ^[1]. Вывод: ошибочно выставленный 301 может какое-то время продолжать работать у посетителей, чьи браузеры его сохранили, даже после исправления на сервере. Поэтому для экспериментов и временных ситуаций используют временные коды.

Спецификация также требует от клиента обнаруживать циклические перенаправления; в одной из ранних версий HTTP рекомендовался предел в пять переходов, и RFC 9110 предупреждает, что некоторые клиенты могут до сих пор применять такой фиксированный лимит ^[1].

Что делает с 301 поисковая система

Google. Получив 301, Google переходит по перенаправлению и использует его как сильный сигнал, что обрабатывать нужно адрес назначения; содержимое, которое отдаёт перенаправляющий адрес, игнорируется ^[5]. При постоянном редиректе система индексирования считает цель канонической, а в результатах поиска показывает новый адрес; старый становится «альтернативным именем» канонического и может появиться в выдаче, если запрос пользователя подсказывает, что тот больше доверяет старому адресу ^[3]. Роботы Google по умолчанию проходят до 10 переходов подряд ^[5].

Яндекс. Справка различает внутрихостовые редиректы (в пределах одного хоста) и межхостовые (между разными хостами). При внутрихостовом редиректе робот индексирует содержимое страницы-цели, а в результатах поиска показывает ссылку на цель; при этом «главная страница хоста всегда будет отображаться в результатах поиска» ^[7]. Если поддомены (например, региональные или языковые версии) связаны редиректом, Яндекс объединяет их в группу сайтов ^[7]. Предельное число переходов в открытых справках Яндекса, которые открывались для этой статьи, не указано ^[7], ^[8].

Виды и классификации

Коды перенаправления по RFC 9110

Классификация IETF ^[1], ^[2]:

Остальные коды класса 3xx в SEO-смысле редиректами не являются: 300 (Multiple Choices) предлагает выбор из нескольких представлений, 304 (Not Modified) отсылает к ранее сохранённой копии, 305 (Use Proxy) объявлен устаревшим, 306 не используется и зарезервирован ^[1].

Как трактуют способы перенаправления Google и Яндекс

Google рекомендует по возможности использовать постоянный серверный редирект ^[3].

Чем 301 отличается от соседних понятий

• 302-редирект — временное перенаправление: Google показывает в выдаче исходную страницу, а не цель ^[3]. Подробнее — в статье 302-редирект.
• Цепочка редиректов — несколько перенаправлений подряд; разбор — в статье Цепочка редиректов.
• Канонический адрес (rel="canonical") — не перенаправляет посетителя, а подсказывает поисковой системе предпочтительный адрес. Google называет и редирект, и rel="canonical" сильными сигналами, а включение в Sitemap — слабым; редирект он советует применять, когда от дубля нужно избавиться ^[6]. См. Канонический адрес (canonical).
• Главное зеркало — механизм Яндекса, при котором адреса объединяются в группу и один из них становится главным; редирект — один из способов сообщить о переезде ^[8]. См. Главное зеркало.

Как применяется на практике

Типовые сценарии (обобщение по ^[3], ^[4], ^[8], ^[10]):

• смена адреса страницы — например, при переходе на ЧПУ (человекопонятный URL) или перестройке разделов;
• переход сайта с HTTP на HTTPS;
• выбор одного варианта хоста (с www или без) и единого написания адресов;
• объединение дублирующих страниц ^[6];
• переезд на новый домен и объединение сайтов.

Переезд сайта: Google и Яндекс

Яндекс поясняет, что переезд позволяет «передать некоторые накопленные показатели старого сайта новому», например внешние ссылки старого сайта «будут учитываться как внешние ссылки нового» ^[8]. Google сообщает, что держать редиректы долго нужно, чтобы передать новым адресам все сигналы, в том числе ссылки с других сайтов ^[4].

Примеры конфигураций

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

Apache, модуль mod_alias. Для простых перенаправлений документация Apache советует директивы Redirect и RedirectMatch, а не RewriteRule ^[14]. Без указания статуса Redirect отдаёт временный 302, поэтому статус задают явно; RedirectPermanent — точный аналог Redirect permanent ^[12]. Директива переносит и вложенные пути: правило для /one/ перенаправит и /one/two.html ^[12], ^[14].

Redirect permanent "/old" "https://example.com/new"
RedirectMatch 301 "^/catalog/(.*)$" "https://example.com/shop/$1"

Apache, переход на HTTPS. Предпочтительный вариант по документации Apache — отдельный виртуальный хост для порта 80 с директивой Redirect ^[15]:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent "/" "https://example.com/"
</VirtualHost>

Если доступа к конфигурации сервера нет и остаётся только файл .htaccess, документация называет подходящим инструментом mod_rewrite ^[15]. Но рецепт из документации с подстановкой $1 в .htaccess дословно переносить нельзя. В контексте каталога (.htaccess) шаблон RewriteRule сравнивается с путём, от которого отрезан префикс каталога, и эта строка «never has a leading slash» ^[20]. Для запроса /foo/bar значение $1 равно foo/bar, и получится адрес вида https://example.comfoo/bar, а в .htaccess подкаталога ещё и потеряется путь каталога (разбор редакции по ^[20]). Для работы с полным путём в контексте каталога документация советует переменную %{REQUEST_URI} ^[20]; она содержит путь запрошенного URI, например /index.html, без строки запроса ^[20].

Правило ниже собрано редакцией по документации mod_rewrite ^[20]; перед переносом на рабочий сервер его проверяют на тестовом:

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^" "https://%{SERVER_NAME}%{REQUEST_URI}" [R=301,L]

Переменная HTTPS содержит «on», если соединение идёт по SSL/TLS, и «off» в остальных случаях ^[20]. Значение SERVER_NAME зависит от настройки UseCanonicalName ^[20], поэтому при нескольких именах хоста надёжнее указать нужный хост явно, например https://example.com%{REQUEST_URI} (вывод). Значение REQUEST_URI уже раскодировано из %-последовательностей ^[20], поэтому адреса с закодированными символами проверяют отдельно.

Флаг [R] без кода даёт 302; флаг почти всегда сочетают с [L], который останавливает обработку правил ^[13].

nginx. Директива return с кодами 301, 302, 303, 307 и 308 отдаёт перенаправление на указанный адрес; код 308 nginx не считал редиректом до версии 1.13.0 ^[16]. У директивы rewrite флаг permanent возвращает 301, флаг redirect — 302 ^[16]. Переменные $host, $request_uri (исходный URI с аргументами) и $scheme описаны в документации модуля ядра ^[19].

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

PHP. Google приводит пример с двумя заголовками — строкой статуса HTTP/1.1 301 Moved Permanently и Location, после которых выполнение скрипта прерывается (exit()) ^[3].

CMS и хостинги обычно дают собственные настройки перенаправлений; их итог проверяют так же — по фактическому коду ответа.

Как измерить или проверить

Формулы у 301-редиректа нет: проверяют фактический ответ сервера.

• Яндекс Вебмастер → Инструменты → «Проверка ответа сервера». Указывается адрес, выбирается робот; инструмент показывает HTTP-код и, для HTTPS, состояние сертификата. Справка предупреждает: у инструмента другой IP-адрес, поэтому его ответ может отличаться от реального ответа роботу; реальный ответ смотрят в логах сервера ^[11].
• Google Search Console. По документации Google, инструменты проверки Google (Google Inspection Tools) перенаправлениям не следуют, поэтому адрес назначения проверяют отдельно ^[5].
• Заголовки ответа. Код и заголовок Location видны в инструментах разработчика браузера (вкладка «Сеть») и в консольных HTTP-клиентах; пример такого обмена, полученного через curl, приводит MDN ^[17].
• Лог-файлы сервера — показывают, какой код получили реальные роботы и посетители ^[11].

Что смотреть после переезда (контрольные показатели редакции, не нормы поисковых систем): доля старых адресов, отвечающих 301 на релевантную страницу; число переходов до конечной цели (Google советует прямой переход, а если он невозможен — в идеале не больше трёх и в любом случае меньше пяти ^[4]); код конечной цели — 200, а не 404 и не новый редирект.

Мини-инструмент «Генератор и проверка 301-редиректа»

Инструмент готовится к запуску. Ниже описано, как он будет работать. До запуска проверить уже настроенный адрес можно в «Проверке ответа сервера» Яндекс Вебмастера ^[11].

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

Что вводится:

• пары «старый адрес → новый адрес» (до 50 строк) или типовой сценарий: HTTP→HTTPS, www→без www и обратно, добавить или убрать слеш в конце, перенос раздела, смена домена;
• сервер: Apache (.htaccess: mod_alias или mod_rewrite), nginx, PHP;
• тип перенаправления: «постоянный» (301) или «временный» (302); переключатель «сохранять метод запроса» меняет коды на 308 и 307.

Что выводится:

1. Строки конфигурации с комментариями — в синтаксисе из документации Apache и nginx ^[12], ^[13], ^[15], ^[16], ^[20]. Для сценария HTTP→HTTPS в .htaccess генератор использует форму с %{REQUEST_URI} из раздела «Примеры конфигураций», а не подстановку $1, которая в .htaccess даёт неверный адрес ^[20]. При выборе 308 для nginx выводится напоминание о поддержке с версии 1.13.0 ^[16].
2. Подсказка по выбору кода — по таблицам этой статьи: постоянный переезд — 301 (или 308 для форм и API), временная ситуация — 302 или 307 ^[1], ^[3], ^[9].
3. Предупреждения валидатора:
   • цель совпадает с источником — петля;
   • цель сама встречается среди источников — цепочка; инструмент предложит свернуть её до прямого перехода ^[4];
   • много разных адресов ведут на главную страницу — риск «мягкой 404» по Google и расхождение с рекомендацией Яндекса ^[4], ^[8];
   • цели на разных протоколах или доменах, переход с HTTPS на HTTP;
   • смесь относительных и абсолютных адресов.

Длинные цепочки разбираются в инструменте статьи Цепочка редиректов.

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

Пример условный. Введены строки /old-page → /new-page и /new-page → /final-page, сервер — nginx, тип — постоянный. Инструмент выведет два правила return 301 и предупреждение: «/old-page ведёт на /new-page, который сам перенаправляется. Рекомендуется направить /old-page сразу на /final-page».

Ошибки, ограничения и спорные вопросы

Редирект всех страниц на главную. Google предупреждает: перенаправление многих старых адресов на одну нерелевантную страницу, например главную, сбивает пользователей и может быть расценено как soft 404; допустимо направлять на одну страницу адреса, чьё содержимое в неё объединено ^[4]. Яндекс по возможности не рекомендует ставить редирект со всех страниц старого сайта на главную нового ^[8]. Удалённый без замены материал должен отдавать 404 или 410 ^[4]; справочник Яндекса для ресурсов, удалённых навсегда, называет код 410, а для перемещённых советует 301 ^[9]. См. Ошибка 404.

Перепутанные постоянный и временный коды. При постоянном переезде временный 302 оставляет в выдаче Google исходную страницу ^[3]. И наоборот: 301 не стоит ставить на время технических работ или A/B-теста — для таких случаев справочник Яндекса называет 302 ^[9], а Google советует постоянный редирект, только когда вы уверены, что он не будет отменён ^[3].

Цепочки и петли. Googlebot проходит до 10 переходов, но при переезде Google просит вести сразу на конечную цель ^[4], ^[5]. Клиент обязан распознавать бесконечные циклы перенаправлений ^[1].

Формы и API. После 301 браузер может заменить POST на GET; если метод важен, нужен 308 ^[1], ^[17].

Редирект по IP-адресу. IP-адрес робота Яндекса может не совпадать с регионом посетителя, поэтому в поиске может оказаться любая версия страницы. Справка советует определять робота, например по User-Agent, и настраивать редирект так, чтобы робот получал один и тот же контент, либо использовать переключатель языка или региона, где обе версии отвечают 200 OK ^[7].

Противоречивые сигналы. Если старый адрес перенаправляется, а внутренние ссылки, Sitemap или rel="canonical" по-прежнему указывают на него, поисковая система получает разные подсказки. Google при переезде просит заменить внутренние ссылки на новые адреса, подготовить Sitemap с новыми адресами и указать на новых страницах канонический адрес на самих себя ^[4]; Яндекс при переходе на HTTPS просит заменить ссылки, адреса в Sitemap и robots.txt ^[10].

Слишком ранняя отмена редиректа. Документация расходится: Google — «Keep the redirects for as long as possible, generally at least 1 year» ^[4]; Яндекс — «Сохраняйте перенаправление минимум 6 месяцев для корректной обработки поисковыми системами» ^[9]. Свести эти рекомендации к одной цифре нельзя: это требования разных систем.

Спор о «передаче веса». Формулировка «301 передаёт 100% веса» не принадлежит ни Google, ни Яндексу. Google в документации пишет, что постоянные редиректы не приводят к потере PageRank ^[4], и называет редирект сильным сигналом канонизации ^[6]. Яндекс говорит о передаче «некоторых накопленных показателей», например внешних ссылок, и не гарантирует сохранения позиций и посещаемости ^[8]. Даже при корректном редиректе Google предупреждает о временных колебаниях позиций во время переезда ^[4].

Кеширование. Поскольку 301 кешируется эвристически ^[1], исправленный на сервере ошибочный редирект может продолжать срабатывать у части посетителей (вывод из ^[1]).

Частые вопросы

Связанные термины

• 302-редирект
• Цепочка редиректов
• Коды ответа сервера
• Ошибка 404
• Канонический адрес (canonical)
• Главное зеркало / Зеркало сайта
• Дубли страниц
• HTTPS и SSL-сертификат
• ЧПУ (человекопонятный URL)
• Индексация
• Лог-файлы сервера