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

В этом руководстве разберем, как увидеть все эти шаги с помощью TrueURL, curl и DevTools в браузере, что означает каждая часть цепочки редиректов и как исправить самые частые проблемы.

Что такое цепочка редиректов

Редирект происходит, когда сервер отвечает HTTP-кодом ответа 3xx и заголовком Location с другим URL. Клиент — браузер или поисковый робот — запрашивает этот URL и повторяет все то же самое, пока не получит ответ, который уже не является редиректом.

Каждый запрос вместе с ответом на него — это один переход. Вся последовательность от первого URL до окончательного ответа называется цепочкой редиректов:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Три редиректа и четыре запроса ради одной страницы. Адрес в Location на третьем переходе относительный: клиенты достраивают его от только что запрошенного URL, как предписывает RFC 9110, поэтому он означает https://www.example.com/shoes/. В идеале каждый из этих адресов должен вести на конечный URL за один переход.

Страница может выполнить редирект и после ответа 200 OK — с помощью тега <meta http-equiv="refresh"> или JavaScript. Такие клиентские редиректы тоже входят в цепочку, но инструменты, которые читают только HTTP-заголовки, например curl, на этой странице останавливаются.

Зачем проверять редиректы

SEO: канонический URL и краулинговый бюджет

Поисковые системы воспринимают редирект как указание, какой URL индексировать. Google считает постоянные редиректы (301 и 308) сильным сигналом того, что канонической должна быть целевая страница, а временные (302, 303 и 307) — слабым сигналом. Поэтому страница, которая переехала навсегда, но через 302 редирект, может остаться в результатах поиска со старым URL.

Важна и длина цепочки. Googlebot проходит не более 10 переходов: если к этому моменту контент не получен, Search Console сообщает об ошибке редиректа. В руководстве Google по краулинговому бюджету также советуют избегать длинных цепочек редиректов: по словам Google, они плохо сказываются на сканировании.

Скорость загрузки

Конечная страница не начнет загружаться, пока не придет ответ на последний редирект. Каждый переход — это дополнительный сетевой цикл «запрос — ответ», а переход на новый хост требует еще и DNS-запроса, нового соединения и, в случае HTTPS, TLS-рукопожатия. В мобильных сетях три-четыре редиректа могут добавить несколько сотен миллисекунд до первого байта нужной страницы. Инструмент «Проверка скорости редиректов» покажет, сколько стоит каждый переход.

Безопасность коротких и незнакомых ссылок

Короткие ссылки и многие трекинговые ссылки в письмах скрывают адрес назначения. Кроме того, фишинговые рассылки используют открытые редиректы на известных доменах, поэтому ссылка, которая начинается на надежном сайте, может привести совсем в другое место. Инструмент «Раскрытие коротких ссылок» еще до клика покажет все домены по пути, а также то, есть ли в цепочке переход с HTTPS на обычный HTTP.

Партнерские и трекинговые ссылки

Маркетинговые ссылки часто проходят через несколько сервисов, прежде чем попасть на посадочную страницу, и каждый из них должен передать строку запроса дальше, иначе UTM-метки, идентификаторы кликов и партнерские метки незаметно теряются. По конечному URL видно, сохранились ли они и ведет ли ссылка по-прежнему на нужную страницу.

Переезд сайта, HTTPS и канонический хост

После редизайна, смены домена или перехода на HTTPS каждый старый URL должен вести на свой новый аналог одним постоянным редиректом. Все четыре базовых варианта адреса сайта (http:// и https://, с www и без) должны приводить на один канонический адрес. Такие правила ломаются незаметно: новое правило в CDN, обновление плагина или переезд на другой сервер могут добавить лишний переход или цикл, и никто этого не заметит.

Как проверить редирект с помощью TrueURL

TrueURL выполняет каждую проверку в edge-сети Cloudflare (на серверах Cloudflare, ближайших к пользователю), поэтому подозрительные ссылки можно изучить, не открывая их в браузере. Инструмент «Проверка редиректов URL» на главной странице проверяет один URL, а «Проверка цепочки редиректов» и другие специализированные инструменты используют тот же механизм проверки.

Шаг 1. Введите URL

Вставьте URL и запустите проверку. Если схема не указана, подставляется https://; чтобы проверить обычный HTTP, введите адрес с http://.

Шаг 2. При необходимости измените дополнительные настройки

По умолчанию сервис отправляет запрос GET с User-Agent актуальной десктопной версии Chrome, без файлов cookie и с лимитом в 20 редиректов. Все это можно изменить в разделе Дополнительные настройки:

  • HTTP-метод: GET, HEAD или POST. HEAD легче, но некоторые серверы отвечают на него иначе, а без тела ответа клиентские редиректы обнаружить нельзя. POST отправляет введенное вами тело запроса — это нужно для обработчиков форм и API. Следующие переходы подчиняются правилам браузера: после POST ответы 301 и 302 продолжают цепочку методом GET, 303 делает это всегда, а 307 и 308 сохраняют метод и тело запроса.
  • Максимум переходов: сколько редиректов пройти, от 1 до 50. Значение по умолчанию, 20, — это лимит, заданный в стандарте Fetch и принятый в Chrome и Firefox. Установите 10, чтобы узнать, укладывается ли цепочка в лимит Googlebot.
  • Пользовательский User-Agent: если поле пустое, используется десктопный Chrome. Среди готовых вариантов — Safari на iPhone, Chrome на Android, Googlebot (для смартфонов и для десктопа), Bingbot, боты предпросмотра ссылок Facebook и X, а также curl.
  • Пользовательские заголовки запроса: дополнительные заголовки, которые отправляются на каждом переходе, например Accept-Language: fr-FR, чтобы вызвать редирект по языку.
  • Cookie: введите name=value; other=value, чтобы воспроизвести состояние после входа в аккаунт, согласия или выбора региона. Файлы cookie, установленные по ходу цепочки, сохраняются для следующих переходов, как в браузере.
  • Клиентские редиректы: следовать тегам meta refresh и простым JavaScript-редиректам или только сообщать о них.
  • Игнорировать ошибки SSL: edge-сеть Cloudflare всегда проверяет сертификаты, поэтому пропустить неисправный сертификат эта настройка не позволит. Ошибка TLS показывается на том переходе, где она возникла.

Шаг 3. Изучите результат

В начале результата показаны конечный URL и его код ответа. Ниже идет цепочка — по строке на каждый переход, где указаны:

  • запрошенный URL и использованный HTTP-метод;
  • код ответа и поясняющая фраза (каждый код описан в справочнике кодов ответа);
  • время ответа — от отправки запроса до получения заголовков, включая DNS-запрос и установку соединения, если они понадобились;
  • адрес из Location, на который указывает переход;
  • заголовки ответа и имена файлов cookie, установленных на этом переходе.

У каждого редиректа отмечено, как он произошел: через код ответа HTTP, meta refresh (с задержкой в секундах) или JavaScript. Клиентские редиректы, которые были найдены, но не пройдены, тоже показываются. Не менее важно, чем закончилась проверка:

Итог Что это значит
Окончательный ответ Цепочка дошла до ответа, который не является редиректом, например 200 OK или 404 Not Found.
Циклический редирект Следующий запрос повторил бы один из предыдущих: тот же URL, метод и файлы cookie. В результате видно, какой переход замыкает цикл.
Достигнут лимит переходов Когда лимит был исчерпан, цепочка все еще продолжалась. Следующий адрес показан, но не запрошен.
Ошибка Один из переходов завершился сбоем (DNS, соединение, TLS или тайм-аут) либо адрес редиректа оказался некорректным или недопустимым URL.

Предупреждения отмечают временный редирект в цепочке, переход с HTTPS на HTTP, больше трех редиректов, конечный URL на другом домене, клиентские редиректы и запросы HEAD, при которых не удалось прочитать тело страницы.

К одному предупреждению стоит отнестись внимательно. Некоторые сайты показывают автоматическому трафику и трафику из дата-центров страницу проверки на бота, например страницу Cloudflare «Just a moment...». TrueURL помечает похожие ответы, потому что запрос уперся в защиту сайта, а не дошел до адреса назначения. Настоящий посетитель может оказаться совсем в другом месте.

Как проверить редиректы из командной строки

curl предустановлен в macOS, Windows 10 и 11 и большинстве дистрибутивов Linux. Он показывает ровно то, что отправляет сервер, без участия кэша браузера. В примерах используется командная оболочка Unix; в Windows PowerShell 5.1 вводите curl.exe, потому что там curl — это псевдоним Invoke-WebRequest, а вместо /dev/null пишите NUL.

Один переход

Bash
curl -I https://example.com/old-page

-I отправляет запрос HEAD и выводит заголовки ответа, включая строку состояния и Location, если он есть. Сам по себе curl редиректам не следует. Некоторые серверы обрабатывают HEAD иначе, поэтому, если результат выглядит странно, повторите проверку запросом GET: -o /dev/null отбрасывает тело ответа, а -D - выводит заголовки:

Bash
curl -sS -o /dev/null -D - https://example.com/old-page

Вся цепочка целиком

-L включает следование редиректам, а с -I или -D - curl выводит заголовки каждого перехода. Фильтр через grep оставляет компактную сводку:

Bash
curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

По умолчанию curl проходит до 50 редиректов; --max-redirs 10 задает лимит Googlebot.

Только конечный URL

Параметр -w (write-out) выводит сведения после завершения запроса и превращает curl в компактный инструмент для раскрытия коротких ссылок:

Bash
curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} — последний запрошенный URL, %{num_redirects} — число пройденных редиректов, %{http_code} — итоговый код ответа. %{time_redirect} показывает, сколько секунд ушло на редиректы до последнего запроса. Без -L переменная %{redirect_url} показывает, куда вел бы первый редирект.

Проверка POST-запросов

-d отправляет тело запроса и превращает запрос в POST. При следовании редиректам curl в этом случае ведет себя как браузер: после 301, 302 или 303 переключается на GET, а после 307 или 308 повторно отправляет POST вместе с телом.

Bash
curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Не сочетайте -X POST с -L. -X принудительно задает метод для каждого запроса, поэтому curl продолжит отправлять POST после 301, 302 или 303, хотя браузер переключился бы на GET, и вы проверите цепочку, которую не воспроизводит ни один реальный клиент.

Bash
# User-Agent смартфона
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Дополнительный заголовок запроса
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Отправить cookie и сохранить cookie, установленные по ходу цепочки
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A задает User-Agent, -H добавляет заголовок, а -b отправляет файлы cookie. -c сохраняет полученные cookie в файл и включает в curl механизм работы с cookie, так что cookie, установленный на одном переходе, отправляется на следующем.

curl не выполняет JavaScript и не реагирует на теги meta refresh. Если последний ответ в curl — HTML-страница с 200 OK, а браузер в итоге оказывается в другом месте, значит, редирект происходит на стороне клиента.

Как проверить редиректы в DevTools браузера

DevTools показывает цепочку так, как ее видит ваш собственный браузер, — с вашими файлами cookie, расширениями и местоположением:

  1. Откройте DevTools (F12 или Cmd+Option+I на Mac) и перейдите на вкладку Network.
  2. Включите Preserve log в Chrome и Edge или Persist Logs в меню настроек сети в Firefox. Иначе список очищается при каждой загрузке страницы и клиентские редиректы пропадают из виду.
  3. Включите Disable cache, чтобы закэшированный редирект не скрыл то, что сервер отправляет сейчас.
  4. Введите URL в адресной строке.

Каждый переход отображается отдельной строкой со своим кодом 3xx; выберите ее и откройте Headers, чтобы увидеть заголовок ответа location. Если в Chrome в столбце Size указано «(disk cache)» или «(memory cache)», редирект взят из кэша, а не получен от сервера.

Иногда Chrome показывает 307 Internal Redirect с http:// на https://. Сервер его не отправлял: браузер сам перевел запрос на HTTPS, обычно потому, что у него сохранена политика HSTS для этого сайта. Чтобы увидеть, что сервер делает с обычным HTTP, используйте curl или TrueURL.

Типичные проблемы с редиректами и их решение

Цепочки длиннее одного перехода

Цепочки нарастают слоями: правило, оставшееся от старого переезда, указывает на URL, который при следующем переезде снова перенаправили. Направьте каждое правило сразу на конечный адрес и обновите внутренние ссылки, теги canonical, разметку hreflang и карты сайта, чтобы ваш собственный сайт никогда не вызывал редиректов. Инструмент «Массовая проверка редиректов» покажет, каким старым URL все еще нужно больше одного перехода.

Циклические редиректы

Chrome сообщает о цикле фразой «redirected you too many times» (ERR_TOO_MANY_REDIRECTS), Firefox — «The page isn't redirecting properly». Типичные причины:

  • HTTPS за прокси или CDN. Исходный сервер перенаправляет HTTP на HTTPS, но прокси обращается к нему по обычному HTTP, поэтому сервер никогда не видит HTTPS и перенаправляет до бесконечности. В Cloudflare это классическое следствие режима SSL/TLS Flexible; используйте Full (strict) или настройте исходный сервер так, чтобы он проверял X-Forwarded-Proto.
  • Два уровня с противоречащими правилами: например, правило CDN убирает www, а сервер его добавляет, или фреймворк добавляет слеш в конце URL, который CDN удаляет.
  • Редиректы, зависящие от cookie. Страница входа или согласия отправляет посетителей обратно на исходный URL, а тот снова перенаправляет их на страницу входа, потому что cookie не сохранился.

Инструмент «Проверка циклических редиректов» покажет, какой переход замыкает цикл. После этого сделайте так, чтобы за каждое правило отвечал только один уровень.

301 и 302 в одной цепочке

Цепочка «301, затем 302, затем 200» — это постоянный переезд с временным шагом посередине. Часто виновато значение по умолчанию: и res.redirect() в Express, и header('Location: ...') в PHP отправляют 302, если явно не указано иное. Используйте постоянный код на каждом переходе и проверьте результат инструментом «Проверка 301 редиректа». Когда какой код уместен, объясняется в нашей статье о кодах редиректов HTTP.

Двойной переход: HTTP → HTTPS → www

Очень распространенная цепочка: http://example.com → https://example.com → https://www.example.com, то есть два перехода там, где хватило бы одного. Перенаправляйте каждый неканонический вариант сразу на конечный URL с HTTPS, а затем проверьте все четыре варианта инструментом «Проверка редиректа на HTTPS».

Есть одно намеренное исключение. Если ваш канонический хост — с www и вы добавляете домен в список предварительной загрузки HSTS (HSTS preload), hstspreload.org требует, чтобы http://example.com сначала перенаправлял на https://example.com: так браузеры запомнят политику HSTS для домена без www.

Непоследовательный слеш в конце URL

/pricing и /pricing/ — это разные URL. Если оба отвечают 200 OK, у вас дублированный контент (дубли страниц); если два уровня перенаправляют эти варианты друг на друга, получается цикл. Выберите одну форму, перенаправьте на нее вторую одним 301 редиректом и везде ссылайтесь на выбранную. Инструмент «Проверка слеша в конце URL» проверяет обе формы сразу.

Редиректы только для мобильных

Отдельные мобильные сайты, предложения установить приложение и определение устройства иногда отправляют посетителей со смартфонов в другое место — часто на главную страницу мобильной версии вместо соответствующей страницы. При индексировании с приоритетом мобильного контента Google сканирует сайты в основном роботом для смартфонов, поэтому для индексирования важнее всего именно мобильная цепочка. Сравните обе цепочки инструментом «Проверка редиректов для мобильных и десктопа».

Редиректы в карте сайта

В карте сайта должны быть канонические URL, которые вы хотите видеть в результатах поиска, а такие URL отвечают 200 OK. Записи с редиректами впустую расходуют запросы на сканирование и посылают противоречивые сигналы о каноническом URL. Запускайте инструмент «Проверка редиректов в Sitemap» после каждого переезда и заменяйте каждую запись с редиректом ее конечным URL.

JavaScript-редиректы и meta refresh

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

Чек-лист по редиректам

Пройдитесь по этому списку после переезда сайта, изменений в CDN или перед запуском рекламной кампании:

  1. Каждый старый URL ведет на конечный адрес за один переход.
  2. Для постоянных переездов на каждом переходе используется 301 или 308.
  3. Все четыре варианта протокола и хоста заканчиваются на каноническом URL с HTTPS.
  4. Ни один переход не ведет с HTTPS на HTTP.
  5. Строки запроса, включая UTM-метки и партнерские ID, сохраняются по всей цепочке.
  6. У каждого URL одна форма слеша в конце, а другая перенаправляет на нее.
  7. Запросы с десктопа, со смартфона и от Googlebot заканчиваются на равнозначных страницах.
  8. Везде, где это возможно, вместо meta refresh и JavaScript используются серверные редиректы.
  9. Внутренние ссылки, теги canonical, hreflang и карты сайта указывают на конечные URL.
  10. Удаленные страницы, у которых нет замены, возвращают 404 или 410, а не перенаправляют на главную.
  11. Редиректы после переезда сайта остаются на месте; Google рекомендует сохранять их не меньше года.