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

Пять переходов. Столько робот делал, чтобы добраться до карточки товара на сайте, который перед этим три года никто не трогал руками. Адрес из старой ссылки вёл на версию без защищённого протокола, та отправляла на вариант с www, тот — на адрес без слеша в конце, дальше срабатывало правило смены раздела, и только пятый ответ отдавал содержимое. Каждый переход занимал от 90 до 210 миллисекунд. В сумме — почти секунда до первого байта настоящей страницы, и это на быстром сервере в Москве.

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

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

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

Редирект — это ответ сервера, который вместо содержимого отдаёт код перенаправления и заголовок Location с новым адресом. Код 301 означает «переехали навсегда», 302 и 307 — «временно», 308 — «навсегда, метод запроса не менять». Браузер и робот идут по указанному адресу и повторяют запрос.

Цепочка возникает, когда по новому адресу их встречает ещё один редирект. Потом ещё один. Формально ничего не сломано: пользователь в итоге попадает куда надо и даже не замечает задержки. Фактически один запрос превращается в три-пять, а поисковая система вынуждена тратить ресурсы на обход служебных ответов вместо содержимого.

Причина невидимости простая. Браузер отрабатывает цепочку молча — в адресной строке вы видите только финал. Инструменты проверки позиций работают с конечным адресом. Метрика фиксирует просмотр итоговой страницы. Даже сканер, если в настройках не включено отображение промежуточных звеньев, покажет вам колонку «Status Code: 200» и не соврёт: конечный ответ действительно двухсотый. Чтобы увидеть проблему, нужно смотреть не на результат, а на путь.

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

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

Откуда берутся цепочки: восемь источников из практики

Никто не создаёт цепочки специально. Они нарастают слоями, как краска на старой двери: каждый слой наносил свой человек, в своё время, по своей уважительной причине. Вот источники, которые я встречаю чаще всего.

Источник	Что появляется в цепочке	Как часто встречаю
Переход на защищённый протокол	Правило «с http на https» отдельным слоем поверх всех остальных	Почти на каждом сайте старше пяти лет
Склейка www и без www	Второе независимое правило, срабатывающее после первого	Очень часто
Нормализация слеша в конце адреса	Третье правило, отрабатывающее последним	Часто
Смена структуры разделов	Правило вида «старый раздел → новый раздел», наложенное на предыдущие	После каждого редизайна
Переезд на новый домен	Слой, который поднимает длину каждой цепочки на единицу	При смене имени сайта
Склейка региональных поддоменов	Постраничные правила, где новый адрес сам уже редиректится	У сетевых и мультирегиональных проектов
Защитные домены и опечаточные имена	Переадресация на основной сайт по старому правилу	Когда домены покупали разные подрядчики
Плагины и модули CMS	Собственные правила движка поверх серверных	Регулярно, особенно на WordPress и Bitrix

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

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

Сколько это стоит на самом деле

Аргумент «ну работает же» разбивается о четыре измеримые потери. Разберу каждую с цифрами, которые можно проверить на своём сайте.

Краулинговый бюджет. Робот приходит на сайт с ограниченным лимитом запросов. Каждый служебный ответ 301 — это израсходованный запрос, который не принёс в индекс ни строчки контента. Считается на пальцах: если у вас 12 000 адресов, из которых 1 400 отдают цепочку из трёх переходов, то на служебные ответы уходит 4 200 запросов вместо 1 400. Три тысячи потраченных впустую обращений робота — это примерно неделя обхода среднего сайта. Для больших проектов разница между «новые страницы в индексе через два дня» и «через три недели» часто упирается именно в это.

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

Скорость. Каждый переход — это новый цикл запроса: DNS при смене хоста, установка соединения, TLS-рукопожатие, ответ сервера. На проводном интернете это 60–150 мс, на мобильном 4G — 200–400 мс на каждый хоп. Цепочка из трёх переходов на телефоне легко добавляет секунду к времени до первого байта. Это прямо бьёт по показателям загрузки, которые учитываются при ранжировании, и по поведению людей — тема пересекается с оптимизацией сайта под мобильные устройства.

Внешние ссылки. Самое обидное. Отраслевой портал поставил на вас ссылку в 2019 году. С тех пор сайт сменил протокол, структуру и домен. Ссылка формально жива, но ведёт в четырёхзвенную цепь. Переписать её у чужого редактора вы не сможете, а значит, единственный способ сохранить ценность — сделать так, чтобы старый адрес вёл на конечную страницу за один переход.

Длина цепочки	Что наблюдаю на практике	Приоритет исправления
1 переход	Норма, ничего чинить не нужно	—
2 перехода	Замедление обхода, потерь почти нет	Плановый, в общей уборке
3 перехода	Заметно реже переобход, страницы дольше обновляются в поиске	Высокий
4 и больше	Часть адресов подолгу висит без переобхода, вес до конца доходит плохо	Срочный
Петля	Страница недоступна вообще, браузер отдаёт ошибку	Аварийный

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

Порядок важен, потому что каждый следующий метод видит то, что предыдущий пропускает.

Метод первый: точечная проверка через curl. Самая честная проверка, потому что показывает всю последовательность ответов без интерпретации. Команда curl -sIL "https://site.ru/staryj-adres/" | grep -E "HTTP/|Location" выводит каждый код ответа и каждый Location по порядку. Прогоните так десяток адресов из старых ссылок, из рекламных кампаний, из визиток. Если увидите больше одной строки с кодом 301 — дальше можно не гадать, проблема есть, вопрос только в масштабе.

Отдельно проверьте то же самое с подменой агента: curl -sIL -A "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)". На сайтах за облачной защитой или с региональной логикой ответ роботу и ответ браузеру нередко различаются, и цепочка, невидимая с вашего компьютера, спокойно живёт для поискового робота.

Метод второй: сканирование. Screaming Frog, Netpeak Spider, любой аналог. Важно не просто просканировать, а включить отображение промежуточных ответов и выгрузить отдельный отчёт по цепочкам — в Screaming Frog это Reports → Redirects → Redirect Chains. На выходе получите таблицу: исходный адрес, каждое звено, финальный адрес, суммарное количество переходов. Сортируйте по количеству и начинайте сверху.

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

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

Дальше берёте топ-100 таких адресов и прогоняете их через curl или сканер в режиме списка. Это и есть рабочая карта проблемы: не «все 12 000 адресов сайта», а «сто адресов, которые кому-то реально нужны». Разница по трудоёмкости — в десятки раз. Практическую логику работы с техническими отчётами я разбираю в рубрике Техническое SEO, там же лежат смежные материалы по индексации.

Четвёртый, вспомогательный источник — панели вебмастеров. В Яндекс.Вебмастере полезен раздел со статистикой обхода: там видно, какая доля запросов робота уходит на коды 3xx. Если эта доля выше 10–15%, чинить нужно не откладывая.

Кейс: как склейка семнадцати поддоменов чуть не создала цепочки на весь сайт

Расскажу свою историю, потому что она показательна: цепочки чаще всего возникают не от небрежности, а в момент правильного и осознанного действия.

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

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

Само по себе это не катастрофа. Но склейка семнадцати доменов — операция, где робот и так делает огромный объём работы, и удваивать её на ровном месте было бы глупо. Лечение заняло полчаса: правила переписаны так, чтобы поддоменный адрес сразу приводился к каноническому виду с нужным слешем. Результат склейки при этом оказался быстрым — по одному из главных высокочастотных запросов сайт вошёл в топ-10 по новому региону через три дня после операции.

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

Как распрямлять: правила, которые работают

Общий принцип формулируется одной фразой: любой адрес, который когда-либо существовал, должен приводить на актуальную страницу за один переход. Не за два и не «хотя бы куда-нибудь». За один, и на смысловой аналог.

Ситуация	Правильное решение	Типовая ошибка
Три слоя нормализации: протокол, www, слеш	Одно правило, приводящее адрес к каноническому виду сразу	Три последовательных правила, каждое «правильное»
Старый адрес ведёт на адрес, который сам переехал	Переписать первое правило на конечный адрес	Добавить ещё одно правило поверх
Раздел переименован дважды за пять лет	Все три варианта адреса ведут напрямую на текущий	Оставить историческую последовательность как есть
Страница удалена, аналога нет	Код 410 или информативная страница ошибки с навигацией	Перенаправление на главную «чтобы не терять посетителя»
Защитный или опечаточный домен	Одно постоянное перенаправление на каноническую страницу	Цепочка через промежуточный домен-прокладку
Мобильная версия на отдельном поддомене	Прямое соответствие адресов без промежуточных шагов	Поддомен → десктоп → раздел → страница
Меняется регистр в адресах	Одно правило приведения к нижнему регистру, до всех остальных	Правило после структурных, отсюда лишний переход

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

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

Ошибки, которые совершают уже при исправлении

• Петля. Правило A отправляет на B, правило B — обратно на A. Браузер отдаёт ошибку «слишком много перенаправлений», страница недоступна полностью. Возникает почти всегда при ручной правке большого файла конфигурации без проверки.
• Временный код вместо постоянного. 302 и 307 говорят поисковой системе «не переклеивай, скоро вернётся». Если переезд навсегда — только 301 или 308. Временный код, оставленный на год, надёжно тормозит склейку адресов.
• Конфликт с каноническим адресом. Страница отдаёт перенаправление на B, а на B в разметке указан канонический адрес A. Поисковая система получает два противоположных сигнала и выбирает сама — обычно не в вашу пользу.
• Правило, написанное без учёта порядка. В конфигурации сервера правила отрабатывают сверху вниз. Новое правило, дописанное в конец файла, может никогда не сработать, потому что раньше него отработает более общее.
• Регулярное выражение, которое ловит лишнее. Классика: правило для раздела /uslugi без якоря конца строки заодно ловит /uslugi-remonta и отправляет его туда же.
• Правка на живом сайте без копии конфигурации. Файл перенаправлений на большом проекте — это документ на сотни строк. Перед любой правкой делается копия, после правки — прогон списка адресов сканером.
• Забытый файл карты сайта. В карте остаются старые адреса, которые теперь отдают перенаправление. Робот исправно ходит по ним и снова тратит бюджет.

Про последний пункт: карта сайта должна содержать только конечные адреса с кодом 200. Ни одного перенаправления, ни одной ошибки. Это проверяется за минуту прогоном карты через сканер в режиме списка и почему-то почти никогда не проверяется. Больше типовых промахов такого рода я собрал в материале про SEO-ошибки сайта.

Регламент, чтобы цепочки не отрастали заново

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

1. Единая таблица перенаправлений. Один файл или одна таблица, где записаны все правила с датой и причиной. Не в трёх местах: часть на сервере, часть в плагине, часть в коде.
2. Проверка при каждом новом правиле. Написали — прогнали десять адресов через curl. Пять минут работы, экономят недели.
3. Ежеквартальный прогон сканером. Отчёт по цепочкам, порог тревоги — любая цепь длиннее одного перехода.
4. Проверка логов раз в месяц. Доля кодов 3xx в общем объёме ответов роботу. Растёт — ищите причину.
5. Ревизия карты сайта. Только конечные адреса.
6. Проверка перед любым крупным изменением. Перед сменой структуры, домена или движка — снимок всех текущих правил. Подробно этот порядок я расписывал в статье про редизайн сайта без потери позиций.
7. Контроль внешних доменов. Опечаточные и защитные имена проверяются отдельно — по ним цепочки обнаруживаются чаще всего, потому что настраивал их обычно другой человек и давно. Про сам механизм таких доменов есть разбор в материале о киберсквоттинге и защите домена.

Частые вопросы

Сколько переходов допустимо? Рабочий ориентир — один. Два — терпимо, если распрямить прямо сейчас нет возможности. Три и больше — работа, которую нужно ставить в план на ближайшую неделю.

Правда, что 301 теряет часть веса? Официально — нет, поисковые системы говорят о полной передаче. На практике разница между прямой ссылкой и ссылкой через три перекладки видна в скорости переобхода и в том, как страница закрепляется в выдаче. Я исхожу из того, что каждый лишний переход — это риск, который ничего не даёт взамен. Смысла держать его нет.

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

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

Влияет ли это на видимость в ответах нейросетей? По моим наблюдениям — да, и сильнее, чем на классический поиск. Краулеры генеративных систем менее терпимы к длинным цепочкам и чаще просто не доходят до содержимого. Если для вас важно попадать в ответы YandexGPT, GigaChat или ChatGPT, техническая чистота адресов — базовое условие, без которого остальная работа над контентом не окупается.

Кто это должен делать — программист или SEO-специалист? Диагностику и таблицу соответствия — специалист по поиску, потому что нужно понимать, какой адрес какому аналогичен по смыслу. Внедрение — программист. Проверку после внедрения — снова специалист. Если этот цикл разорвать, обычно получается технически исправный, но бессмысленный набор перенаправлений.

Коротко

• Цепочка редиректов — это когда робот делает два и больше перехода, прежде чем получить содержимое. В браузере и в отчётах она не видна.
• Цепочка почти никогда не одна ошибка: это наложение нескольких независимо написанных правил — протокол, www, слеш, структура, домен.
• Потери измеримы: краулинговый бюджет, скорость на мобильных, ссылочный вес и ценность внешних ссылок.
• Искать нужно в трёх местах по порядку: точечно через curl, массово сканером, а главное — по логам сервера, потому что только они показывают адреса, по которым реально ходят.
• Распрямлять нужно не последнее звено, а первое — и каждую точку цепи, чтобы с любого адреса до финала был ровно один шаг.
• Перенаправление удалённых страниц на главную вредит: лучше честная страница ошибки с навигацией.
• Один раз почистить мало — нужен регламент: единая таблица правил, проверка каждого нового правила, ежеквартальный прогон и ревизия карты сайта.

Если трафика не хватает, а причина непонятна

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

Меня зовут Анатолий Кузнецов, я частный SEO-специалист из Санкт-Петербурга. В поиске с 2005 года, за это время через мои руки прошло больше 300 проектов, часть сайтов под моим ведением держит первое место в Яндексе восьмой год подряд. Работаю напрямую, без агентских прослоек и менеджеров-посредников: проект ведёт тот же человек, который его диагностировал. Только белые методы — ничего, за что сайт может получить фильтр через полгода.

Что предлагаю:

• SEO-продвижение сайта — системная работа со всеми основными факторами ранжирования, которых на сегодня 1922. Методику не раскрываю: это собственное know-how, собранное за двадцать лет. Продаю результат, а не описание процесса. Тариф «Старт» — от 55 000 ₽ в месяц.
• GEO-продвижение — вывод сайта в ответы генеративных систем: YandexGPT, GigaChat, ChatGPT, Perplexity. Направление, которым я занялся раньше большинства коллег на российском рынке, и сейчас оно даёт трафик, за который ещё никто не конкурирует всерьёз.
• Бесплатный аудит сайта — если хотите сначала понять масштаб проблем. Цепочки редиректов, кстати, всплывают в нём почти всегда.
• SEO-консультация — разбор конкретной ситуации с готовым списком действий, если работать планируете своими силами.
• Доработка сайта — когда понятно, что чинить, но некому.

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

Напишите через форму обратной связи или позвоните: +7 (921) 333-77-45. Посмотрю ваш сайт, скажу, что с ним реально происходит, и честно предупрежу, если продвижение вам сейчас не нужно.