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

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

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

Когда проблема действительно в таксономии, а не в теме или кэше

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

Типичные симптомы

• страница рубрики или метки открывается по старому URL, а по новому даёт 404;
• в админке таксономия отображается, но на фронтенде архив недоступен;
• после изменения slug часть ссылок в меню и хлебных крошках ведёт на несуществующий адрес;
• в Search Console появляются ошибки «Страница не найдена» именно для архивов таксономий;
• старый URL иногда отвечает 301, но новый всё равно не открывается.

Что проверить первым делом

1. Откройте архив таксономии в приватном окне без расширений браузера.
2. Очистите кэш плагина, серверный кэш и CDN, если он есть.
3. Перейдите в Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок.
4. Проверьте, не изменился ли rewrite у таксономии в коде темы или плагина.
5. Посмотрите, не создаёт ли SEO-плагин собственный canonical на старый адрес.

Почему после смены slug WordPress не всегда сам чинит архивы

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

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

Пошаговое решение: как восстановить архивы таксономий

Шаг 1. Сбросьте правила постоянных ссылок

Это самый безопасный и быстрый шаг. Он не меняет контент, а только пересобирает правила маршрутизации.

add_action('init', function () {
    register_taxonomy('product_topic', ['post'], [
        'label'        => 'Темы',
        'public'       => true,
        'hierarchical' => true,
        'rewrite'      => [
            'slug'       => 'topics',
            'with_front'  => false,
            'hierarchical' => true,
        ],
        'show_in_rest'  => true,
    ]);
});

add_action('after_switch_theme', function () {
    flush_rewrite_rules();
});

Если таксономия уже зарегистрирована в плагине, не добавляйте второй register_taxonomy() в тему. В этом случае достаточно один раз пересохранить постоянные ссылки или вызвать flush_rewrite_rules() при активации плагина.

Шаг 2. Проверьте регистрацию таксономии

Ошибки в аргументах rewrite — частая причина 404. Особенно если slug меняли вручную и забыли про иерархию или фронт-приставку.

function wpstock_debug_taxonomy_args() {
    $tax = get_taxonomy('product_topic');

    if ( ! $tax ) {
        error_log('Taxonomy product_topic not found');
        return;
    }

    error_log(print_r($tax->rewrite, true));
}
add_action('init', 'wpstock_debug_taxonomy_args', 20);

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

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

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

add_action('template_redirect', function () {
    if ( is_tax('product_topic') ) {
        $term = get_queried_object();

        if ( $term && ! is_wp_error($term) ) {
            $old_slug = 'old-topics';
            $new_url  = get_term_link($term);

            if ( strpos($_SERVER['REQUEST_URI'], '/' . $old_slug . '/') !== false ) {
                wp_redirect($new_url, 301);
                exit;
            }
        }
    }
});

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

Шаг 4. Обновите ссылки в меню, хлебных крошках и шаблонах

После смены slug часто ломаются не сами архивы, а ссылки на них. Проверьте:

• меню, где адрес был прописан вручную;
• хлебные крошки в теме;
• виджеты с произвольными ссылками;
• шаблоны, где используется жёсткая строка вместо get_term_link();
• SEO-шаблоны title и canonical, если они собираются вручную.

Правильный подход — всегда получать URL через API WordPress, а не хранить его строкой в шаблоне.

Сравнение подходов: плагин, код или серверный редирект

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

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

Проверка должна быть не «страница открылась в браузере», а по цепочке ответа сервера и индексации.

• Откройте старый URL через curl -I https://example.com/old-topics/term/ и убедитесь, что он отдаёт 301.
• Проверьте новый URL: он должен отдавать 200, а не 404 или 302.
• Посмотрите canonical в исходном коде страницы — он должен указывать на новый адрес.
• В Search Console отправьте проверку URL для нового архива и убедитесь, что ошибка исчезла.
• Если используется кэш, очистите его ещё раз и проверьте ответ без cookies.

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

curl -I https://example.com/old-topics/sample-term/
curl -I https://example.com/topics/sample-term/

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

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

Сбросили постоянные ссылки, но 404 остались

Значит, проблема не только в rewrite-правилах. Проверьте регистрацию таксономии, кэш и конфликт с плагином, который может перехватывать архивы.

Редирект ведёт на сам себя

Так бывает, если в условии сравнивается не старый slug, а текущий URL, или если get_term_link() уже возвращает старый адрес из-за неочищенного кэша. В таком случае сначала отключите редирект, очистите кэш, затем проверьте get_term_link() отдельно.

Новый адрес открывается, но в выдаче остаётся старый

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

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

Значит, тема строит их вручную или через устаревший фильтр. Ищите прямые строки с адресом таксономии и заменяйте на get_term_link() или API плагина крошек.

Что делать, если таксономия создаётся плагином

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

Для технической чистки и контроля дублей на уровне сайта иногда удобнее подключать инструменты вроде Clearfy Pro, но только если вы понимаете, какие именно архивы и правила он меняет. Автоматическая чистка без проверки здесь легко создаёт новые 404 вместо исправления старых.

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

• Проверен новый slug таксономии в коде или настройках плагина.
• Сброшены rewrite-правила через сохранение постоянных ссылок или активацию.
• Старые URL получают 301 на новые.
• Canonical указывает на новый адрес.
• Кэш сайта, сервера и CDN очищен.
• Меню, крошки и шаблоны не содержат жёстких старых ссылок.
• В Search Console отправлена повторная проверка проблемных URL.

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