Если вы перенесли страницу, поменяли структуру URL или удалили старый материал, 301-редирект помогает не потерять трафик и передать часть накопленного веса на новый адрес. В WordPress это можно сделать без плагинов: через правила веб-сервера или код в теме. Для постоянных редиректов это обычно надежнее и легче, чем ставить отдельный плагин ради одной-двух записей.
Ниже разберу рабочие способы для Apache и Nginx, а также вариант через PHP, если доступ к конфигу сервера ограничен. Сразу оговорюсь: перед изменениями в правилах сервера сделайте резервную копию. Ошибка в синтаксисе может уронить сайт или зациклить редиректы.
Когда 301-редирект нужен в WordPress
301 используют, когда старый адрес больше не должен открываться как основной, а вместо него есть новый. Типичные случаи:
- сменили структуру постоянных ссылок;
- перенесли страницу в другую рубрику и изменился URL;
- объединили несколько материалов в один;
- удалили устаревшую страницу и хотите отправлять пользователей на ближайший аналог;
- переехали с одного домена на другой.
Если страница просто временно недоступна, 301 не подходит. Для таких случаев используют 302 или 307, но это уже другая задача.
Самый надежный вариант: редирект на уровне сервера
Если у вас есть доступ к настройкам Apache или Nginx, лучше делать редиректы там. Сервер отработает их раньше WordPress, без загрузки PHP и без зависимости от темы.
Apache: редирект через .htaccess
На большинстве хостингов с Apache правила добавляют в файл .htaccess в корне сайта WordPress. Перед правкой сохраните текущую копию файла. Если что-то пойдет не так, вы сможете быстро вернуть рабочую версию.
Для одного адреса на другой можно использовать такое правило:
Redirect 301 /old-page/ https://example.com/new-page/Если нужно перенаправить конкретный URL внутри того же сайта, этого достаточно. Старый путь указывают относительно корня сайта, а новый — полностью, с протоколом и доменом.
Когда требуется более гибкое правило, например редирект по регулярному выражению, удобнее использовать mod_rewrite. Пример для переноса всех URL из старого раздела /blog/ в новый /articles/:
RewriteEngine On
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]Такое правило перенаправит, например, /blog/post-1/ на /articles/post-1/. Важно не дублировать уже существующие правила WordPress и не ставить редирект выше системных директив без необходимости. Если вы не уверены, сначала добавляйте точечные правила для одного-двух адресов, а не массовую замену.
Nginx: редирект в конфиге сервера
На Nginx правила обычно добавляют в конфигурацию сайта, а не в отдельный файл внутри WordPress. Доступ к конфигу зависит от хостинга: на VPS вы правите его сами, на shared-хостинге — через панель или поддержку.
Для одного адреса подойдет такой вариант:
location = /old-page/ {
return 301 https://example.com/new-page/;
}Если нужно перенаправить целый каталог, можно использовать:
rewrite ^/blog/(.*)$ /articles/$1 permanent;После изменения конфигурации Nginx обычно требуется проверить синтаксис и перезагрузить сервис. На VPS это делают командами вроде nginx -t и затем перезапуском или reload, но если сервером управляет хостинг, лучше не выполнять это вручную без понимания последствий. Ошибка в конфиге Nginx может сделать сайт недоступным до исправления.
Если доступа к серверу нет: редирект через functions.php
Когда вы не можете править Apache или Nginx, редирект можно сделать в WordPress-коде. Это рабочий вариант, но он менее предпочтителен: редирект выполняется только после загрузки WordPress, а значит медленнее и сильнее зависит от темы.
Добавлять код лучше в дочернюю тему или в собственный мини-плагин. Не вносите правки прямо в файлы родительской темы, если тема обновляется: изменения затрутся.
Простой редирект одной страницы через template_redirect:
add_action('template_redirect', function () {
if (is_page('old-page')) {
wp_redirect('https://example.com/new-page/', 301);
exit;
}
});Здесь is_page('old-page') проверяет страницу по слагу. Вместо слага можно использовать ID или заголовок, но слаг обычно понятнее и стабильнее, если он не меняется.
Если нужно перенаправить старый URL записи, можно использовать is_single() или проверку по условию для конкретного шаблона. Но для большого числа адресов PHP-способ быстро становится неудобным: правила разрастаются, а каждая загрузка страницы тратит ресурсы на проверку условий.
Как не сломать сайт при настройке редиректов
Главная ошибка — создавать цепочки и петли. Цепочка выглядит так: старый URL ведет на промежуточный, а тот — на конечный. Петля возникает, когда адрес редиректит сам на себя или на URL, который снова возвращает назад. В обоих случаях пользователь и поисковый робот теряют время, а иногда страница вообще перестает открываться.
Проверьте три вещи:
- старый адрес действительно больше не используется как основной;
- новый URL отвечает кодом 200, а не еще одним редиректом;
- в правиле нет лишних условий, которые захватывают соседние страницы.
Если меняете структуру сразу у большого числа страниц, сначала протестируйте несколько самых важных URL. Это проще, чем потом искать, какое правило перехватило лишний адрес.
Как проверить, что 301 работает
После настройки откройте старый адрес в браузере и убедитесь, что вы попадаете на новый. Но визуальной проверки недостаточно: важно увидеть именно код ответа 301, а не 302 или 200.
Самый простой способ — посмотреть заголовки ответа. Если у вас есть терминал, можно использовать:
curl -I https://example.com/old-page/В ответе должен быть статус 301 Moved Permanently и заголовок Location с новым адресом. Если вы видите несколько последовательных переходов, значит редиректов больше одного и их стоит сократить.
Если терминала нет, проверьте URL через любой инструмент просмотра HTTP-заголовков или через браузерные devtools. Главное — убедиться, что старый адрес не отдает контент как обычная страница и не возвращает ошибку 404, если вы рассчитывали на перенаправление.
Какой способ выбрать на практике
| Способ | Когда подходит | Что важно учесть |
|---|---|---|
| .htaccess в Apache | Обычный shared-хостинг с Apache | Нужна аккуратность в синтаксисе, файл легко сломать одной ошибкой |
| Конфиг Nginx | VPS, выделенный сервер, хостинг с доступом к конфигу | Редиректы работают быстро, но правки зависят от доступа к серверу |
| functions.php или мини-плагин | Нет доступа к серверу, нужен точечный редирект | Зависит от WordPress и темы, хуже подходит для массовых правил |
Если у вас есть доступ к серверу, выбирайте серверные правила. Если доступ ограничен и нужен один-два редиректа, допустим PHP-вариант. Для больших миграций лучше заранее собрать список старых и новых URL и перенести правила на уровень веб-сервера, а не размазывать их по теме.
Такой подход помогает сохранить трафик после переезда, не нагружает WordPress лишней логикой и позволяет контролировать поведение каждого старого адреса. Если редиректов много, начинайте с самых посещаемых страниц и проверяйте их вручную после внедрения.