Редиректы при переносе страниц: как выбирать между 301, 302, 307 и 308

Редирект нужен не потому, что старый URL «плохой», а потому, что запрос к одному адресу должен продолжиться по другому. Для постоянного переноса веб-страницы обычно используют 301 или 308; для временного — 302 или 307. Между этими парами есть ещё одна техническая граница: 307 и 308 однозначно сохраняют HTTP-метод при автоматическом переходе, тогда как историческое поведение 301 и 302 допускает смену POST на GET.Но выбрать номер ответа — только половина задачи. При реальном переносе нужно решить, какой старый URL соответствует какому новому, проверить конечный статус, убрать лишние цепочки, обновить внутренние ссылки и не создавать конфликт между redirect и canonical. Иначе формально рабочий редирект превращается в источник новой неоднозначности.

Редирект — это отдельный HTTP-ответ

Когда сервер отвечает 3xx и передаёт новый адрес в заголовке Location, клиент получает не новую страницу, а инструкцию продолжить запрос по другому URI. Следующий запрос — отдельное действие.

GET /old-page
→ HTTP/1.1 301 Moved Permanently
Location: /new-page

GET /new-page
→ HTTP/1.1 200 OK
Content-Type: text/html

Поэтому полезно различать три объекта: исходный URL, redirect response и конечный ресурс. Браузер может скрыть эту механику и сразу показать финальную страницу, но для диагностики промежуточный ответ никуда не исчезает.

Если нужно сначала разобраться, чем вообще отличаются классы 2xx, 3xx, 4xx и 5xx, это разобрано в статье «HTTP-коды веб-страницы».

301 и 308: когда новый URL должен стать постоянным адресом

301 Moved Permanently сообщает, что целевой ресурс получил новый постоянный URI. 308 Permanent Redirect решает ту же задачу переноса, но запрещает автоматическому клиенту менять метод запроса при переходе.

Для обычной HTML-страницы, открываемой через GET, эта разница часто не видна пользователю. Но для endpoint, формы или другого сценария с POST она может быть принципиальной.

Код	Постоянный?	Можно ли при автоматическом переходе сменить POST на GET?	Типичный сценарий
`301`	Да	Да, исторически это допускается	Обычный постоянный перенос страницы
`308`	Да	Нет	Постоянный перенос с сохранением метода

Google Search рассматривает 301 и 308 как постоянные server-side redirects. Такой переход используется как сильный сигнал в пользу того, чтобы целевой URL стал canonical. Это не означает, что один редирект отменяет все остальные сигналы сайта, но направление для поисковой системы становится вполне определённым.

302 и 307: когда перенос действительно временный

302 Found сообщает, что ресурс временно доступен по другому URI. 307 Temporary Redirect сохраняет ту же временную семантику, но, в отличие от 302, не разрешает менять HTTP-метод при автоматическом переходе.

Код	Постоянный?	Метод сохраняется обязательно?	Когда подходит
`302`	Нет	Нет	Временная переадресация обычной веб-страницы
`307`	Нет	Да	Временный перенос, где важен исходный HTTP-метод

Для Google временный redirect не является тем же canonical-сигналом, что permanent redirect. По документации Search Central, при временном перенаправлении Googlebot следует к цели, но indexing pipeline не использует сам redirect как сигнал о том, что target должен заменить source в роли canonical.

Это одна из причин не ставить 302 «на всякий случай», если перенос на самом деле окончательный. Код должен описывать реальное состояние URL, а не служить универсальным безопасным вариантом.

Почему существуют четыре похожих кода

Если свести различия к двум вопросам, система становится гораздо понятнее:

Перенос постоянный или временный?
Нужно ли гарантированно сохранить HTTP-метод?

	Постоянный	Временный
Допускается историческая смена POST → GET	`301`	`302`
Метод должен сохраниться	`308`	`307`

Эта схема следует не из SEO-практики, а из HTTP semantics. RFC 9110 отдельно объясняет, что 307 и 308 появились для однозначного сохранения метода, потому что реальное браузерное поведение вокруг 301 и 302 исторически сложилось иначе.

303 See Other решает другую задачу

303 See Other тоже относится к redirect response, но его полезно не смешивать с обычным переносом веб-страницы. Этот код сообщает, что результат операции можно получить по другому URI с помощью GET.

Классический пример — обработка формы: клиент отправляет POST, сервер завершает операцию и отправляет пользователя на отдельную страницу результата. Здесь мы не говорим, что исходный ресурс «переехал» навсегда или временно. Мы направляем клиента к другому представлению результата.

Для миграции обычного информационного URL выбор чаще остаётся между четырьмя кодами из основной матрицы: 301, 302, 307, 308.

Сначала составьте соответствие old URL → new URL

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

Надёжнее до настройки redirect rules составить карту:

Старый URL	Новый URL	Тип изменения	Ожидаемый ответ
`/catalog/item-a/`	`/products/item-a/`	Постоянный перенос	`301` или `308`
`/summer/`	`/promo/`	Временная кампания	`302` или `307`
`/old-service/`	Нет релевантной замены	Удаление	Не придумывать искусственный redirect

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

Цепочка редиректов — это несколько запросов вместо одного

Технически браузер и crawler могут пройти через несколько промежуточных адресов:

/page-a
→ 301 /page-b
→ 301 /page-c
→ 301 /page-d
→ 200

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

Googlebot способен пройти до 10 hops в redirect chain, однако в руководстве по миграциям Google советует перенаправлять сразу на конечный URL. Если это невозможно, цепочку рекомендуют держать короткой: в идеале не больше трёх переходов и меньше пяти.

Предел crawler не стоит воспринимать как проектную норму. Хорошая цель для большинства миграций проще: старый URL → конечный новый URL.

Цикл редиректов — уже не маршрут, а ошибка

Цепочка хотя бы когда-нибудь заканчивается. Цикл — нет:

/a → 301 /b
/b → 301 /a

Или более неприятный вариант:

http://example.com/page
→ https://example.com/page
→ https://www.example.com/page
→ http://example.com/page

Такие ошибки часто появляются не в одном конфигурационном файле, а на стыке нескольких слоёв: приложение меняет trailing slash, CDN принудительно переводит на HTTPS, веб-сервер добавляет www, а CMS возвращает собственную версию адреса.

Поэтому проверять стоит не отдельное redirect rule, а фактическую цепочку снаружи системы.

После переноса внутренние ссылки должны вести сразу на новый URL

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

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

Google в руководстве по site move отдельно рекомендует обновлять внутренние ссылки и использовать новые URL в sitemap. Здесь логика практическая: новый адрес должен стать реальным рабочим адресом внутри системы, а не только конечной точкой server rule.

Redirect и canonical не должны спорить между собой

Постоянный redirect и rel="canonical" — разные механизмы, но оба участвуют в canonicalization. Google относит redirects и canonical annotations к сильным сигналам выбора canonical URL.

Поэтому конфигурация вроде этой выглядит противоречиво:

/old-page → 301 → /new-page

на /new-page:
rel="canonical" href="/old-page"

Сервер говорит: «старый URL постоянно переехал на новый». Новый документ одновременно говорит: «предпочтительная версия — старый URL». Отдельные механизмы работают, но направление у них разное.

После миграции canonical стоит проверять вместе с redirect map. Разбор того, как Google выбирает основную версию среди похожих URL и какие сигналы могут конфликтовать, будет в статье про canonical URL и дубли страниц.

Не путайте redirect с canonical

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

rel="canonical" работает иначе. Страница продолжает открываться по своему адресу, а поисковой системе передаётся предпочтение по основной версии среди дублей или очень похожих документов.

Если старый URL действительно больше не должен использоваться, постоянный server-side redirect обычно описывает ситуацию точнее. Если оба URL должны существовать, сначала нужно понять, есть ли вообще задача canonicalization, а не автоматически «лечить дубль» перенаправлением.

Что проверить после включения редиректов

Проверка миграции полезнее, если идти от фактического ответа, а не от настроек в CMS.

Исходный URL. Возвращает ли он тот код, который был запланирован?
Location. Ведёт ли он на правильный адрес, а не на соседнюю категорию или главную?
Цепочка. Есть ли ненужные промежуточные hops?
Финальный ответ. Получаем ли ожидаемый 200 OK или другое осознанное состояние?
Canonical. Указывает ли новая страница на актуальную версию?
Внутренние ссылки. Использует ли сайт новые URL напрямую?
Sitemap. Убраны ли старые адреса после постоянного переноса?
Redirect loops. Нет ли циклов между протоколами, хостами, slash-правилами или CMS?

На большой миграции такую проверку удобнее автоматизировать списком URL и сохранять не только первый статус, но всю цепочку. Тогда ошибка вида 301 → 302 → 404 не маскируется красивым правилом в конфигурации.

Короткая матрица выбора редиректа

Ситуация	Решение	Почему
Страница навсегда переехала	`301`	Постоянный server-side redirect для обычного GET-сценария
Постоянный перенос, метод должен сохраниться	`308`	Permanent redirect без смены метода
Переадресация временная	`302`	Source URL остаётся исходным адресом сценария
Временный перенос с сохранением метода	`307`	Temporary redirect без смены метода
Результат POST нужно показать через GET на другом URL	`303`	Это другой тип перенаправления, не обычный перенос ресурса
Страница удалена, релевантной замены нет	Не создавать нерелевантный redirect	Перенаправление должно вести к реальной замене, а не скрывать отсутствие ресурса

Если сомнение остаётся между permanent и temporary, вопрос стоит сформулировать не как «какой код лучше для SEO», а как «должен ли исходный URL оставаться адресом этого ресурса в будущем». Обычно после этого выбор становится заметно проще.

Источники

Источники проверены 19 августа 2026 года. Семантика HTTP сверена со стандартами IETF; рекомендации по обработке миграций — с документацией Google Search Central.