Если на сайте есть страницы, которые меняются в зависимости от параметров в URL или от cookie, общий кэш начинает мешать. Типичный пример — фильтры каталога, персональные промо-страницы, страницы с UTM-логикой, формы с предзаполнением и отдельные сценарии WooCommerce. В WP Super Cache это решается не «полным отключением кэша», а точечными исключениями.
Ниже разберём, как понять, что проблема именно в кэше, какие варианты исключений реально работают, и как проверить результат без гадания по ощущениям.
Когда кэш ломает поведение страницы
Симптомы обычно похожи друг на друга: один пользователь видит старую версию блока, другой — чужую корзину, третьему не применяются параметры фильтра, а после входа в аккаунт страница всё ещё выглядит как для гостя. В таких случаях проблема часто не в шаблоне и не в JS, а в том, что WP Super Cache отдаёт один и тот же HTML там, где контент должен отличаться.
Что проверить до правок
- Откройте страницу в режиме инкогнито и с обычной сессией — сравните HTML и поведение.
- Проверьте, меняется ли контент при добавлении GET-параметра в URL, например
?filter=redили?utm_source=test. - Посмотрите, влияет ли cookie на вывод: авторизован ли пользователь, есть ли cookie корзины WooCommerce, выбран ли язык или регион.
- Убедитесь, что проблема повторяется именно на сервере, а не только в браузерном кеше или CDN.
Если при очистке браузерного кеша поведение не меняется, а после полного сброса кеша сайта проблема исчезает на время, значит, исключения нужно настраивать именно в WP Super Cache.
Какие сценарии стоит исключать из общего кэша
Не все динамические страницы надо исключать полностью. Иногда достаточно убрать из кэширования только один тип запросов. Но есть случаи, где исключение страницы целиком — самый надёжный вариант.
| Сценарий | Что делать | Компромисс |
|---|---|---|
| Корзина, оформление заказа, личный кабинет WooCommerce | Исключить страницы целиком | Минимальный риск, но больше динамики на сервере |
| Фильтры каталога с GET-параметрами | Исключить URL по шаблону или конкретные параметры | Нужно аккуратно выбрать шаблон, чтобы не отключить лишнее |
| Страницы с персонализацией по cookie | Исключить по cookie или не кэшировать для авторизованных | Часть трафика уйдёт мимо кэша |
| Промо-лендинги с UTM и A/B-логикой | Исключить только те параметры, которые реально меняют HTML | Не стоит отключать кэш для всех UTM без причины |
Пошаговая настройка исключений в WP Super Cache
1. Исключите страницы, которые не должны кэшироваться вообще
Самый безопасный путь — добавить в исключения страницы, где контент по определению должен быть живым: корзина, оформление заказа, мой аккаунт, страницы входа и регистрации. Для WooCommerce это базовая гигиена.
В интерфейсе WP Super Cache откройте раздел исключений и добавьте URL страниц без домена, по одной на строку. Обычно это:
/cart//checkout//my-account//login/— если у вас отдельная страница входа
Если у сайта русские слаги, используйте реальные URL, а не английские шаблоны.
2. Исключите URL с GET-параметрами, которые меняют HTML
Если страница каталога меняется от параметров в адресной строке, не кэшируйте её как обычную статическую страницу. Проблема в том, что WP Super Cache может считать разные варианты одного URL одной и той же страницей, если логика исключений не настроена.
Для таких случаев удобнее не отключать весь каталог, а ограничить кэширование для конкретных параметров. Например, если у вас фильтр работает через ?filter= или ?sort=, имеет смысл исключить именно эти сценарии.
<IfModule mod_rewrite.c>
RewriteEngine On
# Пример: не кэшировать запросы с параметрами фильтра
RewriteCond %{QUERY_STRING} (^|&)filter= [NC,OR]
RewriteCond %{QUERY_STRING} (^|&)sort= [NC]
RewriteRule .* - [E=Cache-Control:no-cache]
</IfModule>Это пример для Apache-логики на уровне правил. Если у вас Nginx или другой стек, подход будет отличаться, но смысл тот же: не отдавать общий кэш для запросов, где HTML зависит от параметров.
3. Исключите страницы по cookie, если контент зависит от состояния пользователя
Cookie часто используются для языка, региона, статуса входа, согласия с баннером, корзины и персональных блоков. Если одна и та же страница должна выглядеть по-разному в зависимости от cookie, общий кэш становится источником случайных ошибок.
В WP Super Cache есть логика, завязанная на cookie, но её нужно использовать аккуратно: не добавляйте в исключения все cookie подряд. Сначала определите, какая именно cookie влияет на HTML. Например, если у вас кастомная cookie region, а контент зависит только от неё, исключайте только этот сценарий.
<?php
add_action('init', function () {
if (!empty($_COOKIE['region'])) {
define('DONOTCACHEPAGE', true);
}
});Такой код уместен только если вы понимаете, где он выполняется и почему страница должна быть динамической. Не вставляйте его везде подряд: это быстро убьёт пользу от кэша.
Диагностика: как понять, что исключение сработало
После настройки важно не просто «посмотреть глазами», а проверить, что сервер действительно перестал отдавать кэш там, где нужно. Иначе можно получить ложное ощущение, что всё исправлено, хотя старый HTML продолжает раздаваться части пользователей.
- Откройте страницу в инкогнито и с параметром, который должен отключать кэш.
- Сравните заголовки ответа в DevTools: ищите признаки кэширования и отсутствие повторной генерации там, где она нужна.
- Проверьте два разных сценария: с cookie и без cookie, с параметром и без параметра.
- Очистите кеш WP Super Cache после правок и повторите тест, чтобы исключить старые файлы.
Если у вас есть доступ к серверным логам, полезно посмотреть, не отдаются ли страницы из статического кеша после добавления исключения. Это особенно важно, когда сайт стоит за CDN или reverse proxy.
Кодовый вариант для точечного отключения кэша
Иногда удобнее не полагаться только на настройки плагина, а добавить небольшую логику в тему или mu-plugin. Это полезно, когда решение зависит от конкретного параметра или cookie, а в интерфейсе плагина не хватает гибкости.
<?php
/**
* Отключает кэш для страниц с определёнными GET-параметрами.
*/
add_action('wp', function () {
$cache_sensitive_params = ['filter', 'sort', 'region'];
foreach ($cache_sensitive_params as $param) {
if (isset($_GET[$param]) && $_GET[$param] !== '') {
if (!defined('DONOTCACHEPAGE')) {
define('DONOTCACHEPAGE', true);
}
break;
}
}
});Это рабочий и понятный способ для случаев, когда параметр реально меняет HTML. Но если параметр влияет только на JS-логику на клиенте, отключать кэш на сервере не нужно — лучше оставить страницу кэшируемой.
Частые ошибки и как их исправить
Слишком широкое исключение
Самая частая ошибка — отключить кэш для всего сайта из-за одной проблемной страницы. В результате вы лечите баг ценой потери производительности. Исправление простое: сузьте правило до конкретного URL, параметра или cookie.
Исключили не тот параметр
Например, добавили в исключения utm_source, хотя он не меняет HTML, а реальный динамический параметр — filter. Тогда кэш продолжит ломать страницу, а лишние запросы будут обходить кеширование без пользы.
Не очистили старый кеш
После изменения правил старые файлы могут ещё какое-то время отдаваться пользователям. Всегда очищайте кеш плагина и, если есть CDN, сбрасывайте и его слой тоже.
Забыли про авторизованных пользователей
Если страница должна отличаться для вошедших пользователей, но исключение настроено только по URL, авторизованные всё равно могут видеть чужой HTML. В таких сценариях проверяйте связку URL + cookie + статус входа.
Проверили только в одном браузере
Кэш и cookie ведут себя по-разному в зависимости от сессии. Тестируйте минимум в инкогнито и в обычном окне, а для WooCommerce — ещё и с добавлением товара в корзину.
Практические советы по безопасности и производительности
Исключения из кэша — это не только про корректность, но и про контроль нагрузки. Чем больше страниц вы выводите мимо кеша, тем внимательнее нужно относиться к производительности PHP и базе.
- Не отключайте кэш для страниц, где динамика нужна только в одном маленьком блоке. Лучше вынести этот блок в AJAX или отдельный фрагмент.
- Не используйте слишком общие шаблоны исключений вроде
*или широких масок по URL. - Если страница зависит от cookie, проверьте, нельзя ли заменить cookie на серверную логику только для нужных разделов.
- Для WooCommerce сначала исключайте стандартные системные страницы, а уже потом добавляйте кастомные сценарии.
Если на сайте много исключений и сложная логика по параметрам, имеет смысл дополнительно почистить лишние дубли и служебный мусор в админке с помощью инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpsupercache.ru&utm_medium=article&utm_campaign=wp-super-cache-isklyuchit-otdelnye-stranitsy-po-cookie-i-get-parametram
Проверка результата после внедрения
Финальная проверка должна отвечать на один вопрос: страница теперь ведёт себя стабильно для всех сценариев, но при этом не потеряла кэш там, где он нужен.
- Откройте проблемный URL без параметров — убедитесь, что он по-прежнему кэшируется.
- Откройте URL с нужным GET-параметром — проверьте, что контент меняется корректно и не подхватывает старую версию.
- Проверьте сценарий с cookie: до и после установки cookie результат должен отличаться только там, где это задумано.
- Очистите кеш и повторите тест, чтобы убедиться, что исключение не зависит от случайного старого файла.
- Если есть CDN, проверьте и его слой — иногда проблема остаётся именно там.
Когда исключения настроены правильно, вы видите предсказуемое поведение: статические страницы остаются быстрыми, а проблемные сценарии перестают смешивать данные между пользователями.
}