Проверить цепочки и циклы редиректов

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

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

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

Пошаговая инструкция

Шаг 1. Поймите, как возникают цепочки редиректов

Цепочки не появляются намеренно — они накапливаются со временем. Типичные сценарии:

• Переезд с HTTP на HTTPS. Сначала настроили редирект с http://site.ru на http://www.site.ru, потом с http://www.site.ru на https://www.site.ru, потом с https://www.site.ru на https://site.ru. Итого: три перенаправления вместо одного.
• Редизайн и смена URL. Страница /uslugi/ была перенаправлена на /services/, через год /services/ — на /nashi-uslugi/. Цепочка: /uslugi/ → /services/ → /nashi-uslugi/.
• Слеш на конце URL. Сервер перенаправляет /page на /page/, а CMS — на /page/?ref=main, а плагин очищает параметры и перенаправляет обратно на /page/.
• Правки в .htaccess разными людьми в разное время. Каждый добавляет свои RewriteRule, не проверяя существующие, и правила начинают конфликтовать.

Шаг 2. Найдите цепочки и циклы через Screaming Frog

Screaming Frog SEO Spider — основной инструмент для обнаружения редиректов. Бесплатная версия позволяет сканировать до 500 URL.

1. Запустите Screaming Frog, введите адрес сайта и начните сканирование.
2. После завершения перейдите на вкладку «Response Codes» и отфильтруйте по коду 301 (или 302).
3. В столбце «Redirect URL» видно, куда ведёт каждый редирект. Если целевой URL сам является редиректом — это цепочка.
4. Перейдите в отчёт «Reports» → «Redirect Chains». Screaming Frog автоматически выстроит все цепочки: начальный URL → промежуточный → промежуточный → конечный. Экспортируйте отчёт в Excel.
5. Циклические редиректы Screaming Frog помечает отдельно — они будут видны как ошибки в разделе «Response Codes» → «Redirection Loop».

Шаг 3. Проверьте отдельные URL через онлайн-инструменты

Для точечной проверки используйте сервис httpstatus.io. Вставьте URL и сервис покажет всю цепочку переадресаций: каждый шаг с кодом ответа и целевым адресом. Это удобно для диагностики конкретных проблемных URL, которые вы нашли в Вебмастере или GSC.

Альтернатива — расширения для браузера: Redirect Path (Chrome) или Link Redirect Trace. Они показывают цепочку редиректов в реальном времени при переходе по ссылке.

Шаг 4. Проверьте данные в Яндекс Вебмастере и GSC

В Яндекс Вебмастере перейдите в «Индексирование» → «Страницы в поиске» → «Исключённые». Фильтруйте по причине «Редирект» — здесь собраны URL, которые Яндекс обнаружил, но не проиндексировал из-за переадресации. Если среди них есть страницы, которые должны быть доступны напрямую — значит, редирект настроен ошибочно.

В Google Search Console откройте отчёт «Страницы» → фильтр «Ошибки перенаправления». Google показывает страницы с циклическими редиректами и длинными цепочками, которые он не смог обработать.

Шаг 5. Исправьте цепочки — сократите до одного шага

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

Если цепочка выглядит так:
/uslugi/ → /services/ → /nashi-uslugi/

Исправьте на:
/uslugi/ → /nashi-uslugi/
/services/ → /nashi-uslugi/

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

В .htaccess (Apache):

RewriteEngine On
RewriteRule ^uslugi/$ /nashi-uslugi/ [R=301,L]
RewriteRule ^services/$ /nashi-uslugi/ [R=301,L]

Флаг [L] означает «последнее правило» — после срабатывания обработка RewriteRule прекращается, что предотвращает каскадные перенаправления.

В Nginx:

location = /uslugi/ {
    return 301 /nashi-uslugi/;
}
location = /services/ {
    return 301 /nashi-uslugi/;
}

Шаг 6. Устраните циклические редиректы

Циклический редирект — это когда страница A перенаправляет на B, а B — обратно на A (или A → B → C → A). Браузер показывает ошибку ERR_TOO_MANY_REDIRECTS, страница полностью недоступна.

Частые причины циклов:

• Конфликт правил в .htaccess. Одно правило перенаправляет с www на без-www, другое — обратно. Или одно правило перенаправляет на HTTPS, а другое — с HTTPS на HTTP.
• Конфликт сервера и CMS. Сервер (Nginx) перенаправляет на один URL, а WordPress (через настройку «Адрес сайта») — на другой.
• Плагин безопасности. Плагин принудительно перенаправляет на HTTPS, а сервер не настроен на работу с HTTPS и перенаправляет обратно на HTTP.

Для диагностики откройте .htaccess и прочитайте все RewriteRule последовательно. Проверьте, не противоречат ли они друг другу. В WordPress проверьте настройки: «Настройки» → «Общие» → «Адрес WordPress» и «Адрес сайта» — оба должны содержать одинаковый протокол и домен.

Шаг 7. Обработайте типовые случаи

Переезд на HTTPS. Все варианты должны вести на один конечный URL одним шагом:

• http://site.ru → https://site.ru
• http://www.site.ru → https://site.ru
• https://www.site.ru → https://site.ru

Не допускайте: http://www.site.ru → https://www.site.ru → https://site.ru. Это цепочка из двух шагов, которую легко сократить до одного.

Слеш на конце URL. Выберите один формат (со слешем или без) и настройте единое правило редиректа. Если у вас WordPress — он по умолчанию использует URL со слешем на конце.

Смена структуры URL. При редизайне составьте полную карту переадресаций: старый URL → новый URL. Проверьте, что ни один старый URL не перенаправляет на другой старый URL.

Шаг 8. Проверьте результат после исправлений

После исправления всех цепочек и циклов пересканируйте сайт через Screaming Frog. Отчёт «Redirect Chains» должен быть пустым или содержать минимум записей. Проверьте ранее проблемные URL через httpstatus.io — каждый должен показывать ровно один шаг редиректа до конечной страницы с кодом 200.

Типичные ошибки

• Добавлять новые редиректы поверх старых. Вместо того чтобы исправить существующее правило, добавляют ещё одно. Цепочка удлиняется. Всегда редактируйте правило, а не дублируйте.
• Не проверять .htaccess после обновления плагинов. Некоторые плагины WordPress (SEO-плагины, плагины безопасности, плагины кеширования) модифицируют .htaccess. Это может создать конфликт с вашими правилами.
• Использовать 302 вместо 301. 302 — временный редирект, он не передаёт ссылочный вес. Для постоянных переадресаций всегда используйте 301.
• Не обновлять внутренние ссылки. Исправили редирект, но внутренние ссылки на сайте по-прежнему ведут на старый URL. Робот каждый раз проходит через редирект вместо прямого перехода. Обновите все внутренние ссылки на актуальные URL.
• Забыть про мобильные редиректы. Если сайт перенаправляет мобильных пользователей на отдельную мобильную версию (m.site.ru), проверьте, нет ли циклов при обратном перенаправлении десктопных пользователей.
• Не учитывать CDN и кеш. Если сайт использует CDN (Cloudflare и аналоги), часть редиректов может быть настроена на уровне CDN, а часть — на сервере. Проверяйте оба уровня.

Что проверить в итоге

• Отчёт Screaming Frog «Redirect Chains» пуст или содержит только допустимые случаи.
• Ни один URL на сайте не проходит через более чем один шаг редиректа до конечной страницы.
• Отсутствуют циклические редиректы — все страницы доступны, браузер не показывает ERR_TOO_MANY_REDIRECTS.
• Все варианты домена (http/https, www/без www) перенаправляют на основной адрес одним шагом.
• Внутренние ссылки ведут на актуальные URL напрямую, а не через редиректы.
• В Google Search Console нет ошибок перенаправления в отчёте «Страницы».
• В Яндекс Вебмастере в разделе «Исключённые страницы» нет страниц, исключённых из-за ошибочных редиректов.
• Файл .htaccess (или конфигурация Nginx) структурирован, прокомментирован и не содержит конфликтующих правил.