Цепочка HTTP
Фиксируем каждый статус и Location от исходного URL до повтора, включая различия для GET, POST и отдельных путей.
ERR_TOO_MANY_REDIRECTS
Сайт выполнил слишком много переадресаций
Строим фактическую цепочку ответов, находим два конфликтующих правила и возвращаем запросу один конечный адрес. Проверяем не только браузер, но и сервер, CMS, CDN, авторизацию и поисковые сигналы.
Маршрут запроса
Где замыкается
цепочка
По RFC 9110 серверные перенаправления используют статус 3xx и Location. Ошибка возникает не из-за самого редиректа, а когда несколько слоёв по-разному определяют канонический адрес и возвращают запрос назад.
HTTPS и прокси
Проверяем, видит ли приложение исходный протокол за CDN или балансировщиком и корректно ли передаются заголовки.
www и домены
Сверяем правила основного домена, поддоменов, зеркал и панель хостинга: все варианты должны вести в одну сторону.
CMS и плагины
Ищем конфликт адреса сайта, SEO-плагина, модуля SSL, языковой версии, авторизации и серверной конфигурации.
Cookie и сессия
Сравниваем новый сеанс, авторизованного пользователя и проблемную роль, не удаляя данные до фиксации причины.
SEO после ремонта
Проверяем конечный 200, один переход там, где он нужен, canonical, sitemap и внутренние ссылки без промежуточных URL.
Результат
Один запрос — один конечный адрес
Разорван цикл
Посетитель получает страницу, а не повторяющуюся последовательность ответов.
Согласованы слои
Хостинг, CDN и CMS одинаково определяют протокол и домен.
Исправлены сигналы
Canonical, sitemap и ссылки указывают на конечный индексируемый URL.
Порядок работы
От карты переходов к проверке робота
Не отключаем все правила сразу: это может открыть дубли и сломать старые адреса. Сначала выделяем конфликтующую пару, затем сохраняем нужные постоянные и временные переходы.
Воспроизводим
Проверяем проблемный URL без cookie, с ними и через прямой HTTP-запрос.
Определяем владельца
Связываем каждый переход с CDN, сервером, CMS или кодом приложения.
Исправляем правило
Удаляем конфликт, сохраняя целевой домен, HTTPS и необходимые переносы.
Обходим сайт
Проверяем типовые URL, формы, авторизацию и поисковые сигналы.
Важно
Очистка cookie не лечит серверный конфликт
Она полезна как диагностический тест, но не заменяет исправление. Если новый посетитель снова попадает в цикл, проблема останется и для поискового робота.
Для диагностики подготовьте
- точный URL и текст ошибки;
- когда началась проблема;
- изменения SSL, CDN, домена или CMS;
- проявляется ли ошибка без авторизации;
- доступ к панели, конфигурации и журналам.
После исправления отдельно проверяем, что постоянные редиректы соответствуют реальному переносу страниц.
Вопросы
Перед исправлением
Что означает слишком много переадресаций?
Один URL отправляет запрос на другой, а тот возвращает его назад или запускает повторяющуюся цепочку.
Поможет ли очистить cookie?
Иногда временно, если цикл зависит от сессии. Серверные и прикладные правила всё равно нужно проверить.
Это влияет на SEO?
Да: робот не получает конечную страницу, а длинная цепочка увеличивает задержку обхода.
Какой код редиректа нужен?
301 или 308 — для постоянного переноса, 302 или 307 — для временного. Выбор зависит от назначения, а не от браузера.
Первый шаг
Пришлите проблемный URL
Построим цепочку и определим, на каком слое она замыкается. Для начала достаточно адреса, времени появления ошибки и последних изменений.