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

Циклы и цепочки редиректов в WordPress обычно всплывают после миграции, смены структуры ссылок, установки SEO-плагина или ручных правок в .htaccess. На глаз это выглядит как «страница не открывается», а по факту сайт может гонять пользователя и бота по нескольким адресам, терять скорость ответа и путать индексацию.

Если задача не в том, чтобы «сделать редирект вообще», а в том, чтобы убрать старые правила и оставить только нужные, лучше идти от диагностики: сначала понять, где именно живёт перенаправление, потом удалить дубли и проверить, что цепочка стала короче или исчезла совсем.

Как понять, что проблема именно в редиректах

Самый частый признак — адрес открывается не сразу или браузер показывает ошибку вроде ERR_TOO_MANY_REDIRECTS. Но это не единственный сценарий. Иногда страница работает, однако уходит по цепочке из двух-трёх переходов: http → https → www → конечный URL. Для пользователя это почти незаметно, а для сайта — лишние миллисекунды и лишняя путаница.

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

• открывается ли URL в режиме инкогнито без кэша браузера;
• есть ли редирект в .htaccess или конфиге nginx;
• не добавляет ли перенаправление SEO-плагин;
• не прописан ли тот же редирект в коде темы или mu-plugin;
• не конфликтуют ли правила для www, https и слэша в конце URL.

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

curl -I https://example.com/staryj-url

В ответе ищите строки HTTP/1.1 301 или 302 и заголовок Location. Если таких переходов несколько подряд, значит, редиректов уже слишком много.

Где обычно прячутся старые перенаправления

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

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

Шаг 1. Зафиксируйте текущую цепочку

Не редактируйте всё подряд вслепую. Сначала выпишите, куда именно уходит проблемный URL. Достаточно одного-двух примеров: старый адрес, конечный адрес, код ответа, наличие промежуточных переходов.

Шаг 2. Найдите дублирующее правило

Если редирект задан в .htaccess, ищите строки вида Redirect, RedirectMatch, RewriteRule. Для nginx — правила return 301 и rewrite. Частая ошибка — оставить старое правило после переноса сайта на HTTPS или после смены домена.

Пример типичного лишнего правила в Apache:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

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

Шаг 3. Удалите старый редирект или объедините правила

Если редиректов несколько, оставьте одно правило, которое сразу ведёт на финальный адрес. Не делайте схему «старый URL → промежуточный URL → новый URL», если это не требуется по логике проекта.

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

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

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    if ($request_uri === '/old-page/' || $request_uri === '/old-page') {
        wp_redirect(home_url('/new-page/'), 301);
        exit;
    }
});

Этот вариант подходит для единичных случаев. Если редиректов десятки, лучше хранить их в SEO-плагине или на уровне сервера, а не раздувать functions.php.

Шаг 4. Проверьте, не создаёт ли WordPress автоперенаправление

WordPress сам умеет подправлять «почти правильные» URL через redirect_canonical(). Иногда это полезно, но при нестандартных правилах может мешать. Если у вас уже есть жёстко заданный редирект, canonical-логика может добавить лишний шаг.

Полностью отключать canonical без причины не стоит. Лучше сначала проверить, не конфликтует ли он с вашим правилом. Если конфликт подтверждён, правку делают точечно и только после теста на staging.

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

После удаления лишних правил не ограничивайтесь открытием страницы в браузере. Браузер может показать уже закэшированный результат. Нужна проверка на уровне HTTP.

• снова выполните curl -I для старого URL;
• убедитесь, что ответ сразу ведёт на конечный адрес;
• проверьте, что нет цепочки из нескольких Location;
• очистите кэш плагина, сервера и CDN, если он используется;
• откройте URL в инкогнито и в мобильной сети, если есть сомнения.

Если нужно увидеть всю цепочку, используйте:

curl -IL https://example.com/staryj-url

Флаг -L покажет все переходы. В идеале вы увидите один редирект или вообще сразу конечный 200 OK, если старый адрес больше не должен существовать.

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

Ставят редирект в нескольких местах одновременно

Это самая распространённая причина циклов. Например, правило есть в .htaccess, ещё одно — в плагине, и третье — в настройках хостинга. Решение простое: оставьте один слой управления редиректом, остальные удалите или отключите.

Используют 302 вместо 301 без необходимости

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

Забывают про www и https

Если сайт принудительно уводится на https://www., а в другом месте — на https:// без www, получится бесконечная петля. Перед правкой определите один канонический формат домена и придерживайтесь его везде.

Не чистят кэш после правок

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

Когда лучше использовать плагин, а когда код

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

Для сайтов, где параллельно нужно чистить дубли, закрывать мусорные URL и наводить порядок в SEO-настройках, имеет смысл смотреть в сторону инструментов уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpshab.ru&utm_medium=article&utm_campaign=kak-udalit-starye-perenapravleniya-i-ispravit-cikly-redirectov-v-wordpress. Но даже в этом случае логику редиректов всё равно нужно проверять вручную, а не полагаться только на интерфейс.

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

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

• не храните десятки одноразовых редиректов в functions.php;
• не редактируйте .htaccess без резервной копии;
• проверяйте правила после обновления SEO-плагина;
• не отключайте canonical и другие системные механизмы без причины;
• если редиректов много, ведите их список отдельно, чтобы не потерять историю изменений.

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

Рабочий критерий простой: старый URL либо сразу уходит на нужный конечный адрес, либо отдаёт корректный ответ без лишних промежуточных шагов. Если цепочка осталась, значит, где-то ещё живёт старое правило и его нужно искать дальше.