Редирект кажется простой настройкой: один адрес отправляет посетителя на другой. На практике сайт часто имеет несколько вариантов входа, например http://example.ru, https://example.ru, www и отдельный API-хост. После миграции между CMS, смены сертификата или объединения страниц эти варианты могут образовать длинную цепочку. Браузер в итоге покажет правильную страницу, но поисковый робот, аналитика или интеграция получат лишние задержки и неоднозначные сигналы. Проверка цепочки редиректов нужна перед запуском, после изменения DNS и при расследовании падения органического трафика. Её задача не в том, чтобы убрать любой переход, а в том, чтобы каждый переход имел понятную причину.
Что считать цепочкой
Цепочка состоит из последовательности HTTP-ответов, где сервер сообщает клиенту новый адрес в заголовке Location. Например, запрос к HTTP-версии может перейти на HTTPS, затем с www на основной хост, а затем со старого пути на новый. Финальным результатом считается ответ, который уже не требует перенаправления, обычно 200, 204 или осмысленный ответ API. Не смешивайте редирект с канонической ссылкой в HTML: каноникал подсказывает поисковой системе предпочтительный URL, но не заменяет серверный переход. Также не путайте редирект с DNS-алиасом CNAME. DNS выбирает адрес или имя сервиса, а HTTP-редирект меняет URL на уровне приложения. Для корректного аудита фиксируйте оба слоя.
Составьте матрицу входных адресов
Начните с таблицы вариантов, которые реально используют люди и системы. Включите http и https, www и без www, завершающий слеш, несколько важных старых путей, мобильные или языковые префиксы, а также домены, которые участвовали в миграции. Для API добавьте реальные версии и методы, если они поддерживаются отдельно. Проверяйте не только главную страницу: ошибка может проявляться на `/login`, `/api`, статическом файле или старой посадочной странице. Сохраняйте дату, код ответа, Location, число переходов, финальный адрес и длительность. Если сервер возвращает разные результаты для GET и HEAD, используйте тот метод, который соответствует вашему клиенту, и не объявляйте HEAD полной заменой пользовательского запроса.
- HTTP без www
- HTTP с www
- HTTPS без www
- HTTPS с www
- Старый путь и его новый эквивалент
- Основной API-адрес и версия API
- Адрес с ошибочным или устаревшим поддоменом
Разберите коды 301, 302, 307 и 308
Код 301 традиционно используется для постоянного перемещения ресурса, а 302 обычно означает временное перенаправление. 307 и 308 сохраняют метод запроса и тело более явно, что важно для POST и других небезопасных для автоматической замены методов. Выбор кода должен соответствовать намерению, а не привычке команды. Постоянный переход на новый URL нельзя маскировать временным только ради удобства теста, если старый адрес больше не должен индексироваться. И наоборот, эксперимент, географическая маршрутизация или временная акция не должны навсегда склеивать адреса. В отчёте укажите, почему выбран конкретный код и какая система является владельцем правила. Это помогает не менять редирект случайно при следующем релизе.
Учитывайте, что часть клиентов и промежуточных систем кэширует постоянные ответы. После смены правила пользователи могут некоторое время видеть старый маршрут, особенно если ответ содержал Cache-Control с большим сроком. Поэтому тестируйте контрольный URL и новый URL отдельно, очищайте кэш только в рамках утверждённого плана и не делайте вывод по одному браузеру. Для публичной миграции сначала убедитесь, что новый адрес полностью готов, затем включайте постоянный переход. Если обратный откат возможен, согласуйте кэширование с владельцами CDN и приложений. В документации храните дату включения и ожидаемый срок жизни старого URL.
Найдите циклы и лишние переходы
Цикл возникает, когда адрес A отправляет на B, а B возвращает на A или на другой адрес, который снова приводит к A. Браузер обычно останавливает такой маршрут сообщением о слишком большом числе переходов. Более коварна цепочка длиной четыре или пять шагов: она иногда работает, но добавляет задержку и увеличивает вероятность сбоя. Ищите повторяющиеся хосты, чередование HTTP и HTTPS, дублирование правил слеша, старые промежуточные домены и перенаправление через маркетинговый трекер. Каждый дополнительный шаг должен быть оправдан. Если можно направить старый URL сразу на финальную страницу без потери смысла, это обычно более прозрачная конфигурация. Для сложных миграций сохраните список старых адресов и проверяйте его после каждого изменения.
Свяжите HTTP-переход с DNS и сертификатом
Редирект HTTPS не исправит неправильную DNS-запись и не заменит сертификат. Если HTTP-хост разрешается на один сервер, а HTTPS на другой, посетитель может получить лишний переход, ошибку сертификата или неожиданный контент. Сначала проверьте A, AAAA и CNAME для всех входных имён, затем сопоставьте их с сертификатом и ожидаемым виртуальным хостом. Убедитесь, что SAN покрывает нужные варианты, а цепочка доверия отдаётся полностью. Отдельно решите, должен ли технический поддомен редиректить на сайт или возвращать API-ответ. Смешение этих ролей затрудняет мониторинг и может сломать клиентские библиотеки. В DomScan удобно сочетать проверку редиректов, DNS и SSL в одном контрольном списке.
- Проверить DNS для каждого входного хоста.
- Проверить TLS-сертификат до оценки HTTP-ответа.
- Отправить запрос к каждому варианту протокола и имени.
- Записать все Location и финальный статус.
- Сократить цепочку до необходимого минимума.
- Повторить проверку после публикации и после изменения кэша.
Что важно для SEO и аналитики
Поисковая система должна ясно понимать, какой адрес является актуальным. Согласуйте серверный редирект, внутренние ссылки, sitemap и canonical, чтобы они не указывали на разные варианты. Не перенаправляйте весь старый домен на главную страницу без связи с содержимым: это может ухудшить опыт пользователя и ослабить смысл миграции. Для аналитики проверьте, не теряются ли параметры кампании, реферер и язык при переходе. Сервисы авторизации особенно чувствительны к смене домена, потому что callback URL может быть зарегистрирован отдельно. В отчёте отделяйте технически успешный переход от бизнес-результата: код 200 ещё не означает, что форма, событие или API-клиент продолжили работать.
Автоматизируйте проверку перед релизом
Для небольшого сайта достаточно периодического набора контрольных URL. Для портфеля доменов нужен API, который возвращает исходный URL, каждый промежуточный ответ, финальный URL, статус, ошибки соединения и время проверки. Не сводите timeout, DNS-ошибку и обычный ответ 403 к одному статусу «редирект сломан». Это разные ситуации, требующие разных действий. Введите порог для длины цепочки и список ожидаемых исключений, например переход с HTTP на HTTPS. Сохраняйте прошлый результат, чтобы видеть регрессию после релиза. Перед внедрением проверьте ограничения инструмента и повторяемость на доменах, которые вы контролируете. Если внешний сайт ограничивает запросы, показывайте неизвестный результат, а не придумывайте финальный маршрут.
{
"input": "http://www.example.ru/old",
"hops": 2,
"chain": [
{"status": 301, "location": "https://example.ru/old"},
{"status": 200, "url": "https://example.ru/new"}
],
"classification": "expected_migration"
}Лучший критерий качества цепочки прост: пользователь, робот или API-клиент попадает на ожидаемый ресурс предсказуемым числом шагов, а команда может объяснить каждое правило. Проверяйте не только финальный статус, но и сохранение метода, параметров, заголовков безопасности, cookie и авторизации там, где это разрешено вашим контрактом. После миграции оставьте старые адреса под наблюдением, потому что неожиданный рост обращений к ним подсказывает, что внутренние ссылки или внешние партнёры ещё не обновлены. Такая проверка превращает редиректы из скрытого набора правил в измеряемую часть качества сайта.
Для российского сайта проверьте отдельно домен в зоне .ru, кириллический вариант и региональные поддомены. Редирект с `пример.рф` на латинский адрес может быть правильным решением бренда, но его нужно проверить в браузере, sitemap, почте и рекламных ссылках. Не меняйте каноническую форму только ради красивого URL, если старые адреса участвуют в договорах или API. Согласуйте список постоянных переходов с владельцами SEO, аналитики и поддержки. После публикации оставьте контрольные запросы на старые варианты и зафиксируйте, когда их можно удалить из документации.
Редирект также влияет на кэш, cookie и безопасность. Убедитесь, что переход не отправляет чувствительные параметры на чужой домен, сохраняет нужный метод и не открывает бесконечный open redirect. Для URL с параметрами проверьте разрешённый список назначения и удаление лишнего query string. В отчёте показывайте, какие параметры сохранились, а какие были безопасно удалены. Если правило принадлежит балансировщику или приложению, назначьте его владельца, иначе следующая миграция вернёт старую цепочку. После исправления повторите тест из чистого клиента и сравните полный маршрут, а не только финальный код.
Есть несколько типичных ложных срабатываний. Страница входа может законно отправить гостя на авторизацию, а сервис локализации может выбрать язык по заголовку Accept-Language. Платёжная система может вернуть временный переход на внешний адрес, который нельзя трактовать как часть публичной канонической цепочки. Поэтому тестовый набор должен описывать ожидаемый сценарий и контекст запроса. Запускайте безопасный анонимный тест отдельно от авторизованного сценария, не передавайте реальные токены в сторонний проверяющий сервис и удаляйте чувствительные параметры из журналов. Если сайт использует защиту от автоматических запросов, сохраняйте факт ограничения и повторяйте проверку из разрешённого окружения, а не пытайтесь обходить защиту. В отчёте полезно иметь поля expected, observed и reason, чтобы разработчик мог отличить ошибку правила от нормального бизнес-маршрута.
При переносе сайта с одного домена на другой подготовьте период совместного контроля. Сначала проверьте новый домен напрямую, затем включите редирект со старого. Следите за URL изображений, JavaScript, webhook, callback и robots.txt, потому что они могут не проходить тот же маршрут, что главная страница. Отдельно измеряйте время до первого ответа и полное время до финальной страницы. Если цепочка короткая, но один сервер отвечает нестабильно, проблема не в количестве редиректов. Если финальный URL меняется в зависимости от региона или User-Agent, зафиксируйте это как вариант поведения. Через несколько дней после переключения обновите внутренние ссылки и sitemap, но старые адреса оставьте под контролем до завершения согласованного периода миграции.
В итоговом отчёте полезно отделить ожидаемую миграцию от неожиданного маршрута. Укажите, какой URL проверялся, какая цепочка разрешена и кто подтвердил исключение. Это особенно важно для старых русскоязычных посадочных страниц, которые могут ещё использоваться в рекламе или документации. После обновления ссылок повторите набор тестов и сравните число переходов, финальный адрес и время ответа. Так исправление будет проверено по фактическому поведению, а не только по конфигурации.