Отладка 404 после смены ЧПУ в WordPress и WooCommerce

Автор: Роман Федоров | Опубликовано: 11.08.2026

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

Как понять, где именно ломается маршрут

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

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

открывается ли /wp-admin/options-permalink.php без ошибок;
сохранились ли настройки постоянных ссылок после изменения структуры;
есть ли на сервере Apache или Nginx и кто реально обрабатывает rewrite;
не добавляет ли плагин SEO, мультиязычности или фильтрации товаров свои правила;
не менялись ли вручную post_type, rewrite или has_archive в коде темы.

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

Пошаговое решение

1. Пересохраните структуру постоянных ссылок

Это не магия, а принудительная пересборка rewrite-правил. В админке откройте Настройки → Постоянные ссылки, ничего не меняя, нажмите сохранение. После этого WordPress заново запишет правила маршрутизации.

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

<?php
// Временно можно выполнить один раз, например через mu-plugin или WP-CLI eval.
flush_rewrite_rules();

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

2. Проверьте `.htaccess` или конфигурацию Nginx

На Apache стандартный блок WordPress должен присутствовать и быть доступен для записи, если вы меняете ЧПУ из админки. На Nginx правила в .conf должны прокидывать несуществующие файлы в index.php.

Для Apache базовый фрагмент выглядит так:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Для Nginx обычно нужен аналогичный маршрут через try_files:

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

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

3. Исключите конфликт плагинов и кастомных rewrite-правил

Частая причина — плагин добавляет свой endpoint, а затем другой плагин или тема меняет структуру ссылок для того же типа записей. Особенно это заметно в магазинах, где подключены фильтры, мультиязычность, SEO-модули и плагины доставки.

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

Когда нужен точечный контроль, полезно посмотреть, какие правила реально зарегистрированы:

<?php
add_action('init', function () {
    global $wp_rewrite;
    error_log(print_r($wp_rewrite->wp_rewrite_rules(), true));
});

Этот код не для постоянной работы на живом сайте, а для диагностики. Логи помогут увидеть, есть ли нужный маршрут вообще или он перекрыт более общим правилом.

Если 404 только у WooCommerce

У WooCommerce есть отдельные настройки, которые влияют на URL товаров и архивов. Проверьте WooCommerce → Настройки → Товары и связанные страницы магазина. Если вы меняли базу категорий товаров или слаг магазина, старые ссылки могут перестать совпадать с текущими правилами.

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

Подход	Когда подходит	Минус
Сохранить ЧПУ в админке	После обычной смены структуры ссылок	Не помогает, если проблема в сервере или конфликте плагинов
Сбросить rewrite через код	Когда админка недоступна или правила не обновились	Нужно делать аккуратно и не на каждом запросе
Проверить конфиг Apache/Nginx	Если сайт отдаёт 404 на уровне сервера	Требует доступа к хостингу или панели

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

После исправлений не ограничивайтесь главной страницей. Пройдитесь по нескольким типам URL:

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

Если у вас есть доступ к консоли, можно быстро проверить ответы сервера:

curl -I https://example.com/sample-post/
curl -I https://example.com/product/sample-product/

В идеале нужные страницы должны отдавать 200, а несуществующие старые адреса — 301 на новый URL или 404, если редирект не предусмотрен. Главное, чтобы реальные страницы больше не выпадали в ошибку.

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

Сохранили ЧПУ, но не обновили кэш

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

Сломали правила в `.htaccess`

Иногда файл переписывают вручную и случайно удаляют стандартный блок WordPress. Тогда часть URL перестаёт работать даже при правильных настройках в админке. Сравните файл с эталонным блоком и верните базовые правила.

Поменяли слаг типа записи без редиректов

Если вы изменили rewrite у кастомного post type, старые ссылки станут невалидными. В этом случае нужно либо вернуть старую структуру, либо настроить 301-редиректы со старых URL на новые.

Использовали одинаковые слаги для страниц и таксономий

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

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

Не держите диагностический код в functions.php дольше, чем нужно. Логи и временные проверки лучше выносить в короткоживущий mu-plugin или выполнять через WP-CLI на staging. Это снижает риск случайно оставить отладку на продакшене.

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

Когда проблема связана не с маршрутизацией, а с мусором в настройках и дублирующимися правилами, иногда проще пройтись по сайту инструментом вроде Clearfy Pro и убрать лишние дубли в конфигурации, чем искать конфликт вручную по десяткам плагинов. Но даже в этом случае сначала нужна диагностика, а не автоматическая чистка вслепую.