Две-три пересылки индексацию не ломают, но каждая стоит запроса
Googlebot проходит до 10 переходов подряд, поэтому страница за цепочкой из двух-трёх звеньев индексируется нормально. Вред другой: каждое звено — отдельный запрос к серверу и лишний круг ожидания для человека. А документация Google по переезду сайта просит держать цепочку не длиннее 3 звеньев и в любом случае короче 5.
Когда я прогнал по этой схеме собственный сайт 12 октября 2026 года, самый длинный путь на adlab.ee оказался из 4 переходов.
Лимиты Google: 10 переходов у страниц, 5 у robots.txt
Три цифры из документации Google, сверенные 12 октября 2026 года, определяют, где цепочка просто лишняя, а где уже опасна.
| Что запрашивается | Лимит | Что происходит дальше |
|---|---|---|
| Обычная страница, Googlebot | до 10 переходов | обход цепочки прекращается; какой именно статус увидите в Search Console, документ не уточняет |
| robots.txt | не меньше 5 переходов | файл трактуется как 404: ограничений на сканирование нет, правила Disallow не применяются |
| Переезд сайта, рекомендация | не больше 3, в любом случае меньше 5 | цепочка увеличивает задержку для пользователей, а не все браузеры тянут длинные цепочки |
Строка про robots.txt опаснее остальных. Лимит пять, а файл часто лежит за теми же правилами http → https и www → без www, что и весь сайт. Если поверх ещё лежит старый редирект с прежнего домена, цепочка легко выходит за пять звеньев, правила Disallow перестают действовать, и закрытые разделы сканируются. Подробнее о том, что вообще кладут в этот файл, я писал в статье про sitemap.xml и robots.txt.
Ещё одна оговорка про коды. Для Google 301 и 308 — сильный сигнал, что конечный URL должен стать каноническим, а 302 и 307 — слабый. Как он взвешивает временный редирект в середине цепочки, документация не говорит, и гадать я не буду: в цепочках, которые правлю, оставляю только 301 или 308.
Как цепочка выглядит на живом сайте: четыре правила, четыре звена
Вот что отдаёт adlab.ee по старому адресу переименованной статьи, если зайти с http://www и со слешем на конце. Замер от 12 октября 2026 года, каждое звено — код 308.
Каждое правило по отдельности правильное. Первые два звена, протокол и хост, отдаёт платформа хостинга (в заголовках стоит Server: Vercel), а не код моего приложения. Третье, слеш в конце адреса, убирает фреймворк Next.js. Четвёртое — строка в моём next.config.mjs: статья seo-mebelnogo-magazina-estoniya-2017 переехала на эстонский слаг eesti-mooblipoe-seo-liiklus-kasvas-3x, и старый адрес ведёт на новый одним правилом. Склеивать эти четыре звена мне некуда: три из них не в моём коде.
Что в моей власти, так это адреса, на которые ведут ссылки. Я проверил: из 141 адреса в sitemap.xml на adlab.ee все 141 отвечают 200 с первого запроса, ни одного перехода. Файл robots.txt по адресу http://www.adlab.ee/robots.txt проходит 2 перехода, это ниже порога в 5. В логах сервера я эту проверку не делал, поэтому не знаю, заходит ли Googlebot вообще по четырёхзвенному пути. Достижим он только через внешнюю ссылку в старой форме.
Цена цепочки измерима. Пять замеров curl с моего компьютера дали по прямому адресу 0,12–0,17 с, а по пути из трёх 308 — 0,23–0,42 с. Это не лабораторный тест, одна машина и одна сеть. Зато порядок виден: каждое звено добавляет один круг до сервера и обратно.
Откуда берутся цепочки
Цепочка вырастает слоями: на adlab.ee 4 правила написаны в разное время и в разных местах. Каждый, кто добавляет правило, смотрит на адрес, который перед ним, а не на путь целиком. Тот же механизм работает на любом сайте с историей, но выборки по клиентам у меня нет, поэтому частоты не называю. Слоёв четыре:
- Протокол и хост: http → https и с www на без www. Два звена, которые есть у любого сайта и которые сами по себе нормальны.
- Слеш и регистр: CMS или фреймворк приводит адрес к одному виду, и это ещё одно звено.
- Смена структуры: раздел переименовали, старые адреса ведут на новые, через год переименовали ещё раз, а правило первого раза никто не обновил. Получилось
A → B → CвместоA → C. - Смена домена: старый домен редиректит на промежуточный, тот на новый. Как такие хвосты собирают при переезде, я разбирал в чек-листе миграции сайта.
Как найти все цепочки
Один адрес проверяется одной командой. Флаг -L идёт по редиректам (--max-redirs 15 обрывает на пятнадцатом, а Googlebot остановится на десятом), -w печатает число переходов и итоговый адрес.
curl -sIL --max-redirs 15 -o /dev/null -w '%{num_redirects} %{url_effective} %{http_code}\n' http://www.example.com/old-page/
Весь sitemap проверяется циклом. --max-redirs 0 запрещает идти по переходам, так что в ответе остаётся первый код каждого адреса: всё, что не 200, — кандидат на правку.
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
| while read u; do curl -s -o /dev/null --max-redirs 0 -w '%{http_code} %{url_effective}\n' "$u"; done \
| grep -v '^200'
Если вывод пустой, как у меня, sitemap чист. Если в нём 301 и 308, правка не в редиректах, а в самом sitemap: туда должны попадать только конечные адреса, о чём подробнее в статье про дубли страниц.
Для всего сайта целиком нужен краулер. В Screaming Frog это отчёт Reports → Redirects → Redirect Chains: он показывает начало цепочки, каждое звено и конец, и сразу видно, на каких страницах стоят ссылки на начало. В Search Console смотрите статус «Страница с переадресацией» в отчёте «Индексирование страниц»: это список того, что Google нашёл за редиректом, а не готовый перечень цепочек, но по нему видно, где их искать.
Отдельно проверьте четыре места, куда начало цепочки попадает чаще всего: robots.txt (лимит там всего 5 переходов), sitemap.xml, canonical и hreflang. Ссылка hreflang на адрес с редиректом, как я разбирал в статье про hreflang, рвёт связь между языковыми версиями молча.
В каком порядке исправлять
- Выпишите конец каждой цепочки: конечный адрес, который отвечает 200 и который вы хотите видеть в выдаче.
- Перепишите правила так, чтобы каждое начало вело сразу на конец. Не добавляйте правило сверху, а замените старое:
A → CвместоA → BплюсB → C. - Исправьте источники: меню, подвал, хлебные крошки, canonical, hreflang, sitemap. Google в той же документации по переезду отдельно просит заменить внутренние ссылки на новые адреса по карте соответствий. Этот шаг даёт больше, чем сам редирект, потому что убирает переход там, где вы им управляете: внутренние ссылки вообще не должны вести на редиректы.
- Оставьте старые правила. Google советует держать редиректы как можно дольше, обычно не меньше года, и допускает хранить их бессрочно.
- Проверьте повторно командой из предыдущего раздела и краулером, через неделю после правки.
Когда цепочку лучше не трогать
Не каждая цепочка стоит рабочего дня. Если на сайте до нескольких сотен адресов (у adlab.ee их 141 в sitemap), цепочка состоит из стандартных http → https и www → без www, а ссылки на начало есть только в старых внешних источниках, исправлять нечего: первые 2 звена принадлежат платформе, а потеря ограничена одним запросом.
Тратить время имеет смысл в трёх случаях: цепочка длиннее 3 звеньев (порог из документации Google по переезду), начало цепочки лежит в вашем меню, sitemap или canonical, либо она затрагивает robots.txt с лимитом в 5 переходов. Каталоги с историей нескольких переездов и сайты, которые прошли миграцию, в эту группу попадают в первую очередь. Там цепочки к тому же отнимают часть краулингового бюджета: три звена вместо одного значит три запроса на ту же страницу.
Удалённые страницы в этот разбор не входят. Если замены адресу нет, 301 на главную вреден, и об этом я писал в статье про 404, 410 и редирект.
