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

Автор: Роман Савельев | Опубликовано: 19.08.2026

Ситуация типовая: вы поменяли структуру постоянных ссылок, перенесли сайт, включили префикс у рубрик или изменили slug таксономии — и часть архивов начала отдавать 404. При этом отдельные записи открываются, а страницы категорий, тегов или кастомных таксономий ломаются выборочно. Обычно проблема сидит не в контенте, а в правилах перезаписи, конфликте slug или в том, что WordPress не сбросил rewrite rules после изменений.

Ниже разберём, как быстро понять источник ошибки, что именно править и как проверить, что архивы снова отдаются корректно.

Когда 404 появляется именно на архивах

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

Типовые сценарии

поменяли /category/%category%/ на более короткую структуру и старые URL перестали открываться;
у кастомной таксономии совпал slug с рубрикой, страницей или CPT;
после миграции на новый домен архивы открываются, но часть URL уходит в 404 из-за старых правил в кэше;
плагин для SEO или редиректов подменяет canonical и мешает корректной маршрутизации.

Диагностика проблемы без догадок

Не начинайте с правки кода. Сначала проверьте, где именно ломается маршрут: на уровне WordPress, веб-сервера или кэша. Это экономит время, потому что 404 на архиве может быть следствием не только rewrite rules, но и неправильного ответа Nginx/Apache.

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

Откройте проблемный архив в режиме инкогнито и без кэша браузера.
Очистите кэш плагина, если он есть, и серверный кэш, если он используется.
Зайдите в Настройки → Постоянные ссылки и просто нажмите Сохранить изменения без правок. Это принудительно обновляет rewrite rules.
Проверьте, не совпадает ли slug архива с уже существующей страницей, рубрикой или вложением.
Если сайт на Nginx, убедитесь, что конфигурация действительно передаёт запросы в index.php.

Для быстрой проверки можно временно включить логирование ошибок WordPress и посмотреть, не пишет ли он о конфликте маршрутов или проблемах с шаблоном архива.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После этого откройте проблемный URL и проверьте файл wp-content/debug.log. Если там пусто, а 404 остаётся, вероятнее всего, проблема в rewrite rules или серверной конфигурации.

Пошаговое решение: сбросить правила и убрать конфликт slug

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

Шаг 1. Сбросьте rewrite rules

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

Если нужен программный вариант, можно один раз вызвать flush после регистрации таксономии или CPT, но не делать это на каждом запросе. Постоянный flush на фронтенде убивает производительность.

add_action('init', function () {
    register_taxonomy('product_group', ['post'], [
        'label'        => 'Группы',
        'public'       => true,
        'hierarchical'  => true,
        'rewrite'      => [
            'slug'       => 'groups',
            'with_front' => false,
        ],
        'show_in_rest' => true,
    ]);
});

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

Если таксономия регистрируется в плагине, лучше вызывать flush_rewrite_rules() при активации плагина, а не на init.

Шаг 2. Проверьте конфликт slug

Частая причина 404 — одинаковый slug у рубрики и страницы. Например, у вас есть страница /news/ и рубрика с тем же slug. WordPress может отдавать не тот объект или вообще не находить маршрут.

Проверьте:

страницы с тем же URL, что и архив;
рубрики и теги с одинаковыми slug;
кастомные таксономии, которые повторяют базу category, tag или slug CPT;
переопределения в плагинах редиректов и SEO.

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

Шаг 3. Убедитесь, что сервер пропускает красивые URL

На Apache должен работать .htaccess с базовыми правилами WordPress. На Nginx нужен корректный try_files. Если сервер настроен неверно, WordPress может даже не получить запрос.

# Nginx
location / {
    try_files $uri $uri/ /index.php?$args;
}

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

Сравнение подходов: плагин, код или ручная правка

Подход	Когда подходит	Плюсы	Минусы
Сохранить постоянные ссылки вручную	После смены структуры URL	Быстро, без кода	Не решает конфликт slug
Код с регистрацией rewrite и flush на активации	Для CPT и таксономий	Контролируемо и предсказуемо	Нужно аккуратно внедрять
Плагин для редиректов/SEO	Если нужны массовые 301	Удобно для миграций	Может добавить лишние правила и конфликтовать

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

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

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

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

архив категории открывается без 404;
архив тега открывается без 404;
архив кастомной таксономии открывается по новому slug;
старый URL либо отдаёт 301, либо осознанно удалён из индекса;
в debug.log нет новых ошибок после перехода по проблемным адресам;
кэш плагина и серверный кэш очищены после изменений.

Дополнительно проверьте ответ сервера через DevTools или curl. Для архива должен быть код 200, а для старого адреса — либо 301, либо 404, если редирект не нужен.

curl -I https://example.com/news/

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

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

Не сбросили правила после изменения структуры

Это самая частая причина. WordPress продолжает использовать старые rewrite rules, пока их не пересоздадут. Решение простое: сохранить постоянные ссылки или вызвать flush на активации плагина/темы.

Сделали flush на каждом запросе

Так делать нельзя. flush_rewrite_rules() — тяжёлая операция. Если запускать её на фронтенде, сайт начнёт тормозить. Вызывайте её только один раз при активации или после изменения настроек в админке.

Оставили конфликтующий slug

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

Забыли про кэш

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

Сломали правила на сервере

Если Nginx или Apache настроены неправильно, WordPress не сможет обработать красивые URL. В этом случае правка в админке не поможет, пока сервер не начнёт передавать запросы в index.php.

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

Если вы правите rewrite rules кодом, не делайте это в произвольных местах темы. Лучше вынести логику в плагин или mu-plugin, чтобы она не зависела от смены темы. Это особенно важно на сайтах, где архивы завязаны на SEO и трафик.

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

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

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