Ситуация типовая: вы поменяли структуру постоянных ссылок, включили красивые URL для товаров или перенесли сайт, а вместо карточек, категорий и страницы магазина получили 404. В WooCommerce это часто связано не с самим товаром, а с правилами перезаписи, конфликтом slug'ов или кэшем на уровне сервера и плагинов.
Ниже разберём, как быстро понять источник проблемы и что делать без лишних экспериментов.
Что именно ломается и как это выглядит
404 после изменения ЧПУ обычно проявляется не везде сразу. Чаще всего ломаются:
- отдельные карточки товаров;
- категории и теги товаров;
- страница магазина;
- страницы пагинации каталога;
- старые URL после миграции с другого домена или структуры ссылок.
Если главная и админка открываются, а проблема только на витрине, почти всегда стоит проверять именно rewrite rules, slug'и и кэш.
Диагностика проблемы: с чего начать
Не начинайте сразу с правки кода. Сначала проверьте, где именно ломается маршрут. Это экономит время и помогает не сломать работающие URL.
1. Сбросьте правила постоянных ссылок
Самый безопасный первый шаг — просто пересохранить настройки ЧПУ в админке. Это принудительно обновляет rewrite rules.
- Откройте Настройки → Постоянные ссылки.
- Ничего не меняя, нажмите Сохранить изменения.
- Проверьте проблемный URL в новой вкладке.
Если после этого 404 исчезла, проблема была в неактуальных правилах маршрутизации.
2. Проверьте конфликт slug'ов
У WooCommerce и обычных страниц может совпадать адрес. Например, страница магазина, категория товара и обычная страница с одинаковым slug создают конфликт. В таком случае WordPress может отдавать не тот объект или вообще 404.
Проверьте:
- slug страницы магазина в WooCommerce → Настройки → Товары;
- slug категории товара;
- slug обычных страниц и записей;
- нет ли одинаковых ярлыков у вложенных страниц и таксономий.
3. Убедитесь, что сервер поддерживает нужные правила
Если сайт на Apache, должен работать .htaccess. Если на Nginx — нужны корректные правила для WordPress. После миграции на другой сервер 404 часто появляется именно из-за того, что правила переписывания не перенесены или не применены.
Для Nginx базовый блок обычно выглядит так:
location / {
try_files $uri $uri/ /index.php?$args;
}Это не замена полноценной конфигурации, но если такого правила нет, WordPress и WooCommerce часто не смогут корректно обрабатывать красивые URL.
Пошаговое решение без лишнего риска
Если диагностика показала, что проблема в маршрутизации, идите по порядку. Не перепрыгивайте через шаги: в WooCommerce часто ломается не один слой, а сразу несколько.
Шаг 1. Пересохраните permalink'и
Даже если это уже делали, повторите после очистки кэша. Иногда кэшированная страница продолжает отдавать старый ответ, и кажется, что сброс не сработал.
Шаг 2. Очистите кэш сайта и сервера
Проверьте все уровни кэша:
- плагин кэширования;
- кэш на стороне хостинга;
- CDN, если он используется;
- браузерный кэш при ручной проверке.
Если у вас есть Clearfy Pro или другой инструмент для управления кэшем, очистите именно после изменения permalink'ов и slug'ов, а не до этого.
Шаг 3. Проверьте, не переопределяет ли тема шаблоны WooCommerce
Иногда 404 появляется не из-за маршрута, а из-за того, что тема или дочерняя тема вмешивается в запрос. Особенно это заметно, если в теме есть кастомные шаблоны архива товаров или собственные правила для таксономий.
Для проверки временно переключитесь на стандартную тему и откройте проблемный URL. Если страница заработала, ищите конфликт в теме или дочернем шаблоне.
Шаг 4. Сбросьте rewrite rules программно, если нужно
Если вы переносите сайт, разворачиваете staging или автоматизируете деплой, иногда удобнее сбросить правила один раз кодом. Делать это на каждом запросе нельзя, но при активации темы или плагина — нормально.
register_activation_hook(__FILE__, function () {
flush_rewrite_rules();
});
register_deactivation_hook(__FILE__, function () {
flush_rewrite_rules();
});Важно: flush_rewrite_rules() не стоит вызывать на обычных фронтенд-запросах. Это тяжёлая операция, и при постоянном вызове она только ухудшит производительность.
Шаг 5. Если нужен точечный редирект со старых URL
После смены структуры ссылок часть старых адресов может вести в 404, хотя товар уже доступен по новому URL. В таком случае лучше не надеяться на случайный поиск, а добавить редирект.
add_action('template_redirect', function () {
if (is_404()) {
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if (strpos($request_uri, '/product-old/') === 0) {
wp_redirect(home_url('/product/'), 301);
exit;
}
}
});Это пример для точечного сценария. Для массовой миграции лучше использовать карту редиректов, а не ручные if'ы в коде.
Когда лучше править кодом, а когда — настройками
| Подход | Когда подходит | Минус |
|---|---|---|
| Пересохранить permalink'и | После смены ЧПУ, переноса сайта, обновления WooCommerce | Не решает конфликт slug'ов |
| Редиректы 301 | Старые URL должны сохранять трафик | Нужно поддерживать карту перенаправлений |
| Правка темы/плагина | Если проблема в кастомных rewrite rules | Риск сломать обновления, если править ядро темы |
Проверка результата после внедрения
После исправления не ограничивайтесь открытием одной страницы. Проверьте несколько сценариев, чтобы не оставить скрытую ошибку.
- откройте проблемный товар в обычном и инкогнито-режиме;
- проверьте категорию товара и пагинацию каталога;
- откройте страницу магазина;
- проверьте старый URL, если вы настраивали редирект;
- посмотрите логи 404 на сервере или в плагине аналитики ошибок, если он есть.
Если URL открывается только после ручного обновления permalink'ов, но снова ломается после очистки кэша, значит проблема не в rewrite rules, а в кэшировании или конфликте маршрутов на уровне сервера.
Частые ошибки и как их исправить
Одинаковый slug у страницы и категории товара
Это одна из самых частых причин. Например, страница /catalog/ и категория товара с тем же адресом. Решение простое: переименуйте один из slug'ов и снова сохраните permalink'и.
Редирект сделан через 302 вместо 301
Если URL уже изменён окончательно, временный редирект только запутает поисковые системы и пользователей. Для постоянной замены используйте 301.
Сброс rewrite rules на каждом запросе
Иногда это добавляют в init или в шаблон «для надёжности». Так делать нельзя: сайт начинает работать медленнее, а проблема не исчезает. Сброс нужен один раз — при активации, миграции или ручной диагностике.
Не очищен кэш CDN или хостинга
Админка уже показывает новый URL, а посетители всё ещё видят 404. Это типичный признак того, что старый ответ закэширован вне WordPress.
Правки внесены в родительскую тему
После обновления тема перезапишется, и проблема вернётся. Если вы меняете шаблоны или логику маршрутизации, делайте это в дочерней теме или в отдельном плагине.
Практические советы по безопасности и производительности
Если вы добавляете редиректы или логику проверки URL, не тяните данные из запроса без фильтрации. Используйте только те части URI, которые реально нужны, и не строите сложную маршрутизацию в template_redirect, если можно решить задачу настройками сервера или редирект-плагином.
Для массовых миграций:
- ведите список старых и новых URL;
- проверяйте редиректы после деплоя;
- не храните логику перенаправлений в нескольких местах одновременно;
- после изменения структуры ссылок всегда очищайте кэш и пересохраняйте permalink'и.
Если у вас много подобных задач по чистке и оптимизации сайта, часть операций удобнее вынести в инструменты администрирования вроде Clearfy Pro, но саму проблему 404 он не заменит — здесь важны именно корректные rewrite rules и отсутствие конфликтов slug'ов.
В итоге рабочая схема обычно выглядит так: сначала пересохранить постоянные ссылки, затем убрать конфликт slug'ов, очистить кэш, проверить серверные правила и только потом добавлять редиректы для старых адресов. Такой порядок быстрее всего показывает, где именно сломался маршрут, и не заставляет гадать между темой, плагином и сервером.