Как исправить 404 после смены slug в WordPress без потери трафика

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

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

Когда 404 после смены slug — это не случайность, а системная ошибка

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

Типичные сценарии

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

Диагностика: где именно ломается переход

Сначала нужно понять, старый URL вообще существует в системе или уже полностью потерян. Это важно: если WordPress ещё умеет распознать старый путь, можно обойтись более точечной настройкой. Если нет — нужен явный редирект.

Проверьте три вещи

1. Открывается ли старый URL в браузере без кэша и авторизации.
2. Есть ли этот адрес в wp-content/debug.log или в логах веб-сервера как повторяющийся 404.
3. Не остались ли старые ссылки в меню, контенте, виджетах, блоках или шаблонах темы.

Если у вас есть доступ к серверу, полезно посмотреть заголовки ответа:

curl -I https://example.com/old-slug/

В нормальной схеме вы должны увидеть либо 301 на новый адрес, либо сразу 200 на актуальной странице. Если отдаётся 404, редиректа нет или он не срабатывает.

Что делать сначала: сравнить варианты решения

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

Пошаговое решение: как закрыть старые URL корректно

Шаг 1. Сохраните список старых адресов

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

Шаг 2. Настройте 301-редирект на новый адрес

Если редиректов немного, можно сделать их через плагин. Если нужен код, безопаснее вынести его в мини-плагин или в functions.php дочерней темы. Ниже пример для точечного редиректа старого slug на новый:

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

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

    $map = [
        'old-slug' => 'new-slug',
        'old-page'  => 'new-page',
    ];

    if (isset($map[$path])) {
        wp_redirect(home_url('/' . $map[$path] . '/'), 301);
        exit;
    }
});

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

Шаг 3. Для записей и страниц проверьте, не остались ли старые ссылки в контенте

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

Для массовой замены ссылок используйте поиск по базе с осторожностью. Перед этим сделайте резервную копию и проверьте, не затронет ли замена сериализованные данные. Для обычных URL в контенте безопаснее работать через инструменты, которые понимают структуру WordPress, а не через грубый SQL replace.

Шаг 4. Если менялся slug рубрики или метки, обновите архивные ссылки

После смены slug таксономии проверьте:

• ссылки в меню;
• хлебные крошки;
• блоки с рубриками и тегами;
• sitemap, если он генерируется плагином или ядром;
• внутренние ссылки в похожих записях и списках материалов.

Если архив больше не нужен, не оставляйте его просто в 404. Лучше явно перенаправить старый архив на новый или на ближайший релевантный раздел.

Как сделать редирект точнее: по конкретной записи

Если вы переименовали только одну запись и знаете её ID, можно привязать редирект к объекту WordPress. Это удобнее, когда slug меняется, а запись остаётся той же.

add_action('template_redirect', function () {
    if (!is_singular('post')) {
        return;
    }

    $post_id = get_queried_object_id();
    if (!$post_id) {
        return;
    }

    $current_url = home_url(add_query_arg([], $GLOBALS['wp']->request));
    $canonical = get_permalink($post_id);

    if (trailingslashit($current_url) !== trailingslashit($canonical)) {
        wp_redirect($canonical, 301);
        exit;
    }
});

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

Проверка результата после внедрения

После настройки редиректов не ограничивайтесь открытием страницы в браузере. Браузер может показать вам закэшированный результат, а поисковый бот — совсем другой.

• Проверьте старый URL через curl -I и убедитесь, что ответ 301.
• Откройте новый URL и проверьте код ответа 200.
• Посмотрите, нет ли цепочки 301 → 301 → 200.
• Проверьте внутренние ссылки в меню и контенте.
• Если используется кэш-плагин или CDN, очистите кэш после изменений.

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

curl -IL https://example.com/old-slug/

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

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

Редирект сделан на 302 вместо 301

302 воспринимается как временный переход. Для смены slug нужен именно постоянный редирект, иначе поисковые системы могут дольше держать старый адрес в индексе.

Старый URL ведёт на главную страницу

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

Редирект настроен в плагине и в коде одновременно

Так легко получить конфликт правил. В итоге один слой отправляет на новый URL, второй — обратно или на другой адрес. Оставьте один источник правды: либо плагин, либо код, либо сервер.

Не обновили ссылки в шаблоне темы

Иногда старый slug зашит прямо в шаблон или в настройки блока. Тогда редирект будет срабатывать на каждом клике, хотя проблема лежит в теме. Проверьте шаблоны, особенно если URL собирается вручную через home_url() и строку пути.

Не учли кэш

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

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

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

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

Если вам нужен более широкий набор инструментов для технической чистки сайта — дубли, мета-теги, индексация, кэш и базовые SEO-настройки — имеет смысл смотреть в сторону решений вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином принцип остаётся тем же: сначала найти источник старого URL, потом закрыть его одним корректным редиректом, потом проверить код ответа и внутренние ссылки.

Если после смены slug у вас всё ещё всплывают 404, не начинайте с массовой чистки базы. Сначала проверьте конкретный адрес, цепочку редиректов и источник ссылки. В WordPress это почти всегда быстрее, чем искать проблему «в целом по сайту».