Цепочки редиректов: как сохранить конечный адрес и убрать лишние шаги

Старая ссылка ведёт через три промежуточных адреса или зацикливается, а пользователь видит не тот контент. Разберём, как проверить маршрут переходов, найти лишние узлы и зафиксировать конечный адрес, не меняя работающие канонические правила без карты и отката.

Цепочка редиректов — это два и более последовательных 3xx-ответа на один запрос, где каждый следующий адрес отличается от предыдущего. Чтобы сохранить конечный адрес, нужно выгрузить входы из логов, собрать карту маршрутов с ожидаемым и фактическим адресом, схлопнуть нормализацию схемы, хоста и слэша в один переход с сохранением query-строки и проверить результат через curl -I -L до и после правки.

Где ломается маршрут: условный пример с тремя лишними шагами

Представим условную ситуацию: посетитель кликает по ссылке из старой рассылки на http://shop.example/collection/jackets?size=m, а браузер проходит цепочку http:// → https:// → https://www.shop.example/collection/jackets?size=m → https://www.shop.example/collection/jackets/ и в конце оказывается на общей странице коллекции без выбранного размера. Пользователь видит не то, что обещала ссылка, а поисковый робот получает три перехода вместо одного. Это не гипотетическая катастрофа, а типичный накопленный след от смены домена, включения HTTPS, правки CMS и «быстрого» правила в конфиге nginx, которое кто-то добавил два года назад.

Механика проблемы проста: каждый редирект — это отдельный HTTP-ответ с кодом 3xx и заголовком Location. Браузер и робот обязаны сходить по этому адресу и получить следующий ответ. Если цепочка длинная, растёт время до первого байта полезного контента, а на каждом шаге можно потерять query-параметры, метод запроса или сам конечный ресурс. Google в документации о редиректах прямо указывает, что длинные цепочки и петли — плохая практика, а MDN напоминает: коды 307 и 308 сохраняют метод запроса, 301 и 302 — постоянный и временный переходы, а 307 и 308 — их варианты с сохранением метода, и путать их в постоянных правилах не стоит. Задача этой статьи — не «сделать SEO», а разобрать конкретный маршрут переходов, найти лишние узлы, зафиксировать конечный адрес и не сломать то, что уже работает.

Если ваша задача — проверить маршруты редиректов, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Что именно считать цепочкой, а что — нормальным поведением

Прежде чем что-то править, нужно договориться о терминах. Цепочка редиректов — это два и более последовательных 3xx-ответа на один исходный запрос, где каждый следующий адрес отличается от предыдущего. Одиночный переход http:// → https:// — не цепочка, а штатное поведение. Одиночный переход с www на без-www (или наоборот) — тоже нормально, если он один. Проблема начинается, когда эти два перехода стоят последовательно и к ним добавляется третий: нормализация слэша, смена языка, мобильная версия.

Есть ещё один класс — петля. Это когда A редиректит на B, а B — обратно на A, либо маршрут возвращается к исходному адресу через несколько шагов. Браузер в этом случае выдаёт ошибку ERR_TOO_MANY_REDIRECTS, и пользователь не видит ничего. Петля почти всегда означает конфликт правил: например, правило «всегда HTTPS» на уровне балансировщика и правило «всегда HTTP для внутренних путей» в приложении.

Отдельно стоит держать в голове коды. Постоянный переход (301, 308) говорит роботу: «запомни новый адрес». Временный (302, 307) — «сходи, но адрес не меняй». При этом 307 и 308 дополнительно сохраняют метод запроса, а 301 и 302 могут его менять. Если постоянный ресурс отдаёт 302, поисковые системы могут продолжать считать старый URL каноническим, и это не ошибка конфигурации в строгом смысле, но источник путаницы. Смешивать коды в одной цепочке — почти гарантия, что конечный адрес будет определяться непредсказуемо.

Инвентаризация входов: откуда вообще приходят старые адреса

Прежде чем строить карту переходов, нужно понять, какие входы существуют. Их обычно больше, чем кажется. Внешние ссылки с чужих сайтов, старые рассылки, сохранённые закладки сотрудников, QR-коды на печатной продукции, ссылки в документах и презентациях, рекламные объявления с utm-метками. Каждый вход — это потенциальная точка, где цепочка начинается.

Практичный способ собрать входы — выгрузить логи веб-сервера за разумный период и отфильтровать запросы, которые завершились 3xx. Это даст реальные маршруты, а не гипотезы. Дополнительно стоит посмотреть отчёты о переходах в панели вебмастера, если она используется, — там видны адреса, по которым робот получал редирект. Но логи первичны: они показывают, что происходит на самом деле, а не что должно происходить по документации.

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

Конечный адрес перенаправления: карта маршрутов как таблица, а не как список правил

Конфиг nginx или правила в CMS — это код. Код плохо читается теми, кто отвечает за контент и за маркетинг. Поэтому до правок стоит завести рабочий объект — таблицу маршрутов, где каждая строка описывает один вход и его судьбу. Это не бюрократия, а способ увидеть цепочку целиком, а не по одному правилу за раз.

Минимальный набор полей выглядит так: исходный адрес, ожидаемый конечный адрес, фактический конечный адрес, количество шагов, коды на каждом шаге, статус (ок / цепочка / петля / потеря параметров), владелец решения. Последнее поле важнее, чем кажется: без него правки зависают между разработчиком, который «не знает, зачем этот адрес», и маркетологом, который «не помнит, откуда ссылка».

Такая таблица живёт рядом с проектом и обновляется при каждой правке правил. Она же становится основой для отката: если после схлопывания цепочки что-то пошло не так, видно, какое правило менялось и на что.

Эпизод первый: HTTPS, www и слэш в одном запросе

Условный пример: интернет-магазин переехал на HTTPS и одновременно сменил основной домен на вариант с www. В конфиге остались три правила: «всегда HTTPS», «всегда www», «всегда со слэшем на конце». Пользователь открывает http://shop.example/catalog, и браузер проходит: http://shop.example/catalog → https://shop.example/catalog → https://www.shop.example/catalog → https://www.shop.example/catalog/. Четыре запроса вместо одного, и на каждом шаге есть шанс потерять query-строку, если правило её не сохраняет.

Причина в том, что правила применяются последовательно, а не за один проход. Сервер видит запрос, применяет первое подходящее правило, отдаёт 301, получает новый запрос уже с другим хостом или схемой, применяет следующее правило. Схлопнуть это можно, если каждое правило проверяет все условия сразу и формирует конечный адрес за один ответ. Например, правило «если схема не https или хост не www — отдать 301 на https://www.<host><path> с сохранением query». Тогда любой вход укладывается в один переход.

Тонкость со слэшем: если конечный ресурс — это файл или API-эндпоинт, добавление слэша может сломать обработку. Поэтому правило слэша лучше держать отдельно и применять только к тем путям, где это осознанно. И проверять, что оно не срабатывает на уже нормализованных адресах — иначе получится петля «добавить слэш → убрать слэш».

Как читать заголовки и не доверять одному инструменту

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

Команда curl -I -L покажет цепочку ответов с заголовками Location на каждом шаге. Флаг -L заставляет следовать за переходами, -I запрашивает только заголовки. Если нужно увидеть, что происходит без следования, -L убирают и получают первый ответ. Для проверки query-параметров удобно добавить -v, чтобы видеть полный запрос и ответ. Это не «правильный инструмент», а способ увидеть то, что видит браузер, без прослойки в виде интерфейса.

Отдельно стоит проверять поведение с разными User-Agent. Если сервер отдаёт разный конечный адрес для мобильных и десктопных запросов, это нужно зафиксировать в карте маршрутов. Иногда это осознанное решение (отдельная мобильная версия), иногда — забытое правило. В любом случае это часть маршрута, и она должна быть в таблице.

Эпизод второй: параметры, которые исчезают по дороге

Условный пример: старая рекламная кампания вела на https://example.com/landing?utm_source=email&utm_campaign=spring. Правило редиректа настроено так: «все запросы на /landing перенаправлять на /new-landing». В конфиге написано return 301 https://example.com/new-landing; — без переменной, которая сохраняет query-строку. Пользователь попадает на новую страницу, но метки кампании потеряны, и в аналитике этот переход выглядит как прямой заход. Маркетолог делает вывод, что кампания не сработала, хотя проблема в одном отсутствующем символе в конфиге.

Это самый частый и самый незаметный вид потери. Он не ломает страницу, не вызывает ошибок, но искажает данные. Проверять его нужно отдельно от проверки цепочки: сначала убедиться, что конечный адрес правильный, потом — что query-строка на месте. В nginx сохранение query делается через $request_uri или $is_args$args в зависимости от того, как формируется Location. В правилах на уровне приложения — через явное копирование параметров.

Есть и обратная проблема: параметры, которые не должны переезжать. Например, служебные параметры отладки или токены сессии, которые не стоит тащить в публичный URL. Здесь решение принимается по смыслу: какие параметры влияют на контент (размер, цвет, язык), а какие — на источник трафика (utm) или на состояние (session). Первые сохраняются, вторые — по договорённости, третьи — почти всегда отбрасываются.

Петли: как найти и чем они опасны

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

Искать петли лучше не вручную, а по логам: запросы, которые завершились 3xx и повторяются с тем же путём, но разным хостом или схемой, — кандидаты. Дальше — пройти цепочку вручную и найти точку, где адрес возвращается к уже встречавшемуся. Чаще всего это конфликт между правилом на балансировщике и правилом в приложении: балансировщик редиректит на HTTPS, приложение — обратно на HTTP для определённых путей, и круг замыкается.

Лечится это не «отключением одного из правил», а явным порядком: одно место отвечает за схему и хост, другое — за пути внутри приложения. Если оба уровня трогают одно и то же, петля рано или поздно появится снова, даже если сейчас её нет.

Мобильный адрес, который ведёт на другой контент

Отдельный класс проблем — когда один и тот же вход ведёт на разные конечные страницы в зависимости от устройства. Условный пример: https://example.com/product/123 на десктопе отдаёт страницу товара, а на мобильном редиректит на https://m.example.com/product/123, где контент устарел и цена другая. Формально это не цепочка и не петля, но по сути — расхождение конечного адреса, которое нужно зафиксировать.

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

Тесты перед выкаткой: что и как проверять

Правки правил редиректов — это изменение поведения, которое видно только снаружи. Поэтому проверять нужно не «работает ли сайт», а конкретные маршруты из карты. Минимальный набор тестов выглядит так: для каждого входа из таблицы — запрос с проверкой конечного адреса, кода ответа и наличия нужных query-параметров. Плюс отдельные тесты на петли: запрос, который раньше зацикливался, должен теперь завершаться 200.

Тесты стоит запускать до выкатки на staging-окружении, если оно есть, и сразу после — на продакшене. Если staging нет, проверка идёт на продакшене точечно, по одному маршруту, с возможностью быстро откатить правило. Откат — это часть плана, а не признак неудачи.

Практикум: разбор условного маршрута из шести шагов

Возьмём условный вход http://old.example.org/blog/post-42?ref=newsletter и представим, что он проходит такую цепочку: http://old.example.org/blog/post-42?ref=newsletter → https://old.example.org/blog/post-42?ref=newsletter → https://www.example.org/blog/post-42?ref=newsletter → https://www.example.org/blog/post-42/ → https://www.example.org/blog/ → https://www.example.org/. Шесть шагов, потерянный параметр, конечный адрес — главная страница вместо статьи.

Разбор по шагам. Первый переход — схема, штатный. Второй — смена домена, тоже штатный, но его можно объединить с первым. Третий — добавление слэша, применяется к адресу, который на самом деле не является директорией. Четвёртый — редирект со статьи на раздел блога, скорее всего, следствие удаления статьи. Пятый — редирект с раздела на главную, тоже следствие. Итог: три лишних шага и потеря смысла.

Что делать. Схлопнуть первые два перехода в один: правило, которое проверяет схему и хост одновременно и отдаёт 301 на https://www.example.org<path><query>. Убрать правило слэша для путей, которые не являются директориями. Для удалённой статьи — решить, восстанавливать ли её или настроить один переход на ближайшую по смыслу страницу, а не на главную. Параметр ref сохранить, если он нужен для аналитики, или явно отбросить, если нет.

После правок маршрут должен выглядеть так: http://old.example.org/blog/post-42?ref=newsletter → https://www.example.org/blog/post-42?ref=newsletter → 200 (если статья восстановлена) или один переход на релевантную страницу с сохранением ref. Два шага максимум, конечный адрес осмысленный.

Конечный адрес перенаправления: когда цепочку лучше не трогать

Не всякая цепочка — ошибка. Есть случаи, когда промежуточный шаг осознан и его удаление сломает что-то другое. Например, переход через промежуточный домен, который используется для отслеживания кликов в партнёрской программе: убрать его — значит потерять атрибуцию. Или переход через страницу предупреждения, которую требует применимое регулирование для определённых типов контента. Такие случаи нужно фиксировать в карте маршрутов с пометкой «осознанно» и владельцем решения.

Ещё одно исключение — старые адреса, которые ведут на контент, которого больше нет, но который нельзя удалять из-за внешних ссылок. Здесь выбор между восстановлением контента, переходом на архивную копию и переходом на ближайшую по смыслу страницу. Решение принимает владелец контента, а не разработчик, и оно должно быть записано.

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

Что проверить в первую очередь на своём проекте

Начать стоит с одного конкретного шага: выгрузить из логов запросы, завершившиеся 3xx, за последние две недели, и посмотреть на самые частые пути. Если среди них есть те, что проходят больше одного перехода, — это и есть первый кандидат на разбор. Дальше — собрать по ним карту маршрутов в таблице, проверить конечные адреса и query-параметры, и только после этого трогать конфиг.

Перед любой правкой — зафиксировать текущее поведение и план отката. После правки — прогнать тесты по карте и сверить логи: количество 3xx на этих путях должно уменьшиться, а конечные адреса — совпасть с ожидаемыми. Если что-то пошло не так, откат возвращает предыдущее правило, и разбор продолжается с новыми данными. Такой цикл — не разовая акция, а регулярная проверка, которую стоит повторять после каждой смены домена, включения HTTPS или крупной правки структуры сайта.

Как не превратить аудит в бесконечную миграцию

Соблазн большой: раз уж мы смотрим на редиректы, давайте заодно поправим все старые адреса, переименуем разделы и приведём URL к единому виду. Это уже другая задача — миграция, а не аудит маршрутов. У неё свои риски, свой план и свои проверки. Смешивать их опасно: если в одном изменении и схлопывание цепочек, и переименование разделов, то при проблеме непонятно, что именно её вызвало.

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

Конечный адрес перенаправления на экране сотрудника

Разработчик видит маршруты в конфиге и в логах. Контент-менеджер видит их в интерфейсе CMS, где можно задать редирект для страницы. Эти два представления должны совпадать, иначе правила будут дублироваться и конфликтовать. Практичный минимум — единый список редиректов, доступный и разработчику, и контент-менеджеру, с полями «откуда», «куда», «код», «комментарий» и «кто изменил».

Если такого списка нет, его стоит завести до правок. Даже простая таблица в общем документе лучше, чем правила, разбросанные по трём местам. Когда список появится, станет видно дубли: один и тот же вход, заданный дважды с разными конечными адресами, — почти гарантированная петля или непредсказуемое поведение.

Коды ответов и что они говорят роботу и браузеру

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

Рекомендация: для нормализации схемы, хоста и постоянных переездов использовать 301 или 308, для временных акций и A/B-тестов — 302 или 307. В одной цепочке лучше не смешивать постоянные и временные коды: конечный адрес становится неочевидным. Если смешение неизбежно, зафиксировать это в карте маршрутов и проверить, что конечный адрес отдаёт 200.

Когда стоит остановиться и не трогать

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

Ещё один сигнал остановиться — отсутствие владельца решения. Если непонятно, зачем существует правило и кто отвечает за конечный адрес, правка может сломать чужой сценарий. В таком случае сначала находится владелец, потом принимается решение. Это медленнее, но надёжнее, чем «поправить и посмотреть».

Проверка на практике: конечный адрес перенаправления

Возьмите один старый адрес, по которому точно есть переходы, и прогоните его через curl -I -L. Запишите цепочку: сколько шагов, какие коды, сохраняются ли параметры, куда в итоге попадает пользователь. Если шагов больше одного и конечный адрес не совпадает с ожидаемым — это ваш первый кандидат на разбор. Дальше — таблица маршрутов, проверка по применимым документам у ответственного за инфраструктуру и правка одного правила с планом отката. Такой шаг занимает меньше времени, чем кажется, и сразу показывает, где именно ломается маршрут.

Смежный вопрос разобран отдельно: Перенос сайта с сохранением SEO: карта URL до переключения.