Редиректы 301, 302, 307, 308: что выбрать и где можно потерять SEO

Чем отличается постоянный редирект от временного, почему 307 не равно 302 и что делать, если цепочка редиректов незаметно съедает скорость и позиции в поиске

Как магазин потерял четверть трафика из-за одной цифры в конфиге

Зима 2025 года. Интернет-магазин товаров для дома мигрирует с HTTP на HTTPS — стандартная плановая операция. Разработчик добавляет в конфиг Nginx правило: при заходе по http:// шли на https://. Сертификат настроен, сайт работает, всё в порядке.

Через полгода маркетолог открывает Яндекс.Метрику и видит, что органический трафик упал на 25%. Сервер исправен, скорость нормальная, отказов нет. Зато в Google Search Console — десятки тысяч страниц со статусом «Просканирована, не проиндексирована». Аудит показал: в выдаче параллельно болтаются и http-версии, и https-версии одних и тех же страниц. Они каннибализируют друг друга, и позиции по средне- и низкочастотным запросам обрушились.

Причина обнаружилась в одной строчке конфига: разработчик написал return 302 вместо return 301

. Одна цифра — разница между «временным» и «постоянным» редиректом. Google полгода не считал переход окончательным и продолжал держать в индексе старые URL.

Поправили на 301 — через три недели позиции начали возвращаться, через два месяца трафик восстановился. Урок дорогой: выбор HTTP-кода редиректа — не косметика, а решение, влияющее на бизнес.

Что такое HTTP-редирект

HTTP-редирект — это способ сказать клиенту: «то, что ты ищешь, теперь живёт по другому адресу, иди туда». Сервер вместо обычного 200-ответа отдаёт код из семейства 3xx и заголовок Location

, в котором указан новый URL.

Например, при заходе на http://example.ru

сервер может ответить так:

HTTP/1.1 301 Moved Permanently
Location: https://example.ru/
Content-Length: 0

Браузер видит код 301 и заголовок Location, и автоматически отправляет новый запрос на https://example.ru/

. Для пользователя это происходит незаметно — он только видит, что в адресной строке поменялся URL.

Семейство 3xx состоит из пяти основных кодов: 301, 302, 303, 307, 308. На вид они похожи, на деле различия принципиальны — от них зависит SEO, кэширование и даже то, как пройдёт ваш API-запрос.

Все редиректы в одной таблице

Два ключевых параметра: постоянный/временный (влияет на SEO и кэширование) и сохранение метода (важно для POST/PUT/DELETE). Дальше — что это значит на практике.

301 Moved Permanently — рабочая лошадка миграций

301 говорит браузеру и поисковику: «это навсегда, забудь старый URL». Это самый важный редирект из всех — именно через него:

• мигрируют с HTTP на HTTPS
• переезжают на новый домен (rebranding)
• меняют URL-структуру (новая CMS, новые ЧПУ)
• сливают www.example.ru и example.ru

  в одну каноническую версию

• убирают дубли страниц

Браузеры агрессивно кэшируют 301 — до года, иногда дольше. Если вы поставили 301 со /old-url на /new-url

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

Из-за этого 301 нельзя использовать для временных вещей: для A/B-тестов, обслуживания, баннеров. Только для того, что вы готовы держать годами.

Грабли с кэшированием 301

Если вы случайно отдали 301 на свой собственный сайт (например, на главную), пользователи могут не смочь зайти даже после исправления — их браузеры будут редиректить локально. Лечится только очисткой кэша браузера или сменой URL. Поэтому 301 ставится только после ручной проверки.

302 Found — временный, использовать с пониманием

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

Когда уместен 302:

• технический режим обслуживания (на пару часов перенаправить всех на «идут работы»)
• A/B-тестирование (часть пользователей видит вариант B)
• временная замена страницы (товар временно недоступен)
• логин-флоу старого образца (но лучше использовать 303)

С SEO у 302 история сложная. Формально вес не передаётся — Google и Яндекс продолжают индексировать старый URL. Но если 302-редирект висит много месяцев, поисковики постепенно начинают интерпретировать его как 301 — правда, никто точно не знает, через сколько и в каком объёме. Полагаться на это не стоит.

Главное правило: 302 для миграций — ошибка. Именно эту ошибку сделал магазин из истории в начале статьи.

303 See Other — для форм и POST-запросов

303 — узкоспециализированный код, у него ровно одно применение: после POST-запроса перенаправить на страницу с результатом.

Классическая схема: пользователь заполняет форму заказа, нажимает «Оформить», браузер шлёт POST. Сервер обрабатывает данные и отвечает 303 с Location на страницу подтверждения. Браузер автоматически переключается с POST на GET и открывает страницу подтверждения.

Это нужно, чтобы избежать классической проблемы: пользователь нажал F5 на странице подтверждения и случайно повторил заказ. С 303 этого не происходит — страница подтверждения открыта через GET, F5 просто перезагружает её.

На практике многие используют 302 вместо 303 — современные браузеры ведут себя одинаково. Но 303 — правильный и формально корректный выбор.

307 и 308 — современные, сохраняют HTTP-метод

Это самые молодые коды семейства, появились для решения одной конкретной проблемы: 301, 302 и 303 при перенаправлении меняют POST на GET. Это историческое поведение времён HTTP/1.0, и оно ломает API-вызовы.

Представьте: ваше приложение делает POST /api/orders с JSON-телом. Сервер отвечает 301 с Location на /api/v2/orders

. Браузер (или клиент) преобразует POST в GET, теряет тело запроса и идёт на новый URL. Заказ не создаётся, клиент в шоке.

307 и 308 решают эту проблему: они сохраняют исходный метод и тело запроса. POST остаётся POST, тело сохраняется, API работает корректно.

• 307 Temporary Redirect — временный, как 302, но с сохранением метода
• 308 Permanent Redirect — постоянный, как 301, но с сохранением метода

В современных API-маршрутизациях и микросервисах 307/308 — единственно правильный выбор. Если редиректите версионированный API или поддомен с POST-эндпоинтами — используйте 307 для временных и 308 для постоянных переносов. Не 302 и не 301 — они сломают POST.

Редиректы без HTTP: meta refresh и JavaScript

Кроме HTTP-кодов 3xx, есть ещё два способа перенаправить пользователя — и оба создают больше проблем, чем решают.

Meta refresh — HTML-тег внутри страницы:

<meta http-equiv="refresh" c"0; url=https://new.example.ru/">

Браузер открывает текущую страницу, потом перенаправляет. Для пользователя это выглядит как короткая вспышка пустой страницы. Для поисковика — неопределённость: Google формально воспринимает meta refresh с задержкой 0 как 301, но с задержкой больше 0 — уже как 302. Использовать только если других вариантов нет.

JavaScript-редирект:

window.location.replace("https://new.example.ru/");

Работает только если у пользователя включён JS. Поисковики выполняют JS неравномерно: Google — обычно да, Яндекс — не всегда, маленькие краулеры (от агрегаторов, мониторингов, читалок) — нет. SEO-вес через JS-редирект передаётся непредсказуемо.

Правило простое: любой редирект, который можно сделать через HTTP, делайте через HTTP. Meta refresh и JS — крайние меры, когда нет доступа к серверной конфигурации.

SEO: где передаётся вес, а где теряется

Главный SEO-вопрос: сколько ссылочного веса переходит на новый URL после редиректа. Если у старой страницы было 100 единиц авторитета, сколько получит новая?

По состоянию на 2026 год картина примерно такая:

• 301 и 308 — передают практически весь вес. Google официально с 2016 года говорит, что «передаётся полностью», но на практике потери в 5-15% часто наблюдаются (диалюция при каждом дополнительном прыжке).
• 302 и 307 — формально не передают, фактически Google со временем интерпретирует длительный 302 как 301. Зависнет на 302 на пару дней — ничего страшного. Зависнет на год — начнёт работать.
• 303 — вес не передаётся, страница назначения не индексируется по запросам, ведущим на старый URL.
• Meta refresh с задержкой 0 — примерно как 301.
• JS-редирект — непредсказуемо. Google обычно понимает, но Яндекс может не понять.

Дополнительные нюансы:

• Цепочки редиректов теряют вес на каждом прыжке. A → B → C передаст в C меньше, чем прямой A → C

  . Сократите цепочки до одного прыжка.

• Длинные цепочки (4+ прыжка) Google может вообще не дойти до конца и не проиндексировать целевую страницу.
• Петли (A → B → A) убивают SEO напрочь — Google помечает страницу как сломанную.
• Канонический тег (<link rel="canonical">

  ) часто решает задачу лучше редиректа — например, когда нужно склеить варианты с UTM-параметрами.

Какой код выбрать: шпаргалка по сценариям

Шесть граблей, на которые наступают чаще всего

1. 302 вместо 301 при миграции

Та самая ошибка из истории в начале статьи. Кажется незначительной, но через несколько месяцев приходит счёт в виде минус 20-30% органического трафика. Лечится переключением на 301 и ожиданием 2-6 недель на переиндексацию.

2. Бесконечная петля HTTP ↔ HTTPS

Класcическая ошибка при настройке за прокси (Cloudflare, балансировщик). Прокси терминирует HTTPS и шлёт на сервер обычный HTTP. Сервер видит HTTP и редиректит на HTTPS. Прокси снова терминирует, снова HTTP, снова редирект. Браузер получает ERR_TOO_MANY_REDIRECTS

.

Лечится правильной настройкой X-Forwarded-Proto

и условием в Nginx/Apache: редиректить только если запрос реально по HTTP, а не из-за header'а от прокси.

3. Цепочка из 4+ редиректов

Часто возникает естественно: домен переехал с http://old.com на https://www.new.com, потом убрали www, потом сделали ЧПУ. Каждый этап — 301, и они складываются:

http://old.com/p?id=42
→ 301 https://old.com/p?id=42
→ 301 https://www.new.com/p?id=42
→ 301 https://new.com/p?id=42
→ 301 https://new.com/products/42-vacuum-cleaner

Четыре прыжка, и каждый добавляет 50–200 мс к загрузке + теряет немного веса. Решение: пройтись по правилам и собрать прямые редиректы со старых URL на финальные, минуя промежуточные.

4. 301 при A/B-тесте или короткой акции

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

5. Redirect на POST-эндпоинт с 301 или 302

API-вызов POST /api/orders получает 301 на /api/v2/orders

. Браузер или библиотека преобразует POST в GET, тело запроса теряется, заказ не создаётся. Иногда возвращается 405 Method Not Allowed, иногда — молча 200 без эффекта.

Решение: для POST/PUT/DELETE-эндпоинтов используйте только 307 или 308.

6. Mixed content после миграции на HTTPS

301 редирект на HTTPS работает, но внутри страниц остались абсолютные ссылки на http://… для картинок, CSS и JS. Браузер показывает страницу как «Не полностью защищено», замок зачёркнут, часть ресурсов вообще не грузится.

Лечится поиском по коду на src="http:// и href="http:// и заменой на относительные или //

-префиксные URL.

Как проверить редиректы вручную

Самый быстрый и точный способ — через curl с флагом -I (только заголовки) и -L

(следовать по редиректам):

curl -ILs http://example.ru | grep -E "^HTTP|^Location"

Получите цепочку всех редиректов вплоть до финального ответа 200. Если в выводе появилось больше одного HTTP/… 301 или 302

— у вас цепочка, и её стоит сократить.

В браузере: открыть DevTools → Network → зайти на старый URL → посмотреть последовательность запросов. Каждая 3xx-строка — один прыжок.

Онлайн-инструменты типа httpstatus.io или redirect-checker.org показывают цепочку в удобном виде, если терминала под рукой нет.

Как мониторить редиректы автоматически

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

В Пруфене проверка Доступность (HEAD) стоит 0,01 ₽ за запуск и автоматически отслеживает поведение редиректов:

• Финальный статус-код — если ожидаете 200, но получаете 301 или 302, это сигнал о том, что что-то изменилось
• Длина цепочки редиректов — алерт, если внезапно появился лишний прыжок
• Целевой URL финального редиректа — если редирект внезапно ведёт не туда, куда должен (например, на чужой домен после взлома)
• Время суммарной загрузки — цепочки редиректов увеличивают TTFB, и метрика производительности это поймает

Связка HEAD-проверка + проверка контента по финальному URL закрывает почти все сценарии: страница доступна, отвечает 200, контент на месте, и количество редиректов на пути не выросло.

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

• ☑ Все редиректы для миграции — 301 (не 302)
• ☑ Все редиректы для временных вещей — 302 или 307
• ☑ Все редиректы POST-эндпоинтов — 307 или 308
• ☑ Нет петель: curl -ILs ваш-сайт.ru

  завершается с 200

• ☑ Цепочки сокращены до одного прыжка (старый URL → финальный)
• ☑ Sitemap.xml содержит финальные URL, а не редиректящиеся
• ☑ Внутренние ссылки на сайте указывают на финальные URL, а не на старые
• ☑ В robots.txt

  Sitemap указан на финальный домен

• ☑ Mixed content проверен после HTTPS-миграции
• ☑ Настроен мониторинг финального статуса и цепочки

Итого

Редиректы — не косметика, а часть инфраструктуры, от которой зависят и SEO, и скорость, и работа API. Главное, что стоит запомнить:

• 301 — постоянный, для миграций. Кэшируется надолго.
• 302 — временный, для коротких задач.
• 303 — после POST-формы на страницу подтверждения.
• 307 и 308 — временный и постоянный с сохранением метода. Для API.

И помните: 302 при миграции стоит реального трафика и реальных денег. Одна цифра в конфиге — одна четверть органики. Проверяйте код, проверяйте цепочку, проверяйте регулярно.