Ситуация типовая: сайт работает на кеширующем плагине или на серверном кеше, но отдельные страницы начинают вести себя неправильно. На форме не обновляется состояние, в личном кабинете показываются старые данные, в админке или на служебных страницах виден чужой контент, а после логина пользователь всё ещё получает закешированную публичную версию. В таких случаях не нужно отключать кеш целиком — обычно достаточно исключить конкретные URL, cookies или типы страниц.
Ниже разберём, какие страницы действительно стоит выводить из кеша, чем отличается настройка в плагине от решения через код, и как проверить, что исключение сработало, а не осталось только в интерфейсе настроек.
Когда кеш нужно отключать точечно
Не каждая «медленная» страница должна быть исключением. Если страница просто долго грузится, сначала ищите проблему в запросах к базе, тяжёлых скриптах или изображениях. Исключение из кеша имеет смысл там, где контент зависит от текущего пользователя, сессии, nonce, корзины, состояния формы или времени запроса.
Типичные сценарии
- страницы авторизации, регистрации и сброса пароля;
- личный кабинет и профиль пользователя;
- страницы с формами, где важны nonce и одноразовые токены;
- страницы с динамическими фильтрами, если плагин кеша ломает параметры запроса;
- служебные endpoints, которые отдают персональные данные;
- страницы предпросмотра, если они доступны только авторизованным пользователям.
Если речь о публичной странице с небольшим динамическим блоком, иногда лучше не исключать её целиком, а вынести динамику в AJAX или REST API. Это обычно безопаснее для производительности.
Диагностика: как понять, что проблема именно в кеше
Перед изменением настроек проверьте, что страница действительно отдаётся из кеша. Самый простой способ — открыть её в режиме инкогнито и сравнить заголовки ответа. У разных плагинов и серверов они отличаются, но логика одна: в ответе должен быть признак кеширования или его отсутствия.
Полезно проверить три вещи:
- одинаковый ли HTML приходит для разных пользователей;
- меняются ли данные после выхода из аккаунта и повторного входа;
- не кэшируется ли страница по ошибке вместе с query string, например
?preview=1или?token=....
Если у вас есть доступ к CLI, можно быстро посмотреть заголовки через curl:
curl -I https://example.com/my-account/Ищите заголовки вроде cache-control, x-cache, cf-cache-status, x-litespeed-cache или аналогичные. Название зависит от стека, но если страница должна быть динамической, а ответ явно кешируется, это уже повод настраивать исключение.
Что лучше: настройка в плагине или через код
Если у вас обычный сайт без сложной логики, проще и надёжнее начать с интерфейса кеш-плагина. Код нужен тогда, когда исключение должно зависеть от условий: роли пользователя, типа записи, наличия cookie или конкретного шаблона.
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройка в плагине кеша | Один или несколько фиксированных URL | Зависит от конкретного плагина, сложнее масштабировать |
| Исключение через код | Нужны условия по роли, cookie, шаблону, query vars | Требует аккуратности и тестирования |
| Полное отключение кеша | Только для очень динамичных разделов | Удар по производительности |
Пошагово: как исключить страницу из кеша в плагине
У большинства кеширующих плагинов есть список исключений по URL. Логика обычно такая: вы добавляете путь страницы, сохраняете настройки, очищаете кеш и проверяете ответ заново. Важно указывать именно путь, а не полный домен, если плагин просит относительный URL.
Что добавить в исключения
- точный URL страницы, например
/my-account/; - страницы с параметрами, если плагин поддерживает шаблоны;
- cookie, по которым определяется авторизация или корзина;
- отдельные типы постов, если кеш-плагин умеет исключать их по правилам.
После сохранения настроек обязательно очистите весь кеш: плагина, сервера и CDN, если он есть. Иначе вы можете проверить старую версию страницы и решить, что правило не работает.
Исключение страниц из кеша через код
Если нужно поведение на уровне темы или мини-плагина, можно отключать кеш для конкретных запросов через стандартные фильтры и константы WordPress. Ниже пример для сценария, когда страница должна быть динамической для авторизованных пользователей или для конкретного шаблона страницы.
<?php
/**
* Plugin Name: Disable cache for selected pages
*/
add_action( 'template_redirect', function () {
if ( is_user_logged_in() && is_page( array( 'my-account', 'profile' ) ) ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );Это не универсальная магия для всех кеш-систем, но для многих плагинов и серверных решений такой флаг учитывается. Используйте его только там, где страница действительно должна быть персональной.
Если нужно исключать страницы по cookie, можно проверять их до вывода шаблона:
<?php
add_action( 'init', function () {
if ( ! empty( $_COOKIE['wp_user_session'] ) ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );Здесь важно не подменять реальную логику авторизации самодельной cookie. Используйте только те cookie, которые уже есть в вашей системе и действительно отражают состояние пользователя.
Если нужен более точный контроль: исключение по шаблону или типу записи
Иногда проблема не в конкретной странице, а в целом шаблоне. Например, у вас есть шаблон page-account.php или отдельный тип записи для заявок, где данные должны обновляться без кеша. Тогда удобнее завязаться на условные теги WordPress.
<?php
add_action( 'wp', function () {
if ( is_singular( 'request' ) || is_page_template( 'page-account.php' ) ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );Такой подход лучше, чем перечислять десятки URL вручную, но он требует дисциплины: если шаблон начнут использовать для публичных страниц, кеш тоже будет отключён. Это не ошибка кода, а ошибка архитектуры.
Проверка результата после внедрения
После настройки не ограничивайтесь открытием страницы в браузере. Нужна проверка, которая покажет, что кеш не отдает старую версию.
- откройте страницу в инкогнито и сравните HTML с обычной сессией;
- проверьте заголовки ответа через
curl -Iили DevTools; - войдите под разными пользователями и убедитесь, что контент не смешивается;
- очистите кеш и повторите проверку, чтобы исключить ложный результат;
- если есть CDN, проверьте и его слой отдельно.
Хороший тест — изменить заведомо заметный фрагмент данных, например имя пользователя в профиле или статус формы, и посмотреть, обновился ли он без ручной очистки кеша. Если нет, значит правило исключения не сработало или сработало только на одном уровне кеширования.
Частые ошибки и как их исправить
Указали не тот URL
Часто в исключения добавляют полный адрес с доменом, хотя плагин ожидает только путь. Или наоборот. Сверяйтесь с форматом, который просит конкретный плагин. Если правило не срабатывает, проверьте вариант со слэшем в конце и без него.
Очистили не весь кеш
Плагин мог очиститься, но остался серверный кеш или CDN. В результате вы видите старую страницу и думаете, что исключение не работает. Проверяйте все уровни: плагин, хостинг, прокси, CDN.
Отключили кеш там, где хватило бы динамического блока
Это частая ошибка на сайтах с личными кабинетами и формами. Если страница публичная, а динамичен только один блок, лучше загрузить его отдельно через AJAX или REST API. Иначе вы теряете смысл кеширования для всей страницы.
Сделали исключение по слишком общему условию
Например, отключили кеш для всех авторизованных пользователей, хотя персонализирован только один раздел. В итоге сайт стал медленнее для всех вошедших. Сужайте условие до конкретного шаблона, URL или cookie.
Забыли про query string
Если страница зависит от параметров в URL, а кеш-плагин игнорирует их, можно получить неправильный контент. В таких случаях нужно настраивать отдельное правило для параметров или отключать кеш именно для этого сценария.
Безопасность и производительность: что не стоит делать
Не отключайте кеш «на всякий случай» для всего сайта. Это быстро превращается в лишнюю нагрузку на PHP и базу данных, особенно если трафик растёт. Также не храните в кеше персональные данные, если страница должна быть приватной: это уже не вопрос скорости, а вопрос безопасности.
Если у вас много исключений, проверьте, не проще ли вынести динамику в отдельный endpoint и оставить основную страницу статичной. Для WordPress это обычно лучше, чем бесконечно расширять список исключений.
Если нужно одновременно почистить сайт от лишних дублей, служебных страниц и настроить технические исключения, иногда удобнее использовать комплексный инструмент вроде Clearfy Pro, но только если он действительно закрывает вашу задачу и не дублирует уже существующую логику кеш-плагина.
Мини-чек-лист перед публикацией изменений
- проверен точный URL или шаблон страницы;
- понятно, какой уровень кеша нужно исключить;
- очищен кеш плагина, сервера и CDN;
- страница протестирована в инкогнито и под авторизацией;
- проверены заголовки ответа;
- нет лишнего отключения кеша для всего сайта.
Если после всех проверок страница всё ещё отдаётся из кеша, ищите не в WordPress, а в инфраструктуре: nginx, Varnish, Cloudflare или другой слой может перезаписывать поведение плагина. В таких случаях правило нужно настраивать именно там, где реально происходит кеширование.