302 — это временное перенаправление. Исходный URL остаётся актуальным, а редирект ведёт пользователя на другой адрес только на время.
Что такое 302 и когда его использовать разобрали в отдельной статье. Здесь разберём именно практику: как сделать правило, где его задать и как потом проверить редирект.
Чаще всего 302 редирект нужен там, где адрес меняется временно. Это может быть тест, техработы, временная страница или служебный экран. В таких случаях важно не вдаваться в теоретические дискуссии, а быстро сделать редирект, проверить ответ сервера и убедиться, что правило работает как надо.
Ниже разберём сервер, .htaccess и код приложения. Отдельно посмотрим, как проверить редирект в браузере и через командную строку. Ещё будут типичные сценарии, где такой редирект действительно уместен.
Как сделать 302 редирект на уровне сервера
Самый простой способ — сделать редирект в конфиге сервера. В Nginx для этого задают правило с кодом 302. В Apache делают похожее правило через стандартную директиву перенаправления или через модуль правил. Синтаксис разный, но логика одна: сервер получает запрос, отдаёт временный ответ и указывает новый адрес.
Такой редирект удобно настраивать, когда правило не зависит от данных пользователя. Например, одна страница временно уходит на другую, раздел временно ведёт на заглушку, а старый адрес акции на время переводит трафик на новый адрес. В таких случаях серверный редирект проще держать в одном месте и проще потом убрать.
После правки конфига сначала проверьте сам файл, потом перезагрузите сервер и только после этого делайте проверку в браузере. Если пропустить этот шаг, можно решить, что редирект сломан, хотя на деле сервер просто не принял новый конфиг. Поэтому порядок тут простой: правка, проверка, перезагрузка, тест.
Ещё один важный момент: не стоит делать слишком длинную цепочку перенаправлений. Один redirect — нормально, два — уже хуже. Если страница идёт через несколько адресов подряд, пользователь теряет время, а проверка становится сложнее.
Настройка 302 редиректа через .htaccess: пример
.htaccess — это файл для локальной настройки правил в каталоге. Такой способ часто используют там, где веб-сайт размещён на shared-хостинге и доступа к главному конфигу сервера нет. Через .htaccess можно сделать простой редирект для одного адреса или более гибкое правило для группы адресов.
Если задача простая, обычно хватает прямого правила перенаправления. Такой формат удобен, когда одна страница временно ведёт на другую страницу без дополнительных условий. Если логика сложнее и надо учитывать шаблон адреса, часть URL или несколько похожих путей, тогда уже берут правило на основе модуля rewrite. Но для читателя логика всё равно одна: вы задаёте старый адрес, новый адрес и код ответа.
Простой пример: страница старой акции временно ведёт на новую страницу акции. Или каталог временно ведёт на служебную страницу. Если код не указан явно, Apache может по умолчанию отдавать временный ответ. Но лучше не надеяться на значение по умолчанию и сразу прописать код. Так проще читать правило, проще делать проверку и проще искать ошибку, если редирект сработал не так.
Один 302 настроить несложно, но на живом сайте редиректы копятся: появляются лишние цепочки, неверные коды и битые переходы, которые мешают индексации. ПО Shadow выявляет проблемные редиректы, анализирует структуру URL и проверяет ошибки индексации — и даёт данные, на основе которых настраиваются редиректы, canonical и устраняются технические ошибки сайта.
302 редирект страницы через код: HTTP—заголовок Location
Иногда редирект удобнее сделать не в конфиге сервера, а в коде приложения. Это нужно тогда, когда переход зависит от условий. Например, пользователь вошёл в аккаунт, система видит регион, идёт A/B-тест или часть трафика надо временно перевести на другую страницу. В этом случае приложение само формирует ответ 302 и передаёт заголовок Location с новым адресом.
Такой редирект часто используют в PHP, Python и Node.js. Подход везде один: код получает запрос, проверяет условие и отдаёт редирект на нужный URL. Здесь важно не усложнять логику. Один сценарий — одно правило. Тогда редирект проще читать, проще менять и проще проверять после релиза.
Если условий слишком много, правило быстро становится запутанным. Поэтому лучше заранее решить, где именно должен жить редирект: в коде, в сервере или в прокси. Когда это решение принято, настройка идёт быстрее, а итоговый редирект работает стабильнее.
302 редирект домена и HTTPS: когда он подходит, а когда нужен 301
Первый сценарий — техработы. Основная страница или раздел временно недоступны, и редирект ведёт пользователя на служебную страницу с пояснением. После работ правило убирают, а старый адрес снова начинает работать как раньше. Это самый понятный и самый частый пример.
Второй сценарий — A/B-тест. Часть пользователей временно уходит на новый вариант страницы. Такой редирект помогает проверить гипотезу без полной смены структуры. Когда тест завершён, временный редирект отключают. Это важно: тест закончился — правило убрали.
Третий сценарий — геотаргетинг. Пользователь приходит на общий домен, а система временно ведёт его на нужную страницу по региону. Но для постоянного перевода с http на https и для постоянного выбора основного домена такой вариант не подходит. Там нужен 301. Эту точку лучше сразу держать в уме, чтобы временный редирект не превратился в постоянную схему.
Как проверить, что 302 редирект настроен правильно
Первый способ — DevTools в браузере. Откройте вкладку Network, обновите адрес и посмотрите первый ответ сервера. Правильный редирект должен показать статус 302 и заголовок Location. Если вместо этого вы видите код 200, значит страница просто открылась без временного перехода.
Второй способ — команда «curl» с выводом заголовков. Такая проверка удобна тем, что вы сразу видите ответ сервера без влияния интерфейса. Это хороший способ быстро понять, какой код отдаёт сервер, куда ведёт редирект и нет ли лишнего шага в цепочке.
Что надо проверить в любом случае: статус 302, правильный адрес в Location, отсутствие длинной цепочки редиректов и корректный конечный URL.
Учтите, что 302, в отличие от 301, браузер обычно не кэширует: при каждом заходе он заново обращается к серверу, поэтому исправленный редирект применяется сразу. Если правило всё равно ведёт себя странно, причину стоит искать в конфиге, цепочке редиректов или прокси — застрявший в кэше редирект характерен именно для 301





