Если в корзине WooCommerce появляются старые товары, не обновляется сумма или пользователь видит чужое состояние корзины после возврата на сайт, в первую очередь стоит проверить кэш. Проблема часто не в самом WooCommerce, а в том, что страница корзины или связанные с ней фрагменты отдаются из кэша слишком агрессивно.
Ниже — практический разбор: как диагностировать источник проблемы, какие страницы и запросы нужно исключить, и как проверить результат без догадок.
Когда кэш мешает корзине
Корзина в WooCommerce должна быть динамической. На неё влияют сессия пользователя, cookies WooCommerce и AJAX-обновления мини-корзины. Если серверный или плагинный кэш игнорирует эти механизмы, возникают типовые симптомы:
- товар удалили из корзины, но он снова появляется после обновления страницы;
- сумма заказа не меняется после изменения количества;
- кнопка «Оформить заказ» ведёт на устаревшее состояние корзины;
- у разных пользователей отображаются одинаковые данные в корзине;
- мини-корзина в шапке не совпадает с содержимым страницы корзины.
Что именно нужно исключить из кэша
Минимальный набор — сама страница корзины, страница оформления заказа и страница «Мой аккаунт». В большинстве установок WooCommerce эти страницы уже помечены как служебные, но это не гарантирует, что их не закэширует CDN, серверный reverse proxy или кэширующий плагин.
Если используется кэширование HTML на уровне плагина, важно также не кэшировать запросы, завязанные на cookies woocommerce_items_in_cart, woocommerce_cart_hash и wp_woocommerce_session_*.
Диагностика проблемы перед изменениями
Сначала нужно понять, где именно ломается логика: в плагине кэша, на сервере или на стороне CDN. Самый быстрый путь — проверить корзину в режиме инкогнито и с отключённым кэшем браузера, а затем сравнить поведение с обычной сессией.
- Откройте сайт в инкогнито.
- Добавьте товар в корзину.
- Измените количество или удалите товар.
- Обновите страницу корзины.
- Проверьте, не возвращается ли старое состояние.
Если проблема исчезает после очистки кэша, но возвращается позже, значит кэширование затрагивает динамические страницы. Если проблема видна только у части пользователей, проверьте CDN и кэш на уровне хостинга.
Что смотреть в DevTools и заголовках ответа
Откройте вкладку Network и посмотрите заголовки ответа страницы корзины. Полезно проверить наличие cache-control, x-cache, cf-cache-status или аналогичных заголовков вашего CDN/прокси. Если страница корзины отдаётся как HIT, это почти наверняка ошибка настройки.
Также проверьте, есть ли в HTML страницы корзины признаки динамики: корректные nonce, актуальные значения количества товаров и отсутствие старого содержимого из предыдущей сессии.
Пошаговое решение через настройки WooCommerce и кэша
Сначала используйте штатные настройки плагина кэширования. Это безопаснее, чем сразу править код. В большинстве решений нужно добавить в исключения:
/cart/;/checkout/;/my-account/;- cookies WooCommerce, если плагин умеет исключать по cookie;
- AJAX-эндпоинты WooCommerce, если кэшируется HTML слишком агрессивно.
Если у вас есть CDN, проверьте правила page cache и bypass cache для корзины и checkout. На практике часто забывают именно CDN, а не WordPress-плагин.
Когда достаточно настроек плагина
Если кэш-плагин умеет исключать страницы по URL и cookies, этого обычно хватает. Такой подход лучше кода: он проще в сопровождении и не зависит от темы. Но если кэш строится на уровне сервера или вы не можете точно настроить исключения в панели хостинга, пригодится кодовый вариант.
Программное исключение корзины из кэша
Ниже пример для functions.php дочерней темы или небольшого mu-plugin. Он не «отключает кэш вообще», а помечает корзину и checkout как страницы, которые не стоит кэшировать на уровне WordPress-логики. Это не заменяет настройки CDN, но помогает в связке с плагинами, которые уважают такие сигналы.
<?php
add_action( 'template_redirect', function () {
if ( function_exists( 'is_cart' ) && ( is_cart() || is_checkout() || is_account_page() ) ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
}, 0 );
Этот фрагмент полезен, когда кэширующий плагин ориентируется на константу DONOTCACHEPAGE. Но сам по себе он не решит проблему, если CDN уже отдал HTML из своего кэша.
Если нужно дополнительно убрать кэширование для страниц WooCommerce на уровне HTTP-заголовков, можно отправлять более строгие заголовки для служебных страниц:
<?php
add_action( 'template_redirect', function () {
if ( function_exists( 'is_cart' ) && ( is_cart() || is_checkout() || is_account_page() ) ) {
nocache_headers();
}
}, 1 );
Используйте этот вариант аккуратно: он не должен ломать кэширование всего сайта. Применяйте его только к динамическим страницам WooCommerce.
Сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки кэш-плагина | Есть доступ к панели и понятные исключения по URL/cookie | Нужно не забыть CDN и серверный кэш |
Код через DONOTCACHEPAGE | Нужно быстро пометить служебные страницы как некэшируемые | Зависит от того, поддерживает ли это ваш кэш |
nocache_headers() | Нужны жёсткие HTTP-заголовки для динамических страниц | Не решает проблему внешнего CDN без правил bypass |
Проверка результата после внедрения
После настройки не ограничивайтесь очисткой кэша. Проверьте именно сценарий пользователя:
- добавьте товар в корзину и обновите страницу;
- измените количество и убедитесь, что сумма пересчиталась;
- удалите товар и проверьте, что он не возвращается после refresh;
- откройте корзину в инкогнито и в обычной сессии — состояние должно различаться;
- посмотрите заголовки ответа страницы корзины: она не должна отдаваться как закэшированная HTML-страница.
Если используется мини-корзина в шапке, отдельно проверьте её обновление после AJAX-действий. Иногда основная страница уже исключена из кэша, а фрагменты мини-корзины всё ещё подхватываются из старого состояния.
Частые ошибки и как их исправить
Исключили только /cart/, но забыли /checkout/
Это частая причина странных багов на этапе оплаты. Пользователь доходит до оформления, а там отображается устаревшая сумма или пустая корзина. Добавьте обе страницы в исключения сразу.
Настроили плагин, но не тронули CDN
Если сайт стоит за Cloudflare или другим CDN, HTML может кэшироваться там, даже если WordPress уже отдал правильные заголовки. Проверьте правила bypass cache для корзины, checkout и account.
Сделали глобальное отключение кэша
Это лишает сайт смысла от оптимизации. Не отключайте кэш на всём сайте ради одной проблемы. Ограничьтесь служебными страницами WooCommerce и динамическими запросами.
Не проверили cookies WooCommerce
Если кэш-плагин не учитывает cookies woocommerce_cart_hash и woocommerce_items_in_cart, пользователи будут видеть некорректное состояние корзины. В таких случаях нужно либо включить cookie-based bypass, либо исключить соответствующие страницы из кэша полностью.
Что ещё стоит учесть для безопасности и производительности
Не делайте корзину полностью открытой для индексации и агрессивного кэширования. Это не только ломает UX, но и может приводить к утечке состояния сессий в плохо настроенных окружениях. Для служебных страниц WooCommerce важнее корректность, чем экономия пары миллисекунд.
Если вы используете Clearfy Pro, проверьте, не включены ли дополнительные оптимизации, которые вмешиваются в служебные страницы или скрипты WooCommerce. В подобных сценариях полезно сначала отключить спорную оптимизацию, а потом включать её по одной и тестировать корзину заново.
Практический минимум: исключить корзину и checkout из HTML-кэша, проверить CDN, убедиться, что AJAX-обновления мини-корзины не ломаются, и протестировать сценарий в инкогнито. Если после этого корзина ведёт себя стабильно, значит проблема действительно была в кэшировании, а не в теме или плагине товаров.