Представьте: вы переехали в новую квартиру и оставили на старом адресе записку с новым. Любой, кто придет к вам — курьер, доставщик, почтальон — прочитает ее и отправится уже по правильному адресу. Редирект в веб-разработке работает ровно по такому же принципу.
Редирект — это механизм, при помощи которого сервер или браузер автоматически перенаправляет пользователя и поисковых роботов с одного URL-адреса на другой.
Когда браузер запрашивает страницу по адресу A, сервер отвечает: «Этой страницы здесь больше нет — ищи ее по адресу B». После этого браузер повторяет запрос уже к URL B и получает нужный контент. Для пользователя все происходит незаметно — он просто оказывается на нужной странице.
Если говорить конкретнее, то редирект — это HTTP-ответ сервера с кодом из диапазона 3xx и заголовком Location, в котором указан новый адрес. Именно код определяет, какого рода перенаправление происходит: постоянное или временное, с сохранением метода запроса или нет.
Зачем нужна классификация
Казалось бы, какая разница — один редирект или другой, главное, чтобы пользователь попал на нужную страницу. Но для поисковых систем разница огромная. От типа редиректа зависит:
- Сохранится ли ссылочный вес, накопленный старым URL.
- Какой из двух URL попадет в индекс — старый или новый.
- Как быстро робот обновит информацию о странице в своей базе.
- Не упадут ли позиции сайта после технических изменений — переезда на HTTPS, смены домена, реструктуризации разделов.
Одной из самых распространенных SEO-ошибок является неправильно настроенный редирект. Владелец сайта думает, что «просто переехал», а на деле за несколько месяцев теряет накопленный вес и позиции. Поэтому понимать разницу между типами перенаправлений и знать, как они влияют на индексацию, канонизацию и перенос сигналов, — необходимый минимум для любого, кто работает с сайтом.
Классификация редиректов
Редиректы принято классифицировать по трем характеристикам: по HTTP-статусу, по месту выполнения и по цели или длительности действия. Рассмотрим каждую группу подробно.
По HTTP-статусу
HTTP-статус — это трехзначный числовой код, который сервер возвращает в ответ на запрос браузера или робота. Коды из диапазона 3xx сигнализируют о перенаправлении. Хотя каждый код говорит о редиректе, он несет разный смысл и по-разному интерпретируется поисковыми системами.
301 Moved Permanently — постоянное перенаправление
Код 301 сообщает: «Страница переехала навсегда. Запомни новый адрес и больше не обращайся по старому». Браузер при последующих визитах будет сразу открывать новый URL из кэша, не обращаясь к старому. Поисковый робот постепенно заменит старый URL из индекса и заменит его новым, сохраняя при этом большую часть веса.
Пример настройки в .htaccess (Apache):
# Перенос одной страницы на другую
RewriteEngine On Redirect 301 /old-page/ /new-page/
# Перенос всего сайта с HTTP на HTTPS также является 301-редиректом, но прописывает иначе, чем редирект конкретных страниц
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Пример настройки в Nginx:
# Перенос одной страницы на другую на одном домене, также можно сделать редирект на страницу на другом домене, для этого нужно прописать полный адрес страницы, на которую будет проходить переадресация
server {
listen 80;
server_name example.com www.example.com;
location = /old-page/ {
return 301 /new-page/;
}
}# Перенос всего сайта на другой домен
server {
listen 80;
server_name old-site.com;
return 301 $scheme://new-site.com$request_uri;
}302 Found — временное перенаправление
Код 302 говорит: «Сейчас страница доступна по другому адресу, но это временно. Старый адрес остается актуальным». Браузер не кэширует такое перенаправление так же агрессивно, как 301-редирект. Поисковик сохраняет в индексе исходный URL и ссылочный вес остается за ним.
Раньше браузеры обрабатывали 302-редирект непоследовательно — часть из них меняла метод запроса с POST на GET, что не всегда было желательно. Именно поэтому позднее появились 307 и 303 редиректы.
Пример в .htaccess:
# Перенос одной страницы на другую
RewriteEngine On
Redirect 302 /old-page/ /new-page/Пример настройки в Nginx:
# Перенос одной страницы на другую на одном домене
location = /old-page/ {
return 302 /new-page/;
}# Временный редирект всего сайта
server {
listen 80;
server_name old-site.com;
return 302 http://new-site.com$request_uri;
}307 Temporary Redirect — временное перенаправление с сохранением метода
Код 307 — это «исправленный» вариант 302-редиректа. Ключевое отличие: браузер обязан повторить запрос к новому URL с тем же HTTP-методом, который использовался изначально. Если пользователь отправил форму методом POST, то и к новому адресу браузер обратится через POST — данные не потеряются. Это важно, если вы делаете переадресацию страницы с формой обратной связи или оформлением заказа.
Для поисковых систем 307-редирект означает временное перенаправление — вес и индексируемый URL остаются за исходным адресом.
Пример в .htaccess:
# Перенос одной страницы на другую на одном домене
RewriteEngine On
RewriteRule ^old-page/$ /new-page/ [R=307,L]Пример настройки в Nginx:
# Перенос одной страницы на другую на одном домене
location = /old-page/ {
return 307 /new-page/;
}308 Permanent Redirect — постоянное перенаправление с сохранением метода
Код 308 — это то же самое, что 301-редирект, но с обязательным сохранением HTTP-метода. Если исходный запрос был сделан через POST, то и к новому URL браузер обратится через POST. Используется реже, чем 301-редирект, но полезен для API и форм с загрузкой файлов.
Пример в .htaccess:
# Перенос одной страницы на другую на одном домене
lRewriteEngine On
RewriteRule ^old-page/$ /new-page/ [R=308,L]Пример в Nginx:
location /old-api-endpoint/ {
return 308 https://example.com/new-api-endpoint/;
}303 See Other — перенаправление после обработки
Код 303 отличается от остальных редиректов тем, что срабатывает уже после обработки данных страницы, для поисковых роботов он является табличкой с надписью: «Запрос обработан, теперь перейди по этому адресу и забери результат через GET». Он всегда переключает метод на GET, независимо от исходного метода запроса. Чаще всего применяется после отправки формы, чтобы предотвратить повторную отправку данных при обновлении страницы.
С точки зрения SEO 303-редирект практически не передает ссылочный вес и не используется для оптимизации.
Пример в .htaccess:
RewriteEngine On
RewriteRule ^page-form/$ /form-result/ [R=303,L]Пример в Nginx:
location = /page-form/ {
return 303 /form-result/;
}Сводная таблица кодов редиректов
Ниже представлено краткое сравнение всех рассмотренных кодов редиректов. Каждый из редиректов полезен в той или иной ситуации, но для того чтобы случайно не потерять свои позиции после их простановки, требуется знать, как они влияют на передачу веса и поведение поисковых систем.
По месту выполнения
Помимо HTTP-кода, редиректы различаются по тому, где именно они выполняются — на стороне сервера или на стороне клиента (браузера).
Серверные редиректы
Серверный редирект выполняется до того, как браузер получит какой-либо контент. Сервер принимает запрос, немедленно возвращает ответ с кодом 3xx и заголовком Location — и все. Никакого HTML, никакого контента в ответе нет. Браузер и робот мгновенно понимают: нужно идти по другому адресу.
Серверные редиректы реализуются:
- На уровне конфигурации веб-сервера — в .htaccess для Apache, в блоке server {} для Nginx.
- На уровне серверного скрипта — через header () в PHP, через redirect () в Python (Django/Flask), через res.redirect () в Node.js.
Для SEO это наиболее предпочтительный способ переадресации: поисковый робот мгновенно получает четкий сигнал о перенаправлении и правильно обрабатывает передачу веса.
Клиентские редиректы
Клиентский редирект выполняется уже после того, как браузер получил HTML-страницу. Сервер возвращает код 200 OK с обычной страницей, а инструкция о перенаправлении содержится в самом HTML или в JavaScript.
Существует два основных варианта:
1. Meta refresh — HTML-тег в блоке <head>, который дает браузеру команду перейти на другой URL через заданное время:
\
Значение content="0″ означает немедленный переход. Можно поставить задержку в секундах — например, content="5″ перенаправит через 5 секунд.
2. JavaScript-редирект — скрипт, который изменяет адрес страницы в браузере:
// Немедленный переход
window.location.replace("https://example.com/new-page/");
// Или через assign (оставляет запись в истории)
window.location.href = "https://example.com/new-page/";
Клиентские редиректы менее надежны для SEO: поисковые роботы могут не выполнить код JavaScript или обработать meta refresh с задержкой.
Ключевые различия между типами редиректов
Постоянные и временные: как реагируют браузеры и роботы
Разница между постоянным и временным редиректом кажется простой, но для сохранения своих позиций и трафика важно понимать все нюансы использования той или иной переадресации.
Браузер при 301-редиректе кэширует перенаправление и при следующем обращении к старому URL сразу открывает новый — без запроса к серверу. При 302 и 307 редиректе браузер каждый раз обращается к серверу, чтобы проверить, не изменилось ли направление.
Поисковые роботы реагируют еще более показательно:
- При 301 или 308 редиректе они понимают: старый URL больше не нужен. Со временем поисковая система заменяет его в индексе новым и переносит накопленный вес.
- При 302 или 307 редиректе они думают: «Старый URL актуален, просто сейчас контент временно на другом адресе». Индекс остается за исходной страницей и трафик на новую страницу может почти не приходить.
Именно поэтому важно использовать подходящий редирект. Вы можете использовать 302-редирект вместо 301 при постоянном переезде — но это будет серьезной ошибкой. Формально сайт будет работать, и пользователи попадут куда нужно, но поисковик продолжает считать актуальным старый URL, а новый может так и не получить весь накопленный вес и трафик.
Сохранение метода HTTP-запроса: чем 307-редирект отличается от 302, а 308 от 301
В HTTP-протоколе запросы отправляются разными методами. Самые распространенные — GET (получение страницы) и POST (отправка данных, например, формы).
Ключевая проблема кода 302-редиректа заключалась в непоследовательном поведении браузеров: многие из них при редиректе автоматически меняли метод POST на GET. Это было удобно в некоторых случаях, но приводило к потере данных формы в остальных.
Чтобы устранить двусмысленность, были введены коды 307 и 308 редирект:
- 302 — временный, метод может измениться на GET.
- 307 — временный, метод гарантированно сохраняется.
- 301 — постоянный, метод может измениться на GET.
- 308 — постоянный, метод гарантированно сохраняется.
Для обычных страниц сайта, где используется только GET, разница между 301 и 308-редиректом, а также между 302 и 307-редиректом, на практике незаметна. Но если на вашем сайте есть API или многошаговые формы с POST-запросами — то выбор правильного кода принципиально важен для сохранения корректной работы страницы и считывания поисковыми роботами.
Клиентские редиректы: meta refresh и JavaScript
Meta refresh: задержка и неоднозначное восприятие
Тег <meta http-equiv="refresh"> с нулевой задержкой Google обрабатывает примерно как 301-редирект — если контент на исходной и конечной странице совпадает. Однако это поведение не гарантировано и может отличаться от поисковой системы к поисковой системе.
Если задержка ненулевая (например, 5 или 10 секунд), ситуация становится еще менее предсказуемой:
- Пользователь видит исходную страницу в течение нескольких секунд перед переходом — это ухудшает UX.
- Поисковый робот может проиндексировать исходную страницу как самостоятельную, а не как редирект.
- Передача ссылочного веса значительно снижается или вовсе не происходит.
JavaScript-редиректы: менее предпочтительны для поисковых систем
JavaScript-редиректы — наименее предпочтительный способ с точки зрения SEO по нескольким причинам:
- Роботы могут не выполнить JavaScript. Googlebot, хотя и умеет рендерить JS, делает это в два этапа с задержкой. Яндекс намного хуже справляется с JavaScript-рендерингом.
- Время обнаружения нового URL увеличивается. Чем дольше робот «видит» старый URL без четкого серверного сигнала, тем медленнее обновляется индекс.
- Передача веса не гарантирована. Без явного HTTP-кода 3xx поисковик не получает стандартного сигнала о перенаправлении.
Для сохранения позиций и лучшей работы SEO лучше всегда использовать серверный редирект с нужным HTTP-кодом.
Принципы передачи веса (ссылочного, PageRank) роботам
Ссылочный вес — это условная «авторитетность» страницы, которую она набирает благодаря внешним и внутренним ссылкам. При перенаправлении вопрос состоит в том, перейдет ли этот вес к новому URL или останется за старым URL или, в худшем случае, потеряется совсем.
Передача веса для 301 и 308 редиректа
Редиректы 301 и 308 — наиболее эффективные с точки зрения передачи ссылочного веса.
По официальным данным Google, 301-редирект передает практически весь накопленный вес от старого URL к новому. Ранее существовало мнение, что теряется около 15% PageRank, но Google неоднократно заявлял, что при корректной реализации потери минимальны и со временем выравниваются.
Яндекс придерживается схожей позиции: постоянный редирект сигнализирует о смене адреса, после чего робот переносит ссылочный вес и постепенно выводит исходный URL из индекса.
Что происходит после 301 или 308 редиректа:
- Новый URL начинает получать вес от всех ссылок, которые раньше вели на старый URL.
- Старый URL со временем исчезает из поисковой выдачи.
- Позиции сайта при правильной настройке сохраняются или восстанавливаются в течение нескольких недель.
Передача веса для 302 и 307 редиректа
Временные редиректы совершенно иначе воспринимаются поисковыми роботами.
Логика поисковика такова: раз редирект временный, значит, исходная страница вернется. Поэтому:
- Ссылочный вес остается за исходным URL.
- Новый URL не накапливает вес от входящих ссылок на старый.
- Исходная страница продолжает существовать в индексе.
Если вы годами держите 302-редирект вместо 301 на постоянно переехавшей странице, новый URL так и не получит накопленный авторитет исходной страницы. Это одна из самых дорогостоящих SEO-ошибок в долгосрочной перспективе.
Передача веса для 303-редиректа и клиентских редиректов
Код 303-редиректа специфичен по своей природе — он предназначен для обработки форм, а не для управления SEO. Поисковики практически не интерпретируют его как сигнал для передачи веса. Страницы с 303-редиректом не следует использовать как SEO-инструмент.
Meta refresh (с нулевой задержкой) Google в ряде случаев обрабатывает аналогично 301-редиректу, однако это поведение задокументировано нечетко и не является стандартом. При ненулевой задержке — вес практически не передается.
JavaScript-редиректы — самый непредсказуемый сценарий. Передача веса зависит от того, выполнит ли робот скрипт, насколько быстро и правильно. Это ненадежно, и рассчитывать на полноценную передачу PageRank через JS-редирект не стоит.
Факторы, снижающие передачу веса
Даже при правильно настроенном 301-редиректе можно существенно снизить эффективность передачи веса. Вот основные «враги» ссылочного сока:
1. Цепочки редиректов
Если страница A ведет на B, B ведет на C, C ведет на D — это цепочка редиректов. Каждый дополнительный шаг в цепочке снижает передаваемый вес. Поисковый робот вынужден делать несколько запросов вместо одного, тратит ресурсы краулингового бюджета и с каждым переходом получает все более «разбавленный» вес.
Правило: одна страница — максимум один редирек
Если цепочка со временем все же образовалась — исправьте все промежуточные редиректы, чтобы каждый исходный URL вел сразу на финальный.
2. Кросс-доменные редиректы
Редирект с одного домена на другой (например, с old-domain.by на new-domain.by) обрабатывается поисковиками осторожнее. Google в целом передает вес при кросс-доменном 301-редирект, но процесс занимает больше времени. Яндекс более консервативен: смена домена может сопровождаться временным падением позиций, пока новый домен не «заработает» доверие.
3. Временные редиректы, оставленные на годы
Если 302-редирект стоит больше года — это серьезная проблема. Google в какой-то момент начинает обрабатывать «застрявший» 302-редирект как постоянный, но это поведение непоследовательно. Яндекс же может долго держать оба URL в индексе, создавая дублирование. Чтобы избежать потери позиций и веса, лучше не оставлять 302-редирект надолго.
Практические примеры: как не терять вес
Сейчас мы подробно разберем самые частые ошибки, которые допускают при настройке и расстановке редиректов: от выбора неверного кода ответа до создания цепочек, дублей и циклических перенаправлений.
Работа с цепочками редиректов
Цепочки редиректов возникают постепенно: сначала переехала страница A → B, потом B → C, потом C → D. Каждое изменение казалось логичным, но в сумме образовалась цепочка из трех переходов.
Что при этом происходит:
- Робот делает 3 HTTP-запроса вместо одного.
- Каждый переход «размывает» передаваемый вес.
- Скорость краулинга снижается, что особенно критично для крупных сайтов.
Как исправить ошибку:
Чтобы робот выполнял меньше запросов и вес не терялся, все промежуточные URL должны напрямую указывать на финальный адрес. Никаких промежуточных звеньев:
A → D; B → D; C → D
При таких переходах вес, собранный страницами, будет передаваться конечному адресу, если, конечно, настроен 301-редирект.
Как найти цепочки:
Мы рекомендуем использовать Screaming Frog SEO Spider или Sitebulb — они автоматически находят цепочки и петли редиректов при краулинге сайта.
Исправление дублей: www и без www, HTTP и HTTPS
Один из самых распространенных источников дублирования контента — когда сайт доступен по нескольким адресам одновременно:
- http://example.com и https://example.com
- https://example.com и https://www.example.com
Для поисковика это разные страницы с одинаковым контентом. Необходимо выбрать один канонический адрес и настроить редиректы со всех остальных.
Редирект с HTTP на HTTPS и с www на версию без www в .htaccess
RewriteEngine On
# Редирект с HTTP на HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ example.com/$ 1 [R=301,L]
# Редирект с www на без www (уже на HTTPS)
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ example.com/$ 1 [R=301,L]
Настройка в Nginx
# Блок для HTTP (перенаправляем все на HTTPS без www)
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}# Блок для HTTPS с www (перенаправляем на версию без www)
server {
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}Важный момент: выберите одну каноническую версию и придерживайтесь ее всегда и везде — в sitemap.xml, в тегах canonical, во внутренних ссылках. Несогласованность запутывает поисковых роботов даже при правильно настроенных редиректах.
Сводная таблица практических сценариев
Ниже представлена подборка наиболее частых ситуаций с рекомендуемым типом редиректа. Используйте ее как шпаргалку при работе с сайтом.
Оставьте заявку на консультацию Qmedia — разберем ваш сайт, найдем технические ошибки и подскажем, как усилить SEO без риска для текущих результатов.
3
Комментарии