Как настроить 301 редирект с HTTP на HTTPS и убрать циклы переадресации в WordPress

Сценарий типичный: сайт уже перевели на HTTPS, но часть страниц открывается через цепочку редиректов, а иногда браузер пишет о слишком большом количестве перенаправлений. В WordPress это почти всегда не одна причина, а комбинация из настроек адреса сайта, правил веб-сервера, прокси/CDN и плагинов кэша.

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

Когда проблема действительно в редиректах, а не в браузере

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

Что проверить в первую очередь

• открывается ли сайт в режиме инкогнито;
• повторяется ли ошибка на другом устройстве и в другой сети;
• что показывает curl -I или curl -IL для главной страницы;
• нет ли двух разных канонических адресов в настройках WordPress и на сервере.

Если в ответе видно прыгающее направление между http:// и https://, либо между www и без www, значит редирект настроен в нескольких местах одновременно.

Диагностика: где возникает цикл переадресации

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

curl -IL http://example.com

В выводе ищите повторяющиеся переходы. Например, если сначала сервер отправляет на HTTPS, а затем WordPress снова считает сайт HTTP-версией и возвращает назад, цикл уже найден.

Ещё один частый источник — неверные значения в таблице wp_options. Для сайта, который должен открываться только по HTTPS, оба параметра должны указывать на HTTPS-адрес:

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

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

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

Надёжная схема одна: один источник истины для канонического адреса. Обычно это либо веб-сервер, либо CDN/прокси, либо сам WordPress, но не все сразу.

Шаг 1. Приведите WordPress к одному адресу

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

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

Оба значения должны совпадать по схеме и домену. Если сайт уже работает на HTTPS, не оставляйте там HTTP «на время проверки» — это частая причина циклов.

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

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

Это не постоянная замена нормальной настройке, а способ быстро вернуть управляемость сайтом.

Шаг 2. Настройте один 301-редирект на уровне сервера

Если у вас Apache, редирект обычно делают в .htaccess. Важно не дублировать его с плагином, который тоже пытается «форсировать HTTPS».

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Если сайт должен открываться без www, добавьте отдельное правило, но следите за порядком. Сначала выбирается один канонический хост, потом схема:

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

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

Для Nginx логика должна быть вынесена в отдельный серверный блок, а не в WordPress. Если редирект уже есть на уровне CDN, не повторяйте его в Nginx и в плагине одновременно.

Шаг 3. Уберите конфликтующие плагины

Плагины кэша, безопасности и SSL-обвязки часто имеют опции вроде «Force HTTPS», «Redirect HTTP to HTTPS», «Canonical URLs». Оставьте только один механизм. Если редирект уже настроен на сервере, в плагине эту функцию лучше отключить.

Если нужен контроль на уровне кода, можно сделать редирект через template_redirect, но это запасной вариант для случаев, когда нет доступа к конфигу сервера:

add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax() || wp_is_json_request()) {
        return;
    }

    if (!is_ssl()) {
        $url = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
        wp_redirect($url, 301);
        exit;
    }
});

Такой код не должен жить в теме, если сайт активно обновляется. Лучше вынести его в mu-plugin или отдельный мини-плагин, чтобы не потерять при смене темы.

Сравнение подходов: сервер, плагин или код

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

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

• http://example.com → один переход на https://example.com;
• http://www.example.com → один переход на канонический адрес;
• внутренние страницы, рубрики и записи не создают дополнительных прыжков;
• вход в /wp-admin/ работает без петли;
• в исходном коде страницы канонический URL совпадает с фактическим адресом.

Для быстрой проверки удобно использовать:

curl -IL https://example.com/page/

curl -I http://example.com/page/

Если в ответе только один 301 и затем 200, схема работает. Если видите несколько 301 подряд, ищите второй источник редиректа.

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

Редирект настроен и в плагине, и в .htaccess

Это самая частая причина циклов. Оставьте один уровень управления. Если сервер уже делает 301, отключите аналогичную опцию в плагине.

WordPress хранит старый HTTP-адрес

Проверьте home и siteurl. Если они разные по схеме, WordPress может строить ссылки на HTTP, а сервер будет возвращать на HTTPS.

CDN или прокси не передаёт схему корректно

Если сайт стоит за Cloudflare или другим обратным прокси, WordPress может не понимать, что запрос уже пришёл по HTTPS. В таком случае нужно проверять заголовки X-Forwarded-Proto и конфигурацию прокси, а не только правила в WordPress.

Смешаны правила для www и без www

Когда один блок отправляет на www, а другой — убирает www, цикл неизбежен. Зафиксируйте один канонический хост и придерживайтесь его везде: в DNS, сервере, WordPress и Search Console.

Безопасность и производительность: что не стоит делать

Не ставьте несколько SSL-плагинов одновременно ради «подстраховки». Они часто дублируют одно и то же правило и усложняют диагностику. Не используйте 302 там, где нужен постоянный переезд: поисковым системам и кеширующим слоям нужен именно 301.

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

Если вам нужно одновременно убрать дубли, служебные страницы и лишние редиректы, имеет смысл проверить настройки SEO- и cleanup-плагина. Например, в Clearfy Pro есть инструменты для технической чистки сайта и управления дублями, но даже с такими плагинами базовую логику HTTPS лучше держать на сервере, а не размазывать по нескольким слоям: https://wpshop.ru/plugins/clearfy.

Короткий чек-лист перед публикацией правок

• в home и siteurl указан один и тот же HTTPS-адрес;
• на сервере есть только одно правило 301 для HTTP → HTTPS;
• редирект на www или без www тоже задан в одном месте;
• плагин SSL/кэша не дублирует серверную логику;
• curl -IL показывает один переход, а не цепочку;
• /wp-admin/ открывается без петли;
• в Search Console и в карте сайта указан канонический HTTPS-адрес.

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