Как настроить 301-редирект для удалённых страниц в WordPress

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

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

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

301 ставят не «на всякий случай», а когда у удалённой страницы есть понятный аналог. Например, старая статья переехала в новый URL, карточка услуги заменена обновлённой версией, а раздел каталога был объединён с другим разделом. В этих случаях поисковику и пользователю нужно показать новый адрес, а не тупик.

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

Диагностика перед настройкой

Перед тем как что-то править, проверьте три вещи:

• есть ли на удалённый URL внутренние ссылки из меню, контента, хлебных крошек и похожих материалов;
• есть ли внешние ссылки или трафик из поиска на этот адрес;
• есть ли у страницы замена с близким смыслом и тем же намерением пользователя.

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

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

Для единичных редиректов проще использовать плагин. Для большого количества правил надёжнее держать их на уровне сервера или в отдельном mu-plugin, чтобы не зависеть от темы. Внутри .htaccess или конфигурации Nginx редиректы работают быстрее, но требуют аккуратности и доступа к серверу.

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

Если редиректов немного и вы хотите хранить их в проекте, удобнее сделать отдельный mu-plugin. Так правила не потеряются при обновлении темы.

Создайте файл wp-content/mu-plugins/redirects.php. Если папки mu-plugins нет, её можно создать вручную.

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

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

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';
    $path = parse_url($request_uri, PHP_URL_PATH);

    $map = [
        '/staryj-razdel/' => '/novyj-razdel/',
        '/usluga-2019/'   => '/usluga/',
        '/article-old/'   => '/article-new/',
    ];

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

    wp_redirect(home_url($map[$path]), 301);
    exit;
});

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

• template_redirect срабатывает до вывода шаблона, поэтому заголовки ещё можно отправить;
• мы сравниваем только путь URL, без домена и без параметров;
• wp_redirect() в WordPress безопаснее, чем ручной header('Location: ...'), если вы передаёте корректный URL;
• exit обязателен, иначе WordPress продолжит рендерить страницу.

Если нужен редирект по шаблону URL

Иногда удаляются не отдельные страницы, а целый тип адресов. Например, старый раздел с датой в URL. Тогда можно проверять шаблон через регулярное выражение.

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

    $path = parse_url($_SERVER['REQUEST_URI'] ?? '', PHP_URL_PATH);

    if (!$path) {
        return;
    }

    if (preg_match('#^/blog/20[0-9]{2}/.*#', $path)) {
        wp_redirect(home_url('/blog/'), 301);
        exit;
    }
});

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

Настройка через сервер: когда это лучше

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

Для Apache пример может выглядеть так:

Redirect 301 /staryj-razdel/ https://example.com/novyj-razdel/
Redirect 301 /usluga-2019/ https://example.com/usluga/

В Nginx обычно используют return 301 внутри server-блока:

location = /staryj-razdel/ {
    return 301 https://example.com/novyj-razdel/;
}

location = /usluga-2019/ {
    return 301 https://example.com/usluga/;
}

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

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

После настройки не ограничивайтесь открытием URL в браузере. Проверьте код ответа и отсутствие цепочек.

• Старый URL отдаёт 301, а не 302;
• Новый URL открывается сразу, без промежуточных переходов;
• В адресной строке нет лишних прыжков между http и https или между www и без www;
• Внутренние ссылки на сайте уже ведут на новый адрес;
• Страница назначения отвечает 200 OK, а не ещё одним редиректом.

Проверить код ответа можно через curl:

curl -I https://example.com/staryj-razdel/

В ответе должен быть заголовок HTTP/2 301 или HTTP/1.1 301 Moved Permanently, а в Location — нужный URL. Если видите 302, значит редирект временный, и для постоянного переноса это неверно.

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

Редирект на главную вместо релевантной страницы

Это самая частая ошибка. Поисковик видит, что старый URL исчез, но новая страница не соответствует запросу. В итоге часть сигналов теряется, а пользователь получает нерелевантный контент. Лучше направлять на ближайшую по смыслу страницу или оставить 404/410, если замены нет.

Цепочка из нескольких редиректов

Например, /old/ ведёт на /new/, а /new/ потом ещё на /final/. Такие цепочки замедляют загрузку и усложняют обход. Сразу указывайте конечный адрес.

Смешивание 301 и 302

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

Редирект с сохранением старых параметров без проверки

Иногда в URL есть UTM-метки или служебные параметры. Если вы собираете адрес вручную, можно случайно потерять их или, наоборот, передать лишнее. Для редиректов по пути лучше сравнивать только PHP_URL_PATH, а параметры обрабатывать отдельно, если они действительно нужны.

Что делать с удалёнными страницами, если редирект не нужен

Если у страницы нет замены и она не должна возвращаться, не пытайтесь искусственно «спасти» её редиректом. В таких случаях корректнее оставить 404 или вернуть 410 Gone. Это честнее для поисковика и понятнее для пользователя, чем отправка на случайную страницу.

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

Практические советы по безопасности и производительности

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

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

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

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