Как настроить 301 редиректы в WordPress после смены URL страниц

Если в WordPress поменяли адрес страницы, а старая ссылка уже попала в поиск, письма, закладки или внутренние материалы, нужен именно 301-редирект. Без него пользователь увидит 404, а поисковик начнёт переоценивать новую и старую версии URL как разные сущности. На практике проблема часто всплывает после правки слагов, переноса сайта на новый домен, чистки дублей или изменения структуры рубрик.

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

Когда редирект действительно нужен

Не каждый изменённый URL требует отдельной настройки. Но 301 нужен, если страница уже индексировалась, на неё есть внешние ссылки или она участвует во внутренней перелинковке. Особенно это важно для:

• изменения slug у записи или страницы;
• переноса материалов из одной рубрики в другую, если меняется структура URL;
• объединения похожих страниц в одну;
• смены домена или перехода с http на https;
• удаления старых посадочных страниц, которые нужно перенаправить на ближайший релевантный аналог.

Если страница удалена без замены и у неё нет трафика, иногда достаточно отдать 410. Но это отдельный сценарий; здесь разбираем именно перенос и сохранение веса через 301.

Диагностика: что сломалось после смены URL

Перед настройкой редиректов проверьте, что именно изменилось. Частая ошибка — ставить редирект «на глаз», а потом получить цепочку из двух-трёх переходов или отправить пользователя не туда.

Проверьте старый и новый адрес

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

Для быстрой проверки удобно посмотреть заголовки ответа:

curl -I https://example.com/staraya-stranica/

В ответе для старого URL должен быть статус 301 и заголовок Location с новым адресом. Если видите 200, редиректа нет. Если 302, перенаправление временное, и для постоянного переноса это не лучший вариант.

Найдите источник старых ссылок

Старый адрес может жить не только в поиске. Проверьте:

• внутренние ссылки в контенте;
• меню и виджеты;
• XML-карту сайта и кэш SEO-плагина;
• внешние ссылки с других сайтов;
• старые письма, PDF и рекламные кампании.

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

Какой способ выбрать: плагин, код или сервер

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

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

Пошаговое решение через код

Ниже пример для простого случая: старый URL должен вести на новый. Такой код лучше размещать в mu-plugin или в отдельном функциональном плагине, а не в теме, чтобы правило не исчезло при смене шаблона.

<?php
/**
 * Plugin Name: Simple Redirects
 */

add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    $request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';
    $path = trim(parse_url($request_uri, PHP_URL_PATH), '/');

    $map = [
        'staraya-stranica' => 'novaya-stranica',
        'staryj-razdel/urok-1' => 'novyj-razdel/urok-1',
    ];

    if (!isset($map[$path])) {
        return;
    }

    $target = home_url('/' . ltrim($map[$path], '/') . '/');
    wp_redirect($target, 301);
    exit;
});

Что здесь важно:

• проверка идёт только на фронтенде;
• используется 301, а не 302;
• редирект срабатывает до вывода HTML;
• карта соответствий хранится явно, без попыток «угадать» новый URL.

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

Вариант через .htaccess для Apache

Если сайт работает на Apache и у вас есть доступ к .htaccess, редирект можно сделать на уровне сервера. Это быстрее, чем обработка в WordPress, и полезно для массовых переносов.

RewriteEngine On
RewriteRule ^staraya-stranica/?$ /novaya-stranica/ [R=301,L]
RewriteRule ^staryj-razdel/urok-1/?$ /novyj-razdel/urok-1/ [R=301,L]

Не смешивайте такие правила с логикой, которая зависит от WordPress-переменных. Для простых постоянных перенаправлений серверный уровень надёжнее. Но перед правкой обязательно сделайте резервную копию файла: одна лишняя строка может положить весь сайт.

Как проверить, что редирект сработал

После внедрения проверьте не только сам переход, но и отсутствие цепочек.

• Откройте старый URL в браузере в режиме инкогнито.
• Проверьте статус ответа через curl -I или DevTools.
• Убедитесь, что конечный адрес отдаёт 200, а не новый редирект.
• Проверьте, что канонический URL на новой странице совпадает с целевым адресом.
• Обновите внутренние ссылки, если старый URL всё ещё используется в контенте.

Полезно отдельно посмотреть цепочку редиректов:

curl -I -L https://example.com/staraya-stranica/

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

Частые ошибки и как их исправить

Ставят 302 вместо 301

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

Редирект ведёт на нерелевантную страницу

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

Создают цепочку редиректов

Например, /old/ → /new/ → /final/. Это лишняя задержка и дополнительная точка отказа. Сразу направляйте старый URL на финальный адрес.

Забывают про внутренние ссылки

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

Ставят правило в тему

Если редирект критичен, не храните его в functions.php активной темы. При смене шаблона правило исчезнет. Для постоянной логики лучше использовать mu-plugin или отдельный плагин.

Безопасность и производительность

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

Если переносите большой сайт, сначала соберите карту старых URL. Это можно сделать из:

• логов сервера;
• Google Search Console;
• экспорта из SEO-плагина;
• краулера вроде Screaming Frog или аналогичного инструмента.

После массовой настройки не забудьте очистить кэш страниц, объектный кэш и CDN, если он используется. Иначе вы можете проверить уже устаревшую версию ответа.

Когда лучше использовать плагин

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

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