Если после включения кеша в WordPress админка начинает вести себя странно, а вход то работает, то нет, проблема часто не в пароле и не в пользователе. Кеширующий слой может отдавать устаревшие cookies, HTML формы входа или редиректы, которые не должны кэшироваться вообще. В итоге вы видите циклический вход, 403/401 на админке, странные разлогины или ситуацию, когда после авторизации сайт продолжает показывать гостевую версию.
Ниже разберём, что именно нужно исключить из кеша, как это сделать на уровне плагина, сервера и кода, и как проверить, что исключения реально сработали.
Когда кеш ломает вход и админку
Типичный сценарий выглядит так: сайт ускорили через плагин кеша, серверный кеш или CDN, после чего /wp-admin/ и /wp-login.php начали отдавать не то, что должны. Иногда проблема проявляется только у части пользователей, иногда — только после смены темы, SSL или обновления плагина кеширования.
Признаки, что дело именно в кешировании
- после логина вас возвращает на страницу входа;
- в админке виден старый контент или старый статус пользователя;
- страница входа открывается с задержкой или с ошибкой 403/429;
- после выхода из аккаунта браузер показывает, что вы всё ещё авторизованы;
- на одном устройстве вход работает, на другом — нет;
- при очистке кеша проблема временно исчезает.
Если симптомы плавающие, сначала проверьте не только плагин кеша, но и CDN, reverse proxy, серверный page cache и object cache. Часто ломает не один слой, а их сочетание.
Диагностика: что проверить до правок
Сначала нужно понять, где именно кэшируется ответ. Не стоит сразу править .htaccess или писать фильтры в functions.php, если проблема сидит в CDN или на уровне Nginx.
- Откройте
/wp-login.phpв режиме инкогнито и посмотрите заголовки ответа. - Проверьте, не отдаются ли заголовки кеша вроде
cache-control,age,x-cache,cf-cache-status. - Сравните ответ для гостя и для авторизованного пользователя.
- Очистите кеш плагина, серверный кеш и CDN по очереди, чтобы понять источник.
Для быстрой проверки удобно использовать curl:
curl -I https://example.com/wp-login.phpЕсли вы видите признаки кеширования там, где их быть не должно, значит исключения настроены неполно.
Как правильно исключить wp-login.php и wp-admin из кеша
Надёжный вариант — отключать кеширование не только для страницы входа, но и для всей админки, а также для AJAX и REST-запросов, если они используются в интерфейсе. Важно не просто добавить один URL в список исключений, а закрыть все связанные точки.
1. Настройка в плагине кеша
В большинстве плагинов есть поля для исключения URL, cookies и user agents. Ищите настройки вроде Never cache URLs, Exclude pages, Do not cache cookies.
Минимальный список исключений:
/wp-login.php;/wp-admin/;/wp-admin/admin-ajax.php;- страницы с формами входа, если они вынесены на отдельный URL;
- cookies авторизации WordPress, если плагин позволяет исключать по cookie.
Если кеш-плагин умеет исключать по cookie, добавьте хотя бы такие значения:
wordpress_logged_in_Это не универсальная магическая настройка, но для большинства конфигураций она помогает не отдавать гостевой кеш авторизованным пользователям.
2. Исключение на уровне Nginx
Если кеширование идёт на сервере, плагин может быть ни при чём. Для Nginx обычно используют условия, которые отключают кеш для логин-страниц и админки. Пример зависит от вашей схемы, но логика такая:
set $skip_cache 0;</nset $skip_cache 1 if ($request_uri ~* "/wp-login\.php|/wp-admin/|/wp-json/");В реальной конфигурации синтаксис зависит от того, как у вас подключён fastcgi_cache или proxy_cache. Смысл один: для чувствительных URL кеш не должен включаться вообще.
Если у вас Nginx + PHP-FPM, проверьте, что исключение применяется не только по URI, но и по наличию авторизационных cookies.
3. Исключение через код, если нужен точечный контроль
Иногда плагин кеша не даёт достаточно гибких настроек, а сервером вы не управляете. Тогда можно отключать кеширование для конкретных запросов на уровне WordPress. Это не заменяет серверную настройку, но помогает в спорных случаях.
<?php
add_action('init', function () {
if (is_admin() || strpos($_SERVER['REQUEST_URI'] ?? '', 'wp-login.php') !== false) {
if (!defined('DONOTCACHEPAGE')) {
define('DONOTCACHEPAGE', true);
}
if (!defined('DONOTMINIFY')) {
define('DONOTMINIFY', true);
}
if (!defined('DONOTCDN')) {
define('DONOTCDN', true);
}
}
});Этот код имеет смысл только как дополнительный слой. Он не спасёт, если CDN уже закешировал страницу до WordPress.
Что делать с CDN и прокси
Если сайт стоит за Cloudflare, nginx reverse proxy или другим CDN, исключения в WordPress-плагине могут не сработать. CDN видит запрос раньше WordPress и может отдать кешированный ответ, даже не доходя до PHP.
Проверьте:
- есть ли правило bypass cache для
/wp-login.phpи/wp-admin/*; - не включён ли кеш HTML для всего сайта без исключений;
- не перехватывает ли CDN редирект с
httpнаhttpsи обратно; - не кешируются ли ответы с
Set-Cookie.
Если CDN умеет правила по пути, делайте отдельное исключение для админки и логина. Для WordPress это не роскошь, а базовая гигиена.
Сравнение подходов
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Настройка в плагине кеша | Если кеш управляется из WordPress | Быстро, без правки сервера | Не всегда покрывает CDN и reverse proxy |
| Правка конфигурации Nginx/Apache | Если есть доступ к серверу | Надёжно на уровне инфраструктуры | Нужна аккуратность и доступ к хостингу |
| Код в теме/плагине | Если нужен точечный контроль | Можно закрыть спорные сценарии | Не решает уже закешированные ответы вне WordPress |
Пошаговая схема внедрения
- Сделайте список URL, которые не должны кешироваться: логин, админка, AJAX, REST.
- Добавьте исключения в плагин кеша.
- Проверьте настройки CDN и отключите кеш для этих путей.
- Если есть доступ к серверу, добавьте bypass cache на уровне Nginx или Apache.
- Очистите все уровни кеша: плагин, сервер, CDN, браузер.
- Протестируйте вход в инкогнито и под обычным пользователем.
Проверка результата после внедрения
После настройки не ограничивайтесь одним ручным логином. Проверьте несколько сценариев, потому что кеш-ошибки часто проявляются только в одном из них.
- откройте
/wp-login.phpв инкогнито и убедитесь, что ответ не приходит из кеша; - войдите в админку, обновите страницу и проверьте, что сессия не сбрасывается;
- выйдите из аккаунта и убедитесь, что приватные элементы исчезли;
- посмотрите заголовки ответа через DevTools или
curl -I; - проверьте поведение после очистки кеша и повторного входа.
Если у вас есть мониторинг, полезно отдельно отслеживать 401/403/429 на /wp-login.php и резкие всплески редиректов. Это помогает быстро увидеть, что исключения сломались после обновления плагина или CDN-правил.
Частые ошибки и как их исправить
Исключили только wp-login.php, но не wp-admin
Это частая ошибка. Пользователь входит успешно, но потом получает закешированную админку или старую версию панели. Добавляйте исключение для всей директории /wp-admin/, а не только для формы входа.
Очистили кеш в плагине, но забыли CDN
Если перед сайтом стоит CDN, локальная очистка ничего не меняет. Нужно чистить и внешний кеш, иначе вы будете тестировать старый ответ.
Кешируется HTML, но не учитываются cookies
В этом случае авторизованный пользователь может видеть гостевую версию страницы. Проверьте, что кеш отключается при наличии cookie авторизации WordPress.
Сломали минификацию вместо кеша
Иногда отключают не тот механизм и получают проблемы с JS в админке. Если после правок исчезают кнопки, не работает редактор или ломается AJAX, проверьте, не включили ли вы слишком агрессивную оптимизацию для /wp-admin/.
Практические советы по безопасности и производительности
Админку и логин лучше не только исключать из кеша, но и не пытаться ускорять их теми же правилами, что и публичные страницы. Для /wp-admin/ важнее предсказуемость, чем агрессивная оптимизация.
- не включайте HTML-кеш для авторизованных пользователей без явной проверки cookie;
- не минифицируйте и не объединяйте скрипты админки без теста;
- не кешируйте ответы
Set-Cookieна логине; - после обновления плагина кеша перепроверяйте исключения;
- если используете несколько слоёв кеша, документируйте, где именно лежит каждое правило.
Если нужен более системный аудит дублей, кеша и технических настроек WordPress, имеет смысл смотреть в сторону инструментов вроде Clearfy Pro: у него есть функции для чистки сайта и удаления лишнего технического шума, но даже с ним правила кеширования для логина и админки всё равно нужно проверять вручную.
Главная мысль простая: /wp-login.php и /wp-admin/ должны быть исключены из кеша на всех уровнях, где вообще возможна отдача HTML. Если исключение работает только в одном месте, проблема вернётся при первом же изменении инфраструктуры.