Отличие 301 от 302 редиректа

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

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

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

Когда браузер или робот запрашивает адрес, сервер отвечает не только содержимым страницы, но и трёхзначным кодом состояния. Код 200 значит «вот страница». Коды третьей сотни значат «страницы здесь нет, иди по другому адресу», и вместе с кодом сервер присылает заголовок Location с этим адресом.

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

Код 301 сообщает: адрес сменился окончательно, старого больше не будет. Робот воспринимает это как команду заменить старый адрес новым в своей базе. Все накопленные сигналы — внешние ссылки, история, поведение посетителей — переносятся на новый адрес. Через несколько циклов обхода старый адрес из индекса исчезает, и в выдаче остаётся новый.

Код 302 сообщает противоположное: адрес временно отдаёт другое содержимое, но основным остаётся он сам. Робот в этом случае продолжает считать основным старый адрес, держит его в индексе и периодически возвращается проверить, не восстановилось ли всё. Сигналы никуда не переносятся, потому что переносить их некуда — переезда, с точки зрения системы, не было.

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

Сравнение кодов, которые используются для переадресации

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

Способ	Смысл для поисковой системы	Передаёт вес	Когда применяют
301 Moved Permanently	Адрес сменился навсегда	Да, практически полностью	Переезды, склейка версий, объединение страниц
302 Found	Временная подмена, основной адрес прежний	Нет	Техработы, временная акция, возврат после авторизации
307 Temporary Redirect	То же, что 302, но метод запроса не меняется	Нет	Формы и запросы POST, HSTS-переадресация на https
308 Permanent Redirect	То же, что 301, но метод запроса не меняется	Да	Постоянные переезды в интерфейсах и на API
Тег canonical	Подсказка, какая копия основная	Частично, как рекомендация	Дубли, которые обязаны оставаться доступными
Обновление через meta refresh	Трактуется по-разному, чаще как временное	Ненадёжно	Не применять для SEO-задач

На практике в девяноста случаях из ста хватает 301. Коды 307 и 308 нужны там, где важно сохранить метод запроса — например, если по адресу уходят данные формы. А переадресация через meta refresh в коде страницы или через скрипт — худший из вариантов: робот сначала должен загрузить страницу, потом исполнить её, и только потом понять, что его переадресовали. Часть таких переходов система вообще не отрабатывает.

Отдельно про canonical. Его регулярно предлагают как замену редиректу, и это ошибка постановки задачи. Редирект физически убирает старый адрес: перейти на него уже нельзя. Canonical оставляет обе страницы доступными и лишь подсказывает, какую считать главной. Если дубль обязан открываться — например, товар должен быть доступен из двух категорий, — ставится canonical. Если дубль не нужен никому — ставится 301.

Ситуации, где нужен только 301

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

Подробнее об этом — в статье «Отличие мобильной выдачи Яндекса от десктопной».

• Переезд на новый домен. Постранично: старый адрес ведёт на такой же по смыслу новый, а не все скопом на главную. Массовая склейка на главную обесценивает переезд — система видит, что содержимое не совпадает, и просто выбрасывает старые адреса.
• Переход на защищённый протокол. Каждый адрес по http отдаёт 301 на такой же по https. Без этого получаются две копии сайта, и сигналы делятся между ними.
• Склейка версий с www и без. Направление роли не играет, важна одинаковость по всему сайту.
• Смена структуры разделов. Была плоская структура, стала вложенная — старые адреса ведут на новые.
• Объединение двух похожих страниц. Две услуги, которые конкурировали между собой в выдаче, сводятся в одну, менее сильная ведёт на оставшуюся.
• Удалённая страница с близкой заменой. Товар снят с производства, есть аналог — редирект на аналог. Если замены нет, честнее отдать 404: редирект на нерелевантную страницу система приравнивает к мягкой ошибке.
• Приведение адресов к единому виду. Слэш в конце, регистр букв, лишние параметры — всё сводится к одному варианту.

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

Ситуации, где 302 действительно уместен

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

• Страница временно закрыта на работы и через день-два вернётся по тому же адресу. Здесь как раз нужно, чтобы система сохранила старый адрес в индексе.
• Акционная страница подменяет обычную на период распродажи, после чего всё возвращается назад.
• Переадресация на форму входа с последующим возвратом на запрошенную страницу.
• Тест двух вариантов страницы на ограниченной доле посетителей. Тут важно, чтобы в индексе остался основной вариант.
• Региональная или языковая подмена в момент первого захода, когда пользователю предлагают версию по его местоположению, но исходный адрес остаётся рабочим.

Помогу с продвижением: SEO-продвижение сайтов — вывожу сайты в топ Яндекса белыми методами.

Проверочный вопрос перед выбором кода один: планируете ли вы когда-нибудь снова открыть старый адрес для посетителей? Если ответ «да, через неделю» — 302. Если «нет» или «не знаю» — 301.

Чем оборачивается путаница на практике

Разберём последствия обеих ошибок по отдельности, потому что они выглядят по-разному и лечатся с разной скоростью.

Поставили 302 вместо 301. Самый частый и самый дорогой сценарий, обычно возникает при переезде. Внешне всё в порядке: посетители попадают куда надо, аналитика показывает переходы. Но в поиске остаётся старый адрес. Новый либо не индексируется вовсе, потому что система считает его временной подменой, либо индексируется как отдельная страница-дубль. Внешние ссылки продолжают работать на старый адрес, а новый растёт с нуля. Признак в отчётах: в Вебмастере старые адреса висят в индексе месяцами, новые помечены как дубли или недостаточно качественные.

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

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

Цепочки, петли и другие способы себе навредить

Даже правильно выбранный код можно испортить реализацией. Ниже находки, которые я вижу на каждом втором проекте с историей.

Цепочки редиректов. Классика выглядит так: адрес по http без www ведёт на http с www, тот — на https с www, тот — на https без www. Четыре шага вместо одного. Каждый шаг — отдельный запрос к серверу, а на мобильном соединении это лишние сотни миллисекунд перед показом страницы. Робот цепочки отрабатывает, но неохотно: длинные последовательности он может оборвать, не дойдя до конечного адреса. Правило — не длиннее одного шага, максимум двух в переходный период.

Тему разбирал отдельно: «Всплывающее окно на весь экран: Яндекс за него понижает, а вы теряете людей».

Петли. Адрес А ведёт на Б, Б ведёт обратно на А. Браузер показывает ошибку про слишком много переадресаций. Возникает обычно при наложении двух правил: одно настроено на сервере, второе — в настройках движка или в плагине.

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

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

Редирект вместо страницы 404. Все несуществующие адреса уводятся на главную одним правилом. Кажется аккуратным решением, но лишает вас информации: вы больше не видите, какие адреса ломаются и откуда на них идут ссылки. И плодит бессмысленные переадресации в статистике обхода.

Где настраивается и что чаще всего ломают

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

• Конфигурация nginx. Самый быстрый вариант: ответ отдаётся до того, как запрос дойдёт до PHP. Здесь настраивают протокол, www, слэш и общие правила переезда.
• Файл .htaccess на Apache. Правила читаются на каждый запрос, порядок строк критичен: первое сработавшее правило обрывает обработку. Типичная поломка — новое правило дописали в конец файла, а выше уже стоит общее, которое перехватывает запрос.
• Настройки движка или плагин. Удобно для точечных переадресаций, которые ставит контент-менеджер. Минус — каждая проверка требует загрузки движка, а на больших списках это заметная нагрузка.
• Код страницы. Переадресация из шаблона. Работает, но проверить её из общего списка правил невозможно — правило спрятано в коде, и через год никто не помнит, где оно.

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

Если нужна помощь по теме — мой курс по SEO.

Ещё одна тонкость: .htaccess обрабатывается сверху вниз, и общее правило вида «всё, что не файл, отправить в индексный скрипт» перехватывает запросы раньше ваших точечных правил, если стоит выше. Именно поэтому переадресации, добавленные в конец файла, часто «не работают» без всякой видимой причины.

Как проверить свои редиректы за пятнадцать минут

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

Смежный материал по теме — «Хлебные крошки — это не украшение, а карта сайта для робота Яндекса».

1. Через консоль. Команда curl -sIL https://адрес/ покажет все шаги переадресации с кодами. Смотрите, сколько шагов и какой код на каждом.
2. Через браузер. Откройте вкладку «Сеть» в инструментах разработчика, включите сохранение журнала при переходах и загрузите адрес. Каждый шаг будет отдельной строкой с кодом.
3. Обязательный набор проверок. Главная в четырёх вариантах: с www и без, по http и по https. Три случайные внутренние страницы. Любой заведомо несуществующий адрес — он обязан отдавать 404, а не 200 и не 301 на главную.
4. Массово. Обход сайта краулером с отчётом по кодам ответа: он покажет все внутренние ссылки, которые ведут через переадресацию, и все цепочки длиннее одного шага.
5. После переезда. В Вебмастере отслеживайте, как старые адреса уходят из индекса, а новые приходят. Полная замена занимает от двух недель до пары месяцев в зависимости от размера сайта и частоты обхода.

Отдельно проверьте карту сайта: в ней не должно быть адресов, которые отдают редирект. Карта — это список того, что должно быть в поиске, и адрес, ведущий на другой адрес, в этом списке лишний. То же касается разделов с ошибками в панелях вебмастеров: если после переезда там растёт число адресов с кодом 3xx, значит, ссылки на старые адреса остались где-то внутри сайта.

Полезно сохранять список правил переадресации отдельным документом с датой и причиной. Через год, когда никто не вспомнит, зачем адрес ведёт на другой раздел, этот файл экономит часы. Общая проверка состояния сайта описана в материале как проверить сайт на ошибки — редиректы там один из пунктов.

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

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

Правда ли, что при 301 теряется часть веса?
Раньше называли цифру около пятнадцати процентов, сейчас поисковые системы говорят, что передача практически полная. На практике потери связаны не с самим кодом, а с реализацией: склейка всего на главную, длинные цепочки, редирект на страницу другой тематики. Постраничный переезд один в один даёт результат, близкий к полному переносу.

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

Как быть, если старая страница ранжировалась, а новой ещё нет?
Переезжать всё равно, но постранично и одномоментно. Пока обе страницы открываются с кодом 200, они конкурируют между собой, и система выбирает одну сама. Ставить редирект и ждать эффекта — быстрее, чем держать дубль и надеяться, что всё рассосётся.

Что делать, если по ошибке уже полгода стоит 302?
Поменять код на 301 и отправить старые адреса на переобход в панелях вебмастеров. Затем проверить, что внутренние ссылки и карта сайта ведут на новые адреса. Восстановление занимает от трёх недель до двух месяцев — примерно столько, сколько нужно роботу, чтобы обойти сайт целиком и переоценить страницы.

Влияет ли редирект на скорость сайта?
Один шаг — незначительно, десятки миллисекунд. Цепочка из трёх-четырёх шагов на мобильном соединении даёт полсекунды задержки перед началом отрисовки, и это уже заметно в показателях загрузки. Плюс каждый шаг — отдельное обращение к серверу, а на большом трафике это лишняя нагрузка.

Нужен ли редирект при смене адреса одной статьи в блоге?
Обязательно, если статья уже была в поиске хоть какое-то время. Иначе вы получаете 404 на месте страницы, которая имела позиции, и теряете все ведущие на неё ссылки — как внешние, так и свои внутренние.

Показываю на экране, как выглядит проверка кодов ответа и чем отличается правильно настроенный переезд от неправильного:

2:29

Коротко

• Код 301 говорит поисковой системе «переехали навсегда» и переносит накопленные сигналы на новый адрес; код 302 говорит «временно» и не переносит ничего.
• Проверочный вопрос перед выбором один: планируете ли вы возвращать старый адрес. Нет или не знаю — ставится 301.
• Самая дорогая ошибка — 302 при переезде: посетители попадают куда надо, а в поиске остаётся старый адрес, и новый растёт с нуля.
• Цепочки длиннее одного шага, петли и переадресация на несуществующий адрес обесценивают правильно выбранный код.
• После настройки редиректов внутренние ссылки и карту сайта переписывают на конечные адреса, иначе каждый переход идёт лишним кругом.
• Проверяют не в браузере, а по кодам ответа: команда в консоли или вкладка «Сеть» показывают всю цепочку, браузер её скрывает.

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