Устранение циклических редиректов в WordPress

Циклический редирект в WordPress обычно проявляется как бесконечная переадресация между двумя URL или как ошибка ERR_TOO_MANY_REDIRECTS в браузере. На практике причина почти всегда приземлённая: конфликт HTTPS и HTTP, неверный адрес сайта в настройках, кэш/прокси, плагин редиректов или правила сервера, которые начинают спорить друг с другом.

Если не разбирать цепочку по шагам, легко лечить не то место: менять .htaccess, когда проблема в siteurl, или править адреса в админке, когда редирект уже делает Cloudflare или Nginx. Ниже — рабочий порядок диагностики и исправления.

Как понять, где именно зациклился редирект

Сначала нужно увидеть саму цепочку. Не угадывать, а проверить заголовки ответа. Это особенно важно, если сайт открывается только у части пользователей или проблема возникает после миграции, смены домена, включения SSL или установки плагина безопасности.

Проверка через curl

На сервере или с локальной машины выполните команду:

curl -I -L https://example.ru

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

curl -I https://example.ru

Обратите внимание на:

• код ответа: 301, 302, 307;
• заголовок Location;
• переходы между http и https;
• скачки между www и без www;
• редирект на тот же самый URL с небольшим отличием в слэше или регистре.

Что проверить в админке WordPress

Откройте Настройки → Общие и сравните поля Адрес WordPress (URL) и Адрес сайта (URL). Они должны быть согласованы: либо оба с https, либо оба без него, и с одинаковым вариантом домена — с www или без.

Если один адрес указывает на http://, а другой на https://, WordPress может начать переадресовывать сам себя. После миграции это одна из самых частых причин бесконечного цикла.

Типовые причины и как их отличить друг от друга

Цикл редиректов редко имеет одну причину. Ниже — практическое сравнение, которое помогает не тратить время на лишние правки.

Источник проблемы	Как выглядит	Что исправлять
Настройки WordPress	Редирект между http/https или www/без www сразу после входа на сайт	siteurl, home, настройки в админке
.htaccess / Nginx	Редирект начинается до загрузки WordPress	Правила сервера, конфликтующие rewrite-условия
Плагин редиректов или безопасности	Проблема появляется после активации конкретного плагина	Отключить плагин, проверить его правила
Прокси/CDN	Сайт зацикливается только через Cloudflare или балансировщик	Настройки SSL и заголовков X-Forwarded-Proto

Пошаговое решение без лишних рисков

1. Сначала отключите внешние источники редиректа

Если сайт работает через Cloudflare, другой CDN или прокси, временно проверьте прямой ответ сервера. Иногда WordPress уже настроен правильно, а цикл создаёт внешний слой, который принудительно переводит запросы на HTTPS или на канонический хост.

Для Cloudflare особенно важно проверить режим SSL. Неправильная комбинация вроде Flexible при включённом редиректе на HTTPS на сервере часто даёт бесконечный круг: прокси идёт на сайт по HTTP, сервер отвечает редиректом на HTTPS, а прокси снова подключается по HTTP.

2. Согласуйте адреса сайта в WordPress

Если доступ в админку есть, исправьте адреса в Настройки → Общие. Если вход в админку уже ломается, можно временно зафиксировать адреса в wp-config.php:

define('WP_HOME', 'https://example.ru');
define('WP_SITEURL', 'https://example.ru');

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

3. Проверьте правила редиректа в .htaccess или конфигурации Nginx

Для Apache частая ошибка — несколько блоков, которые одновременно принуждают HTTPS и убирают www, но делают это разными условиями. В результате запросы начинают ходить по кругу.

Ниже пример аккуратного редиректа на HTTPS и без www в .htaccess. Используйте только если сайт реально работает на Apache и вы понимаете, что другие правила не дублируют эту логику:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
</IfModule>

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

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

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

Особенно внимательно смотрите на плагины, которые умеют:

• принудительно переводить сайт на HTTPS;
• менять canonical URL;
• редиректить 404 на главную;
• скрывать wp-admin или wp-login.php;
• управлять trailing slash и структурой постоянных ссылок.

5. Сбросьте кеш после исправлений

После правки редиректов обязательно очистите:

• кеш плагина;
• серверный кеш, если он есть;
• кеш CDN;
• браузерный кеш для проверки в режиме инкогнито.

Иначе можно принять старый 301 за актуальное поведение и продолжить искать проблему в уже исправленном месте.

Если сайт не открывает даже wp-admin

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

Временное отключение плагинов

Переименуйте папку wp-content/plugins в, например, plugins-off. WordPress перестанет загружать плагины, и вы сможете проверить, исчез ли цикл. Если проблема ушла, возвращайте папку обратно и включайте плагины по одному.

Проверка адресов через wp-config.php

Если в базе записан неправильный адрес, а админка недоступна, задайте WP_HOME и WP_SITEURL в wp-config.php. После входа в панель можно убрать эти строки и сохранить адреса через интерфейс, если это удобнее для поддержки.

Как проверить, что решение сработало

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

• главная страница открывается без бесконечной переадресации;
• curl -I https://example.ru возвращает один понятный 301 или сразу 200, без повторяющейся цепочки;
• админка открывается по https и не уводит обратно на http;
• вариант с www ведёт на канонический домен один раз, а не по кругу;
• после очистки кеша редирект не возвращается через несколько минут.

Если у вас есть доступ к логам сервера, посмотрите повторяющиеся запросы к одному и тому же URL. Это помогает понять, не остался ли второй источник редиректа, который вы ещё не отключили.

Частые ошибки и как их исправить

Редирект настроен и в WordPress, и на сервере

Это самая частая ошибка. Например, в .htaccess уже есть принудительный переход на HTTPS, а в плагине безопасности включена та же функция. В итоге запросы начинают спорить друг с другом. Оставьте только один уровень управления редиректом.

Смешаны www и non-www

Если в siteurl указан https://www.example.ru, а сервер переводит на https://example.ru, WordPress может не успевать согласовать адреса. Выберите один канонический вариант и используйте его везде: в настройках, в редиректах, в sitemap и в ссылках внутри темы.

Неправильный режим SSL на прокси

При работе через CDN важно, чтобы сервер и прокси одинаково понимали исходную схему запроса. Иначе WordPress видит запрос как HTTP и пытается перекинуть на HTTPS, хотя снаружи сайт уже открыт по защищённому соединению.

Старый кеш продолжает отдавать 301

После исправления конфигурации старый редирект может жить в кеше браузера, CDN или плагина. Поэтому проверка только в обычной вкладке браузера ненадёжна. Используйте инкогнито, curl и очистку всех уровней кеша.

Что сделать, чтобы проблема не вернулась

После устранения цикла полезно зафиксировать каноническую схему сайта и не разносить логику по разным местам. Для поддержки WordPress это экономит время на будущих миграциях и обновлениях.

• держите один источник правды для редиректов: сервер, а не одновременно сервер и плагин;
• после смены домена сразу проверяйте home и siteurl;
• не включайте несколько плагинов, которые меняют HTTPS и canonical URL;
• проверяйте цепочку редиректов после обновления темы, особенно если она содержит собственные правила перенаправления;
• если используете CDN, документируйте рабочую схему SSL и редиректов для команды.

Если нужен более широкий аудит технических дублей и служебных настроек, удобно сначала привести в порядок базовую SEO-гигиену сайта, а уже потом разбирать редиректы и индексацию. В таких задачах часто помогает Clearfy Pro, если его использовать как инструмент для чистки типовых дублей и служебных элементов, а не как замену ручной проверке конфигурации.