Как проверить редиректы и цепочки переадресаций

Редирект (переадресация) отправляет посетителя или робота с одного адреса на другой. Чтобы правильно проверить редирект, нужны три вещи: код ответа на каждом шаге, количество шагов в цепочке и конечный адрес с его собственным кодом. Ниже — три способа проверки редиректов на сайте (онлайн, через curl и в браузере), разница между 301, 302, 307 и 308 и как исправить цепочки и петли в nginx, Apache и WordPress.

Как проверить редирект онлайн

Быстрее всего — бесплатным чекером редиректов. Он запрашивает URL, сам проходит по каждому заголовку Location (до 15 шагов) и показывает весь путь.

1. Вставьте полный адрес вместе со схемой: http://example.com и https://example.com часто ведут себя по-разному, поэтому проверяйте оба.
2. Посмотрите сводку: количество редиректов, финальный код, общее время и заканчивается ли цепочка на том же или другом домене.
3. Пройдите цепочку по шагам. Для каждого шага показаны URL и код: 301 или 308 помечены как постоянные, 302 или 307 — как временные.
4. Прочитайте рекомендации под цепочкой. Инструмент отмечает цепочки длиннее одного шага, временные редиректы, которые, возможно, должны быть 301, редиректы на другой домен и подтверждает корректный редирект с HTTP на HTTPS.

Два ограничения стоит помнить: чекер проходит только серверные HTTP-редиректы (не meta refresh и не JavaScript, см. ниже) и запрашивает страницу со своим user agent, поэтому редиректы, зависящие от страны, устройства или cookies посетителя, у реальных пользователей могут выглядеть иначе.

Проверка 301 редиректа через curl

В терминале curl показывает заголовки ответа как есть, без кэша браузера:

curl -sIL http://example.com/old-page \
  | grep -iE "^HTTP|^location"

-I запрашивает только заголовки, -L следует за редиректами, а grep оставляет лишь строки со статусом и адресом перехода. Чистый результат выглядит так:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/
HTTP/2 200

Некоторые серверы отвечают на HEAD-запросы иначе, чем на обычные. Если результат выглядит странно, повторите с настоящим GET-запросом: curl -sL -o /dev/null -D - URL.

Проверка редиректов в Chrome DevTools

1. Откройте DevTools (F12) → Network.
2. Включите Preserve log, иначе шаги редиректа пропадут при смене страницы, и Disable cache.
3. Загрузите старый URL. Каждый шаг появится отдельной строкой со своим кодом; заголовок Location — в заголовках ответа.

Браузеры агрессивно кэшируют ответы 301. Если вы поменяли редирект, а браузер всё ещё ведёт по старому, проверьте в режиме инкогнито или через curl, прежде чем решать, что ошибка на сервере.

301, 302, 307 и 308: в чём разница

307 может появиться в DevTools и без участия вашего сервера: так браузер внутренне перенаправляет на HTTPS сайты из списка HSTS. curl и онлайн-чекер покажут реальный ответ сервера.

Цепочки редиректов и петли

Цепочка — несколько редиректов подряд: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Каждый шаг добавляет пользователю лишний запрос к серверу. Googlebot проходит до 10 переходов, но Google рекомендует делать цепочки короткими, а каждый лишний шаг — ещё одно место, где что-то может сломаться при следующем переезде. Цель — один редирект с любого старого адреса сразу на конечный.

Петля — цепочка, которая возвращается на уже пройденный адрес и поэтому никогда не заканчивается. Браузеры показывают ERR_TOO_MANY_REDIRECTS, а страница не может попасть в индекс. В чекере петля выглядит как цепочка, упёршаяся в лимит 15 шагов, с повторяющимися адресами. Типичные причины: HTTPS-редирект на сервере плюс настройка «Flexible SSL» в CDN или противоречащие друг другу правила для www в двух местах (в конфиге сервера и в CMS).

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

Отдельные URL подходят для точечных проверок. Чтобы найти все цепочки на сайте, нужен краулер, который проходит по внутренним ссылкам и фиксирует каждый редирект. Это делает SEO-аудит: он выводит цепочки и петли редиректов отдельными проблемами рядом с битыми ссылками, так что видно, какие внутренние ссылки до сих пор ведут на старые адреса.

Как исправить редиректы

nginx

Объедините смену схемы и хоста в один шаг вместо двух:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name example.com;
  location = /old-page/ {
    return 301 /new-page/;
  }
}

Добавьте отдельный блок listen 443 для www.example.com, который тоже отдаёт 301 на https://example.com$request_uri. После правок выполните nginx -t и перезагрузите конфигурацию.

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Redirect 301 /old-page/ https://example.com/new-page/

Генератор .htaccess соберёт такие правила без опечаток.

WordPress

• Убедитесь, что в Настройки → Общие в обоих полях адреса указан конечный URL (https и нужный вариант www); расхождение с правилом на сервере — классическая причина петель.
• Для отдельных страниц используйте плагин редиректов (например, Redirection) или менеджер редиректов вашего SEO-плагина и не задавайте один и тот же редирект одновременно в плагине и в конфиге сервера.
• После смены структуры постоянных ссылок проверьте несколько старых URL: часть старых слагов WordPress угадывает сам, но не все.

Какой бы ни был сервер, обновите внутренние ссылки, canonical и sitemap так, чтобы они вели сразу на конечные URL, — тогда редиректы нужны только для внешних ссылок и старых закладок.

Почему это важно для продвижения ссылками

Ссылки ведут на конкретный адрес. При постоянном редиректе их вес всё равно доходит до конечной страницы, но продвигать лучше сразу конечный адрес. Если продвигаемая страница переехала после запуска, настройте 301 со старого адреса — переделывать публикации не нужно, см. «Можно ли удалить или изменить публикацию».