Если на сайте периодически «выкидывает» из админки, не сохраняется состояние формы, а после входа пользователь видит старую версию страницы, проблема часто не в WordPress как таковом, а в слишком агрессивном кешировании. Важно не отключать кеш целиком, а исключить только те URL, где он мешает: /wp-login.php, /wp-admin/, страницы восстановления пароля, корзину сессий и, в некоторых случаях, личный кабинет.
Ниже — практический разбор: как понять, что виноват именно кеш, где его отключать точечно и как проверить результат без гаданий.
Когда кеширование действительно мешает
Типичный сценарий выглядит так: пользователь входит в админку, но после обновления страницы снова видит форму логина; в WooCommerce или другом плагине с авторизацией меняется состояние сессии, но страница отдаётся из кеша; после смены пароля браузер показывает старую форму или редиректит не туда. Если на сервере стоит page cache, CDN или плагин кеша, эти симптомы часто связаны именно с ними.
Что проверить в первую очередь
- Отдаётся ли
wp-login.phpс заголовком кеша вродеcache-control: publicилиx-cache: HIT. - Не попадает ли в кеш
/wp-admin/или страницы с параметрами авторизации. - Нет ли отдельного кеша на уровне CDN, который игнорирует правила плагина.
- Не включено ли «кеширование для всех» в плагине, который не умеет корректно исключать приватные страницы.
Диагностика проблемы без лишних догадок
Проверять лучше не по ощущениям, а по заголовкам ответа. Откройте проблемный URL в браузере и посмотрите response headers через DevTools или curl. Для логина и админки кеша быть не должно.
curl -I https://example.com/wp-login.phpЕсли в ответе видите признаки кеширования, например x-cache: HIT, cf-cache-status: HIT или явно публичные директивы, значит исключение не сработало. Для сравнения проверьте обычную публичную страницу: там кеш, наоборот, может быть полезен.
curl -I https://example.com/sample-page/Ещё один полезный тест — войти в админку в приватном окне и обновить страницу несколько раз. Если после логина вас периодически возвращает на форму входа, это почти всегда конфликт между авторизацией и кешем на одном из уровней.
Как отключить кеширование точечно
Самый безопасный подход — не трогать весь сайт, а исключить только чувствительные URL. Делать это можно на уровне плагина кеша, сервера или CDN. Если есть несколько уровней, правило должно быть на каждом из них, иначе верхний слой всё равно отдаст старую копию.
Вариант 1: настройки плагина кеша
У большинства плагинов есть список исключений по URL. Туда обычно добавляют:
/wp-login.php/wp-admin/*/wp-register.php, если используется регистрация- страницы личного кабинета, если они есть
- страницы восстановления пароля и подтверждения email
Если плагин умеет исключать по cookie, это ещё лучше: авторизованные пользователи не должны получать кешированную версию приватных страниц.
Вариант 2: правила на уровне Nginx
Если кешируется сам веб-сервер, исключение делается в конфигурации. Пример для Nginx: не кешировать логин и админку, а остальной сайт оставить под кешем.
location = /wp-login.php {
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
add_header Pragma "no-cache";
}
location ^~ /wp-admin/ {
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
add_header Pragma "no-cache";
}
Это не универсальный шаблон для любого сервера, но логика именно такая: приватные URL должны отдавать заголовки, запрещающие кеширование, и не попадать в page cache.
Вариант 3: исключение через PHP для плагинов кеша
Если вы пишете свой код или настраиваете тему/плагин, можно принудительно отправлять заголовки для чувствительных страниц. Это не заменяет настройки кеша, но помогает на уровне WordPress.
add_action('send_headers', function () {
if (is_user_logged_in() || is_admin() || $GLOBALS['pagenow'] === 'wp-login.php') {
nocache_headers();
}
});
Этот вариант полезен как дополнительная страховка, но не стоит рассчитывать только на него, если CDN или сервер уже отдают кеш до запуска WordPress.
Сравнение подходов
| Подход | Где настраивается | Плюс | Минус |
|---|---|---|---|
| Плагин кеша | Админка WordPress | Быстро и без доступа к серверу | Не всегда перекрывает CDN и серверный кеш |
| Nginx/Apache | Конфиг сервера | Работает раньше WordPress | Нужен доступ и аккуратность |
| PHP-ограничение | functions.php или мини-плагин | Просто внедрить | Не спасает от внешнего кеша |
Пошаговое решение
- Соберите список URL, которые не должны кешироваться: логин, админка, восстановление пароля, личный кабинет.
- Проверьте заголовки ответа через DevTools или
curl -I. - Добавьте исключения в плагин кеша.
- Если есть CDN, повторите исключения там же.
- Если кеш на сервере, внесите правила в конфиг Nginx/Apache.
- Очистите кеш на всех уровнях: плагин, сервер, CDN.
- Повторно проверьте заголовки и поведение в приватном окне.
Как проверить, что всё сработало
После настройки откройте /wp-login.php и /wp-admin/ в приватном окне. На этих страницах не должно быть признаков page cache. В ответе сервера должны исчезнуть заголовки, указывающие на HIT, а при повторной загрузке форма входа не должна вести себя как статическая страница.
Дополнительно проверьте:
- после входа в админку вы не возвращаетесь на форму логина;
- страница восстановления пароля обновляется корректно;
- авторизованный пользователь не видит старую версию приватной страницы;
- публичные страницы по-прежнему кешируются, если это было задумано.
Частые ошибки и как их исправить
Исключили только плагин, но забыли CDN
Это самая частая ситуация. Плагин кеша уже не хранит страницу, но CDN продолжает отдавать старую копию. Решение — повторить исключения в панели CDN и сбросить его кеш.
Отключили кеш для всего сайта
Так делать не нужно: сайт станет медленнее без необходимости. Проблема обычно касается только нескольких URL, а не всего фронтенда.
Использовали слишком широкое правило
Например, исключили весь каталог /wp-admin/, но забыли, что часть AJAX-запросов и служебных эндпоинтов тоже завязаны на авторизацию. Если правило слишком грубое, можно случайно сломать работу плагинов. Проверяйте после каждого изменения.
Не очистили старый кеш
Новые правила не помогут, если в кеше уже лежит старая версия страницы. После изменения конфигурации всегда делайте полный purge на всех уровнях.
Практические советы по безопасности и производительности
Не храните приватные страницы в общем кеше «на всякий случай». Это риск утечки данных и источник странных багов с авторизацией. Если у вас есть личный кабинет, корзина, формы сессий или страницы профиля, лучше явно пометить их как no-store и исключить из page cache.
Если нужно навести порядок в технических настройках WordPress, иногда проще использовать специализированный инструмент для чистки и отключения лишнего, чем вручную собирать десятки мелких правок. Например, Clearfy Pro помогает убрать часть технического мусора и сократить количество конфликтов между оптимизацией и реальной работой сайта: https://wpshop.ru/plugins/clearfy.
Главное правило простое: кеш должен ускорять публичные страницы, а не вмешиваться в авторизацию и админку. Если после настройки вы проверили заголовки, поведение логина и очистили все уровни кеша, проблема обычно уходит без побочных эффектов.