Как настроить 301 переадресацию в WordPress без циклов и потери SEO

Автор: Ярослав Жуков | Опубликовано: 27.08.2026

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

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

Когда 301 начинает ломать сайт

Типичный сценарий выглядит так: страница открывается, но браузер делает 2–4 перехода подряд; в Search Console появляются сообщения о перенаправлениях; старые URL индексируются хуже; а часть внутренних ссылок ведёт на адрес, который сам редиректит ещё куда-то дальше. На практике это чаще всего не проблема WordPress как такового, а ошибка в логике правил.

Что обычно идёт не так

редирект настроен и в плагине, и в .htaccess одновременно;
есть цепочка http -> https -> www -> /new-url/, хотя её можно сократить до одного шага;
правило не учитывает слэш в конце URL;
редирект срабатывает на все запросы, включая админку и AJAX;
старый URL уже редиректит, но его снова переписывает другое правило.

Диагностика: как понять, где именно ошибка

Сначала проверьте ответ сервера, а не только поведение в браузере. Для этого удобно использовать curl. Он покажет цепочку переходов и финальный статус.

curl -I -L https://example.com/old-page/

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

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

Мини-чек-лист перед правкой

сохраните список старых и новых URL;
проверьте, нет ли уже редиректа на уровне хостинга или CDN;
убедитесь, что в WordPress корректно заданы siteurl и home;
очистите кеш плагина, сервера и CDN после изменений;
зафиксируйте, какой адрес должен быть конечным.

Какой способ настройки выбрать: плагин, код или сервер

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

Способ	Когда подходит	Плюсы	Минусы
Плагин редиректов	Небольшое число правил, правка без доступа к серверу	Удобно управлять из админки	Дополнительная нагрузка, риск дублирования правил
Код в теме или мини-плагине	Несколько стабильных редиректов	Контроль в репозитории, меньше зависимостей	Нужен доступ к коду и аккуратное тестирование
.htaccess / nginx	Массовые и постоянные правила	Быстро, без загрузки WordPress	Ошибки могут сломать весь сайт

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

Пошаговое решение через PHP без лишней магии

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

<?php
/**
 * Plugin Name: WPU Redirects
 */

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

    $request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';

    $map = [
        '/old-page/' => '/new-page/',
        '/old-category/' => '/category/new-category/',
    ];

    if (isset($map[$request_uri])) {
        wp_redirect(home_url($map[$request_uri]), 301);
        exit;
    }
});

Этот вариант хорош, когда у вас есть фиксированная таблица соответствий. Он не пытается угадать структуру URL и не трогает админку. Но если список большой, лучше хранить его отдельно и не раздувать код в теме.

Как не создать цикл редиректов

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

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

    $uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';

    if ($uri === '/old-page/') {
        $target = home_url('/new-page/');

        if (trailingslashit(home_url($uri)) === trailingslashit($target)) {
            return;
        }

        wp_safe_redirect($target, 301);
        exit;
    }
});

Здесь используется wp_safe_redirect(), потому что для внутренних переходов это безопаснее, чем безусловный wp_redirect(). Он не решает все проблемы сам по себе, но снижает риск случайного ухода на внешний домен.

Если редирект нужен на уровне сервера

Для Apache правило обычно кладут в .htaccess. Это полезно, когда нужно быстро убрать старую страницу или склеить целый шаблон адресов. Но редактировать файл стоит только после резервной копии.

Redirect 301 /old-page/ https://example.com/new-page/

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

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

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

запустите curl -I -L https://example.com/old-page/;
убедитесь, что конечный адрес соответствует ожидаемому;
проверьте, что нет повторного 301 на целевой странице;
очистите кеш и повторите тест из инкогнито;
посмотрите логи сервера, если переход всё ещё ведёт себя нестабильно.

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

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

Редирект работает в браузере, но не в проверке

Чаще всего виноват кеш: страница отдается из CDN или плагина, а не с сервера. Очистите все уровни кеширования и повторите проверку заголовков.

Старый URL редиректит дважды

Это признак цепочки. Уберите одно из правил и оставьте только финальный адрес. Особенно часто это случается после переноса с http на https и одновременной смены структуры ссылок.

Появилась ошибка 404 вместо 301

Значит, правило не совпало с реальным путём. Проверьте слэш в конце, регистр символов и то, как WordPress формирует REQUEST_URI. Для некоторых сайтов важна даже разница между /page и /page/.

Редирект ломает админку или AJAX

Это обычно происходит, когда правило слишком широкое и не исключает служебные запросы. Добавьте проверки is_admin() и wp_doing_ajax(), а при серверной настройке сузьте область действия правила.

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

Не храните десятки редиректов в functions.php активной темы. При смене темы вы потеряете логику и получите битые ссылки. Для постоянных правил лучше мини-плагин или серверная конфигурация.

Если редиректов много, следите за тем, чтобы они не выполнялись на каждом запросе через тяжёлые проверки базы. Для массовых схем лучше использовать серверный уровень или специализированный плагин с нормальным управлением правилами. Из редакционных инструментов для чистки дублей и SEO-правил иногда используют Clearfy Pro, но только если он реально закрывает вашу задачу и не дублирует серверные настройки: Clearfy Pro.

И ещё один практический момент: после массовой правки URL не полагайтесь только на визуальный просмотр. Прогоните несколько старых адресов через curl, проверьте цепочки и убедитесь, что конечный ответ отдаётся без лишних переходов. Это самый быстрый способ поймать ошибку до того, как её увидят пользователи и поисковые роботы.