О Обходчик
← Блог

Как проверить 301 редирект и цепочку перенаправлений

Редирект может работать и всё равно терять трафик: вести через три прыжка, не на ту страницу или по временному коду. Разбираем, как увидеть это за пять минут.

Руслан Хуснутдинов, основатель Обходчика около 7 мин чтения

Проверить 301 редирект можно за минуту: запросите старый адрес и посмотрите заголовки ответа. Нужен код 301 и заголовок Location с новым адресом, а сам новый адрес должен отвечать 200, без новых перенаправлений по дороге. Если между старым и конечным адресом больше одного перехода, это цепочка, и её стоит сокращать.

Редирект проблемой бывает не всегда. Один переход http → https или со старой страницы на новую — норма. Хуже, когда переходов три и больше, когда вместо 301 стоит временный код или когда адрес ведёт не на аналог, а на главную. Тогда посетитель тратит лишние секунды, а поисковик медленнее понимает, какой адрес считать основным.

Что именно нужно проверить

У любого редиректа три параметра, и все три видны в ответе сервера:

  1. Код ответа. 301 — перемещено навсегда, 302 — временно. Для переезда нужен постоянный.
  2. Адрес в заголовке Location. Он должен вести на страницу, которая заменяет старую.
  3. Число переходов до конечной страницы, которая отвечает 200.

Значения кодов описаны в RFC 9110: 301 Moved Permanently означает, что у ресурса новый постоянный адрес, 302 Found — что ресурс временно находится по другому адресу. Есть и 308: он тоже постоянный, но сохраняет метод запроса, а при 301 клиент вправе заменить POST на GET. Для обычных страниц на практике хватает 301 и 302.

Google в документации по перенаправлениям делит их так же: постоянные (301 и 308) показывают, что конечный адрес должен стать основным в выдаче, а временные (302, 303, 307) такого сигнала не дают, и старый адрес может остаться в результатах.

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

Когда редирект — проблема

Признак Что происходит Нужно ли чинить
Один переход 301 на страницу с кодом 200 Рабочий постоянный редирект Нет
http → https → версия с www → слэш в конце Цепочка из трёх переходов Да, свести к одному
302 вместо 301 на постоянном переезде Временный сигнал на постоянное событие Да
Редирект на главную вместо аналога Посетитель теряет контекст Да
A → B → A Петля, браузер выдаст ошибку Срочно
301 на страницу с ошибкой 404 или 5xx Старый адрес ведёт в никуда Срочно

Про длину цепочки есть прямое ограничение. В справке Google об ошибках HTTP и сети сказано: «By default, Google's crawlers follow up to 10 redirect hops». Если за десять переходов страница не нашлась, адрес считается недоступным. Бояться стоит задолго до десятка: каждый лишний переход — отдельный запрос и задержка.

Как проверить редирект по шагам

Три способа, от самого быстрого до самого подробного.

Через браузер

  1. Откройте DevTools (F12) и вкладку Network.
  2. Включите «Preserve log», иначе список очистится после первого перехода.
  3. Введите в адресной строке старый адрес.
  4. Найдите первый запрос: в колонке Status будет 301 или 302, а в заголовках ответа — Location.
  5. Пройдите по запросам вниз до последнего. У него должен быть статус 200.

Есть минус: браузер кеширует 301, и повторная проверка может показать результат из памяти. Открывайте адрес в режиме инкогнито или отключите кеш в DevTools.

Через командную строку

Команда curl показывает всю цепочку без картинок и скриптов:

curl -sIL https://example.com/staraya-stranica

Флаг -I запрашивает только заголовки, -L ведёт по перенаправлениям, -s убирает служебный вывод. В ответе будут блоки заголовков по числу переходов, в каждом — строка статуса и Location. Сколько блоков, столько запросов сделал бы посетитель.

Некоторые серверы по-разному отвечают на запрос заголовков (HEAD) и на обычный GET. Если результат вызывает сомнения, повторите без -I: curl -sL -o /dev/null -w "%{url_effective} %{http_code}\n" https://example.com/staraya-stranica. Команда выведет конечный адрес и итоговый код.

Через онлайн-проверку

Для разовой проверки удобнее сервис, который сам проходит цепочку и показывает каждый шаг. Он выручает, когда вы смотрите чужой сайт, у вас нет терминала или результат нужно показать клиенту. Подойдёт любая проверка, где на каждом шаге видны код и адрес; пример есть в конце статьи.

Типичные ошибки и что с ними делать

Цепочки редко появляются из-за одной ошибки. Обычно правила добавляли в разное время и разные люди: сначала http → https, потом www, потом новый адрес раздела, и каждое правило срабатывает по очереди.

Порядок исправления:

  1. Выпишите все переходы, которые видите в цепочке.
  2. Определите конечный адрес — тот, который должен остаться.
  3. Перепишите каждое правило так, чтобы оно вело сразу на конечный адрес, а не на следующий промежуточный.
  4. Обновите внутренние ссылки, меню и карту сайта: они должны указывать на конечные адреса.
  5. Проверьте результат заново с чистым кешем.

Про сам переезд на новый домен и сопоставление старых и новых адресов подробнее в статье про переезд сайта на новый домен. Если после изменений часть страниц отвечает ошибкой, разберитесь с ними по материалу про ошибку 404.

Отдельно об HTTPS. Редирект с http на https работает, только если сертификат действителен. Когда он истёк, посетитель увидит предупреждение браузера вместо страницы, и редирект не поможет. Что делать в таком случае, описано в статье про истёкший SSL-сертификат.

Как найти редиректы на всём сайте

Проверка одного адреса отвечает на вопрос, работает ли этот редирект. Чаще нужно другое: понять, где на сайте вообще есть перенаправления, особенно после смены CMS или структуры. Для этого есть несколько подходов:

  • Выгрузка из краулера. Программы для обхода сайта собирают все адреса и показывают код ответа каждого. Отфильтруйте коды 301, 302, 307, 308 и посмотрите, куда они ведут.
  • Конфигурация сервера. Правила обычно лежат в .htaccess (Apache), в конфиге Nginx или в настройках CMS и плагинов-редиректоров. Сверьте их с реальным поведением: правила копятся годами, и часть уже не нужна.
  • Внутренние ссылки. Если меню, подвал или текст ведут на адреса, которые редиректятся, это лишний переход для каждого посетителя. Проще заменить такие ссылки на прямые, чем держать правило.
  • Отчёты вебмастеров. В Google Search Console и Яндекс Вебмастере видно, какие адреса поисковик считает дублями или перенаправлениями.

Если после переезда страницы пропали из выдачи, причина часто не в самом редиректе, а в чём-то рядом. Порядок поиска причин — в статье про исчезновение сайта из поиска Яндекса.

Редиректы удобно включить в регулярный осмотр: они ломаются тихо, например при обновлении плагина или переносе на другой сервер. Что ещё смотреть раз в месяц, перечислено в ежемесячном чек-листе.

Как проверить редирект прямо сейчас

Чтобы быстро увидеть цепочку, не открывая терминал, воспользуйтесь проверкой цепочки редиректов: вставьте адрес и посмотрите каждый переход с кодом и конечной страницей. Регистрация для разовой проверки не нужна.

Если редиректы связаны с переходом на HTTPS, заодно посмотрите срок действия и состояние SSL-сертификата: неверный сертификат сломает даже правильно настроенный переход.

Проверить у себя

Бесплатно и без регистрации, по одному домену.

← Другие разборы в блоге