Плагин кэша можно включить за пару минут, но это ещё не значит, что страницы действительно отдаются из кэша. На практике чаще всего проверяют только факт установки плагина и забывают посмотреть на заголовки ответа, поведение для гостя и авторизованного пользователя, а также на исключения для динамических страниц. Из-за этого сайт может оставаться медленным, а иногда кэш работает не там, где нужно, и показывает устаревший контент.
Надёжная проверка занимает немного времени: сначала смотрим, меняется ли ответ сервера для повторного визита, затем сравниваем поведение гостя и авторизованного пользователя, после этого проверяем, не мешают ли кэшу исключения, CDN или серверные настройки. Ниже — практический порядок действий без лишней теории.
Что именно нужно проверить
Когда говорят «кэширование работает», обычно имеют в виду не одну, а несколько разных вещей. Для WordPress важно разделять:
- кэш страницы — готовая HTML-страница отдаётся без повторной сборки WordPress;
- браузерный кэш — файлы CSS, JS, изображения сохраняются у посетителя в браузере;
- object cache — кэшируются результаты запросов к базе данных и вычисления внутри WordPress;
- серверный кэш — кэш на уровне Nginx, LiteSpeed, Varnish или другого слоя;
- CDN-кэш — копия статических и иногда HTML-страниц на стороне CDN.
Для обычного информационного сайта чаще всего проверяют именно кэш страницы. Для интернет-магазина, сайта с личным кабинетом или формами авторизации важно ещё убедиться, что кэш не затрагивает персональные страницы и корзину.
Самый быстрый способ понять, отдается ли страница из кэша
Начните с простой проверки в браузере в режиме инкогнито или в другом браузере, где вы не авторизованы на сайте. Откройте одну и ту же страницу дважды с небольшой паузой между загрузками. Если кэш страницы работает, второй запрос обычно проходит быстрее, а в ответе сервера появляются признаки кэша.
Но ориентироваться только на скорость нельзя: быстрый ответ может быть связан с хорошим хостингом, а не с кэшем. Надёжнее смотреть заголовки ответа. Для этого подойдёт любой инструмент разработчика в браузере или онлайн-сервис проверки заголовков.
Какие заголовки искать
Названия заголовков зависят от плагина, сервера и CDN, поэтому универсального единственного признака нет. Чаще всего встречаются такие варианты:
X-Cache: HITилиX-Cache: MISS;Cache-Control;Age;CF-Cache-Statusу Cloudflare;X-Cache-Status,HIT,MISS,BYPASSу разных серверных решений;- служебные заголовки плагина, например у WP Super Cache могут встречаться признаки вроде
WP-Super-CacheилиX-WP-Super-Cacheв зависимости от версии и окружения.
Если при повторной загрузке страницы вы видите статус HIT или аналогичный признак попадания в кэш, это хороший знак. Если постоянно отображается MISS или BYPASS, кэш не используется либо запросы исключаются из него.
Для быстрой проверки через командную строку можно использовать curl. Это удобно, если вы хотите сравнить заголовки без влияния расширений браузера и локального кэша.
curl -I https://example.com/Команда покажет только заголовки ответа. Если нужно увидеть больше деталей, можно добавить -L для переходов по редиректам. Но если вы не уверены, что делаете, не меняйте URL на боевом сайте без понимания, куда он ведёт: редиректы могут увести на другой домен или на страницу входа.
Проверка для гостя и для авторизованного пользователя
Это один из самых важных тестов. Кэш страницы почти всегда должен работать для гостя, но для авторизованного пользователя поведение зависит от сайта. На обычном блоге авторизованный администратор часто видит страницу без кэша или с особыми служебными заголовками, чтобы не мешать редактированию. На сайте с личным кабинетом, корзиной или персональными данными кэш для авторизованных пользователей обычно ограничивают или отключают.
Проверьте страницу в трёх сценариях:
- в обычном окне браузера, где вы не вошли в WordPress;
- в режиме инкогнито;
- после входа в админку WordPress в другом браузере или профиле.
Если для гостя кэш работает, а для авторизованного пользователя нет — это не всегда ошибка. Важно понять, соответствует ли это логике сайта. Например, для магазина и личного кабинета это часто нормально. А вот для обычной статьи или страницы услуги авторизованный администратор всё равно должен видеть понятный и предсказуемый результат, без случайного обхода кэша из-за лишних cookies.
Если вы тестируете WP Super Cache, обратите внимание на режим работы плагина и исключения. В некоторых конфигурациях он может не кэшировать страницы для вошедших пользователей вообще, а в других — отдавать кэш только для гостей. Это зависит от настроек, темы и дополнительных плагинов.
Как понять, что кэш действительно обновляется после изменений
Проверка «кэш есть или нет» — это только половина задачи. Вторая половина — убедиться, что после изменения контента кэш очищается вовремя. Иначе посетители будут видеть старую версию страницы, хотя вы уже всё обновили.
Сделайте простой тест:
- откройте страницу и зафиксируйте её текущий вид;
- измените заметный элемент — заголовок, текст, цену, дату или изображение;
- сохраните запись;
- очистите кэш плагина, если он не очищается автоматически;
- обновите страницу в режиме инкогнито и проверьте результат.
Если изменения не видны сразу, причина может быть не только в кэше WordPress. Иногда мешает CDN, браузерный кэш, серверный кэш или даже кэш самого хостинга. В такой ситуации важно очищать кэш по слоям: сначала плагин, затем сервер или CDN, если они используются.
Типичные причины, почему кэш «не работает»
На практике чаще всего проблема не в самом кэше, а в настройке или окружении. Вот что стоит проверить в первую очередь.
Страница исключена из кэша
Многие плагины позволяют исключать URL, категории, параметры, cookies или типы страниц. Это полезно для корзины, оформления заказа, личного кабинета, поиска и страниц с формами. Но если в исключения попала обычная статья или главная страница, кэш не будет работать там, где вы его ждёте.
На странице есть динамический контент
Если тема или плагин подставляет персональные блоки, счётчики, корзину, приветствие пользователя или результаты поиска, часть страницы может обходить кэш. Это не всегда ошибка: иногда так и должно быть. Но если динамика встроена в основной шаблон без необходимости, она может мешать кэшированию всей страницы.
Кэш сбрасывается слишком часто
Некоторые сайты очищают кэш при каждом сохранении записи, обновлении виджета, изменении меню или даже при каждом визите администратора. В результате кэш формально включён, но почти не успевает работать. Это особенно заметно на сайтах, где контент часто редактируют несколько человек.
Мешает CDN или серверный кэш
Если на сайте подключён Cloudflare, Nginx FastCGI cache, LiteSpeed Cache на уровне сервера или Varnish, плагин WordPress может быть только частью цепочки. Тогда проверять нужно не только WordPress, но и заголовки CDN или сервера. Бывает и обратная ситуация: плагин показывает, что кэш есть, а CDN продолжает отдавать старую версию страницы.
Браузер показывает старые файлы
Иногда кажется, что не обновился кэш страницы, хотя на деле браузер держит старый CSS или JS. Если после изменений «сломался» дизайн или не применяются новые стили, это уже вопрос браузерного кэша и версионирования файлов, а не HTML-кэша WordPress.
Мини-чек-лист проверки без лишней диагностики
Если нужно быстро понять, всё ли в порядке, пройдитесь по этому списку:
- страница открывается в режиме инкогнито без авторизации;
- при повторной загрузке видны признаки
HIT,Ageили служебные заголовки кэша; - авторизованный пользователь видит ожидаемое поведение, без случайных персональных данных из кэша;
- после изменения записи кэш очищается и новая версия страницы появляется вовремя;
- страницы, которые нельзя кэшировать, действительно исключены;
- если используется CDN или серверный кэш, они тоже проверены.
Если хотя бы один пункт не проходит, не спешите отключать кэш целиком. Сначала найдите, на каком уровне возникает проблема: плагин, сервер, CDN или браузер.
Когда проблема не в кэше
Кэширование ускоряет отдачу готовой страницы, но не исправляет всё подряд. Если сайт медленный из-за тяжёлых изображений, большого количества внешних скриптов, медленной базы данных, неоптимальной темы или перегруженных плагинов, один только кэш даст ограниченный эффект. То же касается слабого хостинга: если сервер не справляется с нагрузкой, сначала нужно смотреть на тариф, PHP-версию, настройки веб-сервера и качество кода.
Для технической чистки WordPress иногда полезно использовать инструменты вроде Clearfy Pro от WPShop — не для самого кэша, а для сопутствующей оптимизации: убрать лишний код, отключить ненужные функции, сократить технический шум на сайте. Подробности можно посмотреть на wpshop.ru, если вам нужен именно такой набор задач. Но подменять этим проверку кэша не стоит: сначала убедитесь, что страницы действительно отдаются из кэша, а уже потом оптимизируйте остальное.
Что делать, если кэш не подтверждается
Если заголовки не показывают кэш, а повторный запрос не меняет поведение, действуйте по порядку:
- очистите кэш плагина и проверьте настройки исключений;
- временно отключите другие плагины оптимизации, минификации и защиты, если они могут вмешиваться;
- проверьте, не включён ли серверный кэш или CDN, который перехватывает ответ;
- сравните поведение для гостя и авторизованного пользователя;
- посмотрите, нет ли на странице cookies, параметров URL или динамических блоков, из-за которых кэш обходится;
- если сайт на управляемом хостинге, уточните у поддержки, есть ли у них отдельный кэш на уровне сервера.
Если после этого кэш всё равно не подтверждается, проблема уже не на уровне «галочки в плагине». Тогда нужно смотреть конкретную конфигурацию сайта: тему, плагины, веб-сервер, CDN и правила исключений. Для сложных проектов, особенно с магазином или личным кабинетом, это лучше делать аккуратно, чтобы не сломать динамические страницы и не показать пользователям устаревший контент.