Цепочка редиректов

Как работает

Идеальный редирект — один шаг: старый URL сразу ведёт на новый через 301. Цепочка появляется, когда между ними встают промежуточные:

GET /product/old-name/          → 301 → /product/new-name/
GET /product/new-name/          → 301 → /catalog/new-name/
GET /catalog/new-name/          → 200 OK

Три запроса вместо одного, три TCP+TLS соединения, лишние 300-800 мс задержки для пользователя. Google обходит цепочки длиной до 10 переходов, но передача PageRank ослабевает на каждом шаге — по разным оценкам, на 10-15% на каждый редирект. К пятому шагу от исходного веса остаётся половина.

Типичные источники цепочек:

• смена HTTPS: http:// → https:// + смена структуры URL: /old/ → /new/ = два редиректа
• фикс trailing slash: /page → /page/ наложился на другой редирект /page/ → /new-page/
• редирект с www → без www + внутренний редирект структуры = два шага
• CDN добавляет свой уровень редиректа перед основным сервером

В Nginx каждый шаг — отдельная директива:

rewrite ^/product/old-name/?$ /product/new-name/ permanent;
rewrite ^/product/new-name/?$ /catalog/new-name/ permanent;

Правильное решение — заменить всю цепочку на один прямой редирект: /product/old-name/ сразу на /catalog/new-name/.

Почему важно для SEO

Google Search Central подтверждает: цепочки 3-5 редиректов обходятся, но передача сигналов ослабевает. Цепочки длиннее 10 — обрыв, Googlebot прекращает следовать и помечает URL как «ошибка перенаправления». В Search Console такие случаи попадают в отчёт «Индексирование страниц → Ошибка перенаправления».

Косвенный эффект — расход краулингового бюджета. Один цепочечный URL забирает 3-5 запросов у робота вместо одного. На сайте с 10 000 таких URL это тысячи впустую потраченных обходов в месяц — реальные страницы индексируются медленнее.

Для пользователя цепочка означает лишние 300-800 мс до загрузки конечной страницы. На мобильном соединении с высоким RTT — до 2-3 секунд. Прямо бьёт в TTFB и LCP, а с ними — в поведенческие сигналы для Яндекса.

Частые ошибки

• Массовые цепочки после переезда HTTPS + перепланирования структуры URL без объединения редиректов.
• Внутренние ссылки продолжают вести на старые URL, которые редиректятся, вместо прямых ссылок на новые.
• Смешанные 301 и 302 в одной цепочке — Google теряет вес на переходе от 301 к 302 полностью.
• Циклический редирект A → B → A — страница становится недоступна, Google исключает URL из индекса.
• Цепочка редиректов с изменением протокола: HTTP → HTTPS → другой домен → финальный — тратит соединения.
• Забыли обновить sitemap после серии редиректов — робот тратит бюджет на обход через цепочки.

Как проверить

В терминале — curl -L -I https://example.com/old-url/ следует по всем редиректам и показывает каждый шаг с его статусом. Онлайн-сервис httpstatus.io делает то же самое через веб-интерфейс с визуализацией цепочки. В Chrome DevTools вкладка Network → колонка Status показывает всю последовательность при загрузке URL с редиректом.

SEO Crawler при обходе сайта строит полную карту редиректов: находит цепочки длиннее 2 переходов, циклы, смешанные 301/302, помечает внутренние ссылки, ведущие на URL с редиректом. В отчёте это блок «Редиректы» — с приоритизацией правок по числу входящих внутренних ссылок и трафику затронутых URL.

Вывод

Цепочка редиректов — накапливающаяся техническая проблема: каждый переезд сайта добавляет один-два шага, если не следить за консолидацией. Держите редиректы прямыми (один шаг), обновляйте внутренние ссылки после каждого крупного переноса, регулярно проверяйте цепочки через httpstatus.io или SEO Crawler. Экономия на TTFB и краулинговом бюджете часто заметнее любых мелких on-page правок.