Редирект с помощью HTML

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

Четыре способа отправить посетителя на другой адрес

Технически перенаправление можно организовать на четырёх разных уровнях, и они отличаются не синтаксисом, а тем, кто и когда принимает решение о переходе.

• Серверный редирект. Веб-сервер отвечает на запрос кодом из семейства 3xx и заголовком Location. Тело страницы вообще не отдаётся. Решение принимается до того, как браузер получил хоть один байт контента.
• Meta refresh. Сервер отдаёт обычный код 200 и полноценную страницу, внутри которой стоит инструкция «через N секунд перейди туда-то». Решение принимает браузер уже после загрузки разметки.
• Переход средствами скрипта. Страница загружается, выполняется JavaScript, и он меняет адрес окна. Решение принимает интерпретатор скриптов — если он вообще запустится.
• Редирект средствами CMS или плагина. Формально это тоже серверный редирект, но правило хранится не в конфигурации веб-сервера, а в базе данных, и обрабатывается кодом движка при каждом запросе.

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

Что происходит при серверном редиректе

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

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

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

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

Meta refresh: страница сначала грузится, только потом уходит

Мета-обновление ставится в head документа и выглядит примерно так:

<meta http-equiv="refresh" content="0; url=https://site.ru/new-page/">

Первое число — задержка в секундах, после точки с запятой — адрес назначения. Внешне результат похож на редирект: человек попадает куда надо. Внутри всё иначе.

Сервер отдаёт код 200. С точки зрения протокола страница существует, она успешно загрузилась, у неё есть полноценное тело. Никакого сигнала «этот документ переехал» на уровне заголовков нет.

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

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

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

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

Редирект скриптом: самый ненадёжный из всех вариантов

Скриптовое перенаправление в общем виде выглядит как присвоение нового значения адресу окна:

window.location.replace("https://site.ru/new-page/");

Или как переход по свойству href того же объекта. Разница между методами только в том, останется ли старый адрес в истории переходов. Для поисковой оптимизации существеннее другое.

Если нужны детали, смотрите «Чистый html код — влияние на SEO продвижение».

• Робот может не выполнить скрипт. Обработка JavaScript — отдельный, более дорогой этап индексирования. Он выполняется не для всех страниц и не сразу.
• Даже если выполнит — с задержкой. Между первичным обходом и рендерингом проходит время: от часов до недель. Всё это время в индексе остаётся страница-пустышка.
• Передача сигналов не гарантирована. Формально ответ сервера — код 200. Оснований склеивать старый адрес с новым у поисковой системы нет, и внешние ссылки на старый URL могут не сработать на новый.
• Отключённый JavaScript ломает переход полностью. Скрипт не выполнился — человек остался на пустой странице без единой ссылки. То же произойдёт при ошибке в другом скрипте выше по коду, при блокировке файла расширением или при обрыве загрузки.
• Скорость. Переход происходит только после парсинга разметки и выполнения кода. Это лишние сотни миллисекунд на каждом переходе.

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

Сравнение способов перенаправления

Способ	Код ответа	Передаёт ли сигналы	Когда применять
Серверный редирект 301	301	Да, полностью	Постоянная смена адреса, склейка зеркал, переход на HTTPS
Серверный редирект 302	302	Частично, старый адрес остаётся в индексе	Временная заглушка, A/B-тест, сезонный раздел
Meta refresh с нулевой задержкой	200	Возможно, но без гарантий	Только когда нет доступа к серверу и к движку
Meta refresh с задержкой	200	Нет	Информационная заглушка вида «переходим через 5 секунд»
Переход скриптом	200	Нет	Логика внутри интерфейса, шаги после действия пользователя
Редирект средствами CMS	301 или 302	Да, как у серверного	Точечные правила, когда нет доступа к конфигурации
Канонический адрес	200	Да, но обе страницы доступны	Дубли, сортировки, метки в адресах

Из таблицы видно главное правило выбора: если адрес меняется навсегда и обе стороны известны заранее, вариант всегда один — серверный 301. Всё остальное — компромиссы разной степени тяжести.

Чем 301 отличается от 302 и когда каждый уместен

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

Параметр	301 Moved Permanently	302 Found
Смысл	Документ перенесён окончательно	Документ временно доступен по другому адресу
Что попадает в индекс	Новый адрес, старый выпадает	Как правило, остаётся старый адрес
Передача веса ссылок	Переносится на новый URL	Остаётся на исходном URL
Кэширование в браузере	Кэшируется надолго, иногда бессрочно	Не кэшируется по умолчанию
Частота обхода старого адреса	Снижается со временем	Сохраняется, робот продолжает проверять
Типичный сценарий	Смена структуры адресов, склейка www и без www, переход на HTTPS, удаление раздела с заменой	Технические работы, временная акция, тест новой версии страницы
Цена ошибки	Трудно откатить: браузеры кэшируют правило	Старый адрес не уступает место новому месяцами

Помогу с продвижением: SEO-продвижение для бизнеса — вывожу сайты в топ Яндекса белыми методами.

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

Остальные коды семейства 3xx

Помимо двух основных существуют коды, которые встречаются реже, но иногда решают задачу точнее.

• 303 See Other — «результат смотри по другому адресу». Применяется после отправки формы, чтобы обновление страницы не отправляло данные повторно.
• 307 Temporary Redirect — строгий аналог 302: гарантирует, что метод запроса не поменяется с POST на GET.
• 308 Permanent Redirect — строгий аналог 301 с тем же сохранением метода.
• 304 Not Modified — не редирект вовсе, а ответ «содержимое не изменилось, бери из кэша». Путать его с перенаправлением не стоит.

Для типовых задач продвижения хватает 301 и 302. Коды 307 и 308 нужны там, где важна сохранность метода запроса, — в основном в работе с интерфейсами обмена данными.

Как правильно ставить серверный редирект на разных конфигурациях

Apache и файл конфигурации каталога

На связке с Apache правила обычно живут в файле конфигурации уровня каталога. Общая форма постраничного правила:

Redirect 301 /old-page/ https://site.ru/new-page/

Для правил с шаблонами применяется модуль перезаписи адресов. Условие проверяет что-то в запросе, а следующая строка описывает, что с ним сделать:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]

Здесь важны три вещи. Флаг R=301 задаёт код ответа — без него перезапись пройдёт незаметно для клиента. Флаг L останавливает обработку, чтобы следующие правила не наложились сверху. Порядок строк имеет значение: правила читаются сверху вниз, и первое сработавшее с флагом L обрывает цепочку.

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

Nginx и связки с несколькими серверами

На Nginx перенаправление описывается в блоке сервера. Общая форма постоянного переноса:

server {
    server_name www.site.ru;
    return 301 https://site.ru$request_uri;
}

Для отдельных адресов применяется директива rewrite с указанием флага permanent или redirect — первый даёт 301, второй 302. Принципиальное отличие от Apache в том, что конфигурация Nginx перечитывается только при перезапуске: правка файла без перезагрузки конфигурации не даёт эффекта, и это регулярно вводит в заблуждение при проверке.

Отдельный случай — связка, где Nginx стоит перед Apache и отдаёт статику напрямую. Правило, записанное в файл уровня каталога, в такой схеме может не примениться к картинкам и файлам стилей, потому что до Apache запрос просто не доходит. Проверять такие редиректы нужно именно на тех типах файлов, ради которых они ставились.

Подробнее об этом — в статье «HTML теги для сайта».

Редирект средствами CMS и плагинов

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

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

Чем это опасно при сотнях правил:

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

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

Цепочки редиректов: почему нельзя строить лестницы

Цепочка возникает, когда один адрес ведёт на второй, второй на третий, третий на четвёртый. Каждое звено добавлялось в своё время и по своей причине: сначала сменили структуру разделов, потом перешли на защищённый протокол, потом склеили домен с www, потом переименовали товар. По отдельности каждое правило корректное, вместе они образуют лестницу.

Чем это вредит:

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

Правило простое: цепочка должна состоять из одного звена. Если старый адрес А ведёт на Б, а Б впоследствии переехал на В, правило для А нужно переписать так, чтобы оно сразу указывало на В. Старое звено А—Б при этом удаляется, а не остаётся «на всякий случай».

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

Петли редиректов и как они возникают

Если нужна помощь по теме — создание сайтов.

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

Типичные источники петель:

• Одновременно включены правило принудительного HTTPS в конфигурации сервера и аналогичное правило в движке, причём одно из них проверяет протокол неправильно.
• Правило склейки адресов со слэшем на конце конфликтует с правилом, убирающим слэш.
• Правило склейки www конфликтует с настройкой основного адреса в движке.
• Сайт стоит за прокси, который передаёт исходный протокол в заголовке, а правило проверяет протокол напрямую и каждый раз видит незащищённое соединение.

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

Тему разбирал отдельно: «html теги для текста».

Типичные ошибки и их последствия

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

Как проверять редиректы

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

• Консольная проверка кодов ответа. Запрос с выводом только заголовков и отслеживанием всех переходов показывает полную цепочку с кодами. Самый быстрый и самый честный способ: он не зависит от кэша браузера и от расширений.
• Онлайн-сервисы проверки заголовков. Показывают ту же цепочку в наглядном виде и позволяют подставить робота в качестве клиента, чтобы увидеть ответ глазами поисковой системы.
• Обход парсером. Настольные краулеры строят полный отчёт по всем адресам сайта: коды ответа, длина цепочек, конечные адреса, входящие внутренние ссылки на перенаправленные URL. Отдельно стоит выгрузить список внутренних ссылок, ведущих на адреса с кодом 3xx, и переписать их на конечные — внутренние ссылки должны вести напрямую.
• Панель вебмастера. В разделе со страницами и статусами обхода видны адреса, исключённые как перенаправленные, а также мягкие ошибки. Появление большого числа мягких 404 после переезда — почти всегда признак массового перенаправления на главную.
• Проверка в режиме без кэша. Постоянные перенаправления браузер кэширует, и после исправления правила вы можете видеть старое поведение. Проверять нужно в приватном окне или через консоль.

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

Чек-лист проверки после настройки

Что проверяем	Как проверяем	Ожидаемый результат
Код ответа старого адреса	Запрос заголовков через консоль	301, заголовок Location с корректным адресом
Длина цепочки	Трассировка всех переходов	Ровно один переход до конечного адреса
Конечный адрес доступен	Отдельный запрос конечного URL	Код 200, страница отдаёт содержимое
Сохранение пути и параметров	Запрос вложенного адреса с параметрами	Путь и параметры перенесены без потерь
Варианты написания	Проверка со слэшем, без слэша, с www, по обоим протоколам	Все варианты ведут в одну точку
Служебные файлы	Запрос карты сайта и файла правил для роботов	Код 200, правило их не захватило
Внутренние ссылки	Обход парсером, фильтр по кодам 3xx	Внутренних ссылок на перенаправленные адреса нет
Отсутствие петель	Открытие в приватном окне	Страница открывается, ошибки о числе переходов нет
Карта сайта	Просмотр файла со списком адресов	Только конечные адреса с кодом 200
Реакция поисковой системы	Отчёты панели вебмастера через две-три недели	Старые адреса помечены как перенаправленные, новые в индексе

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

Перенаправление — инструмент для случая, когда документа по старому адресу больше нет. Если обе страницы должны оставаться доступными, задача решается иначе.

• Дубли с параметрами. Адреса с метками рекламных кампаний, идентификаторами сессий, параметрами сортировки и фильтрации. Здесь нужен канонический адрес: страница отдаёт код 200, а в разметке указывает, какой URL считать основным.
• Товар в нескольких категориях. Если движок формирует несколько путей к одной карточке, канонический адрес указывает основной путь, а остальные остаются рабочими.
• Версия для печати. Она нужна пользователю, но не нужна в индексе — снова канонический адрес.
• Страница удалена без замены. Раздел закрыт, аналога нет. Честный ответ — 404, а если удаление окончательное — 410. Перенаправление на главную в этом случае только запутывает и робота, и человека.
• Пагинация. Страницы списка должны отдавать код 200 и оставаться доступными для обхода — иначе глубокие элементы каталога выпадут из индекса.

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

Как выбрать способ под конкретную задачу

Короткий алгоритм, который закрывает почти все реальные ситуации.

1. Адрес меняется навсегда, обе стороны известны заранее — серверный 301 в конфигурации веб-сервера.
2. Правил немного, доступа к конфигурации нет — встроенный механизм движка, обязательно с кодом 301.
3. Перенос временный, старый адрес вернётся — 302, с пометкой в задачнике о дате снятия.
4. Обе страницы должны остаться доступными — канонический адрес, а не перенаправление.
5. Переход зависит от действия пользователя в интерфейсе — скрипт, но только внутри логики самой страницы, не для смены адресов.
6. Нет доступа ни к серверу, ни к движку, а перенести нужно — мета-обновление с нулевой задержкой как временная мера, с обязательной заменой на серверное правило при первой возможности.

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

Что делать, если редиректы уже стоят неправильно

Разбор запущенной ситуации удобно вести в четыре шага.

1. Инвентаризация. Соберите все источники правил: конфигурация веб-сервера, настройки движка, расширения, настройки прокси и системы доставки контента. Выгрузите каждый список отдельно.
2. Обход. Прогоните сайт парсером и получите отчёт по кодам ответа. Отдельно выгрузите адреса с цепочками и адреса, ведущие на ошибки.
3. Чистка. Схлопните цепочки до одного звена, удалите правила-дубли, замените 302 на 301 там, где перенос постоянный, уберите правила, ведущие на несуществующие страницы.
4. Перелинковка. Перепишите внутренние ссылки на конечные адреса, обновите карту сайта, отправьте изменённые адреса на переобход через панель вебмастера.

После чистки вернитесь к отчётам через две-три недели: количество исключённых как перенаправленные должно расти, количество мягких ошибок — падать, а новые адреса — появляться в индексе с сохранением видимости.

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

Заменит ли мета-обновление серверный редирект, если поставить нулевую задержку?
Частично. Поисковые системы обычно распознают такую конструкцию как постоянный перенос, но гарантии нет: ответ сервера остаётся 200, и решение остаётся на усмотрение алгоритма. Плюс страница всё равно грузится целиком перед переходом. Как временная мера при отсутствии доступа к серверу — приемлемо, как постоянное решение — нет.

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

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

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

Что лучше при склейке домена с www — правило в конфигурации или настройка в панели вебмастера?
Правило в конфигурации веб-сервера. Оно работает для всех клиентов сразу и не зависит от того, как конкретная поисковая система обрабатывает настройку главного зеркала. Настройка в панели дополняет правило, но не заменяет его.

О том, влияет ли сам домен на продвижение:

1:19

Коротко

• Серверный редирект отдаёт код 301 или 302 до загрузки страницы — это единственный способ, который поисковая система понимает однозначно и по которому переносит накопленные сигналы.
• Мета-обновление отдаёт код 200 и грузит страницу целиком перед переходом; трактуется неоднозначно, задержка портит впечатление, историческая репутация у конструкции плохая.
• Скриптовый переход хуже всех: робот может не выполнить код или выполнить с большой задержкой, передача сигналов не гарантирована, при отключённом JavaScript человек остаётся на пустой странице.
• 301 — навсегда, с переносом веса и заменой адреса в индексе; 302 — временно, старый адрес остаётся основным. Подмена одного другим стоит позиций.
• Цепочки схлопываем до одного звена, перенаправление всего подряд на главную не делаем, пагинацию не трогаем, а после настройки прогоняем сайт по чек-листу проверки.

Проверить редиректы и структуру адресов вашего сайта помогу на SEO-консультации.