Коротко: Проверить редирект можно тремя способами — через браузерный DevTools, онлайн-чекер или консольный запрос. Критично смотреть не только сам факт переадресации, но и код ответа (301 или 302), длину цепочки и отсутствие циклов. Цепочки длиннее двух хопов и циклы — самые частые проблемы, из-за которых страницы выпадают из индекса.
Рефакторинг сайта, смена CMS, переезд на HTTPS, склейка зеркал без www — после каждого такого изменения на проде появляются новые или ломаются старые редиректы. Если их не проверять, часть ссылок начинает возвращать 404 или уходить в бесконечный цикл, а поисковые роботы вычёркивают такие URL из индекса. Ниже — рабочие способы, которые мы используем на проектах, и типичные места, где настройка летит прямо в продакшене.
Проверка через браузер и DevTools
Быстрее всего проверить редиректы прямо в браузере: любой переход по ссылке — это цепочка HTTP-запросов, которую DevTools показывает без установки дополнительных программ. Открываете вкладку Network, включаете Preserve log (сохранение журнала) и переходите по URL — увидите каждый хоп со статусом 301, 302 или 307 и конечный код 200.
Важный момент: без включённого Preserve log вкладка Network чистится при каждом переходе, и вы увидите только последний запрос. Именно из-за этого новички делают вывод «редиректа нет», хотя он есть — просто уже завершился.
Что именно смотреть в панели Network
Столбец Status содержит код ответа. Столбец Location в блоке Headers запроса показывает, куда ведёт перенаправление. Клик по первому запросу из списка — и Headers → Response Headers покажет серверный ответ, по которому видно весь маршрут.
- Откройте DevTools — F12 или Ctrl+Shift+I (Cmd+Option+I на macOS).
- Перейдите во вкладку Network и поставьте галочку Preserve log.
- Введите URL в адресную строку и дождитесь загрузки.
- Изучите цепочку запросов сверху вниз: первый — исходный URL, последний — конечная страница.
- Проверьте, что финальный статус — 200, а все промежуточные — 301/302/307/308.
Chrome, Firefox и Safari — небольшие различия
В Chrome и Edge вкладка Network устроена одинаково. В Firefox дополнительно полезна колонка Transferred и опция «Persist Logs» в настройках вкладки. В Safari нужно сначала включить меню «Разработка» в настройках, иначе DevTools скрыт.
Использование онлайн-чекеров
Когда нужно быстро редирект проверить с чужого компьютера или показать клиенту, удобнее сервисы. Они отправляют запрос от своего сервера, поэтому видят то же, что и поисковый робот, — без кеша браузера и без cookies пользователя. Это критично: то, что видит ваш Chrome с закешированным 301, и то, что видит робот с чистого IP, — часто разные ответы.
Что умеют сервисы проверки
Базовый набор одинаковый: цепочка хопов, коды ответов, конечный URL, время ответа. Некоторые дополнительно показывают заголовки целиком, поддерживают пакетную проверку и сохраняют историю запросов.
| Инструмент | Что даёт | Когда удобен |
|---|---|---|
| Редирект-чекер Яндекса | Коды и цепочка по одному URL | Быстрая проверка после настройки |
| Redirect Checker | Полные HTTP-заголовки | Диагностика нестандартных кодов |
| HTTPStatus.io | Пакет до 10 URL | Сравнение старой и новой версии страницы |
| Редирект чекер при анализе URL | Обзор логики работы сервиса | Когда решаете, чем проверять регулярно |
Онлайн-сервисы удобны для точечной диагностики, но плохо масштабируются. Если у вас после переезда 500 URL и надо проверить цепочку редиректов по каждому — это уже задача для краулера, не для веб-формы.
Анализ HTTP-заголовков
Серверная сторона даёт самую честную картину. Утилита curl показывает цепочку ответов без визуальной части, только заголовки, — именно их и читает поисковый робот в первую очередь.
Какие коды что означают
| Код | Название | Когда используют |
|---|---|---|
| 301 | Moved Permanently | Постоянный переезд страницы или всего сайта |
| 302 | Found | Временная переадресация, например A/B-тест или акция |
| 307 | Temporary Redirect | Временный, но с сохранением HTTP-метода |
| 308 | Permanent Redirect | Постоянный, с сохранением HTTP-метода (POST остаётся POST) |
| Meta refresh | HTML-редирект | Резервный вариант, поисковики трактуют как 302 |
Как читать заголовки через curl
Команда curl -I https://site.ru/old-page вернёт заголовок только первого ответа. Чтобы увидеть всю цепочку, добавляйте флаг -L, а для подробностей — -v. Пример: curl -IL -A "Mozilla/5.0" https://site.ru/old-page покажет каждый хоп, Location и финальный код.
Флаг -A важен: без корректного User-Agent сервер может отдавать другую логику для ботов и людей — и вы получите неверную картину.
По наблюдениям команды Google, цепочки из трёх и более редиректов теряют часть сигналов ранжирования — примерно 10–15% на каждом лишнем хопе (источник: Google Search Central, раздел про HTTP-переадресации, 2025).
Что смотреть в заголовках помимо кода
Поле Location — куда именно ведёт редирект. Cache-Control — кешируется ли ответ браузером (актуально, если долго видите старую версию). X-Redirect-By — некоторые серверы и плагины пишут сюда, кто поставил редирект. Это упрощает поиск правила в конфиге, когда их в .htaccess или nginx десятки.
Отдельно обратите внимание на код ответа от балансировщика — иногда ошибка возникает не на стороне приложения, а на реверс-прокси. Подробнее о том, как разбирать такие сценарии при аудите, есть в статье про Навигатор СЕО при аудите сайта.
Выявление циклов перенаправления
Когда страница А ведёт на Б, Б — на В, а В снова на А, браузер через несколько хопов возвращает ERR_TOO_MANY_REDIRECTS. Проверить цепочку редиректов на цикл можно двумя способами: визуально по вкладке Network (цепочка не заканчивается) или через curl -IL, который в этом случае печатает одну и ту же последовательность Location по кругу.
Признаки цикла
- Браузер показывает «Слишком много перенаправлений» без явного редиректа при открытии в инкогнито.
- curl -IL зацикливается и повторяет один и тот же Location.
- Финальный код 200 не приходит — последнее, что видит клиент, снова 301/302.
Почему циклы появляются
Классика — конфликт правил: одно требует заменить http на https, второе — определить https как http для части путей, третье — плагин CMS перехватывает URL и возвращает его же. Реже встречается обратная ситуация: правило на стороне Nginx и правило в коде приложения матчат один и тот же путь и отправляют друг к другу.
Перед серией экспериментов полезно сложить карту из уже существующих правил: где живут редиректы, в каком порядке отрабатывают. Иногда помогает разбор через уже готовый опыт — например, в материале про функции Ahrefs для анализа конкурентов, часть инструментов показывает логику переходов и подсказывает, где ломаются цепочки.
Проверка массовых редиректов
Одиночная проверка — это разведка. Настоящая работа начинается, когда URL сотни и тысячи: после смены структуры каталога, переезда между доменами или объединения разделов. Здесь нужен краулер, который обойдёт сайт по списку и соберёт отчёт по каждой ссылке.
Чем сканировать список URL
- Screaming Frog SEO Spider — до 500 URL бесплатно, дальше платно. Показывает цепочки, коды, финальные адреса, выгружает в CSV.
- Netpeak Spider — десктопный краулер, умеет сразу группировать редиректы по длине цепочки.
- Sitebulb — визуализирует схему переходов, удобно при сложных конфигурациях.
- Скрипт на Python с библиотекой requests — когда список не помещается ни в одну бесплатную лицензию, а нужен только статус.
Как правильно собрать отчёт
- Соберите полный список исходных URL — из старого sitemap, базы CMS или выгрузки аналитики за год.
- Прогоните через краулер в режиме «List Mode», не через обычный скан сайта — так обработаются и URL, недоступные для обхода.
- Экспортируйте отчёт с полями: исходный URL, цепочка, коды каждого хопа, финальный URL.
- Отсортируйте по длине цепочки и сначала исправьте всё, где больше двух хопов.
- Отдельно отметьте 404 в финале — это битые ссылки, редирект ведёт в никуда.
- Сравните ожидаемое и фактическое: нередко редирект ведёт на похожую, но нерелевантную страницу — такое чаще всего видно только в массовом отчёте.
После правок отчёт прогоняют заново. Нормой считаем ситуацию, когда цепочки из двух хопов остались только для http→https + www→без www, а количество URL с циклом и 404 равняется нулю. Если структура меняется регулярно, проверку стоит вывести в рутину: перед каждым релизом — автотест на ключевые URL, после релиза — полный прогон по списку. Смежным этапом аудита часто становится крауд-маркетинг: при размещении ссылок на сторонних площадках важно, чтобы каждая вела не через три хопа к нужной странице, а сразу.
Коротко о главном
Проверить редирект — это не одно действие, а связка из трёх уровней: браузер показывает, что видит пользователь, HTTP-заголовки — что видит робот, краулер — всю картину целиком. Для быстрой диагностики хватает DevTools с включённым Preserve log. Для регулярной работы над структурой нужен сканер и список URL. Ключевое правило при настройке: один хоп — норма, два — допустимо, три и больше — уже потеря веса и лишние миллисекунды. Если после аудита не хочется возиться с массовой выгрузкой и правкой конфигов — эту работу можно делегировать: у нас она входит в стандартный технический SEO-разбор.