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