Как проверить 301 редирект и цепочку перенаправлений
Редирект может работать и всё равно терять трафик: вести через три прыжка, не на ту страницу или по временному коду. Разбираем, как увидеть это за пять минут.
Проверить 301 редирект можно за минуту: запросите старый адрес и посмотрите заголовки ответа. Нужен код 301 и заголовок Location с новым адресом, а сам новый адрес должен отвечать 200, без новых перенаправлений по дороге. Если между старым и конечным адресом больше одного перехода, это цепочка, и её стоит сокращать.
Редирект проблемой бывает не всегда. Один переход http → https или со старой страницы на новую — норма. Хуже, когда переходов три и больше, когда вместо 301 стоит временный код или когда адрес ведёт не на аналог, а на главную. Тогда посетитель тратит лишние секунды, а поисковик медленнее понимает, какой адрес считать основным.
Что именно нужно проверить
У любого редиректа три параметра, и все три видны в ответе сервера:
- Код ответа.
301— перемещено навсегда,302— временно. Для переезда нужен постоянный. - Адрес в заголовке
Location. Он должен вести на страницу, которая заменяет старую. - Число переходов до конечной страницы, которая отвечает
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». Если за десять переходов страница не нашлась, адрес считается недоступным. Бояться стоит задолго до десятка: каждый лишний переход — отдельный запрос и задержка.
Как проверить редирект по шагам
Три способа, от самого быстрого до самого подробного.
Через браузер
- Откройте DevTools (F12) и вкладку Network.
- Включите «Preserve log», иначе список очистится после первого перехода.
- Введите в адресной строке старый адрес.
- Найдите первый запрос: в колонке Status будет
301или302, а в заголовках ответа —Location. - Пройдите по запросам вниз до последнего. У него должен быть статус
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, потом новый адрес раздела, и каждое правило срабатывает по очереди.
Порядок исправления:
- Выпишите все переходы, которые видите в цепочке.
- Определите конечный адрес — тот, который должен остаться.
- Перепишите каждое правило так, чтобы оно вело сразу на конечный адрес, а не на следующий промежуточный.
- Обновите внутренние ссылки, меню и карту сайта: они должны указывать на конечные адреса.
- Проверьте результат заново с чистым кешем.
Про сам переезд на новый домен и сопоставление старых и новых адресов подробнее в статье про переезд сайта на новый домен. Если после изменений часть страниц отвечает ошибкой, разберитесь с ними по материалу про ошибку 404.
Отдельно об HTTPS. Редирект с http на https работает, только если сертификат действителен. Когда он истёк, посетитель увидит предупреждение браузера вместо страницы, и редирект не поможет. Что делать в таком случае, описано в статье про истёкший SSL-сертификат.
Как найти редиректы на всём сайте
Проверка одного адреса отвечает на вопрос, работает ли этот редирект. Чаще нужно другое: понять, где на сайте вообще есть перенаправления, особенно после смены CMS или структуры. Для этого есть несколько подходов:
- Выгрузка из краулера. Программы для обхода сайта собирают все адреса и показывают код ответа каждого. Отфильтруйте коды 301, 302, 307, 308 и посмотрите, куда они ведут.
- Конфигурация сервера. Правила обычно лежат в
.htaccess(Apache), в конфиге Nginx или в настройках CMS и плагинов-редиректоров. Сверьте их с реальным поведением: правила копятся годами, и часть уже не нужна. - Внутренние ссылки. Если меню, подвал или текст ведут на адреса, которые редиректятся, это лишний переход для каждого посетителя. Проще заменить такие ссылки на прямые, чем держать правило.
- Отчёты вебмастеров. В Google Search Console и Яндекс Вебмастере видно, какие адреса поисковик считает дублями или перенаправлениями.
Если после переезда страницы пропали из выдачи, причина часто не в самом редиректе, а в чём-то рядом. Порядок поиска причин — в статье про исчезновение сайта из поиска Яндекса.
Редиректы удобно включить в регулярный осмотр: они ломаются тихо, например при обновлении плагина или переносе на другой сервер. Что ещё смотреть раз в месяц, перечислено в ежемесячном чек-листе.
Как проверить редирект прямо сейчас
Чтобы быстро увидеть цепочку, не открывая терминал, воспользуйтесь проверкой цепочки редиректов: вставьте адрес и посмотрите каждый переход с кодом и конечной страницей. Регистрация для разовой проверки не нужна.
Если редиректы связаны с переходом на HTTPS, заодно посмотрите срок действия и состояние SSL-сертификата: неверный сертификат сломает даже правильно настроенный переход.