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

Происхождение и история термина

Последовательные перенаправления обсуждались задолго до современных инструментов технического SEO — проверки сайта для поисковых систем. В историческом RFC 2068, опубликованном в январе 1997 года, раздел о перенаправлениях рекомендовал клиенту не выполнять автоматически больше пяти переходов: длинную последовательность связывали с вероятностью бесконечного цикла. ^[6] Это свидетельство развития механизма, а не дата появления выражения «цепочка редиректов».

RFC 9110, опубликованный в июне 2022 года, рекомендует клиенту обнаруживать циклические перенаправления. Старое ограничение пятью переходами приведено как историческая особенность некоторых клиентов. ^[1] Поэтому старую цифру нельзя превращать в современную универсальную норму для сайта. Практический вопрос сместился от одного числового порога к поведению конкретного клиента и назначению маршрута.

Суть и механизм

Представим учебный переезд каталога. Посетитель открывает старый адрес товара A. Сервер возвращает код 301 и поле ответа Location с адресом B. Браузер запрашивает B, получает 302 с адресом C и затем запрашивает C. В нашем примере C отвечает 200. Получились три записи об ответах и две стрелки между ними. Дополнительный обмен запросом и ответом создаёт накладные затраты времени. ^[5]

Код описывает смысл ответа, а Location указывает направление. Если вместо полного адреса записано /catalog/item, его разрешают относительно адреса текущего запроса. ^[1] Поэтому после перехода на другой сайт нельзя продолжать подставлять в относительные адреса имя исходного сайта.

Для разбора полезно различать GET — запрос получения ресурса — и POST, которым, например, отправляют форму. ^[1] При некоторых перенаправлениях меняется и метод запроса: алгоритм Fetch заменяет POST на GET после 301 или 302; после 303 он заменяет на GET методы, отличные от GET и HEAD. HEAD запрашивает сведения об ответе без его содержимого. ^{[1] [2]} Это важно при испытании форм: журнал одних адресов не показывает, что произошло с отправленными данными.

Виды и классификации

Документация MDN разделяет перенаправления на постоянные, временные и специальные. К постоянным относит 301 и 308; к временным — 302, 303 и 307. При 307 и 308 метод и тело запроса сохраняются. ^[5] Это классификация отдельных ответов: цепочку со смешанными кодами нужно разбирать по шагам.

Яндекс отдельно различает внутрихостовые и межхостовые редиректы. Хост — имя узла в адресе, например shop.example.test; переход на www.shop.example.test уже меняет хост. ^[4] Для редакционного разбора добавим ещё один признак: журнал завершён конечным ответом, оборван на перенаправлении либо содержит повтор адреса. Это рабочая классификация результата проверки, а не дополнительный стандарт HTTP.

Как применяется на практике

Предлагаемая процедура приёмки начинается с таблицы соответствий: старый адрес, нужная конечная страница, причина переноса. В учебном каталоге старый товар должен вести к его новой карточке. Если направить его на главную страницу, короткий маршрут сам по себе не решит задачу посетителя. Поэтому сначала определяют правильную цель, затем убирают ненужные промежуточные шаги.

Для каждого выбранного адреса сохраните журнал до изменения и после него. В протоколе укажите время, средство проверки, метод запроса и условия входа. Отдельно испытайте ссылки на карточку, раздел и статью: одна удачная проверка главной страницы не охватывает разные правила маршрутизации. Это предлагаемая выборка редакции, а не обязательный перечень поисковой системы.

Практический смысл перенаправления для поиска зависит от правил конкретного поисковика. Канонический адрес — адрес, который поисковая система выбирает основным для страницы. Документы Google и Яндекса описывают разные стороны обработки, поэтому их формулировки нельзя механически подменять друг другом.

Редакционный вывод для приёмки прост: завершение маршрута и наблюдение результата в поиске — разные проверки. Не обещайте изменение выдачи только на основании зелёного сообщения локального анализатора.

Как измерить или проверить

Откройте мини-инструмент и вставьте журнал формата URL | код | Location. URL означает полный адрес ресурса. Для строки без дальнейшего перенаправления укажите в третьем столбце дефис. Учебный пример:

text https://example.test/a | 301 | /b https://example.test/b | 302 | /c https://example.test/c | 200 | -

Инструмент различает количество записанных ответов с перенаправлением и количество переходов, подтверждённых соседними строками. В связном журнале последнее число равно числу строк минус один. Здесь три минус один равно двум. Если удалить последнюю строку, останутся два объявления редиректа, но только один подтверждённый переход; получение ответа C неизвестно. Это счёт записей, а не доказательство достоверности введённых данных.

Одна строка с конечным ответом даёт ноль переходов. Адреса сравниваются после разбора стандартным объектом URL; фрагмент после знака решётки при сравнении исключается. Инструмент поддерживает HTTP(S), коды перенаправлений 301, 302, 303, 307, 308 и конечные ответы классов 2xx, 4xx, 5xx. Остальные случаи отклоняются как выходящие за его модель.

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

Ошибки, ограничения и спорные вопросы

В алгоритме Fetch после двадцати уже учтённых перенаправлений попытка продолжить маршрут завершается сетевой ошибкой. ^[2] Это правило конкретного алгоритма, не разрешение создавать двадцать шагов ради поискового продвижения. Локальный анализатор не воспроизводит Fetch: его предел сто строк ограничивает объём ввода, а не поведение браузера.

Повтор адреса может указывать на цикл, когда маршрут снова и снова возвращается к прежнему шагу. ^[5] Но наш журнал не хранит состояние входа пользователя и отправленные данные. Он сообщает лишь о повторе: для диагноза необходимо воспроизвести маршрут при одинаковых условиях. Редиректы по региону тоже требуют отдельной проверки: Яндекс предупреждает, что сетевой адрес робота может привести его не к ожидаемой региональной версии. ^[4]

Анализатор не выполняет JavaScript страницы, не проверяет её текст, настройки индексирования или доступность сервера. Он выявляет ошибки записи: пропущенную цель, разрыв последовательности, неподдерживаемый код. Конечный ответ 404 в корректно записанном журнале остаётся поводом разбираться со страницей, а не успешным результатом переезда.

Частые вопросы

Связанные термины

• 301-редирект
• 302-редирект
• Коды ответа сервера
• Канонический адрес