Как устранить 404 на старой странице после смены URL в WordPress

Автор: Диана Соколова | Опубликовано: 20.09.2026

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

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

Когда 404 после смены URL — это не случайность

Сначала важно понять, откуда берётся ошибка. В WordPress 404 на старой странице обычно возникает в трёх сценариях:

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

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

Как быстро диагностировать источник проблемы

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

curl -I https://example.com/staryy-url/

В ответе ищите статус 301 и заголовок Location. Если видите 404, 200 на неправильной странице или несколько последовательных редиректов, это повод править конфигурацию.

Что делать: редирект 301 на новый адрес

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

Способ	Когда подходит	Минус
.htaccess / nginx	Нужно быстро и точно закрыть один или несколько URL	Требует доступа к серверу и аккуратности
Плагин редиректов	Редиректами управляет редактор или контент-менеджер	Дополнительная нагрузка и зависимость от плагина
Код в теме или mu-plugin	Нужна централизованная логика для конкретных случаев	Нужно уметь поддерживать код

Вариант 1: редирект через .htaccess

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

Redirect 301 /staryy-url/ https://example.com/novyy-url/

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

Вариант 2: редирект через functions.php или mu-plugin

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

<?php
/**
 * Plugin Name: Custom Redirects
 */
add_action('template_redirect', function () {
    if (is_admin()) {
        return;
    }

    $request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';

    if ($request_uri === '/staryy-url/' || $request_uri === '/staryy-url') {
        wp_redirect(home_url('/novyy-url/'), 301);
        exit;
    }
});

Здесь важно не пытаться «ловить всё подряд» через размытые условия. Чем точнее совпадение, тем меньше шанс случайно отправить на новый адрес лишние страницы.

Вариант 3: плагин редиректов

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

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

Пошаговая схема внедрения

Соберите список старых URL из Search Console, логов сервера, аналитики и внутренних ссылок.
Для каждого URL определите новый целевой адрес.
Выберите способ реализации: сервер, плагин или код.
Добавьте редирект 301, а не 302, если адрес изменился навсегда.
Проверьте, что нет цепочки из нескольких переходов.
Обновите внутренние ссылки в контенте, чтобы не гонять пользователей через редирект.

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

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

Проверка должна быть не только визуальной. Откройте старый адрес и убедитесь, что:

старый URL отдаёт 301;
в Location указан нужный новый адрес;
новая страница открывается со статусом 200;
нет цепочки редиректов вида старый → промежуточный → новый;
внутренние ссылки на сайте больше не ведут на старый адрес.

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

curl -I https://example.com/staryy-url/
curl -I https://example.com/novyy-url/

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

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

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

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

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

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

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

Например, старый адрес сначала идёт на промежуточный slug, а потом уже на финальный. Это лишняя задержка и дополнительный риск ошибки. Сведите всё к одному прямому переходу.

Редирект работает в браузере, но не в curl

Так бывает, если правило завязано на JavaScript или на клиентскую логику. Для SEO и серверной обработки это не подходит. Редирект должен отдаваться сервером или WordPress до вывода HTML.

Правило ломает админку или REST API

Если вы пишете редирект кодом, обязательно исключайте /wp-admin/, /wp-login.php и REST-запросы. Иначе можно получить странные побочные эффекты в редакторе и интеграциях.

Чек-лист перед публикацией изменений

старый URL сохранён в списке редиректов;
новый URL отвечает 200;
редирект один, без промежуточных шагов;
внутренние ссылки обновлены;
нет конфликтов с кэшем;
проверка через curl -I пройдена;
страница не попала в петлю редиректов.

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

Если редиректов немного, серверное правило обычно быстрее и чище, чем отдельный плагин. Но если правил много и ими управляет команда контента, плагин может быть практичнее — при условии, что вы не дублируете логику в нескольких местах.

Не храните редиректы одновременно в .htaccess, в плагине и в коде темы. В такой схеме почти невозможно быстро понять, какое правило сработало. Для поддержки это лишний риск.

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

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