Проверка редиректов: цепочки и петли, которые съедают вес страниц

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

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

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

Краулер по сайту. Screaming Frog, Netpeak Spider или SiteAnalyzer запускаются обычным обходом от главной; в отчёте интересует всё, что отдало 301, 302, 303, 307 и 308. Обязательно включите опцию Always Follow Redirects и выгрузите отчёт Redirect Chains — он показывает не конечную точку, а весь путь со всеми звеньями. Без него краулер покажет финальный код 200 и скроет два переезда, которые к нему привели.

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

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

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

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

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

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

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

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

Конструкция	Что получает робот	Что с весом	Срочность
Прямой 301 на релевантную страницу	Один запрос, сразу конечный адрес	Передаётся почти полностью	Норма
Цепочка из двух звеньев	Два визита вместо одного	Передаётся, склейка откладывается	Плановая
Цепочка из трёх и более звеньев	Каждое звено — отдельный визит	Склейка откладывается на месяцы	Высокая
Цепочка с 302 внутри	Сигнал «переезд временный»	Не передаётся или передаётся частично	Высокая
Петля из адресов	Ошибка соединения, содержимое не получено	Страница выпадает из индекса	Критическая
Редирект на главную с удалённой страницы	Код 200 вместо 404	Растёт доля мягких 404	Высокая

Петли редиректа: откуда берутся и как находятся

Петля — это замкнутый путь переходов: адрес A ведёт на B, B возвращает на A. Браузер после определённого числа переходов сдаётся и показывает ERR_TOO_MANY_REDIRECTS. Apache в части конфигураций отдаёт код 500, а при исчерпании внутренних переходов в mod_rewrite — 508 Loop Detected. Робот содержимое не получает, и страница уходит из индекса как недоступная.

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

Вторая причина — перевод на защищённый протокол по переменной %{HTTPS} на сервере за прокси или балансировщиком. До приложения запрос доходит по HTTP, переменная всегда пустая, правило срабатывает всегда, адрес циклится сам на себя. Лечится проверкой заголовка X-Forwarded-Proto.

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

Находятся петли двумя способами. Краулер помечает такие адреса статусом Redirect Loop — этот фильтр просматривается первым. Точечно адрес проверяется командой curl -I с переходом по заголовку Location: адреса начали повторяться — петля найдена.

Редирект на главную вместо релевантной страницы

Решение выглядит удобным: удалили раздел, поставили правило «всё, чего нет, ведёт на главную», и ошибок 404 формально не осталось. На практике так создаётся проблема неприятнее, чем честные битые адреса.

Поисковая система сравнивает содержимое исходного адреса и адреса назначения. Если страница про ремонт рулевой рейки ведёт на главную, где эта тема упомянута в одном пункте меню, переезд признаётся нерелевантным. Дальше либо старый адрес остаётся в индексе как страница с содержимым главной, либо помечается как мягкая ошибка 404 — формально код 200, фактически заглушка. В Google это отдельный тип в отчёте «Индексирование страниц», в Яндексе такие адреса копятся в исключённых с формулировкой о недостаточном качестве.

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

Порядок решений для удалённой страницы такой. Есть прямая замена — товар другой модели, обновлённая статья на ту же тему — ставите 301 на неё. Замены нет, но есть родительская категория — 301 на категорию, это ещё релевантно. Ни того ни другого нет — оставляете честный 404 или 410. Код 410 сообщает роботу, что адрес удалён окончательно, и из индекса такие страницы выпадают быстрее.

Протокол и слеш: четыре версии одного адреса

У любого адреса есть минимум четыре технически разных варианта: с HTTP и HTTPS, с www и без. Умножьте на две версии окончания — со слешем и без — получите восемь. Задача: убедиться, что семь ведут на восьмой одним переходом, а не двумя и не по кругу.

Проверять нужно вручную: краулер стартует от главной и промежуточные комбинации может не встретить. Составьте список из восьми адресов для любой внутренней страницы и прогоните каждый через curl -I. Правильно: первый же ответ несёт 301 и Location с канонической версией. Неправильно: HTTP без www ведёт на HTTP с www, тот на HTTPS с www и только потом на HTTPS без www — три звена вместо одного.

Конструкция возникает почти всегда одинаково: сначала включили www, потом добавили перевод на HTTPS отдельной строкой, потом отказались от www и дописали третье правило. Чинится объединением в одно правило.

Со слешем тоньше. Технически /uslugi и /uslugi/ — разные адреса, и оба могут отдавать 200. Выбор варианта на ранжирование не влияет, влияет последовательность: работает один, второй отдаёт на него 301. Проверьте, что внутренние ссылки, карта сайта и canonical указывают на тот же вариант, что и правило редиректа. Расхождение canonical с редиректом — отдельный источник путаницы, о нём есть разбор Clean-param vs canonical vs 301: что куда и почему путаница стоит позиций.

Отдельно проверьте главную: частая ошибка — правило приведения /index.php к корню, написанное так, что корень сам попадает под условие, и получается петля на главной. Если переезд на защищённый протокол был недавно, пройдите по чек-листу из материала Переход WordPress на HTTPS: смешанный контент, редиректы и что проверить в Вебмастере.

Внутренние ссылки, которые ведут на старые адреса

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

Внешние ссылки вы не контролируете, и редирект для них — единственное решение. Внутренние контролируете полностью, и оставлять их на старых адресах значит платить за переход, которого можно избежать. Ищутся они в том же отчёте краулера: столбец Inlinks для строк с кодом 3xx перечисляет страницы-источники.

Массовая замена в базе делается запросом с функцией REPLACE по полю содержимого записей. Три правила, которые я соблюдаю всегда. Первое: перед запросом снимается резервная копия базы. Второе: замена дробится на порции по несколько сотен записей — один большой запрос на объёмной таблице упирается в таймаут и обрывается посередине. Третье: в шаблон включается кавычка, ищется href="/staryj-adres/" целиком, а не фрагмент пути, иначе под замену попадут вхождения внутри других адресов. После замены обновляется дата изменения записей — иначе автоматическая переиндексация правку не увидит.

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

Порядок починки: от критического к косметическому

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

Шаг	Что проверяется	Признак проблемы	Действие
1	Петли на главной и в основных разделах	ERR_TOO_MANY_REDIRECTS, код 500 или 508	Найти конфликтующие правила, оставить одно
2	Комбинации протокола и www	Больше одного перехода до конечного адреса	Объединить разрозненные правила в одно
3	Слеш в конце адреса	Обе версии отдают 200 либо ведут друг на друга	Выбрать вариант, второй отправить в 301
4	Цепочки от трёх звеньев	Отчёт Redirect Chains краулера	Переписать первое правило сразу на конечный адрес
5	Правило «всё несуществующее на главную»	Мягкие 404 в отчётах поисковых систем	Заменить точечными 301 либо 404 и 410
6	Коды 302 и 307 на постоянных переездах	Старый адрес держится в индексе	Сменить на 301, кроме временных случаев
7	Внутренние ссылки на адреса с 3xx	Столбец Inlinks у строк с кодом 3xx	Массовая замена в базе порциями, с бэкапом
8	Карта сайта и canonical	Адреса с кодом 3xx внутри sitemap.xml	Пересобрать карту, свести canonical с редиректом
9	Повторный обход краулером	Новые цепочки после правок	Прогнать полный обход заново и сверить

После правок отправьте ключевые адреса на переобход в Вебмастере и Search Console. Дальше нужно терпение: позиции подтянутся по мере того, как робот пройдёт по адресам и склеит их со старыми, — от двух недель до полутора месяцев. Учтите, что отчёты Вебмастера показывают состояние на момент последнего обхода: починенный вчера адрес провисит там с ошибкой ещё недели, текущую картину дают только краулер и curl. Значения кодов ответа собраны в справочнике Коды ответа сервера: руководство с примерами использования, а если нужен взгляд со стороны на техническую часть и помощь, чтобы наладить продвижение сайта в поиске, это уже отдельная работа с приоритетами и планом правок.

Когда редирект не нужен и когда он не сработает

Редирект не универсальное лекарство, и в ряде ситуаций он вреден либо бесполезен.

Не нужен для дублей с параметрами. Адреса с utm-метками, идентификаторами сессий и параметрами сортировки в 301 отправлять не надо: для них есть Clean-param и canonical. Редирект здесь сломает рекламные системы — они не увидят своих меток и перестанут считать источники.

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

Не сработает при смене тематики. Если старая страница была про одно, а новая про другое, переезд не признают: формально 301 отработает, фактически вес не передастся. То же касается склейки дропнутого домена с сайтом другой тематики.

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

Не поможет без исправления причины. Если адреса меняются сами при каждой правке заголовка или при переносе товара, редиректы будут плодиться быстрее, чем вы их выпрямляете. Сначала фиксируется схема адресов, потом порядок в переездах. Что ещё регулярно ломает адреса, есть в разборе 404, 301, 302: как битые ссылки и неправильные редиректы крадут вес страниц.

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

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

Теряется ли вес при 301? Обе системы заявляют, что при прямом 301 на релевантную страницу вес передаётся практически полностью. Потери идут не от кода, а от обстоятельств: длины цепочки, нерелевантности страницы назначения, кода 302 внутри пути.

Старые редиректы удалять или держать вечно? Держать те, по которым идёт живой трафик или на которые есть внешние ссылки. Остальные снимаются через год-полтора после переезда, предварительно проверив по логам, что робот и посетители по ним не приходят.

Почему после выпрямления цепочек позиции не выросли сразу? Склейка происходит не в момент правки, а после того как робот заново обойдёт исходный адрес, получит новый Location и переоценит конечную страницу. От двух недель на небольшом сайте до полутора-двух месяцев на крупном.

Как отличить проблему редиректов от проблемы индексации? По коду ответа. Исходный адрес отдаёт 3xx, конечный 200 — это редиректы. Адрес отдаёт 200, а в поиске его нет — это индексация: закрытие в robots, метатег noindex, canonical на другую страницу, качество содержимого.

Коротко

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

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