Иногда проблема не в самом кешировании, а в том, что в кеш попадают страницы, которые должны оставаться динамическими: корзина, оформление заказа, личный кабинет, формы с токенами, страницы с персональными данными, результаты поиска по сайту. Если их отдать из кеша как обычный HTML, пользователь увидит чужое состояние страницы, а отладка потом превращается в охоту за случайностями.
Ниже — рабочая схема, как исключить отдельные URL из кеша в WordPress на уровне плагина, сервера и CDN, а потом проверить, что исключение реально сработало.
Когда кеш нужно отключать точечно
Не стоит выключать кеширование целиком, если проблема касается одной-двух страниц. В WordPress чаще всего нужно исключать:
- страницы с формами, где используются nonce или одноразовые токены;
- личный кабинет и страницы профиля;
- поиск по сайту, если результат зависит от параметров запроса;
- страницы с фильтрами, которые меняются от пользователя к пользователю;
- страницы, где выводится корзина, избранное, уведомления, счетчики;
- админские или служебные URL, если они случайно попали под правила кеша.
Если кешировать такие страницы без исключений, появляются типичные симптомы: не обновляется форма, отображается старое содержимое, после входа в аккаунт пользователь видит гостевую версию, а при повторной загрузке страница ведет себя по-разному в зависимости от того, кто открыл ее первым.
Диагностика: где именно ломается кеш
Сначала нужно понять, на каком уровне работает кеш. В WordPress это может быть плагин, серверный кеш, объектный кеш, CDN или их комбинация. Один и тот же URL может одновременно попадать под несколько правил, и тогда править только плагин недостаточно.
Что проверить в первую очередь
- Есть ли у страницы одинаковый HTML для разных пользователей.
- Меняется ли заголовок
Cache-Controlв ответе. - Есть ли заголовки от плагина кеша или CDN, например
X-Cache,CF-Cache-Status,Age. - Не кешируется ли страница на уровне Nginx/Apache, даже если плагин ее исключил.
- Не подставляет ли CDN старую версию из edge-кеша.
Удобно смотреть ответ через DevTools или curl. Например:
curl -I https://example.com/account/Если в ответе видите признаки кеша, а страница должна быть динамической, значит исключение не применилось на нужном уровне.
Пошаговое решение: исключаем URL из кеша
1. Настройте исключения в плагине кеша
Большинство популярных плагинов кеша умеют исключать URL по маске. Логика обычно одна: вы добавляете точный путь или фрагмент пути, и плагин перестает сохранять HTML для этих страниц.
Пример подхода для типичного плагина: исключить /cart/, /checkout/, /my-account/, /search/. Если плагин поддерживает регулярные выражения, не усложняйте без необходимости: сначала проверьте простые точные пути.
Если у вас есть отдельные параметры в URL, например ?preview=1 или ?nocache=1, их тоже можно использовать как триггер для обхода кеша, но только если плагин это поддерживает. Не все решения умеют исключать по query string одинаково.
2. Добавьте серверное исключение, если плагин не хватает
Если кеш строится на уровне Nginx или reverse proxy, исключение в админке WordPress может не помочь. В таком случае правило нужно добавить в конфигурацию сервера. Для Nginx это обычно делается через location или через условия, которые отключают кеш для нужных URI.
location ~* ^/(cart|checkout|my-account)/ {
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
proxy_no_cache 1;
proxy_cache_bypass 1;
}Этот пример не универсален и зависит от того, как у вас настроен reverse proxy. Но сама идея правильная: для динамических страниц сервер должен не только не отдавать кеш, но и не записывать его.
3. Для WordPress добавьте условное отключение кеша кодом
Если нужно защитить конкретные шаблоны или URL, можно отключать кеш на уровне темы или небольшого mu-plugin. Для этого подойдут стандартные функции WordPress, без выдуманных хуков.
<?php
add_action('template_redirect', function () {
if (is_page(array('account', 'checkout', 'cart')) || is_search()) {
if (!defined('DONOTCACHEPAGE')) {
define('DONOTCACHEPAGE', true);
}
nocache_headers();
}
});Здесь используется константа DONOTCACHEPAGE, которую понимают многие кеширующие плагины. Это не магическая кнопка для всех случаев, но в реальных проектах она часто помогает, если проблема именно в WordPress-слое.
4. Если используется CDN, проверьте правила на его стороне
CDN может продолжать отдавать старую версию, даже если WordPress и сервер уже настроены правильно. Для таких страниц нужно либо отключить кеширование на CDN, либо создать правило обхода по пути.
Практически это означает: для чувствительных URL не полагайтесь только на purge. Лучше сразу задать правило, что эти страницы не должны кешироваться на edge.
Сравнение подходов: плагин, сервер, код
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин кеша | Нужно быстро исключить несколько URL | Просто настроить, не требует доступа к серверу | Не всегда перекрывает серверный кеш и CDN |
| Серверное правило | Есть Nginx/Apache и reverse proxy | Работает ниже по стеку, надежнее для динамики | Нужен доступ к конфигу и аккуратная проверка |
| Код в WordPress | Нужно отключать кеш по условиям шаблона | Гибко, можно привязать к логике сайта | Не спасает, если внешний кеш уже отдал страницу |
Проверка результата после внедрения
После настройки не ограничивайтесь визуальной проверкой в браузере. Нужна проверка именно заголовков и поведения страницы для разных запросов.
- Откройте страницу в режиме инкогнито и под авторизованным пользователем.
- Сравните HTML и заголовки ответа через
curl -I. - Проверьте, что на исключенной странице нет признаков кеша: например, не растет
Age, не появляетсяHITтам, где должен быть bypass. - Обновите страницу несколько раз и убедитесь, что динамические блоки не залипают.
- Если есть CDN, проверьте ответ не только с сайта, но и через его панель или диагностические заголовки.
Полезно сравнить две страницы: одну кешируемую и одну исключенную. На кешируемой вы должны видеть обычное поведение кеша, а на исключенной — либо отсутствие кеш-заголовков, либо явный bypass.
Частые ошибки и как их исправить
Исключили не тот URL
Часто проблема в несовпадении пути: в настройках указан /account, а реальный URL — /my-account/. Сначала посмотрите фактический permalink, потом добавляйте исключение.
Отключили кеш только в плагине
Если сервер или CDN кешируют отдельно, плагин ничего не изменит. В таком случае нужно искать второй слой кеша и править его правила.
Сломали кеш для всего сайта слишком широким правилом
Иногда добавляют слишком общий шаблон, и из кеша выпадает половина сайта. Не используйте широкие маски без необходимости. Лучше несколько точных путей, чем одно правило на весь раздел.
Забыли про query string
Если страница зависит от параметров в URL, а кеш игнорирует query string, вы получите одинаковый HTML для разных запросов. Для таких сценариев нужно либо исключать конкретные параметры, либо полностью обходить кеш для этого маршрута.
Не очистили старый кеш
После изменения правил старые версии могут оставаться в кеше до истечения срока жизни. Обязательно сделайте purge на всех уровнях: плагин, сервер, CDN.
Чек-лист перед публикацией изменений
- Проверен точный список URL, которые должны обходить кеш.
- Настроено исключение в плагине кеша.
- Проверены правила на сервере, если кеш есть ниже WordPress.
- Добавлен
DONOTCACHEPAGEили аналогичная логика, если это оправдано. - Сделан purge старого кеша.
- Проверены заголовки ответа через
curl -Iили DevTools. - Сравнено поведение страницы для гостя и авторизованного пользователя.
Практические советы по безопасности и производительности
Не отключайте кеширование шире, чем нужно. Каждая лишняя исключенная страница увеличивает нагрузку на PHP и базу данных. Если динамика нужна только в одном блоке, иногда лучше вынести этот блок через AJAX или REST API, чем выключать кеш для всей страницы.
Если на сайте есть персональные данные, не полагайтесь на «почти не кешируется». Для таких страниц нужны жесткие правила обхода кеша и проверка заголовков ответа. Это особенно важно для форм, кабинетов и страниц, где отображается пользовательский контент.
Если вы регулярно чистите сайт от дублей, мусора и лишних технических страниц, удобно держать под рукой инструменты, которые помогают управлять SEO-настройками и очисткой без ручного редактирования каждого шаблона. Например, для части таких задач может пригодиться Clearfy Pro, если он уже используется в проекте и подходит под ваш стек. Но правила кеша все равно нужно проверять на реальном ответе сервера, а не только в интерфейсе плагина.
Если после настройки исключений страница все равно отдается из кеша, не ищите проблему только в WordPress. В большинстве случаев причина в том, что один из уровней стека — сервер, reverse proxy или CDN — продолжает жить по своим правилам. Именно поэтому проверка заголовков и сравнение ответов для разных пользователей здесь важнее, чем визуальная галочка в админке.