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

Проверить редирект онлайн: как читать результат

Вставьте ссылку, и инструмент пройдёт по ней так же, как браузер: запросит адрес, прочитает заголовок Location, перейдёт дальше и так до страницы, которая ответит не редиректом. Учитываются серверные коды 301, 302, 303, 307 и 308, максимум 15 переходов. Вверху отчёта четыре числа:

• Редиректов — сколько переходов до конечной страницы. Норма — 0 или 1.
• Финальный статус — код конечного адреса. Нужен 200. Если там 404, редирект ведёт в никуда. Если 3xx при 15+ переходах, это петля.
• Общее время всех запросов. Каждый лишний шаг добавляет сетевую задержку, особенно на мобильном интернете.
• Тот же или другой домен — помогает заметить, что ссылка уводит на сторонний сайт.

Ниже идут рекомендации. Цепочка больше двух шагов помечается как слишком длинная, два шага — как повод сократить. Временные коды 302, 303 и 307 инструмент предлагает заменить на 301, если перенос постоянный. Переход с http на https отмечается как правильно настроенный. Редиректы через <meta http-equiv="refresh"> и JavaScript здесь не видны: это не HTTP-ответы, и для поисковика они слабее серверного 301.

Проверка ссылки на редирект: куда ведёт короткая ссылка

Частый сценарий — не настройка своего сайта, а вопрос «куда меня отправит эта ссылка». Короткие ссылки (bit.ly, cutt.ly), ссылки из рассылок и партнёрские ссылки проходят через один или несколько сервисов отслеживания, прежде чем привести на сайт. Вставьте такую ссылку в проверку, и вы увидите конечный адрес, не открывая его в своём браузере: запросы отправляет наш сервер, а не ваше устройство. Отметка «Другой домен» сразу показывает, что ссылка уводит с исходного сайта, а в конечном URL видны метки UTM и идентификаторы партнёрки.

Ограничение то же: часть сокращателей и рекламных сетей показывает промежуточную страницу и переводит дальше через JavaScript. Тогда цепочка закончится на этой странице со статусом 200. Если конечный домен вызывает сомнения, проверьте его отдельно, прежде чем вводить там данные или оплачивать.

301, 302, 307, 308: какой редирект ставить

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

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

Для быстрой проверки из консоли хватит одной команды. Флаг -I запрашивает только заголовки, -L заставляет идти по редиректам:

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

Каждая пара «HTTP/… код» и «location» — один шаг цепочки. Чтобы проверить редирект на основное зеркало, прогоните все четыре варианта адреса. Правильно настроенный сайт приводит каждый на один и тот же адрес не больше чем за один шаг:

for u in http://example.com http://www.example.com https://example.com https://www.example.com; do
  echo "$u -> $(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$u")"
done

Мобильный редирект

Инструмент обращается к сайту со своим User-Agent, как десктопный клиент. Если сайт перенаправляет телефоны на m.example.com по User-Agent, проверьте это через curl с мобильным заголовком:

curl -sIL -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" https://example.com/catalog/

Мобильный редирект должен вести на соответствующую страницу мобильной версии, а не на главную. Иначе мобильный пользователь из поиска теряет страницу, на которую кликнул.

Массовая проверка редиректов

После переезда удобно проверить список старых адресов целиком. Положите их в urls.txt, по одному в строке:

while read u; do
  curl -s -o /dev/null -L -w "$u\t%{http_code}\t%{num_redirects}\t%{url_effective}\n" "$u"
done < urls.txt

В выводе ищите строки, где код не 200, где больше одного редиректа и где конечный адрес — главная страница вместо нужного раздела.

Типичные ошибки: цепочки, петли, редирект с www

• Цепочка из-за двух правил. http://www.example.com → https://www.example.com → https://example.com. Одно правило переводит на https, второе убирает www, и они срабатывают по очереди. Решение: одно правило сразу на конечный вариант (примеры ниже).
• Петля с Cloudflare. Режим SSL «Flexible» ходит на сервер по http, а сервер отвечает редиректом на https, и так до бесконечности. Браузер показывает ERR_TOO_MANY_REDIRECTS. Лечится переключением в режим «Full (strict)».
• Конфликт WordPress и сервера. В «Настройки → Общие» указан адрес с www, а nginx убирает www, и они перекидывают друг на друга. Адрес в WordPress и правило сервера должны совпадать.
• Слэш в конце. /catalog → /catalog/ — лишний шаг для каждой внутренней ссылки без слэша. Исправляйте ссылки в шаблонах, а не только редирект.
• Все удалённые страницы — на главную. Google считает такие редиректы soft 404, и вес не переносится. Ведите на ближайший по смыслу раздел, а если его нет — отдавайте 404 или 410.

Как настроить редирект в nginx, Apache и WordPress

nginx: http и www — сразу на https без www, одним шагом:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate ...;
    return 301 https://example.com$request_uri;
}
# отдельная страница:
location = /old-page/ { return 301 /new-page/; }

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/

Если сайт стоит за прокси или CDN, %{HTTPS} может всегда быть off. Тогда проверяйте заголовок X-Forwarded-Proto, иначе получите петлю. Готовые правила под свой случай можно собрать в генераторе .htaccess.

WordPress: основной домен задаётся в «Настройки → Общие» (оба поля адреса). Для отдельных страниц удобен плагин Redirection: он хранит 301 в базе и показывает журнал 404. После любой правки снова проверьте адрес здесь и убедитесь, что внутренние ссылки ведут на конечные URL. Ссылки, которые всё ещё идут через редирект, находит проверка битых ссылок. Теория — что такое цепочки и почему при переезде теряется трафик — изложена в статье как проверить редиректы.