Как исключить страницы из кеширования в WordPress

Иногда проблема не в самом кешировании, а в том, что в кеш попадает страница, которая должна оставаться динамической: личный кабинет, корзина, оформление заказа, результаты поиска, формы с одноразовыми токенами, страницы с персональными данными или контентом, зависящим от cookies. Если не исключить такие URL, пользователь увидит устаревшее состояние, а в худшем случае — чужие данные.

Ниже разберём, как точечно исключать страницы из кеша в WordPress: через настройки плагина, через правила на уровне сервера и через код, если нужен контроль над отдельными шаблонами или URL.

Когда страницу нужно исключать из кеширования

Не каждая страница обязана обходить кеш. Для обычных статей и страниц кеш полезен. Исключение нужно там, где HTML зависит от текущего пользователя, сессии, nonce, корзины, авторизации или быстро меняющегося состояния.

Типовые сценарии

• страницы входа и восстановления пароля;
• личный кабинет и профиль пользователя;
• корзина и оформление заказа;
• страницы с результатами поиска по сайту;
• формы, где используются nonce или одноразовые токены;
• страницы с персональными блоками: приветствие, баланс, история заказов;
• лендинги, где часть контента подставляется через AJAX и ломается из-за полного HTML-кеша.

Если у вас на странице есть только небольшой динамический блок, не всегда нужно исключать весь URL. Иногда лучше оставить кеш страницы и вынести динамику в AJAX-запрос или отдельный фрагмент без кеша. Это обычно быстрее и безопаснее.

Диагностика: как понять, что кеш мешает

Перед настройкой проверьте, действительно ли проблема в кеше, а не в плагине, теме или CDN. Самый простой признак — страница показывает старое состояние после действия пользователя: вход выполнен, а шапка всё ещё как для гостя; товар добавлен в корзину, но счётчик не меняется; форма отправлена, а ответ не обновился.

Полезно посмотреть заголовки ответа в браузере или через curl. Если у страницы есть признаки кеша, вы увидите заголовки вроде cache-control, x-cache, cf-cache-status или заголовки конкретного плагина кеширования.

curl -I https://example.com/my-account/

Смотрите не только на наличие кеша, но и на то, одинаковый ли ответ для гостя и авторизованного пользователя. Если HTML одинаковый там, где он должен отличаться, страницу нужно исключать или переделывать логику вывода.

Способы исключить страницу из кеша

Есть три рабочих подхода: через интерфейс плагина кеширования, через правила на сервере и через код WordPress. Выбор зависит от того, чем именно вы управляете: плагином, Nginx/Apache или темой/плагином.

1. Исключение через плагин кеширования

У большинства плагинов есть поле для URL, которые не надо кешировать, и отдельные настройки для cookies, query string или пользовательских ролей. Это самый безопасный путь, если вы не хотите трогать сервер.

Например, если у вас есть страницы /cart/, /checkout/, /my-account/, добавьте их в список исключений в интерфейсе плагина. Для поиска по сайту часто исключают шаблон ?s= или сам маршрут поиска, если он есть.

Если вы используете плагин с поддержкой исключений по cookies, добавьте туда cookie, по которой определяется авторизация или корзина. Но не исключайте лишнее: чем шире правило, тем меньше пользы от кеша.

2. Исключение через код WordPress

Если нужно отключать кеш только для конкретных страниц или условий, можно сделать это в мини-плагине. В WordPress для этого часто используют константу DONOTCACHEPAGE. Её понимают многие плагины кеширования.

<?php
/**
 * Plugin Name: Disable cache for selected pages
 */

add_action('template_redirect', function () {
    if (is_page(array('cart', 'checkout', 'my-account')) || is_search()) {
        if (!defined('DONOTCACHEPAGE')) {
            define('DONOTCACHEPAGE', true);
        }
    }
});

Такой код лучше хранить не в functions.php, а в небольшом mu-plugin или отдельном плагине. Тогда он не пропадёт при смене темы.

Если нужно исключать страницу по ID, это тоже рабочий вариант:

<?php
add_action('template_redirect', function () {
    if (is_page(array(42, 87, 103))) {
        if (!defined('DONOTCACHEPAGE')) {
            define('DONOTCACHEPAGE', true);
        }
    }
});

Этот подход особенно полезен, если URL может меняться, а ID страницы остаётся стабильным.

3. Исключение на уровне сервера

Если у вас Nginx, Varnish или другой reverse proxy, исключение лучше делать там, чтобы запрос даже не доходил до генерации кеша. Логика зависит от стека, но общий принцип один: не кешировать конкретные пути, cookies или query string.

Для Nginx это обычно делается через location или условия по URI. Пример ниже не универсален для всех сборок, но показывает сам принцип:

location ~* ^/(cart|checkout|my-account)/ {
    add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
    expires off;
    try_files $uri $uri/ /index.php?$args;
}

Если кеш у вас на стороне хостинга или CDN, проверьте, нет ли там отдельного списка исключений. Иногда WordPress уже отдаёт правильные заголовки, но внешний кеш их игнорирует.

Пошаговая настройка без лишнего риска

1. Составьте список URL, которые не должны кешироваться. Начните только с реально динамических страниц.
2. Проверьте, есть ли у вас кеш на уровне плагина, сервера или CDN. Исключение должно быть на том уровне, где кеш создаётся.
3. Добавьте исключения в плагине кеширования, если он управляет HTML-кешем.
4. Если плагин не помогает, добавьте DONOTCACHEPAGE в мини-плагин для нужных условий.
5. Очистите кеш плагина, сервера и CDN, если он есть.
6. Проверьте страницу в режиме инкогнито и под авторизованным пользователем.

Если страница зависит от роли пользователя, не пытайтесь решать всё одним URL-исключением. Иногда лучше отключить кеш только для авторизованных пользователей, а гостям оставить кешированную версию.

Как проверить, что исключение сработало

Проверка должна быть не на глаз, а по признакам ответа сервера и поведению страницы.

• откройте страницу в инкогнито и убедитесь, что она загружается без старого состояния;
• выполните действие, которое меняет контент, и обновите страницу;
• проверьте заголовки ответа через DevTools или curl -I;
• если используется плагин кеша, посмотрите его логи или статус исключений;
• сравните HTML до и после очистки кеша.

Полезный тест: войдите как пользователь, откройте страницу, затем выйдите и откройте её снова в том же браузере. Если кеш настроен правильно, гостевая и авторизованная версии не должны путаться.

Частые ошибки и как их исправить

Исключили не тот URL

Часто в список добавляют красивый URL, а реальный маршрут отличается из-за слэша, языка, пагинации или параметров. Сверяйте точный путь, который отдаёт WordPress, и не забывайте про вариант с завершающим слэшем.

Отключили кеш слишком широко

Если исключить весь раздел или все страницы с query string, вы можете потерять почти весь эффект от кеширования. Лучше сузить правило до конкретных URL, cookies или ролей.

Не очистили внешний кеш

Плагин уже настроен, но CDN или серверный кеш продолжает отдавать старую версию. В таких случаях нужно чистить все уровни кеша, а не только WordPress.

Положились только на JavaScript

Если страница изначально отдаёт неверный HTML, а потом исправляется скриптом, это хрупкое решение. При медленной загрузке, ошибке JS или блокировке скрипта пользователь увидит неправильное состояние.

Использовали DONOTCACHEPAGE не там, где нужно

Константу нужно определять до того, как плагин кеша сформирует страницу. Если код подключён слишком поздно, эффект может быть нулевым. Для таких задач безопаснее использовать template_redirect или mu-plugin.

Безопасность и производительность

Исключение страниц из кеша — это не только про корректность, но и про нагрузку. Чем больше страниц вы выводите без кеша, тем выше цена каждого запроса. Поэтому сначала исключайте только то, что действительно динамично.

Если у вас есть страница, где меняется только один блок, вынесите этот блок в отдельный AJAX-запрос или REST API. Тогда основная страница останется кешируемой, а динамика будет подгружаться отдельно. Это обычно лучше, чем отключать кеш целиком.

Для сайтов с большим количеством авторизованных пользователей проверьте, не кешируются ли страницы профиля между сессиями. Если есть риск утечки персональных данных, приоритет у безопасности, а не у скорости.

Если вы используете готовые инструменты для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не конфликтуют ли его настройки с вашим плагином кеширования. На практике проблемы чаще всего возникают не из-за самого кеша, а из-за пересечения нескольких оптимизационных плагинов.

Когда лучше не исключать страницу, а переделать логику

Если страница меняется только в одном месте, полное исключение из кеша — не лучший вариант. В таких случаях проще:

• вынести персональный блок в отдельный запрос;
• использовать фрагмент без кеша;
• передавать данные через REST API;
• показывать статический HTML и обновлять только счётчик или статус.

Так вы сохраните скорость и не будете отключать кеш там, где он всё ещё полезен.