Если сайт начал отдавать цепочки 301/302, а в браузере или Search Console всплывает ошибка перенаправления, проблема обычно не в одной строке кода. Чаще всего конфликтуют правила .htaccess, настройки адреса сайта в WordPress, SSL-редирект на уровне сервера и правила плагина для SEO или кеша. В итоге одна и та же страница гоняется по кругу: http → https → www → без www → снова http.
Как понять, что редиректы сломаны именно у вас
Симптомы обычно довольно приземлённые: часть страниц открывается только после нескольких попыток, админка просит повторно войти, а в логах видно повторяющиеся ответы 301 или 302. Иногда проблема проявляется только на мобильных, только для неавторизованных пользователей или только после включения кеш-плагина.
Проверять нужно не «на глаз», а по цепочке ответа сервера. Самый быстрый способ — посмотреть заголовки:
curl -I https://example.com/страница/Если видите несколько переходов подряд, ищите источник каждого шага. Отдельно проверьте:
- значения
homeиsiteurlв настройках WordPress; - правила в
.htaccessили конфиге nginx; - настройки SSL и принудительного HTTPS у хостинга;
- SEO-плагин, который может добавлять канонические редиректы;
- кеш-плагин или CDN, если редирект появляется только у части посетителей.
Что смотреть в браузере и в логах
В DevTools откройте вкладку Network и обновите страницу. Если первый запрос получает 301, а следующий снова уходит на другой адрес, это уже не случайность. В серверных логах полезно искать повторяющиеся запросы к одной и той же странице с разными схемами и хостами. Если доступа к логам нет, хотя бы сравните ответ для http:// и https://, а также для варианта с www и без него.
Почему возникает цикл перенаправлений
Самая частая причина — несколько источников правды одновременно. WordPress считает каноническим один адрес, сервер — другой, а плагин пытается «помочь» и переписывает правила ещё раз. В результате один редирект не завершает задачу, а запускает следующий.
| Подход | Когда подходит | Риск |
|---|---|---|
Исправить только .htaccess |
Если проблема в Apache и правилах редиректа | Не поможет, если конфликтует WordPress или плагин |
| Починить настройки WordPress | Если неверны home и siteurl |
Может быть недостаточно при редиректе на уровне сервера |
| Отключить лишние редиректы в плагинах | Если SEO/кеш-плагин дублирует логику | Нужно проверить, не сломаются ли канонические URL |
Пошаговое решение без лишних догадок
Надёжнее идти от внешнего слоя к внутреннему: сначала сервер, потом WordPress, потом плагины. Так проще понять, где именно появляется лишний переход.
1. Зафиксируйте один канонический адрес сайта
Проверьте, что в WordPress и на сервере выбран один и тот же вариант домена: с www или без него, с https и без смешивания схем. Если есть доступ к wp-config.php, можно временно зафиксировать адреса там, чтобы исключить влияние базы данных:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Это полезно, когда в админке адреса уже «поплыли» или сайт переехал на HTTPS, а старые значения остались в базе. Но не держите так конфигурацию без необходимости: после проверки лучше вернуть управление в админку, если это удобнее для поддержки.
2. Уберите дублирующие правила редиректа
Если сайт на Apache, проверьте .htaccess. В нём часто одновременно живут правила WordPress, принудительный HTTPS и отдельный редирект на www. Достаточно одного лишнего условия, чтобы получить цикл.
<IfModule mod_rewrite.c>
RewriteEngine On
# Один вариант: без www и только HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
</IfModule>Если у вас nginx, аналогичную логику нужно перенести в конфиг сервера, а не пытаться лечить её через WordPress. Смешивать редиректы в нескольких местах — самый короткий путь к бесконечной цепочке.
3. Проверьте плагины, которые вмешиваются в URL
SEO-плагины, плагины кеша и некоторые security-решения умеют менять canonical, принудительно переводить на HTTPS или переписывать адреса вложений и архивов. На время диагностики отключите всё, что связано с редиректами, и проверьте страницу в чистом виде. Если проблема исчезла, включайте плагины по одному.
Если используете набор функций для SEO и чистки дублей, вроде Clearfy Pro, проверьте, не включены ли одновременно несколько опций, которые делают похожую работу: каноникал, редиректы архивов, удаление служебных URL. Дублирующая логика здесь вреднее, чем польза.
4. Сбросьте постоянные ссылки
Иногда WordPress продолжает использовать старую структуру правил после миграции или ручного редактирования .htaccess. Зайдите в Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это пересоздаст rewrite rules и уберёт часть странных переходов.
Если доступ в админку ограничен, можно сделать это программно через WP-CLI, но только если команда уже доступна на сервере:
wp rewrite flush --hardКоманда безопасна для штатной среды, но не запускайте её в цикле и не используйте как «магическую кнопку» после каждого изменения. Она нужна для пересборки правил, а не для лечения конфликта редиректов.
Как проверить, что исправление сработало
После правок нужно проверить не только главную страницу, но и типовые проблемные URL: запись, страницу, архив, вложение, страницу входа. Смысл в том, чтобы увидеть один понятный переход или вообще его отсутствие, а не цепочку из нескольких ответов.
- Откройте URL в режиме инкогнито.
- Проверьте заголовки через
curl -I. - Сравните поведение для
httpиhttps. - Проверьте вариант с
wwwи без него. - Посмотрите, не меняется ли адрес после входа в админку.
Если редирект остался только один — это нормально, когда он ведёт на канонический адрес. Плохо, когда один и тот же URL возвращает разные ответы в зависимости от куки, устройства или времени запроса.
Частые ошибки и как их исправить
Редирект на HTTPS включён и в сервере, и в плагине
Оставьте только один источник редиректа. Если сервер уже переводит весь трафик на HTTPS, отключите аналогичную опцию в плагине. И наоборот: если хостинг не даёт управлять конфигом, настройте редирект в одном месте внутри WordPress, но не в двух сразу.
WordPress хранит старый адрес сайта
После переезда на другой домен или смены схемы проверьте таблицу wp_options. Значения home и siteurl должны совпадать с реальным адресом. Если база недоступна через админку, временно задайте их в wp-config.php, а затем исправьте в интерфейсе.
Кеш отдаёт старый ответ
Иногда редирект уже исправлен, но браузер, серверный кеш или CDN продолжают отдавать старую цепочку. Очистите кеш на всех уровнях: плагин, сервер, CDN, браузер. Для проверки используйте приватное окно и запрос с заголовком, который обходит кеш, если ваш стек это поддерживает.
Правило написано без учёта конечного URL
Классическая ошибка — редирект на тот же адрес, который уже обрабатывается другим правилом. Например, сначала принудительно отправляете на https://example.com, а потом отдельным правилом снова переписываете на https://www.example.com. В итоге оба правила спорят друг с другом. Уберите одно из них и оставьте только финальный вариант.
Практические советы по безопасности и производительности
Редиректы сами по себе не должны превращать сайт в комбайн из плагинов. Чем больше слоёв участвует в обработке URL, тем сложнее отлаживать и тем выше шанс получить лишний запрос. Если задача простая, лучше держать редирект на уровне сервера. Если нужна логика внутри WordPress, делайте её точечно и без дублирования.
Не используйте массовые цепочки 302 там, где нужен постоянный 301. Временные редиректы хуже кэшируются и чаще маскируют проблему, а не решают её. Для безопасности также важно не оставлять открытыми старые адреса после миграции: они должны либо вести на новый канонический URL, либо отдавать понятный 404/410, если страница больше не существует.
Если на сайте много технических дублей и служебных страниц, имеет смысл централизовать часть настроек в одном инструменте, а не размазывать их по нескольким плагинам. Но даже в этом случае сначала проверьте, кто именно уже управляет редиректами, иначе получите тот же конфликт, только в более удобной панели.