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

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

Как понять, что проблема именно в URL, а не в теме или плагине

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

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

• Настройки Постоянные ссылки в админке.
• Есть ли редирект со старого URL на новый.
• Не изменился ли slug записи, рубрики или таксономии.
• Не конфликтует ли новый путь со страницей, архивом или endpoint.
• Не кеширует ли сервер или плагин старый ответ 404.

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

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

Типовой сценарий выглядит так: сайт жил на адресах вида /2024/05/post-name/, потом структуру поменяли на /%postname%/. Старые ссылки в статьях, в sitemap, в внешних каталогах и в поиске остались прежними. WordPress сам не знает, куда вести старый адрес, если вы не добавили явный редирект.

Ещё одна частая причина — сброс правил перезаписи не был выполнен после изменений в register_post_type() или register_taxonomy(). В этом случае новые URL могут не открываться до повторного сохранения постоянных ссылок или до корректной регистрации rewrite-правил.

Пошаговое решение: как убрать 404 без потери трафика

Шаг 1. Зафиксируйте список проблемных адресов

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

Шаг 2. Добавьте 301-редирект для старых URL

Для единичных адресов подойдёт плагин редиректов или код в .htaccess/nginx. Для WordPress-уровня можно использовать хук template_redirect, если логика простая и не требует сложных условий.

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

        // Пример: старые URL вида /2024/05/post-name/
        if (preg_match('#^/\d{4}/\d{2}/([^/]+)/?$#', $request_uri, $m)) {
            $slug = sanitize_title($m[1]);
            $post = get_page_by_path($slug, OBJECT, 'post');

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

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

Шаг 3. Сбросьте правила перезаписи

Если вы меняли register_post_type(), register_taxonomy() или структуру постоянных ссылок, после правок нужно обновить rewrite rules. В админке это делается через сохранение страницы Настройки → Постоянные ссылки без изменения значений. Для кода в плагине или теме это обычно делают один раз при активации.

<?php
register_activation_hook(__FILE__, function () {
    // Здесь должны быть ваши register_post_type / register_taxonomy
    flush_rewrite_rules();
});

register_deactivation_hook(__FILE__, function () {
    flush_rewrite_rules();
});

Важно: не вызывайте flush_rewrite_rules() на каждом запросе. Это тяжёлая операция, и на живом сайте она быстро создаст лишнюю нагрузку.

Шаг 4. Обновите внутренние ссылки

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

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

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

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

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

• Откройте старый URL в режиме инкогнито.
• Проверьте заголовки через curl -I https://site.ru/staryy-adres/.
• Убедитесь, что новый URL отдаёт 200 OK.
• Проверьте, что в sitemap остались только актуальные адреса.
• Посмотрите отчёт 404 в Search Console через несколько дней после правок.

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

curl -I https://example.com/2024/05/post-name/

В ответе должно быть что-то вроде HTTP/2 301 и заголовок Location с новым адресом. Если вместо этого остаётся 404, значит правило не сработало или не совпал шаблон URL.

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

Редирект сделан, но старый URL всё равно в индексе

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

После смены slug сломались архивы рубрик

Проверьте, не совпадает ли новый slug рубрики с уже существующей страницей или архивом другого типа записей. WordPress может отдать не тот объект или 404, если путь конфликтует. В таких случаях проще изменить slug, чем пытаться чинить конфликт через костыли.

Новые правила не применяются

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

Редирект-цепочка из нескольких шагов

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

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

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

Если редиректы пишете в коде, обязательно:

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

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

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

• Старые URL собраны и классифицированы по шаблонам.
• Для каждого шаблона есть понятный новый адрес или правило.
• Проверен код ответа: старый URL — 301, новый — 200.
• Сброшены rewrite-правила после изменения CPT или таксономий.
• Очистен кеш плагина, сервера и CDN.
• Обновлены внутренние ссылки в контенте и меню.
• Проверен sitemap и robots.txt на актуальные адреса.

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