Если на сайте с WP Super Cache кэшируются страницы входа, профиль пользователя или внутренние разделы с персональными данными, проблемы обычно проявляются быстро: после авторизации пользователь видит старую версию страницы, кнопка выхода не срабатывает как ожидается, а в личном кабинете отображается чужой или устаревший контент. В большинстве случаев это не «поломка кэша», а неверно выбранные исключения.
Ниже — рабочая схема для WordPress: как найти проблемные URL, что именно исключать из кэша, как проверить результат и где чаще всего ошибаются.
Когда нужно исключать страницу из кэша
Кэшировать можно почти весь публичный контент, но есть страницы, где HTML должен быть уникальным для конкретного пользователя или сессии. Для WP Super Cache это типичный сценарий для:
- страницы входа и выхода;
- регистрации;
- личного кабинета;
- страницы профиля;
- форм с персональными данными;
- разделов, где контент зависит от cookie, роли или авторизации.
Если такие страницы отдаются из кэша, вы получаете не ускорение, а рассинхронизацию состояния. Для публичных страниц это нормально, для приватных — нет.
Диагностика проблемы: что проверить до настройки
Сначала убедитесь, что проблема действительно в кэше, а не в теме или плагине авторизации. Проверка простая и занимает несколько минут.
1. Посмотрите заголовки ответа
Откройте проблемную страницу в браузере и проверьте заголовки через DevTools или curl. Если страница отдается с кэшем, это будет видно по служебным заголовкам и по поведению при повторной загрузке.
curl -I https://example.com/my-account/Ищите признаки кэширования и сравните их для гостя и авторизованного пользователя. Если одна и та же HTML-страница возвращается всем одинаково, а контент должен быть персональным, исключение нужно настраивать.
2. Проверьте cookie и URL
WP Super Cache может различать страницы по cookie, но для личного кабинета надежнее исключить сам URL. Это проще сопровождать и меньше зависит от сторонних плагинов. Отдельно проверьте:
- есть ли у страницы стабильный URL;
- не меняется ли он через редиректы;
- не генерирует ли плагин авторизации отдельные query-параметры;
- не используется ли AJAX для подгрузки приватных данных вместо обычной страницы.
3. Сравните поведение гостя и авторизованного пользователя
Откройте страницу в приватном окне и после входа в аккаунт. Если контент совпадает там, где должен отличаться, это явный сигнал, что кэш нужно ограничить.
Пошаговая настройка исключений в WP Super Cache
Самый надежный путь — исключить приватные страницы по URL и, при необходимости, добавить исключение по cookie. Начните с URL: это проще и безопаснее.
Шаг 1. Добавьте приватные URL в исключения
В настройках WP Super Cache откройте раздел исключений и добавьте пути, которые не должны кэшироваться. Обычно это:
/my-account//login//register//profile/
Если у вас свои слаги, используйте именно их. Важно указывать путь так, как он реально открывается в браузере, включая конечный слэш, если он есть на сайте.
Шаг 2. Исключите страницы через код, если интерфейса недостаточно
Когда список URL формируется динамически или зависит от логики темы, удобнее добавить исключения программно. Для этого можно использовать фильтр wpsc_exclude_urls, который WP Super Cache применяет к списку исключений.
<?php
add_filter( 'wpsc_exclude_urls', function( $urls ) {
$urls[] = '/my-account/';
$urls[] = '/login/';
$urls[] = '/register/';
return array_values( array_unique( $urls ) );
} );Такой код удобно держать в небольшом mu-plugin или в отдельном плагине сайта. Это лучше, чем править тему: исключения не потеряются при обновлении.
Шаг 3. При необходимости исключите по cookie
Если приватность зависит не только от URL, но и от состояния сессии, можно добавить правило по cookie. Это полезно, когда один и тот же URL показывает разный контент для гостей и авторизованных пользователей.
<?php
add_filter( 'wpsc_cachedata', function( $cachedata ) {
if ( ! empty( $_COOKIE['wordpress_logged_in_'] ) ) {
$cachedata['cache_enabled'] = false;
}
return $cachedata;
} );Этот пример намеренно простой: он отключает кэш для запросов, где присутствует cookie авторизации WordPress. Используйте его только если действительно нужно отключать кэш шире, чем по отдельным URL. Для большинства сайтов достаточно исключить конкретные страницы.
Что лучше: URL, cookie или код
На практике выбор зависит от того, насколько предсказуемы приватные страницы. Если структура сайта стабильная, URL-исключения обычно выигрывают по простоте и сопровождению.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Исключение по URL | Личный кабинет, вход, регистрация | Просто проверить и поддерживать | Нужно знать точные пути |
| Исключение по cookie | Один URL показывает разный контент | Гибко для авторизованных пользователей | Легко переисключить лишнее |
| Код через фильтр | Сложная логика темы или плагина | Можно централизовать правила | Нужна аккуратная поддержка |
Проверка результата после внедрения
После настройки не ограничивайтесь «страница открывается». Проверьте именно поведение кэша.
- Откройте исключенную страницу в приватном окне — она должна отдаваться без кэшированного HTML.
- Войдите в аккаунт и обновите страницу несколько раз.
- Сравните содержимое до и после входа: имя пользователя, ссылки выхода, персональные блоки должны обновляться.
- Проверьте заголовки ответа для гостя и авторизованного пользователя.
- Очистите кэш после изменения правил, чтобы старые копии не мешали тесту.
Если используете плагин для проверки заголовков, смотрите не только на наличие кэша, но и на то, не отдается ли приватная страница из промежуточного CDN-кэша. Иногда проблема не в WP Super Cache, а в внешнем уровне кеширования.
Частые ошибки и как их исправить
Указан не тот URL
Самая частая ошибка — добавить в исключения адрес без конечного слэша, когда на сайте используется другой формат. Проверьте фактический URL в браузере и внесите именно его.
Исключили только страницу входа, но не личный кабинет
После авторизации пользователь попадает в приватный раздел, который тоже должен быть исключен. Если оставить его в кэше, проблема просто переместится на следующий экран.
Слишком широкое правило по cookie
Когда кэш отключают для всех запросов с cookie, можно случайно убрать кэш и для обычных страниц, где это не нужно. В результате сайт теряет часть выигрыша в производительности. Сначала пробуйте исключать конкретные URL.
Не очищен старый кэш
После изменения правил старые HTML-файлы могут продолжать отдаваться до ручной очистки. Если тесты показывают старое поведение, сначала сбросьте кэш, потом повторите проверку.
Приватный контент выведен через общий шаблон
Если в шаблоне страницы есть блоки с персональными данными, а сама страница кэшируется как публичная, исключение URL не поможет полностью. В этом случае вынесите персональный блок в AJAX-запрос или сделайте страницу некэшируемой.
Практические советы по безопасности и производительности
Если страница содержит данные пользователя, не пытайтесь «ускорить» ее ценой кэширования общего HTML. Лучше оставить кэш только для публичной части сайта, а приватные экраны обслуживать без него.
- не кэшируйте формы, где есть токены, nonce или персональные данные;
- не полагайтесь на визуальную проверку — всегда смотрите заголовки ответа;
- держите список исключений коротким и понятным;
- если правила задаются кодом, храните их в отдельном mu-plugin;
- после обновления плагинов авторизации повторяйте тест входа и выхода.
Если на сайте много исключений и дублей в технических настройках, иногда проще сначала навести порядок в SEO- и служебных страницах, а затем уже тонко настраивать кэш. Для этого полезны плагины вроде Clearfy Pro, если они уже используются в проекте и не конфликтуют с текущей схемой кеширования.
Хороший ориентир простой: публичные страницы должны кэшироваться быстро и стабильно, а все, что зависит от пользователя, должно обходить кэш без двусмысленностей. Тогда WP Super Cache работает предсказуемо, а не «почти правильно».