Как настроить 301 редиректы в WordPress

Если у страницы меняется адрес, материал удаляется или вы переносите разделы сайта, без 301 редиректа посетители и поисковые системы будут попадать на 404. Для WordPress это обычная задача, но решать её лучше не «как получится», а в правильном месте: иногда редирект удобнее сделать в плагине, иногда — на уровне сервера, а иногда вообще в коде темы или mu-plugin. От выбора зависит, будет ли редирект работать стабильно и не появятся ли цепочки вида URL A → URL B → URL C.

301 редирект нужен, когда старый адрес должен навсегда вести на новый. Браузер и поисковые роботы понимают такой ответ как постоянное перенаправление и со временем начинают учитывать новый URL вместо старого. Это именно тот случай, когда вы меняете структуру сайта, переводите записи в другие рубрики, объединяете страницы или удаляете контент, у которого есть замена.

Где лучше настраивать 301 редиректы

В WordPress есть три практических уровня, на которых обычно настраивают перенаправления: плагин, сервер и код сайта. Универсального варианта нет, но для разных задач есть очевидно более удобные решения.

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

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

Самый простой вариант: плагин для редиректов

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

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

Что важно проверить перед использованием плагина:

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

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

Редиректы на уровне сервера: когда это предпочтительнее

Если у вас есть доступ к конфигурации Apache или nginx, серверный редирект обычно надёжнее и быстрее. Он отрабатывает до запуска WordPress, поэтому не тратит ресурсы PHP и не зависит от активных плагинов.

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

Пример для Apache, если нужно перенаправить один старый адрес на новый:

Redirect 301 /staryj-url/ https://example.com/novyj-url/

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

Для nginx правило выглядит иначе и добавляется в конфигурацию сайта, а не в WordPress:

rewrite ^/staryj-url/$ https://example.com/novyj-url/ permanent;

Здесь permanent означает постоянный редирект, то есть 301. После изменения конфигурации nginx обычно требуется перезагрузка или reload сервиса, а на shared-хостинге доступ к этому уровню может быть закрыт.

Если вы не уверены, где именно настраивается сервер, не экспериментируйте вслепую. Ошибка в .htaccess или конфиге nginx может сделать сайт недоступным целиком, а не только для одного URL.

Когда редирект лучше делать в коде WordPress

Иногда редирект зависит не от статического списка URL, а от логики сайта. Например, вы хотите перенаправлять записи из старой рубрики в новую, если они относятся к определённому типу контента, или обрабатывать старые адреса по шаблону. В таких случаях можно использовать PHP и хук template_redirect.

Ниже пример простого редиректа в WordPress. Его можно добавить в functions.php дочерней темы, но безопаснее — в отдельный mu-plugin, чтобы правило не исчезло после смены темы.

add_action('template_redirect', function () {
    if (is_page('old-page')) {
        wp_redirect(home_url('/new-page/'), 301);
        exit;
    }
});

Здесь is_page('old-page') проверяет страницу по slug, а wp_redirect() отправляет браузеру постоянное перенаправление. После вызова wp_redirect() обязательно нужен exit;, иначе WordPress продолжит формировать страницу дальше.

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

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

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

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

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

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

Например, если у вас старый адрес /category/news/post/, а итоговый — /blog/post/, не нужно сначала вести на новую рубрику, а потом отдельно на саму запись. Сразу указывайте конечный URL.

Как избежать конфликтов с WordPress и постоянных ссылок

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

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

После переноса структуры сайта полезно проверить:

• не изменились ли настройки постоянных ссылок;
• не осталось ли старых правил в плагине редиректов;
• не дублируются ли правила в .htaccess и в WordPress;
• не ведёт ли новый URL обратно на старый из-за ошибки в шаблоне ссылки.

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

Как проверить, что 301 работает правильно

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

Проверить можно несколькими способами:

• открыть старый URL в режиме инкогнито и убедиться, что он ведёт на нужную страницу;
• посмотреть код ответа через инструменты разработчика или онлайн-проверку заголовков;
• проверить, что ответ именно 301, а не 302;
• убедиться, что конечный URL отдаёт 200 OK, а не ещё один редирект.

Если у вас есть доступ к консоли, можно проверить заголовки командой curl:

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

В ответе должен быть статус 301 Moved Permanently и заголовок Location с новым адресом. Если вместо этого вы видите несколько последовательных переходов, значит редиректов больше одного и цепочку нужно сокращать.

Что делать с удалёнными страницами

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

Если подходящей замены нет, возможны два сценария. Первый — редирект на тематически близкую страницу, если она действительно отвечает на тот же запрос. Второй — оставить 404 или 410, если контент удалён без замены и перенаправление только запутает посетителя. Но если на странице были внешние ссылки, трафик или она участвовала в структуре сайта, обычно всё же ищут ближайший релевантный адрес.

Для переноса структуры сайта это особенно важно: старые разделы не должны вести в случайные места. Лучше заранее составить карту соответствий «старый URL → новый URL» и пройтись по ней один раз, чем потом исправлять хаотичные перенаправления.

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