Редакция Romanov Lab · Опубликовано
Старая ссылка открывает нужную страницу, но только после нескольких переходов. Или браузер сообщает о слишком большом количестве перенаправлений. Такие проблемы возникают и без переезда: правило HTTPS на CDN, нормализация адреса на сервере и модуль CMS могут по отдельности работать логично, а вместе образовать цепочку или петлю. Исправление начинается с записи каждого шага.
Разделите цепочку, петлю и переход в браузере
Цепочка заканчивается конечным документом: адрес A отправляет на B, B на C. Петля возвращает к уже посещённому адресу: A ведёт на B, а B снова на A. Отдельно встречается ответ 200, после которого JavaScript меняет местоположение страницы. Если смотреть только конечный экран, эти ситуации неразличимы.
Проверяйте полный маршрут GET-запроса, включая статус, заголовок Location и итоговый URL. Запрос HEAD удобен для первичного осмотра, но приложение может обрабатывать его иначе; спорный результат перепроверьте обычной загрузкой документа. В браузерной панели Network включите сохранение журнала и изучите переходы основного документа. Это также поможет заметить клиентское перенаправление, которого нет в простом HTTP-отчёте.
Google рекомендует серверный постоянный редирект для постоянного перемещения; 301 и 308 относятся к постоянным перенаправлениям. Временный сценарий нужно оценивать отдельно. Это описано в руководстве Google по редиректам. Яндекс также различает постоянные и временные коды в справке об обработке перенаправлений. Одного кода недостаточно: цель всё равно должна отвечать исходной задаче.
Сделайте ведомость переходов
Для каждого проблемного входа выпишите исходный адрес, все промежуточные URL, конечную страницу и предполагаемый слой, отвечающий за шаг. Слой сначала может быть неизвестен. Не определяйте его только по заголовку Server: часть инфраструктуры скрывает или переписывает этот заголовок. Сопоставляйте наблюдение с журналом запроса и конфигурацией совместно с администратором.
| Шаг | Что происходит | Что выяснить |
|---|---|---|
| http://www.example.com/old | Переход на HTTPS | Может ли крайний узел сразу выбрать конечный хост и путь |
| https://www.example.com/old | Удаление www | Где закреплён предпочтительный хост |
| https://example.com/old | Переход на /catalog/new | Почему правило миграции не учитывает конечную форму адреса |
| https://example.com/catalog/new | Добавление завершающего слеша | Можно ли указать /catalog/new/ сразу в карте соответствий |
Этот пример показывает способ анализа, а не готовую конфигурацию. Нельзя просто перенести все правила в один слой: часть маршрутов может зависеть от состояния приложения. Практическая цель — направлять известный старый публичный URL сразу на его действующую конечную версию там, где это безопасно, и перестать создавать внутренние ссылки на промежуточные адреса.
Как найти типичную петлю HTTPS
Предположим, CDN принимает HTTPS, а с приложением связывается по HTTP. Приложение не учитывает согласованные сведения о внешнем протоколе и каждый раз перенаправляет посетителя на тот же HTTPS-адрес. Клиент снова приходит через CDN, и условие повторяется. Такое объяснение нужно подтвердить трассировкой и настройками; похожий симптом может иметь другая причина.
Попросите администратора проверить, как приложение определяет внешний протокол и каким прокси доверяет. Не исправляйте петлю отключением HTTPS или безусловным доверием любым пользовательским заголовкам. Доверие к прокси — часть настройки безопасности, поэтому изменение должно учитывать реальную схему доставки и проходить соответствующую проверку.
Для петли со слешем последовательность проще: сервер добавляет слеш, CMS его убирает. Здесь нужен один владелец правила нормализации и одинаковые ожидания у маршрутизатора, генератора ссылок и карты перенаправлений. Добавить третье обратное правило означает усложнить причину, а не устранить её.
Проверьте то, что легко потерять при сокращении цепочки
- Значимые параметры. Номер страницы, выбранная модель или язык не должны исчезать вместе с рекламной меткой.
- Точное соответствие пути. Правило для /service/ не должно случайно захватывать /service-manual/.
- Публичный и авторизованный режим. Вход может иметь собственную последовательность возврата; её проверяют отдельно от поисковых страниц.
- Протокол и варианты хоста. Рабочий HTTPS-адрес не доказывает, что старый HTTP-вход или www-вариант корректно доходят до него.
- Файлы и служебные маршруты. Новая общая нормализация не должна перенаправлять PDF, API и ресурсы оформления в HTML-раздел.
Не применяйте поисковое правило редиректа ко всем методам запроса без анализа. Отправка формы и открытие страницы — разные операции. Если затрагиваются POST-запросы, проверку сохранения данных и метода должен выполнить разработчик в рамках поведения приложения. Для SEO-аудита достаточно явно исключить эти маршруты из неподтверждённой массовой правки.
Проверка после исправления
Подготовьте положительные и отрицательные примеры до изменения. В положительном наборе должны быть старые адреса, известные альтернативные формы и URL с допустимыми параметрами. В отрицательном — похожие, но самостоятельные пути, неизвестная страница и конечный URL. Последний должен открываться сразу, а не отправлять посетителя обратно.
Сравните маршруты до и после выпуска. Уберите промежуточные адреса из внутренних ссылок, sitemap и канонических указаний там, где они действительно устарели. Отдельно проверьте ответ после обновления конфигурации на всех нужных слоях: браузер или CDN могут некоторое время хранить старый переход. Фиксируйте условия теста, чтобы не принять старый кэш за новую петлю.
Задача закрывается, когда утверждённые входы достигают правильного документа без циклов, параметры ведут себя по договорённости, а соседние маршруты не повреждены. Исчезновение сообщений в поисковом кабинете — последующее наблюдение. Универсального «разрешённого количества переходов для SEO» для приёмки не требуется: команда может проверить и обосновать каждый оставшийся шаг.
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
