На живом сайте почти всегда есть страницы, которые нельзя отдавать из кэша как обычный HTML: личный кабинет, оформление заказа, результаты поиска, формы с токенами, страницы с персональными данными. Если кэшировать их без исключений, появляются типичные симптомы: пользователь видит чужие данные, не обновляется содержимое после логина, ломаются nonce-поля, а в админке сложно понять, где именно проблема.
Ниже разберём, как исключать отдельные страницы из кэша в WordPress без лишней магии: через настройки плагина, через код и через проверку заголовков ответа. Подходы зависят от того, какой кэш у вас стоит — плагин уровня страницы, серверный кэш или CDN, но логика одна: сначала найти динамические URL, потом исключить их из выдачи и убедиться, что они больше не отдаются как cached.
Когда кэш нужно отключать точечно
Полностью выключать кэш ради одной проблемной страницы — плохая идея. Обычно достаточно исключить конкретные URL, шаблоны или cookies. Это касается страниц, где контент зависит от пользователя, времени или состояния сессии.
Типовые сценарии
- страница входа и восстановления пароля;
- личный кабинет и профиль пользователя;
- корзина, оформление заказа, страница оплаты;
- поиск по сайту, если результаты зависят от параметров запроса;
- страницы с формами, где используются nonce и одноразовые токены;
- страницы с персонализированными блоками: приветствие, баланс, рекомендации.
Если у вас статический лендинг, исключений может не быть вовсе. Но как только на сайте появляется авторизация, формы или динамические блоки, точечное исключение становится обязательным.
Диагностика проблемы: что именно ломается
Перед настройкой исключений нужно понять, какой слой кэширования вмешивается. На практике проблема может быть в плагине, в сервере, в объектном кэше или в CDN. Один и тот же URL может отдавать разные заголовки в зависимости от того, кто его кэширует.
Что проверить в первую очередь
- открывается ли проблемная страница в режиме инкогнито без авторизации;
- меняется ли контент после очистки кэша;
- есть ли в ответе заголовки вроде
cache-control,x-cache,cf-cache-status; - не совпадает ли HTML у авторизованного и гостевого пользователя;
- не лежит ли проблема в плагине форм или безопасности, а не в кэше.
Удобнее всего смотреть заголовки через DevTools в браузере или через curl. Это помогает не гадать, а увидеть, кто именно отдаёт кэшированный ответ.
curl -I https://example.com/my-account/Если в ответе есть признаки кэша, а страница должна быть динамической, её нужно исключать на том уровне, где кэш создаётся. Иногда достаточно настроек плагина, иногда приходится добавлять правила на сервере.
Как исключить страницу из кэша в плагине
Большинство плагинов кэширования умеют исключать URL по точному адресу, маске или фрагменту пути. Названия пунктов меню отличаются, но смысл одинаковый: добавить страницу в список исключений и очистить кэш.
Что обычно нужно добавить
- точный URL:
/my-account/; - маску для группы страниц:
/checkout/*; - параметры запроса, если они меняют контент;
- cookies, по которым определяется авторизация или корзина;
- правило не кэшировать для залогиненных пользователей.
Если плагин поддерживает отдельные исключения для мобильной версии, проверьте и их. Иногда кэш ломается только на одном типе устройств из-за разной логики шаблона.
| Подход | Когда использовать | Минус |
|---|---|---|
| Исключение URL в плагине | Одна-две проблемные страницы | Нужно не забыть очистить кэш после изменения |
| Исключение по шаблону | Группа динамических страниц | Можно случайно отключить кэш шире, чем нужно |
| Код в теме или mu-plugin | Когда нужен контроль на уровне логики | Требует поддержки при обновлениях |
Если вы используете плагин уровня сайта, не пытайтесь закрыть проблему только через robots.txt или noindex. Это про индексацию, а не про кэш. Поисковик и браузер — разные задачи.
Решение через код: исключение страниц по условию
Когда в плагине нет удобного списка исключений или нужно поведение на уровне логики, можно добавить правило в тему или, лучше, в mu-plugin. Это безопаснее, чем править functions.php активной темы, потому что обновление темы не затрёт правило.
Ниже пример для сценария, когда нужно запретить кэширование для конкретных страниц по slug. Код не привязан к конкретному плагину кэша, но показывает правильный способ: выставить заголовки, которые подскажут промежуточным слоям не сохранять ответ.
<?php
add_action('template_redirect', function () {
if (is_page(array('my-account', 'checkout', 'cart'))) {
if (!defined('DONOTCACHEPAGE')) {
define('DONOTCACHEPAGE', true);
}
nocache_headers();
}
}, 0);Этот вариант полезен, если ваш кэш-плагин уважает константу DONOTCACHEPAGE и стандартные заголовки WordPress. Но важно понимать: если кэш создаётся на уровне сервера или CDN, одного этого может быть недостаточно.
Если нужно исключать по URL-паттерну
Иногда страницы динамические не по slug, а по структуре URL. Например, все адреса вида /account/* или /order-received/*. Тогда удобнее проверять путь запроса.
<?php
add_action('template_redirect', function () {
$uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';
if (strpos($uri, '/account/') === 0 || strpos($uri, '/checkout/') === 0) {
if (!defined('DONOTCACHEPAGE')) {
define('DONOTCACHEPAGE', true);
}
nocache_headers();
}
}, 0);Такой код стоит использовать аккуратно: чем шире условие, тем выше риск случайно выключить кэш там, где он не нужен. Если есть возможность, лучше ограничиться точными страницами.
Проверка результата после внедрения
После настройки нельзя ограничиться очисткой кэша в админке. Нужно убедиться, что страница действительно перестала кэшироваться и не ломает сценарии пользователя.
Минимальный чек-лист проверки
- открыть страницу в инкогнито и после авторизации;
- сравнить HTML до и после обновления;
- проверить заголовки ответа через DevTools или
curl -I; - очистить кэш плагина, серверный кэш и CDN, если он есть;
- пройти целевой сценарий: вход, отправка формы, оформление, переход назад;
- убедиться, что остальные страницы сайта по-прежнему кэшируются.
Если страница всё ещё отдаётся из кэша, смотрите не только WordPress-плагин. Часто виноват Nginx FastCGI cache, LiteSpeed Cache на сервере или CDN. Тогда исключение нужно продублировать и там.
Частые ошибки и как их исправить
Отключили кэш слишком широко
Самая частая ошибка — добавить в исключения целый раздел, хотя проблема только в одной странице. В итоге падает скорость на всём сайте. Исправление простое: сузить правило до конкретного URL или шаблона и проверить, не затронуты ли статические страницы.
Очистили только один слой кэша
Плагин очищен, а CDN продолжает отдавать старую версию. В таких случаях кажется, что настройка не работает, хотя на деле вы просто не сбросили внешний кэш. После изменения правил всегда проверяйте цепочку целиком.
Использовали noindex вместо исключения из кэша
noindex не решает проблему с кэшированием. Страница может быть закрыта от индексации, но всё равно отдавать устаревший HTML пользователям. Это разные механизмы, и путать их нельзя.
Положились только на cookies
Некоторые плагины умеют не кэшировать для определённых cookies, но если cookie выставляется поздно или не на всех сценариях, кэш всё равно может сработать. Лучше проверять и URL, и поведение пользователя.
Безопасность и производительность
Точечное отключение кэша — это не только про удобство, но и про безопасность. Если страница содержит персональные данные или одноразовые токены, её нельзя отдавать из общего кэша. При этом не стоит превращать исключения в список из десятков URL без причины: чем больше исключений, тем сложнее поддержка и тем меньше пользы от кэширования.
Если на сайте много дублей, технических страниц и мусорных URL, имеет смысл параллельно навести порядок в SEO- и технических настройках. В таких задачах иногда помогает Clearfy Pro: он закрывает часть типовых проблем с дублями и чисткой сайта, но кэш всё равно нужно настраивать отдельно. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
Когда лучше не писать код
Если у вас уже есть рабочий кэш-плагин с понятным списком исключений, сначала используйте его. Код нужен тогда, когда:
- правило должно зависеть от логики WordPress;
- нужно централизованно управлять исключениями для нескольких шаблонов;
- плагин не умеет исключать нужный тип страниц;
- вы хотите зафиксировать поведение в репозитории проекта.
Для большинства сайтов лучший порядок такой: сначала настройка в плагине, потом проверка заголовков, и только если этого мало — точечный код в mu-plugin. Так проще сопровождать сайт и меньше шанс сломать производительность на ровном месте.