301 и 302 редиректы: когда какой и как не потерять трафик

Что редирект означает для поиска

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

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

Ответ 301 читается так: адрес сменился навсегда, перенеси на новый все накопленное, а прежний постепенно убери из выдачи. Ответ 302 - ровно наоборот: новый адрес показывай пользователю, а основным в индексе держи старый. Из этой разницы вырастают почти все ошибки с переадресацией. Человек ставит временный код на постоянный переезд и потом полгода не понимает, почему новый адрес не растет.

Серверный редирект приходит кодом ответа, поэтому робот узнает о переезде до того, как загрузит хоть один байт разметки. Переброс через `meta refresh` или скрипт работает иначе: сервер отвечает кодом 200, робот получает обычную страницу, читает тег или выполняет скрипт и только потом понимает, что его отправили дальше. Google такие переходы обрабатывает, Яндекс тоже, но оба - медленнее серверного редиректа и с меньшей уверенностью в том, что адреса надо склеить. Для переезда годится только серверный вариант.

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

301 и 302: когда какой ставить

Код выбирают по одному признаку: вернется ли старый адрес. Вернется - временный. Нет - постоянный.

Временный код на постоянном переезде - самая дорогая ошибка. Поиск получает инструкцию «старый адрес оставь основным» и честно ее выполняет: держит его в выдаче, не переносит накопленные сигналы, а новый адрес считает подменой на пару дней. Сайт при этом выглядит рабочим. Люди попадают куда надо, отчеты не краснеют, проседают только позиции нового раздела, а связать это с кодом ответа получается далеко не сразу.

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

307 и 308 - те же временный и постоянный, но с сохранением метода запроса: браузер не превращает POST в GET по дороге. Для контентных страниц разница неважна, оба кода поиск читает так же, как 302 и 301 соответственно.

Проверить, что именно отдает сервер, из браузера нельзя. Переход выглядит одинаково при любом коде: адрес в строке сменился, страница открылась. Нужен инструмент, который показывает сырой ответ. Я пользуюсь Screaming Frog SEO Spider в режиме списка. Загружаете адреса, получаете колонку с кодом и колонку с конечной точкой. Полминуты работы.

Порядок действий при переезде домена

Смена домена - случай, где ошибка стоит дороже всего: на кону весь трафик сайта, а не одного раздела.

• Соберите карту соответствия. Каждому старому адресу - конкретный новый. Один к одному, постранично. Выгрузите список адресов из карты сайта и отчетов Google Search Console (GSC), чтобы не потерять страницы, о которых вы забыли, а поиск помнит.
• Поднимите новый домен и проверьте, что он отвечает. Все целевые страницы должны отдавать код 200 до того, как на них польется трафик со старого домена.
• Поставьте постраничные правила с кодом 301. Не общее правило на главную, а пара «адрес - адрес» по карте соответствия.
• Перепишите внутренние ссылки в теле страниц. Ссылки должны вести на новые адреса напрямую. Полагаться на переадресацию тут нельзя: каждая внутренняя ссылка через редирект - лишний запрос робота и потеря точности сигнала.
• Перегенерируйте карту сайта. В ней остаются только новые адреса. Старых там быть не должно - подробнее про это в материале о том, как собрать sitemap.xml и не сломать индексацию.
• Добавьте новый ресурс в GSC и Яндекс Вебмастер. В обеих панелях есть отдельный инструмент для переезда: с ним поиск обрабатывает смену адреса быстрее.
• Отправьте старые адреса на переобход. Без этого поиск узнает о переезде только в следующий приход робота, а ждать его можно месяцами.
• Смотрите отчет «Индексирование страниц» четыре-восемь недель. Новые адреса должны набирать показы, старые - терять.

Свести весь прежний сайт на главную страницу нового домена - не переезд. Такой вариант экономит пару часов работы и стоит потом квартала трафика. Поиск сравнивает содержимое исходной и конечной страницы, не находит соответствия и засчитывает мягкий 404: адрес формально отвечает, а запрошенного содержимого по нему нет. Накопленное в таком случае никуда не переносится. Интернет-магазин из Казахстана переезжает на новый домен, сваливает три тысячи карточек товара на главную - и теряет их все.

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

Смена структуры адресов: что забывают обновить

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

Порядок, который я вывел для себя после переезда одного из разделов блога:

• Собрать список правил «старый адрес - новый»: один переход, без промежуточных звеньев.
• Заменить внутренние ссылки по всему сайту, включая меню, хабы разделов и подписи под материалами.
• Обновить хлебные крошки и разметку: там тоже лежат адреса, и они устаревают.
• Удалить старые страницы физически, а не только поставить на них правило. Адрес, который после переезда все еще отдает содержимое, конкурирует со своей заменой.
• Перегенерировать карту сайта и проверить, что прежних адресов в ней не осталось.
• Отправить новые адреса на обход, старые - на переобход.

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

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

Сюда же относится слеш на конце адреса. Если `/blog/analytics/` и `/blog/analytics` оба отдают код 200, для поиска это две разные страницы с одинаковым содержимым. Классический источник дублей, который лечится одним правилом: выбрать форму и переадресовать на нее вторую. Остальные виды дублей и случаи, когда вместо переадресации хватает canonical, собраны в отдельной статье о том, как найти и закрыть дубли страниц.

Когда редирект вместо удаления страницы вредит

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

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

Хуже обоих вариантов третий. Правило стоит, работает, отдает код 301, а страница, на которую оно ведет, удалена. Пример с этого сайта: десять адресов свернутого раздела `/cases/` вели на страницы, которых уже не было. Конец каждой цепочки - 404 с запретом на индексацию. Правило записано, переход одиночный. Вес при этом никуда не передается, а адреса продолжают числиться в отчетах GSC.

Поверх этого лежала вторая ошибка, которая встречается едва ли не чаще первой. Восемь конечных адресов закрыли правилом Disallow в robots.txt, чтобы «убрать из индекса». Эффект получился обратный: робот перестал обходить эти адреса, а значит, не увидел, что страниц нет, и не смог убрать их из отчетов. Закрытие в robots.txt не ускоряет удаление из индекса, а тормозит его. Механику разбираю подробнее в статье про настройку robots.txt, тут достаточно правила: сначала дайте роботу увидеть 404, потом закрывайте, если это вообще нужно.

Все десять адресов перевели одним переходом на раздел-преемник, который принимает трафик и отвечает кодом 200. Восемь строк Disallow из robots.txt убрали, чтобы робот дошел до удаленных страниц и вычеркнул их сам. Вариант с 404 тоже годился, но тогда пропал бы остаточный вес входящих ссылок.

Редирект проверяют по конечной точке цепочки. Пока не открыли последний адрес и не увидели там код 200, работа не сделана.

Цепочки и петли: как найти и разорвать

Цепочка - это когда старый адрес ведет на промежуточный, а тот на конечный. Появляется она не за один раз. Первый переезд ставит одно правило, второй достраивает к нему звено, а прежние записи при этом никто не пересматривает.

Отчет «Индексирование страниц» на срез августа показывал у сайта 41 адрес со статусом «Страница с переадресацией». В списке одновременно лежали и корневой адрес статьи, и ее версия в промежуточном разделе. Это признак двухступенчатого переезда: сначала из корня в общую ветку, оттуда в профильную. Два перехода вместо одного тратят вдвое больше запросов робота и хуже передают вес.

Сам статус «Страница с переадресацией» ошибкой не считается. Так помечается любой известный поиску адрес, который отдает 3xx, и после переезда таких адресов становится много - это норма. Чинить надо не факт переадресации, а длину цепочки. Как читать остальные статусы отчета, разбираю в материале про то, почему страницы не попадают в индекс.

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

Проверка ответа сервера по списку адресов покажет каждое звено с кодом. В отчете «Индексирование страниц» видно, что и корневой, и промежуточный адрес известны поиску. Полную картину сразу по всем правилам дает обход сайта настольным краулером - это единственный способ найти цепочки, о которых никто не помнит.

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

Сколько старый адрес держится в индексе

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

Цифры с моего сайта, GSC за шесть месяцев. Кластер статей про рекламу в Meta Ads переехал с `/blog/target/` на `/blog/meta-ads/`. Четыре статьи проверял вручную по последнему отрезку пути: переадресация серверная, переход один, canonical проставлен верно. К внедрению претензий нет.

По трем темам из четырех старый адрес собирает больше трафика, чем его замена, хотя отдает 301 и никакого содержимого не показывает. По переехавшему пулу счет за полгода такой: 55 старых адресов дали 785 кликов и 58 822 показа против 1 102 кликов и 120 347 показов на 176 новых. Сорок два процента кликов по этим страницам приходят на адреса, которых формально нет.

Пока обе версии в индексе, считать результат переезда по трафику нового адреса бессмысленно: почти половина кликов лежит на старом. Складывайте пару адресов в один отчет и смотрите сумму - иначе успешный переезд выглядит как провал раздела, а провал маскируется под сезонное падение.

Задержка возникает не на сервере. Поиск узнает о переадресации только тогда, когда робот придет на старый адрес. А ходит он туда редко: внутренних ссылок на старый адрес после переезда не осталось. Пока робот не пришел, правило записано на сервере, но для индекса еще не существует.

Что сокращает срок:

• Отправка старых адресов на переобход: инструмент проверки URL в GSC и его аналог в Яндекс Вебмастере.
• Внутренние ссылки на новый адрес по всему сайту, начиная с хаба раздела.
• Canonical нового адреса на себя и отсутствие старого адреса в карте сайта.
• Внешние ссылки, которые получится переставить на новый адрес: их владельцам стоит написать.

Что не сокращает: переустановка правила, смена кода с 301 на 302 и обратно, скрытие адреса через инструмент удаления в GSC. Последний убирает адрес из выдачи примерно на полгода, но причину не трогает: срок кончится, адрес вернется.

Задают код на стороне хостинга или CMS, и постоянный вариант там стоит не всегда. В Тильде правила лежат в настройках сайта, в разделе с доменом; пачку удобно готовить файлом CSV и заливать разом, а не вбивать пары адресов руками. Код проверяют отдельно. Панель показывает, что правило создано, но чем именно отвечает сервер - не показывает.

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

Что проверить у себя за час

Порядок для сайта, где переадресация уже настроена и работает непонятно как:

• Откройте пять-десять старых адресов через инструмент проверки ответа сервера. Смотрите код и число переходов до конечной страницы.
• Проверьте конечные точки: каждая должна отдавать 200, а не 404.
• Откройте отчет «Индексирование страниц» и посмотрите, лежат ли в разделе с переадресацией и исходные адреса, и промежуточные.
• Сверьте карту сайта: адресов, которые отдают 3xx, там быть не должно.
• Прогоните сайт краулером и найдите внутренние ссылки, ведущие через редирект.

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

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

Передает ли 301 редирект весь накопленный вес

Google с 2016 года говорит, что переадресация 3xx не съедает PageRank сама по себе. Потери возникают из-за другого: содержимое конечной страницы не совпадает с исходным, цепочка растянута на несколько переходов или конечный адрес закрыт от индексации. При переезде один к одному и единственном звене в цепочке накопленное уходит на новый адрес почти целиком.

Сколько времени поиск обрабатывает редирект

От нескольких дней до нескольких месяцев, и срок зависит от того, как часто робот заходит на старый адрес. Популярные страницы обрабатываются за недели, редко посещаемые - дольше. На своем сайте я вижу старые адреса в выдаче спустя полгода после верно поставленного 301. Ускоряет дело ручная отправка на переобход в GSC и Яндекс Вебмастере.

Можно ли поставить редирект со всех старых адресов на главную

Нет. Поиск смотрит, соответствует ли конечная страница той, с которой человек пришел, и при несовпадении засчитывает мягкий 404: накопленное не переносится, адрес выпадает из индекса. Переезд делается постранично, по карте соответствия. Страницы без преемника отдают 404 или 410 - это честнее и быстрее.

Чем редирект отличается от canonical и когда что ставить

Переадресация физически убирает старый адрес: пользователь на него уже не попадет. Canonical - подсказка поиску о том, какую из двух рабочих страниц считать основной, обе при этом открываются. Ориентир такой: страница не нужна никому - редирект, страница нужна пользователю, но не нужна в выдаче - canonical.

Сколько переходов в цепочке допустимо

Норма - один. Googlebot идет по цепочке до десяти переходов за один обход, дальше останавливается и возвращается позже, так что формально запас есть. На деле каждое лишнее звено тратит запросы робота и размывает сигнал, а еще одно звено добавляется при следующем переезде. Два перехода - повод переписать исходное правило.

Что делать со старой страницей после переезда: удалять или оставить

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