Цикл редиректов в WordPress обычно выглядит одинаково: страница не открывается, браузер пишет про слишком много перенаправлений, а в логах и DevTools видно, что URL гоняется между двумя или тремя адресами. Чаще всего проблема не в одном месте, а в связке: HTTPS, www/non-www, слэш на конце, правила в .htaccess, плагин редиректов, кэш или неверный адрес сайта в настройках.
Ниже — рабочий порядок диагностики и исправления. Он подходит для обычного сайта на WordPress, где нужно быстро найти источник редиректа и не сломать индексацию, админку и вход в панель.
Как понять, где именно зациклился редирект
Сначала нужно не «чинить всё подряд», а увидеть цепочку ответов сервера. Это экономит время: один и тот же симптом может быть вызван разными слоями — сервером, WordPress, плагином или CDN.
Что проверить в первую очередь
- открывается ли сайт в режиме инкогнито без расширений;
- редиректит ли только главная или все страницы;
- есть ли разница между
http://иhttps://; - меняется ли поведение для
wwwи безwww; - не стоит ли перед WordPress прокси, Cloudflare или другой CDN;
- не включён ли плагин, который управляет редиректами, кэшем или безопасностью.
Самый быстрый способ увидеть цепочку — curl. Он покажет, куда именно уходит запрос и на каком шаге начинается петля.
curl -I -L https://example.comЕсли редиректов много, полезнее смотреть без автоматического перехода:
curl -I https://example.comВ ответе ищите заголовок Location. Если он указывает на тот же URL или на адрес, который снова возвращает назад, это и есть цикл.
Пошаговое решение: от простого к сложному
Не меняйте сразу несколько настроек. Иначе вы не поймёте, что именно помогло. Идти лучше в таком порядке: WordPress-адреса, плагины, серверные правила, кэш, CDN.
1. Проверьте адреса сайта в WordPress
Откройте Настройки → Общие и сравните поля Адрес WordPress (URL) и Адрес сайта (URL). Они должны быть согласованы с реальным вариантом домена: с HTTPS, с нужным поддоменом и с одинаковой логикой слэша.
Если в админку не попасть, можно временно задать адреса через wp-config.php:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Это полезно, когда в базе уже записан неправильный адрес и сайт уходит в петлю ещё до загрузки панели.
2. Отключите плагины, которые влияют на редиректы
Частая причина — SEO-плагин, плагин безопасности, кэш или отдельный модуль редиректов. Если есть доступ к файловой системе, проще всего временно переименовать папку wp-content/plugins или конкретный плагин. После этого проверьте сайт снова.
Если сайт ожил, включайте плагины по одному и проверяйте, на каком шаге редирект возвращается. Так вы быстро найдёте конфликт.
3. Проверьте правила в .htaccess или конфигурации сервера
На Apache цикл часто создают дублирующиеся правила для HTTPS и canonical-редиректов. Например, одно правило отправляет на HTTPS, второе — обратно на HTTP из-за неверно определённого протокола за прокси.
Базовый WordPress-блок в .htaccess должен быть без лишних самодельных редиректов внутри него:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>Если вы добавляли отдельные правила для HTTPS или www/non-www, временно уберите их и проверьте сайт. Потом возвращайте только одно правило, а не несколько конфликтующих.
4. Убедитесь, что сервер и WordPress одинаково видят HTTPS
Если сайт стоит за прокси или CDN, WordPress может думать, что запрос пришёл по HTTP, хотя снаружи он HTTPS. Тогда начинается бесконечный обмен редиректами.
Для таких схем иногда нужен корректный $_SERVER['HTTPS'] или доверие к заголовкам прокси. Но править это нужно только если вы понимаете, как именно настроен сервер. На shared-хостинге лучше сначала проверить настройки панели и поддержку HTTPS у хостера.
5. Очистите кэш на всех уровнях
После исправления правил старый 301 может продолжать отдаваться из кэша браузера, плагина или CDN. Поэтому проверка должна быть не только в обычном окне браузера.
- очистите кэш плагина;
- сбросьте серверный кэш, если он есть;
- очистите кэш CDN;
- проверьте в режиме инкогнито;
- проверьте через
curl -I, а не только в браузере.
Если редирект создаёт код темы или плагина
Иногда проблема не в настройках, а в кастомном коде. Например, разработчик добавил редирект в template_redirect, чтобы отправлять гостей на страницу входа, или сделал принудительный переход на канонический URL без проверки текущего запроса.
Пример безопаснее делать через условие и только для нужного сценария:
add_action('template_redirect', function () {
if (is_admin() || wp_doing_ajax() || wp_doing_cron()) {
return;
}
if (is_page('private-area') && !is_user_logged_in()) {
wp_safe_redirect(wp_login_url(get_permalink()));
exit;
}
});Если в коде есть что-то похожее на редирект на home_url() без проверки текущего URL, это кандидат на цикл. Особенно опасны конструкции, которые срабатывают на любой запрос, включая уже целевой адрес.
Сравнение подходов: что использовать в реальной задаче
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин редиректов | Нужно быстро управлять несколькими правилами без правки сервера | Легко получить конфликт с SEO/кэш-плагином |
| Правка .htaccess | Нужен один базовый редирект на HTTPS или www/non-www | Ошибку сложнее отлаживать без доступа к логам |
| Код в теме или MU-плагине | Редирект зависит от логики пользователя, роли или типа страницы | Можно сломать фронт, если не проверить условия |
Если задача простая, лучше оставить редирект на уровне сервера. Если логика зависит от WordPress-условий, используйте код, но выносите его в MU-плагин или отдельный мини-плагин, а не в functions.php активной темы.
Проверка результата после внедрения
После исправления важно подтвердить не только то, что сайт открывается, но и то, что редирект стал однозначным.
- Проверьте URL с
http://иhttps://. - Проверьте вариант с
wwwи без него. - Сравните ответ
curl -Iдо и после правки. - Откройте главную, запись, страницу, архив и вход в админку.
- Проверьте, не остались ли старые 301 в кэше браузера.
Если нужен более точный контроль, посмотрите цепочку заголовков:
curl -I -L --max-redirs 10 https://example.com/page/Нормальный результат — один понятный переход на целевой URL без возврата назад. Если в цепочке снова появляется тот же адрес, значит, где-то остался второй источник редиректа.
Частые ошибки и как их исправить
Редирект на HTTPS и обратно
Обычно это конфликт между сервером, прокси и WordPress. Проверьте, не принудительно ли WordPress считает запрос HTTP. На уровне сервера должен быть один источник истины, а не два.
Плагин редиректов спорит с .htaccess
Если и плагин, и сервер отправляют на разные канонические адреса, петля почти гарантирована. Оставьте только один слой, который отвечает за базовый редирект.
Неправильный адрес сайта в базе
После миграции часто забывают поменять siteurl и home. Тогда WordPress сам отправляет запросы не туда. Исправляйте через админку, wp-config.php или напрямую в базе, но только после бэкапа.
Кэш продолжает отдавать старый 301
Это особенно заметно после переноса домена или смены SSL. Очистка только в браузере не помогает, потому что редирект живёт в серверном или CDN-кэше.
Что стоит сделать для безопасности и стабильности
Редиректы часто правят в спешке, а потом забывают, где именно они были добавлены. Это плохо для поддержки и безопасности.
- храните серверные правила в одном месте и комментируйте их;
- не дублируйте один и тот же редирект в плагине и в
.htaccess; - перед изменениями делайте резервную копию
.htaccessи базы; - если используете код, оформляйте его как MU-плагин, а не как разовый фрагмент в теме;
- после исправления проверьте, не открываются ли старые адреса с параметрами, которые тоже должны вести на канонический URL.
Если на сайте уже есть много ручных правил, полезно вынести их в понятную систему и не держать логику редиректов в нескольких местах. Для технической чистки WordPress иногда удобнее использовать отдельные инструменты, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином принцип остаётся тем же: один редирект — один источник, без дублирования на уровне сервера и WordPress.
Если после всех проверок цикл остаётся, значит, источник сидит вне WordPress: в панели хостинга, прокси, CDN или в глобальных правилах веб-сервера. В этом случае уже нужен доступ к конфигурации сервера и логам, иначе вы будете чинить только симптомы.