Если после смены структуры сайта или удаления страниц старые адреса продолжают открываться, их нужно перенаправить на новые. Для WordPress это обычно делают редиректом 301: он сообщает браузерам и поисковым системам, что страница переехала навсегда, а не временно. Без такого перенаправления вы теряете трафик, получаете ошибки 404 и часто ломаете внутренние ссылки из старых материалов, рассылок и закладок.
Без плагинов редиректы настраивают на уровне веб-сервера или, если доступа к конфигурации нет, через код темы или mu-plugin. Самый надёжный вариант — серверный редирект: он срабатывает раньше WordPress и не зависит от темы, кэша страниц или состояния базы данных.
Когда 301 нужен именно в WordPress
Редирект 301 ставят не для любой смены URL, а когда адрес действительно изменился надолго. Типичные случаи:
- изменили структуру постоянных ссылок;
- перенесли страницу в другую рубрику и поменяли слаг;
- объединили несколько страниц в одну новую;
- удалили старую запись, но хотите отправить пользователей на ближайший релевантный материал;
- переехали с HTTP на HTTPS или с www на без www, либо наоборот.
Если страница просто временно недоступна, 301 не подходит. В таком случае нужен другой код ответа, но это уже отдельная задача. Для постоянного переезда используйте именно 301.
Какой способ выбрать: .htaccess, Nginx или PHP
Выбор зависит от того, на чём работает сайт. Для WordPress это обычно Apache или Nginx, реже — другой сервер с похожими правилами.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
.htaccess | Сайт на Apache или LiteSpeed | Быстро, не требует правок WordPress | Нужно аккуратно редактировать файл, ошибка может сломать сайт |
| Конфиг Nginx | Сайт на Nginx | Надёжно и быстро | Нужен доступ к конфигурации сервера или помощь хостинга |
| PHP-редирект | Нет доступа к серверным настройкам | Можно сделать из WordPress | Позже срабатывает, зависит от темы или mu-plugin |
Если есть доступ к серверу, выбирайте серверный вариант. PHP-редирект оставляйте как запасной, когда хостинг не даёт править конфигурацию.
Редирект 301 через .htaccess на Apache
На большинстве сайтов WordPress на Apache правила добавляют в файл .htaccess в корне сайта. Перед правкой сделайте резервную копию файла. Если ошибиться в синтаксисе, сайт может начать отдавать ошибку 500.
Для одного старого адреса и нового URL достаточно такого правила:
Redirect 301 /staryj-url/ https://example.com/novyj-url/Здесь важно указать путь относительно домена, а не полный старый URL. Вторая часть — уже новый абсолютный адрес.
Если нужно перенаправить несколько старых страниц, добавляйте отдельную строку для каждой. Для более сложных случаев удобнее использовать модуль mod_rewrite. Например, когда нужно перенаправить старую рубрику на новую:
RewriteEngine On
RewriteRule ^category/staryj-razdel/?$ https://example.com/novyj-razdel/ [R=301,L]Правило должно находиться выше стандартного блока WordPress, который начинается с комментариев # BEGIN WordPress и # END WordPress. Сам блок WordPress лучше не трогать без необходимости.
Если вы меняете схему с HTTP на HTTPS или с www на без www, обычно это делают отдельным общим правилом, а не по одной странице. Но перед этим убедитесь, что SSL уже настроен и сайт открывается по новому адресу без ошибок сертификата.
Редирект 301 в конфигурации Nginx
На Nginx правила пишут в конфигурации сайта, обычно в блоке server. Доступ к файлам конфигурации часто есть только у администратора сервера или у техподдержки хостинга. Это нормальная ситуация: на shared-хостинге править Nginx напрямую обычно нельзя.
Для одного адреса правило выглядит так:
location = /staryj-url/ {
return 301 https://example.com/novyj-url/;
}Если нужно перенаправить несколько похожих URL, можно использовать регулярное выражение, но тут легко ошибиться. Когда старых адресов немного, безопаснее прописать их по одному.
После изменения конфигурации Nginx обычно требуется перезагрузка или reload сервера. Если вы не управляете сервером сами, попросите хостинг применить изменения и проверить конфиг на ошибки.
Редирект через PHP, если серверные настройки недоступны
Этот способ используют, когда нельзя редактировать .htaccess или конфиг Nginx. Лучше всего делать редирект не в functions.php активной темы, а в небольшом mu-plugin. Тогда правило не пропадёт после смены темы.
Создайте файл, например wp-content/mu-plugins/redirects.php. Если папки mu-plugins нет, её можно создать вручную. Вставьте туда такой код:
<?php
add_action('template_redirect', function () {
if (is_page('staryj-url')) {
wp_redirect('https://example.com/novyj-url/', 301);
exit;
}
});Функция is_page() подходит для страниц. Для записей можно использовать is_single(), для произвольных типов записей — соответствующие условия. После вызова wp_redirect() обязательно нужен exit;, иначе WordPress продолжит отдавать страницу.
У этого способа есть ограничение: он работает только после загрузки WordPress. Для небольшого числа редиректов это приемлемо, но если у вас много старых URL и важна скорость, лучше перенести правила на уровень сервера.
Как проверить, что редирект работает правильно
После настройки не ограничивайтесь открытием ссылки в браузере. Браузер может скрыть детали, а вам нужно убедиться, что сервер действительно отдаёт код 301 и правильный новый адрес.
Проверьте старый URL одним из способов:
- в терминале через
curl -I https://example.com/staryj-url/; - через онлайн-проверку HTTP-заголовков;
- в инструментах разработчика браузера, если умеете смотреть ответ сервера.
В ответе должен быть статус 301 Moved Permanently и заголовок Location с новым адресом. Если видите 302, значит редирект временный, а это уже другая логика. Если вместо редиректа открывается старая страница, правило не сработало или стоит ниже другого правила, которое его перебивает.
После проверки откройте новый URL и убедитесь, что он отдаёт 200 OK, а не зацикливается на новом редиректе. Петля редиректов часто возникает, когда старый и новый адреса перепутаны местами или когда одновременно работают несколько правил: в плагине, в теме и на сервере.
Типичные ошибки, из-за которых редирект не срабатывает
На практике проблемы обычно повторяются. Вот что стоит проверить в первую очередь:
- правило написано не в том месте файла и перекрывается общими правилами WordPress;
- в
.htaccessдопущена синтаксическая ошибка; - в Nginx забыли перезагрузить конфигурацию;
- в PHP-редиректе условие не совпадает с реальным типом записи или слагом;
- новый URL уже сам перенаправляет куда-то ещё;
- на сайте включён кэш, и вы смотрите старую версию ответа;
- редирект настроен и в плагине, и вручную, из-за чего возникает конфликт.
Если редиректов много, сначала уберите дублирующиеся правила и оставьте один источник истины. Для WordPress это особенно важно: когда одно и то же перенаправление прописано в нескольких местах, отладка становится заметно сложнее.
Что делать после переноса старых URL
Когда основные 301 уже стоят, пройдитесь по старым адресам из аналитики, Search Console и логов сервера. Обычно именно там всплывают страницы, о которых вы не помнили: старые статьи, архивы, вложения, URL с ошибками в написании, ссылки из внешних сайтов.
Не перенаправляйте всё подряд на главную страницу. Для поисковых систем и пользователей это плохой сигнал: человек ожидал конкретный материал, а получил нерелевантную страницу. Если точного аналога нет, выбирайте ближайшую по смыслу страницу или раздел.
Если сайт большой и структура менялась не один раз, ведите простой список старых и новых URL. Это экономит время при повторных правках и помогает не забыть уже настроенные правила. Для WordPress это особенно полезно после редизайна, миграции на новый домен или массового обновления слагов.
Смысл 301-редиректа в том, чтобы сохранить переходы и не оставлять пользователей на 404. Если настроить его на сервере и потом проверить ответ заголовков, задача обычно решается без плагинов и без лишней нагрузки на сам WordPress.