Проверка сайта на редиректы: цепочки, петли и потеря скорости
Редирект сообщает браузеру или поисковому роботу, что запрошенный ресурс нужно искать по другому адресу. Такая переадресация необходима после переноса страницы, смены домена, перехода на HTTPS или нормализации URL. Проблема возникает, когда маршрут становится длинным, противоречивым либо замыкается сам на себя. Поэтому проверка сайта на редирект должна учитывать не только первый ответ сервера, но и весь путь от исходного адреса до конечной страницы.
Что именно нужно искать
Корректный сценарий обычно выглядит просто: старый URL возвращает один редирект, после которого открывается актуальная страница с содержимым. Пользователь почти не замечает перехода, а техническая логика остается прозрачной. При ошибочной настройке между начальной и конечной точками появляются лишние промежуточные адреса или переход никогда не завершается.
Одиночный редирект
Схема /old → /new состоит из одного перехода. Она уместна, если прежний адрес действительно заменен новым и конечная страница доступна напрямую. Сам факт редиректа не является ошибкой: оценивать нужно его назначение, тип и результат.
Цепочка редиректов
Цепочка возникает, когда один URL ведет на второй, второй — на третий и далее: /a → /b → /c → /d. Каждый дополнительный шаг требует нового HTTP-запроса. Это увеличивает время до получения конечного документа, усложняет обход сайта и делает конфигурацию менее устойчивой. Если промежуточное правило изменится, весь маршрут может привести не туда.
Петля редиректов
Петля не имеет конечной страницы. Простейший вариант — /a → /b → /a. Возможен и саморедирект, когда адрес направляет запрос на самого себя. Браузер после нескольких попыток останавливает загрузку и показывает ошибку о слишком большом количестве переадресаций. Для посетителя ресурс фактически недоступен.
Чем различаются 301 и 302
Код 301 Moved Permanently обозначает постоянное перемещение. Его применяют, когда старый адрес больше не должен быть основным: например, после окончательного изменения структуры URL. Код 302 Found сообщает о временном перенаправлении и подходит для ситуации, в которой исходный адрес планируется использовать снова.
Выбор нельзя делать механически. Постоянный редирект для временной страницы и временный редирект после окончательного переноса создают неоднозначный сигнал о назначении URL. Кроме 301 и 302 существуют коды 307 и 308. Они также обозначают временное и постоянное перенаправление, но явно сохраняют HTTP-метод запроса. Это особенно важно для форм и API: перенаправлять POST-запрос так же, как обычный переход по ссылке, небезопасно без проверки поведения приложения.
Эта статья рассматривает именно HTTP-переадресации между URL. Проверка всех кодов ответа сайта и анализ элементов canonical — отдельные задачи. Canonical не выполняет перенаправление браузера и не должен использоваться как замена редиректу.
Диагностический алгоритм
1. Соберите исходные адреса
Начните с URL, по которым реально может прийти запрос: старые страницы, внутренние ссылки, адреса из карты сайта, варианты с HTTP и HTTPS, с www и без него, со слешем и без слеша. После миграции добавьте адреса из прежней структуры. Важно проверять точные URL, включая регистр символов, параметры и путь.
2. Запросите URL без автоматического следования
Сначала зафиксируйте первый ответ сервера. Например, заголовки можно получить командой:
curl -I https://example.ru/old-pageИщите код в первой строке и заголовок Location. Если инструмент автоматически переходит дальше, исходный редирект может остаться незаметным.
3. Проследите весь маршрут
Для просмотра цепочки используйте переход по заголовкам Location с фиксацией каждого шага:
curl -IL --max-redirs 10 https://example.ru/old-pageОграничение числа переходов защищает от бесконечного цикла. Для каждого шага запишите исходный URL, код, значение Location, следующий URL и итоговый результат. Относительный адрес в Location допустим по протоколу, но абсолютный вариант проще анализировать при переносах между доменами.
4. Проверьте конечную страницу
Недостаточно увидеть последний адрес. Убедитесь, что он открывается, соответствует смыслу исходной страницы и больше не перенаправляет запрос. Проверьте также, не ведут ли внутренние ссылки на старый URL. Даже правильный редирект не оправдывает лишний переход, если ссылку на сайте можно сразу заменить конечным адресом.
5. Повторите проверку в разных условиях
Правила могут зависеть от устройства, cookie, языка, региона или параметров запроса. Сравните обычный запрос и запрос без сохраненных cookie. Если переадресация формируется JavaScript-кодом, одного просмотра HTTP-заголовков недостаточно: потребуется проверка в браузере с открытой вкладкой Network.
Проверяемые критерии
| Критерий | Нормальный результат | Признак проблемы |
|---|---|---|
| Количество переходов | Один переход до актуального URL | Два и более последовательных редиректа |
| Завершение маршрута | Достигается конечная страница | Повтор URL, саморедирект или превышение лимита |
| Тип редиректа | Соответствует постоянному или временному сценарию | 302 используется после окончательного переноса либо 301 — для временной логики |
| Заголовок Location | Содержит корректный и доступный адрес | Пустое, поврежденное или неожиданное назначение |
| Внутренние ссылки | Ведут сразу на конечный URL | Ссылаются на старый или промежуточный адрес |
| Варианты хоста и протокола | Сводятся к выбранному варианту за один шаг | HTTP, HTTPS и www образуют несколько переходов |
| Смысл назначения | Конечная страница заменяет исходную по содержанию | Все удаленные страницы отправляются на главную без учета смысла |
Типовые ошибки настройки
- Последовательная нормализация. HTTP сначала переходит на HTTPS, затем добавляется
www, после чего отдельно исправляется слеш. Эти преобразования лучше объединить в один переход к итоговому URL. - Старые правила после нескольких миграций. Адрес первой версии сайта ведет на вторую, а она — на третью. Старое правило следует обновить так, чтобы оно сразу указывало на действующий адрес.
- Конфликт уровней. CDN, веб-сервер, CMS и плагин одновременно меняют URL. Правила могут дублироваться или направлять запросы в противоположные стороны.
- Петля HTTPS. Прокси сообщает приложению о запросе по HTTP, хотя пользователь уже работает по HTTPS. Приложение снова инициирует переход, и цикл повторяется.
- Редирект на удаленный URL. Первый переход формально работает, но назначение возвращает ошибку или запускает новую неподходящую переадресацию.
- Массовый переход на главную. Такое правило скрывает отсутствие точного соответствия, ухудшает навигацию и не помогает посетителю найти ожидаемый материал.
Как исправлять цепочки и петли
Для цепочки определите единственный актуальный адрес и направьте каждый прежний URL непосредственно на него. Затем обновите внутренние ссылки, меню, карту сайта и другие управляемые источники URL. Не удаляйте первое правило только потому, что внутри сайта старый адрес больше не используется: внешние ссылки и сохраненные закладки могут продолжать обращаться к нему.
При петле составьте таблицу всех участников цикла и выясните, на каком уровне создается каждый переход. Проверяйте конфигурацию прокси, веб-сервера и приложения отдельно. После изменения очистите только относящиеся к проверке кэши и повторите запрос без cookie. Сначала тестируйте конкретный URL, затем соседние шаблоны: слишком широкое регулярное выражение способно затронуть целый раздел.
Границы метода
Проверка публичного URL показывает поведение, доступное внешнему посетителю, но не объясняет автоматически, какое правило в CMS или конфигурации сервера его создало. Один и тот же адрес может отвечать по-разному после авторизации, при другой геолокации, с определенным User-Agent или при наличии cookie. Закрытые тестовые среды также нельзя оценить без доступа.
SiteVisor работает с публичным URL без доступа к CMS и оценивает технические, SEO/GEO и конверсионные сигналы страницы. Такая внешняя проверка полезна как отправная точка, однако источник конфликтующего правила все равно нужно искать в инфраструктуре конкретного сайта.
Итоговый чек-лист
- Зафиксировать первый HTTP-ответ без автоматического перехода.
- Проследить все значения
Locationдо конечного URL. - Исключить саморедиректы, повторы адресов и незавершенные маршруты.
- Сократить необходимую переадресацию до одного шага.
- Сопоставить 301 или 308 с постоянным, а 302 или 307 — с временным сценарием.
- Проверить доступность и смысловую релевантность конечной страницы.
- Заменить внутренние ссылки на прямые конечные URL.
- Повторить тест после исправлений для разных вариантов протокола и хоста.
Хорошая схема переадресации предсказуема: каждый устаревший адрес ведет прямо к одной подходящей странице, а маршрут завершается без лишних запросов. Чтобы получить исходную техническую оценку публичной страницы и определить направления дальнейшей диагностики, можно запустить бесплатную проверку SiteVisor.