Проверка редиректов

Как это работает

1. Каждый URL запрашивается с нашего сервера с user-agent Chrome (и, если выбрано, ещё раз как Googlebot); редиректы не следуются автоматически — каждый переход это отдельный запрос, чтобы записать его статус, Location, Cache-Control и время
2. До 10 переходов на цепочку; URL, встреченный дважды, — цикл; 8 с на запрос и 25 с на цепочку; каждый переход проходит те же проверки публичного хоста (никаких частных, link-local или localhost целей)
3. Читается только тело последнего ответа, только если это HTML, с ограничением 256 КБ — чтобы найти <meta http-equiv="refresh">, встроенные паттерны location.href / location.replace() и <link rel="canonical">
4. Замечания по цепочке: нет редиректа / конец OK / конец с ошибкой (4xx–5xx), цикл, достигнут предел переходов, больше 3 переходов, 302 или 307 в цепочке, 303, относительный Location, http→https→www в два перехода, понижение https→http, смена хоста, meta refresh, JavaScript-редирект, canonical отличается от конечного URL, медленная цепочка (> 3 с)
5. С опцией Googlebot две цепочки сравниваются: другой конечный URL или статус помечается — классический признак клоакинга по user-agent или редиректа только для ботов
6. Пакетно: до 20 URL за запуск, 5 параллельно; таблицу переходов каждой цепочки можно скачать как CSV

О редиректах и о том, что сообщает инструмент

Редирект говорит клиенту, что ресурс находится по другому URL. Для поисковых систем код статуса несёт смысл: 301 и 308 говорят, что перенос постоянный, поэтому сигналы ранжирования должны объединиться на цели, а старый URL может выпасть из индекса; 302 и 307 говорят, что перенос временный, поэтому исходный URL должен сохранить своё место. Google годами говорит, что на практике считает давно стоящие 302 постоянными, но ему всё равно приходится угадывать — 301 убирает догадку. 303 — это идиома POST→GET, которой не место при переносе сайта. Инструмент показывает код каждого перехода, так что намерение цепочки видно, а не выводится.

Цепочки расходуют краулинговый бюджет и понемногу размывают сигналы с каждым переходом, а Googlebot сдаётся после десяти. Обычный виновник — не одно плохое правило, а несколько правильных, наложенных друг на друга: http→https на веб-сервере, без www → www в CMS, конечный слеш от фреймворка и переименование URL в приложении — четыре перехода там, где хватило бы одного. Инструмент явно называет паттерн http→https→www, потому что он самый частый и его легче всего свернуть в одно правило, ведущее сразу на конечный URL.

Не все редиректы — HTTP. Страница, которая возвращает 200, а затем переносит посетителя через <meta http-equiv="refresh"> или строку JavaScript, для пользователя редирект, а для краулера без выполнения скриптов — обычная страница; Google, который рендерит JavaScript, считает такие случаи слабым сигналом по сравнению с серверным 301. Инструмент читает конечный HTML на оба паттерна и сообщает о них; он не следует по ним, потому что в этом и суть: HTTP-цепочка и реальная цель различаются.

Запрос как Googlebot рядом с браузером ловит сразу две проблемы. Редиректы только для ботов — отправка краулеров на другую страницу, чем пользователей, — нарушают политику Google о клоакинге, намеренно это или нет (достаточно неверно настроенной защиты от ботов или гео-правила). А некоторые сайты перенаправляют браузеры по языку или стране, оставляя Googlebot на версии по умолчанию, что нормально, но об этом стоит знать. Инструмент сравнивает конечный URL и статус двух агентов и говорит, совпадают ли они. Что делать с различием, зависит от его причины; инструмент его сообщает.

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

301 или 308?

Оба постоянные. 308 дополнительно запрещает клиенту менять метод (POST остаётся POST), что важно для API и форм, а не для страниц. Для переносов сайта 301 понимают все; 308 тоже подходит. Для индексации Google трактует их одинаково.

Вредит ли 302 SEO?

Не обязательно. Google говорил, что со временем считает постоянно стоящий 302 постоянным и в любом случае объединяет сигналы. Проблема в неоднозначности: 302 говорит «это временно», поэтому при миграции поисковая система может держать старый URL в индексе дольше, чем вы хотите. Если перенос постоянный, скажите это через 301 — инструмент помечает 302/307 в цепочке, чтобы вы могли решить.

Сколько переходов — слишком много?

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

Почему инструмент говорит, что canonical конечной страницы отличается?

Потому что HTML, на котором заканчивается цепочка, указывает в <link rel="canonical"> на другой URL, чем тот, на который вы попали. Редирект на страницу B, чей canonical называет страницу C, рассказывает Google две разные истории. Обычно один из них устарел после миграции; инструмент сообщает о расхождении и об обоих URL.

Что такое цикл редиректов и почему инструмент останавливается рано?

Цикл — это цепочка, которая возвращается к уже посещённому URL: A → B → A. Браузеры показывают ошибку, краулеры сдаются. Инструмент останавливается, как только URL повторяется, и помечает цепочку как цикл; он также останавливается на 10 переходах независимо от цикла, потому что так делает Googlebot.

Зачем запрашивать как Googlebot?

Некоторые сайты — намеренно или из-за неверного правила — отправляют краулеров не туда, куда браузеры. Перенаправлять Googlebot на другую страницу, чем пользователей, — клоакинг по правилам Google о спаме; перенаправлять браузеры по языку, оставляя ботов на версии по умолчанию, — распространённая и допустимая практика, но о ней стоит знать. Инструмент проходит цепочку дважды с двумя user-agent и сообщает, совпадают ли конечный URL и статус. Учтите, что некоторые сервисы защиты от ботов блокируют всех, кто называет себя Googlebot с непроверенного IP, — 403 в прогоне для бота может быть этим, а не правилом редиректа.

Следует ли инструмент по meta refresh или JavaScript-редиректам?

Нет. Он обнаруживает их в конечном HTML и сообщает цель, но показываемая цепочка — это HTTP-цепочка, то есть то, что видит краулер без выполнения скриптов. Google рендерит JavaScript и считает такие случаи редиректами, но медленнее и с меньшей уверенностью, чем серверный 301. Если инструмент сообщил о таком, реальная цель на шаг дальше, чем показывает таблица.