Цепочка редиректов и SEO: сколько переходов - это слишком много?

Цепочка редиректов - это два или более редиректа подряд между URL, который запросил кто-то, и страницей, которая наконец отвечает кодом 200. Google документирует, что Googlebot следует до 10 переходов, советует перенаправлять напрямую на итоговое место назначения и называет длинные цепочки помехой для обхода. Он не говорит, что они разрушают ранжирование, и говорит, что постоянные редиректы не вызывают потери PageRank. Так что честный вывод таков: цепочки - проблема задержки и эффективности обхода, которую стоит дёшево исправить, а не катастрофа для SEO.

Большинство цепочек строится не нарочно. Кто-то добавляет правило HTTPS, кто-то другой - правило www, маркетинговый инструмент оборачивает ссылку в трекер, и каждый переход сам по себе разумен. Ниже: как слои накладываются друг на друга, чего стоит каждый переход, какие утверждения о SEO выдерживают проверку документацией Google и как отследить и выровнять цепочку. Для начала по лексике кодов состояния карта - типы редиректов URL. Если цепочка замыкается на себя, вам нужна статья как исправить петлю редиректов.

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

Цепочка редиректов возникает, когда URL A перенаправляет на B, а B перенаправляет на C, вместо того чтобы A указывал прямо на C. Каждая стрелка - отдельный HTTP-ответ, и клиент делает новый запрос для каждого. Один редирект - норма; «цепочка» начинается с двух.

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

Как образуются цепочки редиректов

Цепочки накапливаются, потому что каждый слой навязывает собственное предпочтение. Обычные слои в порядке, в котором их встречает запрос:

• Схема. http:// переходит на https://, обычно правилом сервера или прокси.
• Хост. Корневой домен переходит на www или наоборот, в другом правиле, срабатывающем после правила схемы.
• Путь. Нормализатор завершающего слеша или нижнего регистра переписывает /Promo/ в /promo.
• Обёртка кампании или отслеживания. Трекер кликов рекламы, переписчик ссылок почтовой платформы или короткая ссылка стоит перед всем остальным.
• Устаревшая карта. Редирект от прошлого редизайна, который никто не перенастроил.

Сложите их, и простой http://example.com/Promo/ может сделать четыре перехода: на HTTPS, затем на www, затем на нормализованный путь, затем через старое правило редизайна на живую страницу. Короткие ссылки присоединяются спереди. Один переход законен. Вред начинается, когда её место назначения - не итоговый URL. Вставьте http://example.com/promo как цель, и ваша ссылка возглавит цепочку, построенную сайтом назначения незаметно для вас. Сторону ранжирования этого вопроса освещает статья вредят ли сервисы сокращения URL SEO; краткий ответ - один чистый переход допустим, а наслоенный вам предстоит исправлять.

Цепочки легко пропустить, потому что браузеры их скрывают: адресная строка показывает итоговый URL, страница загружается, и ничто не кажется неправильным. Они также проявляются только для варианта запроса, который задевает все правила, обычно для самой старой ссылки http:// на самых старых печатных материалах.

Сколько переходов проходит Googlebot?

Googlebot по умолчанию следует по цепочке до 10 переходов. Это прямо из документации краулера Google. Там же сказано, что отдельные продукты Google могут использовать другие лимиты, а инструмент проверки URL редиректам вообще не следует. Google не поясняет, что происходит с более длинной цепочкой, поэтому исходите из того, что цель просто не достигается.

Десять - потолок, а не рекомендация. Рекомендации Google по переносу сайта говорят перенаправлять прямо на итоговое место назначения, а когда это невозможно, держать цепочку короткой, «в идеале не длиннее 3 и менее 5», потому что цепочки добавляют задержку для пользователей, а не все пользовательские агенты поддерживают длинные цепочки. Запомните так: цель - один переход, допуск - несколько, жёсткая остановка - десять.

У браузеров свои пределы. Chrome сдаётся на 20 и возвращает ERR_TOO_MANY_REDIRECTS, это симптом, описанный в руководстве по петлям редиректов. Стандарт HTTP тоже не фиксирует число: RFC 9110 лишь говорит, что клиентам следует обнаруживать циклические перенаправления и вмешиваться.

Чего стоит каждый переход в задержке

Каждый переход стоит как минимум одного сетевого цикла. Переход на другое имя хоста стоит больше. Клиент разрешает новое имя, открывает TCP-соединение и завершает рукопожатие TLS, прежде чем сможет что-либо отправить. Собственный аудит Lighthouse отклоняет страницу с двумя и более редиректами и говорит, что лишний цикл может задержать ресурс «на сотни миллисекунд».

Вот арифметика, как иллюстрация, а не замер. Допустим, цикл занимает 100 мс, что обычно для мобильного соединения при среднем сигнале. Переход на новый хост с DNS, TCP и рукопожатием TLS 1.3 до запроса легко стоит от трёх до четырёх циклов, то есть 300-400 мс. Переход, использующий открытое соединение с тем же хостом, стоит один, то есть 100 мс. Цепочка из четырёх переходов с двумя новыми соединениями тратит тогда примерно 900 мс до начала настоящей страницы против около 450 мс для одного плоского редиректа.

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

Цепочки также теряют данные. Каждый переход - место, где правило перезаписи может отбросить строку запроса, а потерянный utm_source - обычный способ, которым UTM-параметры пропадают из аналитики.

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

Сначала ссылочный вес. Документация Google по переносу сайта утверждает, что «301 и другие постоянные редиректы не вызывают потери PageRank». Гэри Иллис из Google сказал то же о редиректах 30x в 2016 году, но это была публикация в соцсети, а не документация. Так что старое эмпирическое правило, что каждый переход редиректа теряет фиксированный процент веса, - фольклор. Ни один источник Google не называет процент, а числа вроде 15 процентов вы увидите повторяемыми в SEO-статьях без ссылок. Если кто-то называет вам такое число, спросите об источнике.

Цепочки всё равно не бесплатны. Задокументированы два эффекта. Во-первых, эффективность обхода: рекомендации Google по краулинговому бюджету для крупных сайтов прямо говорят избегать длинных цепочек редиректов, которые отрицательно влияют на обход. Во-вторых, задержка для пользователей, о которой говорилось выше и которая питает сигналы пользовательского опыта страницы. Краулинговый бюджет важен в основном для очень крупных или быстро меняющихся сайтов; сайт из 200 страниц вряд ли почувствует проблему краулингового бюджета из-за нескольких цепочек, хотя посетители по-прежнему ощущают цену скорости.

Есть и нюанс индексации. Google использует постоянные редиректы как канонический сигнал для цели. Какой URL будет показан, отчасти зависит от того, был ли каждый редирект временным или постоянным. Цепочка, смешивающая переходы 301 и 302, делает этот сигнал менее ясным, и это веская причина определиться с кодами один раз. Как эти сигналы взаимодействуют, разбирает статья canonical против редиректа 301.

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

Как обнаружить цепочки редиректов

Начните с curl, потому что он печатает каждый переход там, где браузер их скрывает. Первая команда показывает строку состояния и Location каждого ответа:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Чистый результат - один 3xx, затем 200. Цепочка сначала показывает две и более строки 3xx. Для подсчёта и времени, проведённого внутри редиректов, запросите у curl его собственные числа:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Две оговорки. -I отправляет запрос HEAD, а некоторые серверы отвечают на HEAD иначе, чем на GET, так что, если результат выглядит слишком чистым, повторите без -I и отбросьте тело с помощью -o /dev/null -D -. И проверяйте худший вариант, тот, который задел бы каждое правило: http://, без www, путь в верхнем регистре, завершающий слеш. Проверка только канонического URL - так цепочки и выживают. Я лучше перепроверю уродливые варианты, чем поверю чистому.

В браузере откройте инструменты разработчика, перейдите на панель Network, отметьте «Preserve log», чтобы предыдущие переходы пережили навигацию, и перезагрузите. Каждый редирект отображается отдельной строкой 301 или 302. Наша проверка ссылок показывает ту же цепочку без терминала.

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

Как выровнять цепочку редиректов

Выравнивание означает, что каждый устаревший URL указывает прямо на итоговый. Шаги по порядку:

1. Выберите каноническую форму: схема, хост, политика завершающего слеша и регистр. Запишите её.
2. Отследите каждый старый URL и запишите его итоговое место назначения.
3. Перепишите каждое правило так, чтобы оно указывало на итоговое место назначения, а не на следующее правило.
4. Обновите внутренние ссылки, карты сайта и теги rel="canonical" до итогового URL, чтобы краулеры и пользователи вообще перестали входить в цепочку.
5. Повторите трассировку и убедитесь, что переход не более одного.

Серверный приём - объединить схему и хост в одном правиле. В nginx это выглядит так, с использованием $request_uri, чтобы путь и строка запроса сохранились:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Запрос http://example.com/page теперь идёт на https://www.example.com/page за один переход, где два правила дали бы два. Эквиваленты для Apache и уровня приложения описывают статьи настройка редиректа в .htaccess и как перенаправить URL.

Сначала тестируйте с 302. Браузеры агрессивно кэшируют 301, так что ошибка задерживается. Когда цепочка сведена к одному переходу, переключитесь на постоянный код. HSTS тоже помогает: после того как браузер увидел заголовок Strict-Transport-Security, он внутренне повышает http:// до https://, так что вернувшиеся посетители вообще пропускают этот переход. Для краулеров и новых посетителей он ничего не даёт, поэтому дополняет правило одного перехода, а не заменяет его.

Если цепочки продолжают появляться, причина в процессе, а не в синтаксисе; статья профилактика гниения ссылок описывает привычку аудита, которая не даёт старым картам копиться.

Как выглядит добросовестный редирект короткой ссылки

Короткая ссылка должна быть ровно одним переходом от слага до итоговой канонической страницы, и ничем больше. Запрос приходит на короткий домен. Ответ - 3xx с местом назначения в Location. Место назначения отвечает 200 напрямую. Никакого промежуточного сервиса сокращения, никакого трекера, который снова перенаправляет, никакого места назначения, которое перескакивает на www или HTTPS, потому что вы вставили старую форму.

Код зависит от случая использования.

• 302 (или 307) для отслеживаемых, редактируемых ссылок в кампаниях, соцсетях, письмах и QR-кодах. Он позволяет позже перенаправить место назначения и сохраняет прохождение каждого клика через слой редиректа, так что аналитика остаётся полной.
• 301 (или 308), когда перенос постоянный и вы хотите, чтобы место назначения считалось каноническим, например красивый URL, навсегда заменяющий старый адрес.

Ловушку кэширования, из-за которой значение 302 по умолчанию разумно, разбирает статья редиректы 301 и 302. Две привычки удерживают цепочку на одном переходе. Всегда вставляйте итоговый URL как место назначения, один раз загрузив его и скопировав адрес из строки, и запускайте подсчёт curl выше на новых ссылках до запуска. Если хотите хранить это место назначения один раз и редактировать без повторной печати, начните с бесплатного рабочего пространства Elido и отследите свою первую ссылку командами из этой статьи.

Третьи стороны могут добавить переходы, которые вы не контролируете. Трекер кликов рекламной платформы или обёртка ссылок почтового провайдера стоят перед вашей короткой ссылкой, хотите вы того или нет, и это лучший довод держать вашу часть пути в один переход. Брендированный домен переход не добавляет, как объясняет статья собственные домены для коротких ссылок.

Эта статья входит в кластер инженерии. Полную карту кодов состояния читайте в статье типы редиректов URL, а о слое редиректов за короткой ссылкой - как работают сервисы сокращения URL.

Читайте также в блоге

• Петля редиректов: как найти и исправить ERR_TOO_MANY_REDIRECTS
• Типы редиректов URL: 301, 302, 307, 308 и другие
• Редиректы 301 и 302: какой использовать для коротких ссылок
• Вредят ли сервисы сокращения URL SEO? Честный ответ
• Canonical и редирект 301: как выбрать верный сигнал
• Как перенаправить URL: шесть способов и когда каждый подходит