Как найти и убрать лишние редиректы в WordPress

Лишние редиректы в WordPress обычно появляются незаметно: сначала меняют структуру ссылок, потом включают плагин для SEO, затем добавляют правила в .htaccess или на уровне сервера. В итоге один URL ведёт не напрямую на нужную страницу, а через цепочку из двух-трёх переходов. Для пользователя это лишняя задержка, для поисковика — лишний обход, а для администратора — источник странных дублей и конфликтов каноникализации.

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

Как понять, что редиректы уже мешают

Проблема не всегда видна в браузере. Часто сайт открывается «нормально», но технически запрос проходит через несколько промежуточных URL. Это особенно заметно после переезда с http на https, смены www на без www, правок в siteurl/home или установки SEO-плагина, который тоже пытается управлять каноническими адресами.

Типичные признаки

• страницы открываются с задержкой, хотя сервер не перегружен;
• в отчётах краулинга видны цепочки 301 → 301 → 200;
• один и тот же URL доступен через несколько вариантов, а часть из них редиректится не напрямую;
• после смены структуры ссылок старые адреса ведут через несколько промежуточных переходов;
• в админке и на фронтенде разные варианты домена или слэша.

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

curl -I -L https://example.com/staryi-url/

Смотрите на последовательность заголовков Location и на код ответа. Если один и тот же адрес сначала отправляет на https://www., потом на версию без www, а затем ещё и на URL со слэшем, это уже лишняя цепочка.

Откуда в WordPress берутся лишние редиректы

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

Чаще всего лишняя цепочка возникает, когда один и тот же переход задан сразу в двух местах. Например, сервер отправляет http на https, WordPress — на канонический домен, а плагин редиректов — ещё и со старого пути на новый.

Пошагово: как найти источник редиректа

1. Проверьте серверный уровень

Сначала исключите правила веб-сервера. Если редирект уже происходит в .htaccess или конфигурации nginx, WordPress до него может вообще не дойти. Для Apache ищите блоки с RewriteRule и Redirect. Для nginx — правила return 301 и rewrite.

Пример типичного правила для принудительного HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если после этого WordPress или плагин делает ещё один редирект на тот же адрес, нужно оставить только один источник канонизации.

2. Сверьте адреса в настройках WordPress

В Настройки → Общие проверьте Адрес WordPress (URL) и Адрес сайта (URL). Они должны быть согласованы между собой и с реальным доменом. Разница между www и без www или между http и https часто создаёт лишний переход при каждом открытии сайта и входе в админку.

Если нужно проверить значения программно, можно временно вывести их через wp-cli:

wp option get home
wp option get siteurl

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

3. Посмотрите активные плагины редиректов и SEO

Плагины для редиректов удобны, но именно они часто создают цепочки, если правила дублируют серверные. То же касается SEO-плагинов: часть из них умеет управлять canonical, а часть — ещё и перенаправлениями старых URL.

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

Как убрать лишние редиректы без побочных эффектов

Ниже — рабочая последовательность. Не меняйте всё сразу: так проще понять, что именно сломало маршрут.

1. Определите канонический вариант домена: https, с www или без него, со слэшем или без — в зависимости от вашей текущей политики.
2. Оставьте только одно правило, которое приводит все варианты к каноническому адресу.
3. Уберите дублирующие правила из плагинов, если тот же переход уже делает сервер.
4. Проверьте старые URL после миграции: они должны вести сразу на финальный адрес, а не через промежуточный.
5. Очистите кеш сайта, CDN и браузера, иначе вы можете видеть старую цепочку.

Пример: редирект старых URL через WordPress-хук

Если нужно перенаправить конкретный устаревший адрес на новый, лучше делать это точечно, а не через широкие шаблоны, которые заденут лишние страницы.

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

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

    if ($request_uri === '/staryi-razdel/') {
        wp_redirect(home_url('/novyi-razdel/'), 301);
        exit;
    }
});

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

Пример: убрать лишний редирект со слэшем в конце

Иногда проблема не в домене, а в конфликте между сервером и WordPress по поводу завершающего слэша. Если сайт уже настроен на «красивые» URL, не добавляйте отдельное правило, которое повторяет поведение ядра.

Проверка через curl покажет, есть ли лишний переход:

curl -I https://example.com/sample-page
curl -I https://example.com/sample-page/

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

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

После правок важно проверить не только главную страницу, но и несколько типовых URL: записи, страницы, архивы, старые адреса после миграции и URL с параметрами. Иначе можно случайно исправить один маршрут и сломать другой.

• Проверьте curl -I -L для 3–5 реальных URL.
• Убедитесь, что каждый адрес приводит к финальной странице за один переход.
• Сравните заголовки Location до и после правок.
• Откройте сайт в режиме инкогнито, чтобы исключить влияние кеша браузера.
• Очистите кеш плагина, серверный кеш и CDN, если они используются.

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

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

Два источника редиректа одновременно

Самая частая ошибка — правило уже есть в nginx или .htaccess, а потом его же добавляют в плагин редиректов. В результате один и тот же запрос проходит два шага. Решение: оставить один уровень управления для каждого типа редиректа.

Редирект на неканонический домен

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

Слишком широкие правила

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

Проверка только в браузере

Браузер может скрывать часть переходов из-за кеша или HSTS. Для технической проверки используйте curl или инструменты анализа заголовков. Иначе можно не заметить, что цепочка всё ещё существует.

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

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

Если у вас много старых URL, не пытайтесь закрыть всё одним универсальным шаблоном. Лучше сначала собрать список реальных адресов из логов, Search Console или краулера, а потом добавить точечные правила. Это и безопаснее, и проще для поддержки.

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

Если вам нужно системно чистить дубли, технические страницы и лишние URL, имеет смысл смотреть на инструменты, которые помогают управлять SEO-настройками и служебными страницами без ручного хаоса. Например, у Clearfy Pro есть набор функций для технической чистки WordPress: https://wpshop.ru/plugins/clearfy?utm_source=wpvip.ru&utm_medium=article&utm_campaign=kak-naiti-i-ubrat-lishnie-redirecty-v-wordpress

После внедрения любых правок держите под рукой короткий чек-лист:

• один канонический домен;
• один источник редиректов для каждого сценария;
• нет цепочек 301 → 301 → 200 на типовых URL;
• нет циклов между www/non-www, http/https и слэшем;
• кеш очищен на всех уровнях.

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