Если после переименования товара, категории или атрибута в WooCommerce часть страниц начала отдавать 404, проблема обычно не в «битом сайте», а в несоответствии между старым URL, правилами перезаписи и кэшем. На живых магазинах это часто всплывает после массового редактирования товаров, миграции на новый домен или правки структуры постоянных ссылок.
Ниже разберём, как быстро понять, где именно ломается маршрут, и что делать без лишних экспериментов с базой данных.
Когда 404 в WooCommerce появляются после изменения URL
Типичный сценарий выглядит так: товар открывается по старой ссылке, но после смены slug выдаёт 404; категория товаров доступна в админке, но на фронтенде не открывается; часть URL работает только после ручного сохранения настроек постоянных ссылок. В WooCommerce это особенно заметно у товаров с вариациями, вложенными категориями и кастомными базами URL.
Что чаще всего ломается
- изменили slug товара, но старые ссылки остались в меню, карточках и письмах;
- поменяли базу категорий товаров в
Настройки → Постоянные ссылки, но не обновили правила перезаписи; - включён кэш страницы или CDN, который отдаёт старую версию маршрута;
- плагин для SEO или редиректов перехватывает URL и создаёт конфликт;
- в теме или плагине есть жёстко прописанные ссылки на старые адреса.
Диагностика проблемы: где именно возникает 404
Начинать нужно не с редиректов, а с проверки того, что реально отдаёт сервер и что хранится в WordPress. Если URL открывается с 404 только у части товаров, это почти всегда локальная проблема маршрута, а не глобальная поломка сайта.
Проверка в браузере и в админке
- Откройте проблемный URL в режиме инкогнито.
- Проверьте, нет ли редиректа на похожий адрес с другим slug.
- В админке откройте товар и сравните его текущий
slugс URL на фронтенде. - Для категорий товаров проверьте, не изменялась ли база в WooCommerce.
Проверка через WP-CLI
Если есть доступ к консоли, удобно быстро посмотреть, существует ли объект по новому slug. Для товаров и категорий это помогает отличить проблему маршрута от отсутствия записи.
wp post list --post_type=product --name=old-product-slug --fields=ID પોસ્ટ_title,post_nameЕсли запись находится, но URL всё равно отдаёт 404, значит проблема в правилах перезаписи, кэше или конфликте с плагином.
Что смотреть в логах
Полезно проверить access/error-логи веб-сервера и логи плагинов редиректов. Если запросы к старому URL стабильно получают 404, а к новому — 200, это нормальная ситуация после смены slug. Если же новый URL тоже 404, значит WordPress не распознаёт маршрут.
| Подход | Когда уместен | Минус |
|---|---|---|
| Сохранить постоянные ссылки | После массовой смены slug или структуры | Не решает конфликт с кэшем и редиректами |
| Редирект 301 | Когда старый URL уже используется в индексе и ссылках | Нужно следить за цепочками редиректов |
| Правка кода/правил | Если конфликт создаёт тема или плагин | Требует теста на staging |
Пошаговое решение: как восстановить корректные URL
1. Сбросьте правила перезаписи
Самый безопасный первый шаг — пересохранить настройки постоянных ссылок. Это не меняет контент, но пересобирает rewrite rules. После этого WooCommerce часто начинает корректно распознавать новые адреса товаров и категорий.
Сделать это можно вручную в админке: откройте Настройки → Постоянные ссылки и нажмите «Сохранить изменения» без правок. Затем проверьте проблемный URL ещё раз.
2. Очистите кэш страницы и объектный кэш
Если на сайте стоит page cache, Redis, Memcached или CDN, старый ответ 404 может продолжать отдаваться даже после исправления маршрута. Очистите кэш на всех уровнях: плагин кэширования, сервер, CDN, браузер.
- сбросьте кэш плагина;
- очистите серверный кэш, если он есть;
- purge в CDN;
- проверьте URL в приватном окне.
3. Добавьте 301-редирект со старого URL на новый
Если slug уже изменён и старые ссылки есть в поиске или внешних источниках, нужен редирект. Для точечного случая достаточно кода в теме или мини-плагине. Ниже пример для одного товара:
add_action('template_redirect', function () {
if (!is_404()) {
return;
}
$request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';
if ($request_uri === '/product/old-product-slug/') {
wp_redirect(home_url('/product/new-product-slug/'), 301);
exit;
}
});Если таких URL много, лучше не плодить десятки условий в template_redirect, а использовать плагин редиректов или отдельную таблицу соответствий в коде. Для массовых правок это проще сопровождать и легче откатывать.
4. Проверьте конфликт с плагинами SEO и редиректов
Иногда 404 появляется не из-за WooCommerce, а из-за того, что SEO-плагин создаёт канонический редирект на несуществующий адрес. На время диагностики отключите плагины редиректов и проверьте поведение на чистом маршруте. Если проблема исчезла, ищите правило, которое перехватывает именно товарные URL.
5. Если меняли базу категорий, обновите ссылки в шаблонах
Когда меняют базу категорий товаров, ломаются не только старые URL, но и ссылки в меню, хлебных крошках, блоках фильтрации и шаблонах темы. Проверьте, не захардкожены ли адреса в файлах темы или в пользовательских блоках.
<a href="<?php echo esc_url( get_term_link( $term ) ); ?>"><?php echo esc_html( $term->name ); ?></a>Если в шаблоне стоит строка с ручным URL, замените её на get_term_link() или get_permalink(). Это убирает зависимость от старого slug.
Как проверить, что решение сработало
После исправления важно не ограничиваться открытием страницы в браузере. Нужна проверка на уровне ответа сервера и маршрутизации.
- Откройте новый URL товара и убедитесь, что код ответа
200. - Проверьте старый URL: он должен отдавать
301, если вы настроили редирект. - Убедитесь, что в карточке товара, в хлебных крошках и в связанных товарах нет ссылок на старый адрес.
- Проверьте страницу в режиме инкогнито и после очистки кэша.
- Если есть Search Console, посмотрите, не растёт ли число ошибок «Страница не найдена» по этим URL.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/product/new-product-slug/
curl -I https://example.com/product/old-product-slug/В первом случае ожидается 200 OK, во втором — 301 Moved Permanently или другой осознанный ответ, а не случайный 404.
Частые ошибки и как их исправить
Редирект ведёт на несуществующий адрес
Это случается, когда старый URL перенаправляют на новый slug, который ещё не опубликован или был изменён повторно. Проверьте конечный адрес вручную и уберите цепочку из нескольких редиректов.
После сохранения постоянных ссылок проблема возвращается
Значит, кто-то или что-то снова переписывает правила: плагин кэша, SEO-модуль, код в теме или mu-plugin. Ищите источник, который добавляет свои rewrite rules или фильтрует permalink.
404 только у части пользователей
Обычно это кэш. Один пользователь видит старую страницу из CDN, другой — уже обновлённую. Проверьте заголовки ответа и purge на всех уровнях, включая мобильный CDN, если он используется.
Категория открывается, а товар внутри неё — нет
Часто это означает, что категория и товар живут в разных правилах перезаписи. Убедитесь, что у товара нет конфликтующего slug, совпадающего со страницей, записью или термином таксономии.
Практические советы по безопасности и производительности
Если вы добавляете редиректы кодом, не делайте это в functions.php активной темы без необходимости. Лучше вынести логику в небольшой mu-plugin или отдельный плагин, чтобы она не исчезла при смене темы.
Не создавайте бесконечные цепочки редиректов и не проверяйте каждую страницу тяжёлыми запросами к базе. Для массовых соответствий старых и новых URL лучше хранить карту редиректов в одном месте и обновлять её централизованно.
Если на сайте много правок URL, полезно держать под рукой staging-копию. На ней можно безопасно проверить, как WooCommerce реагирует на изменение slug, прежде чем переносить изменения на боевой магазин.
Для снижения риска ручных ошибок при чистке дублей и SEO-настроек можно использовать Clearfy Pro, если он уже есть в вашем стеке: https://wpshop.ru/plugins/clearfy. Но саму проблему 404 он не заменяет — здесь всё равно нужно проверить rewrite rules, кэш и редиректы.
Мини-чек-лист перед публикацией изменений
- новый slug товара или категории сохранён;
- постоянные ссылки пересохранены;
- кэш на сайте и CDN очищен;
- старый URL ведёт на 301-редирект;
- в шаблонах нет жёстко прописанных старых ссылок;
- новый URL отдаёт 200 в инкогнито и через
curl; - в Search Console не растёт число новых 404 по этим адресам.
Если проблема повторяется после каждого изменения, значит, дело не в одном товаре. Тогда нужно искать системный источник: конфликт rewrite rules, автоматическую генерацию ссылок в плагине или шаблон, который продолжает собирать URL по старому шаблону.