Редиректы 301 и 302: когда цепочка переадресаций убивает ранжирование

Введение

Редиректы 301 и 302 — это HTTP-коды ответа сервера, которые указывают браузеру и поисковому роботу, куда перенаправить запрос с одного URL на другой: 301 означает постоянное перемещение, 302 — временное.

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

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

Отдельная история — цепочки переадресаций. Когда один редирект ведёт на второй, второй на третий, а тот на четвёртый, каждый дополнительный шаг увеличивает нагрузку на бюджет обхода (краулинговый бюджет) сайта. Яндекс.Бот тратит ресурсы на прохождение каждого звена цепочки — и в какой-то момент просто перестаёт её проходить до конца, оставляя конечные страницы без переобхода.

Чтобы разобраться, почему именно это происходит и как это работает на уровне HTTP-протокола, нужно сначала понять механику самих кодов.

Что такое редиректы seo

Редирект — это HTTP-ответ сервера, который сообщает браузеру и поисковому роботу: «запрошенный адрес больше не здесь, иди по другому URL». Технически это трёхзначный код состояния в заголовке ответа: 301, 302, 307, 308 и другие. Для SEO принципиальны первые два — они определяют, как поисковая система трактует переезд страницы и что происходит со ссылочным весом (link juice) и позициями.

Разница между кодами — не техническая формальность, а сигнал о намерениях владельца сайта. Код 301 означает постоянное перемещение: поисковый робот фиксирует, что старый URL прекратил существование, переносит накопленный ссылочный вес на новый адрес и со временем исключает старый из индекса. Код 302 означает временное перемещение: робот сохраняет исходный URL как основной, не переносит вес и ожидает, что старый адрес вернётся. Использовать 302 там, где нужен 301 — одна из классических ошибок, после которой ссылочный вес «зависает» на адресе, которого уже нет.

Механика на уровне HTTP-протокола выглядит так: браузер запрашивает страницу A, сервер отвечает кодом 3xx и передаёт в заголовке Location адрес страницы B. Браузер автоматически переходит по новому адресу — пользователь этого не замечает. Поисковый робот делает то же самое, но дополнительно интерпретирует код: при 301 обновляет внутренние таблицы индекса, при 302 — нет. Именно поэтому неправильный код редиректа не ломает сайт для пользователя, но незаметно подрывает SEO-продвижение на протяжении недель и месяцев.

Редиректы появились как инструмент управления URL-пространством сайта ещё в первых версиях HTTP-протокола. Исторически их использовали для трёх задач: переезд домена, реструктуризация разделов, склейка дублей (www и без www, http и https). С ростом сложности сайтов добавились новые сценарии — переезд на новый CMS, объединение нескольких сайтов, A/B-тестирование посадочных страниц. Каждый из этих сценариев требует своего кода и своей логики настройки Google Search Central — Redirects and Google Search.

Отдельная история — цепочки редиректов. Это ситуация, когда страница A ведёт на B, B ведёт на C, C ведёт на D. Каждый шаг цепочки — отдельный HTTP-запрос. Индексирующий робот Яндекса тратит на каждый запрос часть бюджета обхода (краулингового бюджета). Допустим, интернет-магазин с пятью тысячами товарных карточек накопил цепочки из трёх-четырёх редиректов после нескольких переездов и смен CMS. Итог: робот обходит меньше страниц за сессию, часть карточек выпадает из регулярного переобхода, актуализация цен и остатков в индексе запаздывает. Проблема не в самом факте редиректа, а в его количестве на пути к целевому URL.

Как это работает

Редирект — это HTTP-ответ с кодом состояния, который браузер и поисковый робот получают вместо запрошенной страницы. Сервер возвращает заголовок Location с новым адресом и числовым кодом, который определяет дальнейшее поведение клиента. Браузер автоматически переходит по новому адресу, пользователь этого не замечает. Поисковый робот — замечает и реагирует по-разному в зависимости от кода.

Код 301 сообщает: «этот URL переехал навсегда». Поисковый робот фиксирует новый адрес, переносит на него накопленный ссылочный вес (link juice) исходной страницы и постепенно заменяет старый URL в индексе. Код 302 говорит другое: «переезд временный, исходный адрес актуален». Робот сохраняет старый URL в индексе и не переносит на него ссылочный вес с нового адреса — потому что с точки зрения поисковика страница ещё вернётся.

Именно здесь кроется первая практическая ловушка. Когда 302 используют вместо 301 при постоянном переезде — Яндекс.Бот продолжает обходить и индексировать старый URL, а новый остаётся без ссылочного веса. Позиции не переносятся. Страница фактически переехала, но поисковик об этом не знает Google Search Central — redirects.

Цепочки редиректов — отдельная история. Цепочка возникает, когда URL A ведёт на URL B, который ведёт на URL C, а иногда и на D. Технически браузер пройдёт весь путь и покажет пользователю финальную страницу. Поисковый робот тоже дойдёт до конца — но каждый дополнительный шаг стоит ресурсов бюджета обхода. Яндекс.Бот тратит лимит запросов к сайту, и если сайт большой, а цепочки длинные — робот просто не успевает обойти все важные страницы за один визит.

Конкретный сценарий: интернет-магазин с несколькими тысячами карточек товаров провёл редизайн и сменил структуру URL. Разработчики настроили 301 с /catalog/product-123 на /products/product-123. Спустя полгода провели ещё одну миграцию — и добавили редирект с /products/product-123 на /shop/product-123. Итог: каждая карточка теперь проходит через два шага переадресации. Умножьте на несколько тысяч страниц — и получите серьёзную нагрузку на бюджет обхода. Страницы индексируются медленнее, часть из них выпадает из обхода на недели.

Ещё один нюанс — смешанные цепочки, где 301 чередуется с 302. Допустим, URL A → 301 → URL B → 302 → URL C. Поисковый робот в такой ситуации получает противоречивые сигналы: первый шаг говорит «переезд постоянный», второй — «нет, временный». На практике это означает, что ссылочный вес передаётся частично или непредсказуемо, а финальный URL C не получает полного веса исходной страницы.

Отдельный случай — редирект на редирект через HTTPS. Сайт переехал с HTTP на HTTPS, но часть старых внутренних ссылок осталась на HTTP. Плюс одновременно сменилась структура URL. Получается цепочка: http://site.ru/old-page → 301 → https://site.ru/old-page → 301 → https://site.ru/new-page. Технически всё работает, но два шага вместо одного — это расточительство бюджета обхода, которое легко устранить, настроив прямой редирект сразу на финальный адрес.

Практическое применение

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

Разберём конкретные сценарии и механику их работы.

Когда ставить 301

• Смена домена. Переезд с old-site.ru на new-site.ru — классический сценарий для 301. Поисковый робот зафиксирует новый адрес, перенесёт ссылочный вес и со временем заменит старые URL в индексе на новые. Если поставить 302, Яндекс.Бот продолжит считать старый домен основным и не перенесёт накопленный авторитет.
• Склейка HTTP и HTTPS. После установки SSL-сертификата все запросы на http:// должны уходить на https:// через 301. Временный редирект здесь бессмысленен — переезд на HTTPS постоянный.
• Склейка с www и без www. Выберите одну каноническую версию (например, без www) и настройте 301 со всех остальных вариантов. Без этого поисковик видит два отдельных сайта и делит ссылочный вес между ними.
• Удаление страницы с переносом аудитории. Если раздел блога объединяется в один материал, старые URL переадресуются на новый через 301. Ссылочный вес объединяется, позиции сохраняются.
• Изменение структуры URL. Например, при переходе с /catalog/item123 на /catalog/electronics/item123 — каждая старая страница получает постоянный редирект на новый адрес.

Когда ставить 302

• A/B-тестирование. Пользователей временно отправляют на альтернативную версию страницы. Поисковый робот сохраняет исходный URL в индексе — именно это нужно, чтобы после теста не восстанавливать позиции с нуля.
• Технические работы и обслуживание. Сайт временно недоступен, пользователей перенаправляют на страницу-заглушку. Как только работы завершены, редирект снимают.
• Сезонные акции. Страница акции активна только в определённый период. Редирект 302 с основной страницы категории на акционную сохраняет индексацию основного URL.
• Геолокационные перенаправления. Пользователей из разных регионов отправляют на разные версии сайта — при этом исходный URL остаётся в индексе как основной.

Цепочки редиректов: как они возникают и почему опасны

Цепочки появляются не из-за злого умысла, а из-за накопленных изменений. Допустим, интернет-магазин сначала переехал с HTTP на HTTPS (добавили 301), потом убрали www (добавили ещё один 301), потом переименовали категорию (добавили третий 301). В итоге один URL ведёт через три прыжка к финальному адресу. Каждый прыжок — это дополнительный HTTP-запрос, дополнительное время ожидания и дополнительная нагрузка на бюджет обхода Яндекс.Вебмастер — миграция на HTTPS (301-редиректы).

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

Решение — схлопывание цепочек: каждый промежуточный URL должен напрямую вести на финальный адрес. Это делается на уровне конфигурации сервера (Apache .htaccess или nginx server-блок) или через CMS. Технически это означает: вместо A→B→C→D настраиваем A→D, B→D, C→D — три отдельных прямых редиректа.

Частный случай: 302 вместо 301 при смене домена

Это одна из самых дорогих ошибок при переезде. Яндекс.Бот получает 302 и продолжает считать старый домен основным. Новый домен индексируется, но без передачи ссылочного веса. Через несколько месяцев старый домен истекает или отключается — и сайт теряет все накопленные позиции разом, без предупреждения. Восстановление занимает от нескольких месяцев до года.

Инструменты

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

Screaming Frog: основной инструмент для аудита цепочек

Screaming Frog обходит сайт так же, как поисковый робот, и фиксирует каждый шаг переадресации. В разделе «Response Codes» отфильтруйте коды 3xx — получите полный список страниц с редиректами. Вкладка «Redirect Chains» показывает URL, у которых переадресация идёт через промежуточные адреса: видно количество шагов, промежуточные URL и финальный адрес назначения Screaming Frog SEO Spider.

Типичный сценарий: после редизайна интернет-магазина с несколькими тысячами страниц часть URL переехала дважды — сначала с http на https, потом со старой структуры категорий на новую. Screaming Frog за один обход покажет, сколько таких двойных цепочек осталось, и даст экспорт в CSV для пакетного исправления в.htaccess или nginx.conf.

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

Яндекс Вебмастер: мониторинг после изменений

После переезда домена или масштабной смены URL-структуры откройте Яндекс Вебмастер → «Индексирование» → «Страницы в поиске». Здесь видно, какие адреса поисковый робот уже зафиксировал как новые, а какие ещё числятся под старыми URL. Если через несколько недель после 301-редиректа старые URL не исчезают из индекса — это сигнал, что робот не прошёл цепочку до конца или получил смешанные сигналы (например, 301 на один адрес и canonical на другой) Яндекс.Вебмастер — рекомендации по индексированию.

Раздел «Диагностика» → «Ошибки обхода» показывает страницы, которые робот пытался обойти и получил нестандартный ответ. Цепочки редиректов, которые заканчиваются ошибкой 404 или 5xx, попадают именно сюда. Это быстрый способ найти «битые» переадресации без полного краулинга.

curl и DevTools: точечная диагностика

Когда нужно проверить конкретный URL, а не весь сайт, — используйте командную строку. Команда curl -I -L https://example.ru/old-page возвращает цепочку заголовков ответа с кодами и адресами на каждом шаге. Флаг -L заставляет curl следовать по редиректам, -I запрашивает только заголовки без тела страницы. Это занимает секунды и даёт точный ответ без сторонних сервисов.

Заключение

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

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