301-редирект в WordPress обычно настраивают не ради «красивого URL», а чтобы убрать дубли, склеить старые адреса после переезда и не терять трафик из поисковиков. На практике проблемы начинаются не с самого редиректа, а с его окружения: цепочки, петли, конфликт с каноникалами, редирект на редирект и правила, которые срабатывают не там, где вы ожидали.
Если задача простая — перенести одну страницу или закрыть старый адрес после смены структуры — можно обойтись кодом или штатным плагином. Если редиректов много, сначала нужна диагностика: иначе легко получить ситуацию, когда браузер открывает страницу, а поисковый робот видит совсем другую цепочку.
Когда 301 нужен, а когда он только маскирует проблему
301-редирект — это постоянное перенаправление. Его используют, когда старый URL больше не должен быть основным: после смены структуры записей, переезда с HTTP на HTTPS, объединения дублей со слешем и без, удаления устаревших страниц, смены домена или раздела.
Но если страница существует, а редирект ставят только потому, что «так меньше дублей», это часто плохая идея. Для страниц с одинаковым содержимым сначала проверьте причину дубля: архивы, параметры в URL, пагинацию, сортировки, служебные страницы поиска. Иногда правильнее закрыть дубли от индексации, чем отправлять их на главную или на случайную категорию.
Типовые сценарии
- старый адрес записи после изменения структуры постоянных ссылок;
- перенос с
http://наhttps://; - склейка версий со слешем и без слеша;
- удалённая страница, у которой есть замена;
- редирект служебных URL, которые не должны индексироваться.
Диагностика: что проверить до внесения правил
Перед правкой .htaccess или PHP-кода посмотрите, как именно ведёт себя URL сейчас. Это экономит время: одинаковая ошибка может выглядеть по-разному в браузере, в cURL и в отчёте краулера.
Проверка цепочки редиректов
Самый быстрый способ — посмотреть заголовки ответа. Для теста удобно использовать curl:
curl -I https://example.com/staryj-url/Если всё настроено нормально, вы увидите один ответ 301 Moved Permanently и конечный 200 OK на целевой странице. Если в ответах несколько переходов подряд, это уже цепочка. Если адрес возвращает 302, а должен быть постоянным, поисковики могут дольше переобходить старый URL.
Что смотреть в админке и логах
- есть ли одинаковые страницы с разными адресами;
- не создаёт ли тема или плагин собственный редирект;
- не включён ли одновременно редирект в плагине и на уровне сервера;
- не меняется ли адрес после авторизации, добавления слеша или параметров;
- нет ли петли вида
/page→/page/→/page.
Если у вас есть доступ к логам веб-сервера, проверьте повторяющиеся запросы к одному и тому же URL. Это часто помогает найти петлю быстрее, чем ручной просмотр в браузере.
Пошаговое решение: редирект через код
Если нужен один или несколько точечных редиректов, безопаснее начать с кода в небольшом mu-plugin или в отдельном плагине для сайта. Так правило не потеряется при смене темы.
Ниже пример для редиректа старой записи на новую. Он срабатывает только на фронтенде и не трогает админку.
<?php
/**
* Plugin Name: Site Redirects
*/
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if ($request_uri === '/staryj-url/' || $request_uri === '/staryj-url') {
wp_redirect(home_url('/novyj-url/'), 301);
exit;
}
});Для нескольких адресов удобнее хранить карту редиректов в массиве. Это проще сопровождать, чем размазывать условия по разным хукам.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$path = wp_parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH);
$path = untrailingslashit($path);
$redirects = [
'/old-page' => '/new-page',
'/archive-2022' => '/archive/',
'/contact-us' => '/kontakty/',
];
if (isset($redirects[$path])) {
wp_safe_redirect(home_url($redirects[$path]), 301);
exit;
}
});Здесь важно использовать wp_safe_redirect(), если вы перенаправляете на внутренние URL сайта. Это не панацея, но лишняя проверка безопасности не мешает.
Пошаговое решение: редирект через .htaccess
Если сайт работает на Apache и редирект нужен на уровне сервера, правило в .htaccess обычно быстрее и надёжнее для массовых перенаправлений. Но править его стоит аккуратно: одна лишняя строка легко ломает весь сайт.
Пример для одного адреса:
Redirect 301 /staryj-url/ https://example.com/novyj-url/Если нужно перенаправить HTTP на HTTPS, правило должно стоять выше WordPress-блока, иначе вы получите лишнюю цепочку:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Не смешивайте в одном месте несколько систем редиректов без необходимости. Если часть правил уже живёт в плагине, а часть — в .htaccess, отладка превращается в угадывание, какое правило сработало первым.
Плагин или код: что выбрать в реальной задаче
Для небольшого сайта плагин удобен, если редиректы меняются часто и ими управляет редактор. Для проекта с техническим контролем лучше код или серверные правила: меньше лишней логики и меньше риска, что обновление плагина что-то перепишет.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин редиректов | Много ручных правил, нужен интерфейс в админке | Дополнительная нагрузка и риск конфликтов |
| PHP-код | Точечные правила, нужен контроль в репозитории | Нужен доступ к коду и базовая дисциплина |
| .htaccess / сервер | Массовые и быстрые редиректы на уровне веб-сервера | Ошибки в синтаксисе могут сломать доступ к сайту |
Если на сайте уже используется плагин для SEO или чистки дублей, проверьте, не умеет ли он создавать редиректы сам. Например, в связке с Clearfy Pro можно закрывать технические дубли и управлять частью служебных настроек, но массовые редиректы всё равно лучше держать отдельно и прозрачно.
Как проверить, что редирект сработал правильно
После внедрения не ограничивайтесь открытием URL в браузере. Браузер может кэшировать ответ, а расширения и CDN — подменять поведение.
- проверьте
curl -Iдля старого и нового адреса; - убедитесь, что старый URL отдаёт
301, а не302; - проверьте, что конечная страница отдаёт
200 OK; - посмотрите, нет ли второй переадресации на том же пути;
- проверьте вариант со слешем и без слеша;
- откройте URL в режиме инкогнито и без расширений;
- если есть Search Console, отправьте проверку переобхода после массовых изменений.
Для быстрой проверки цепочки удобно использовать и curl -L -I, если нужно увидеть все переходы подряд:
curl -L -I https://example.com/staryj-url/Частые ошибки и как их исправить
Редирект ведёт на сам себя
Это классическая петля. Обычно она появляется, когда условие сравнивает не нормализованный путь, а полный URL, или когда целевой адрес совпадает с исходным после добавления слеша. Решение: сравнивайте только путь и явно исключайте целевой URL из правил.
Смешаны 301 и 302
Если временный редирект остался после тестов, поисковики могут дольше держать старый адрес в индексе. Проверьте, где именно задаётся код ответа: в плагине, в PHP или на уровне сервера.
Редирект есть, но страница всё равно индексируется
Так бывает, если старый URL ещё отдается как 200 OK для части пользователей, если есть кэш на CDN или если поисковик давно не переобходил страницу. Сначала убедитесь в реальном ответе сервера, потом обновите карту сайта и отправьте URL на переобход.
Появилась цепочка из нескольких переходов
Например, http:// → https:// → /page → /page/. Это не всегда критично для пользователя, но для SEO и скорости обхода лишнее. Сведите правила к одному шагу: сразу на финальный URL.
Безопасность и производительность
Редиректы — не тяжёлая логика, но при ошибочной реализации они могут заметно нагружать сайт. Особенно если правило проверяет много условий на каждом запросе. Для массовых перенаправлений лучше серверный уровень, для точечных — компактный PHP-код.
Не делайте редирект на основе данных из $_GET или $_POST без жёсткой валидации. И не отправляйте пользователя на внешний адрес без проверки, если это не осознанный сценарий. Для внутренних переходов используйте wp_safe_redirect(), а для внешних — только если вы понимаете, зачем это нужно.
Если редиректов становится много, держите их в одном месте и документируйте. Иначе через пару месяцев никто не вспомнит, почему старый адрес товара ведёт на категорию, а не на ближайшую замену.
Практический порядок работ
- Соберите список старых URL и целевых страниц.
- Проверьте, нет ли уже редиректа в плагине, теме или
.htaccess. - Выберите один уровень реализации, а не несколько сразу.
- Добавьте правило и проверьте ответ через
curl -I. - Убедитесь, что нет цепочки и петли.
- Обновите внутренние ссылки на новый адрес.
- Проверьте индексацию старых URL через Search Console или краулер.
Если редиректов много и параллельно нужно убрать технические дубли, удобно сначала привести в порядок структуру сайта, а уже потом настраивать перенаправления. Иначе вы будете чинить следствие, а не причину.