Как исправить цикл редиректов в WordPress

Если WordPress перестал открываться и браузер пишет о слишком большом количестве перенаправлений, проблема почти всегда в конфликте настроек адреса сайта, SSL или правил редиректа на сервере. В такой ситуации сайт обычно не «сломался» окончательно: доступ можно вернуть, если последовательно проверить, какой именно адрес считает основным сам WordPress, что настроено в базе данных и не дублируют ли друг друга редиректы на хостинге, в .htaccess или в плагинах.

Самая частая ошибка — менять домен, включать HTTPS или переносить сайт, а потом править только один из уровней: например, адрес в админке, но не в базе, или SSL в панели хостинга, но не в настройках WordPress. В результате сайт начинает перекидывать запросы между двумя вариантами URL: с www и без www, с http и https, со старым и новым доменом.

С чего начать диагностику

Сначала нужно понять, где именно возникает цикл. Это важно, потому что решение для конфликта домена и решение для неправильного SSL не одинаковы.

• Если не открывается только главная страница, а другие URL ведут себя по-разному, чаще всего проблема в правилах редиректа на сервере или в плагине.
• Если не открывается вообще весь сайт, а в адресной строке мелькают варианты с http/https или www/без www, обычно конфликтует базовый адрес WordPress и адрес, который ожидает сервер.
• Если после переноса на новый домен сайт уводит на старый, значит где-то остались старые URL: в базе, в файле конфигурации или в кэше.

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

Проверьте адрес сайта в WordPress и в базе данных

WordPress ориентируется на два ключевых параметра: home и siteurl. Если они отличаются от реального адреса сайта, начинается переадресация туда-сюда. Особенно часто это происходит после смены домена или перехода с HTTP на HTTPS.

Если есть доступ в админку, откройте Настройки → Общие и проверьте:

• Адрес WordPress (URL);
• Адрес сайта (URL).

Оба значения должны соответствовать фактическому адресу сайта. Обычно они совпадают, если WordPress установлен в корне домена. Если сайт работает на поддомене или в отдельной папке, адреса могут отличаться, но это должно быть сделано осознанно.

Если в админку войти нельзя, проверьте эти значения в базе данных. В большинстве установок таблица называется wp_options, но префикс может быть другим. Нужно найти строки home и siteurl и убедиться, что там указан правильный домен и протокол.

Если доступ к базе есть через phpMyAdmin, можно выполнить запрос:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('home', 'siteurl');

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

Когда нужно задать адрес вручную через wp-config.php

Если цикл редиректов мешает зайти в админку, а в базе вы не уверены или не можете быстро попасть в phpMyAdmin, временно задайте адрес сайта в wp-config.php. Это рабочий способ вернуть доступ, но использовать его лучше как временную меру: постоянное хранение URL в конфиге удобно не всегда.

Добавьте строки перед комментарием /* That's all, stop editing! Happy publishing. */:

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

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

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

Проверьте SSL и схему http/https

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

Что нужно проверить:

• сертификат действительно выпущен для этого домена и, если используется www, для него тоже;
• на хостинге нет двух конфликтующих правил: одно в панели управления, другое в .htaccess или конфигурации nginx;
• в home и siteurl указан тот же протокол, который реально должен использоваться на сайте.

Если сертификат установлен недавно, иногда помогает очистка кэша на стороне хостинга и CDN. Но если редирект зациклен именно из-за смешения HTTP и HTTPS, кэш не решит проблему сам по себе.

Что делать, если сайт за прокси или CDN

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

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

Проверьте правила редиректа на сервере и в плагинах

Ещё одна типичная причина — дублирующиеся правила перенаправления. Например, хостинг уже отправляет все запросы на HTTPS, а плагин редиректов или код в .htaccess делает то же самое, но с немного другой логикой. В итоге запросы начинают ходить по кругу.

Если у вас Apache, откройте .htaccess и временно проверьте, нет ли там нестандартных правил, связанных с редиректом на другой домен, на HTTPS или на версию с www. Для стандартного WordPress-файла обычно достаточно базового блока перезаписи. Если вы не уверены в содержимом файла, не удаляйте его целиком: сначала сохраните копию.

Если сайт на nginx, правила редиректа обычно находятся в конфигурации виртуального хоста, а не в .htaccess. На shared-хостинге доступ к ним может быть ограничен, поэтому в таком случае проще проверить панель управления хостингом или обратиться в поддержку с просьбой показать активные правила редиректа.

Плагины редиректов, SSL-плагины и некоторые плагины безопасности тоже могут вмешиваться в схему перенаправления. Если админка недоступна, временно отключите подозрительные плагины через файловый менеджер или FTP: переименуйте папку плагина в wp-content/plugins, чтобы WordPress не смог его загрузить. Это безопаснее, чем удалять файлы сразу, и позволяет быстро проверить гипотезу.

Если сайт переадресует на старый домен после переноса

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

Проверьте:

• home и siteurl в базе;
• настройки домена в панели хостинга;
• редиректы на старом домене;
• кэш плагина и серверный кэш;
• жёстко прописанные URL в теме или в настройках плагинов.

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

Как проверить, что цикл редиректов устранён

После правок откройте сайт в обычном окне браузера и в режиме инкогнито. Это помогает отделить проблему от локального кэша и старых cookies. Если сайт открывается в инкогнито, но не открывается в обычном окне, причина может быть в кэше браузера или в сохранённых cookies, а не в WordPress.

Проверьте несколько адресов вручную:

• главную страницу;
• адрес с http:// и с https://;
• вариант с www и без него, если оба когда-то использовались;
• страницу входа в админку /wp-admin/.

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

Что обычно ломает редирект снова

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

• в базе указан один домен, а в wp-config.php — другой;
• хостинг принудительно переводит на HTTPS, а плагин делает обратное или дублирует редирект;
• сертификат установлен только для одного варианта домена, а сайт открывают по другому;
• после миграции не очищен кэш CDN, сервера или плагина;
• в .htaccess остались старые правила от предыдущей настройки.

Чтобы не ловить цикл снова, держите один источник истины для адреса сайта. Для большинства установок это либо база данных WordPress, либо временно wp-config.php на время восстановления. Чем меньше мест, где прописан один и тот же редирект, тем проще отследить ошибку, если она вернётся.

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