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

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

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

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

Как понять, что 404 идут именно со старых URL

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

Что проверить в первую очередь

отчёт Страницы в Google Search Console, если сайт уже там подключён;
access log веб-сервера: запросы к старым путям и статус 404;
внутренние ссылки в контенте, меню и виджетах;
внешние ссылки из старых публикаций, партнёрских материалов, соцсетей;
кэш и CDN: иногда они продолжают отдавать старые адреса из-за задержки обновления.

Если URL были вида /2023/05/nazvanie-posta/, а стали короткими /nazvanie-posta/, то старые адреса нужно не просто закрыть, а перенаправить на новый эквивалент. Для поисковика это сигнал, что страница переехала, а не исчезла.

Пошаговое решение: от редиректов к проверке индексации

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

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

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

RewriteEngine On
RewriteRule ^[0-9]{4}/[0-9]{2}/(.+?)/?$ /$1/ [R=301,L]

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

Вариант 2: редирект через PHP в WordPress

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

add_action( 'template_redirect', function () {
    if ( is_404() ) {
        $request_uri = $_SERVER['REQUEST_URI'] ?? '';

        if ( preg_match( '#^/([0-9]{4})/([0-9]{2})/([^/]+)/?$#', $request_uri, $m ) ) {
            $slug = sanitize_title( $m[3] );
            $post = get_page_by_path( $slug, OBJECT, array( 'post', 'page' ) );

            if ( $post ) {
                wp_redirect( get_permalink( $post ), 301 );
                exit;
            }
        }
    }
} );

Этот код стоит использовать только после теста на staging. Он не должен превращать любой 404 в случайную переадресацию: если совпадение найдено неверно, пользователь попадёт не туда, а поисковик получит плохой сигнал.

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

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

Подход	Когда подходит	Минус
Серверный редирект	Один старый шаблон URL на весь сайт	Сложнее отлаживать без доступа к логам
PHP в теме/плагине	Нужна логика по типам записей и слагам	Риск ошибок при обновлении темы
Плагин редиректов	Много точечных правил и ручная поддержка	Дополнительная нагрузка и зависимость от плагина

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

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

Чек-лист проверки

старый URL отдаёт 301, а не 302;
новый URL открывается с кодом 200;
нет цепочки из нескольких редиректов подряд;
внутренние ссылки в контенте уже обновлены;
в sitemap.xml нет старых адресов;
в Search Console не растёт число ошибок по старому шаблону.

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

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

После настройки откройте несколько старых URL вручную и через curl. Важно смотреть не только на конечную страницу, но и на код ответа. Для SEO критично, чтобы старый адрес отдавал именно 301 Moved Permanently.

curl -I https://example.com/2023/05/nazvanie-posta/

В ответе должно быть что-то вроде:

HTTP/2 301
location: https://example.com/nazvanie-posta/

Дальше проверьте новый URL:

curl -I https://example.com/nazvanie-posta/

Здесь нужен 200 OK без лишних переадресаций. Если видите цепочку 301 → 301 → 200, лучше сократить её до одного шага. Каждая лишняя переадресация замедляет загрузку и усложняет обход сайта роботами.

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

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

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

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

Так делают, когда не знают точный новый адрес. Для пользователя это плохой сценарий, а для поисковика — слабый сигнал релевантности. Лучше найти соответствующую страницу или оставить честный 404, если аналога больше нет.

Создают бесконечный цикл

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

Не обновляют внутренние ссылки

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

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

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

Если редиректы на сайте уже разрослись, полезно периодически чистить неиспользуемые правила. Это снижает риск конфликтов и упрощает отладку. Для технической чистки и удаления дублей в WordPress можно посмотреть на Clearfy Pro, если вам нужен набор инструментов для SEO-настроек и обслуживания сайта в одном месте.

Что делать, если старый URL уже не имеет аналога

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

Практически это выглядит так: для важных старых URL настраиваем 301 на ближайший релевантный аналог, для устаревших и незначимых — оставляем 404/410, но следим, чтобы такие ошибки не были вызваны технической поломкой. Именно поэтому сначала нужна диагностика, а уже потом массовая правка.

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