В блоге на WordPress обычно кешируют почти все страницы, и это нормально. Проблема начинается там, где одна и та же HTML-страница должна вести себя по-разному для разных посетителей или быстро меняться после отправки формы, входа в админку, предпросмотра записи, поиска или работы виджета с персональными данными. Если такой URL попадает в кеш, пользователь видит устаревший контент, а автор — странные баги, которые сложно повторить.
Ниже разберем, как точечно исключить отдельные страницы из кеширования без отключения кеша на всем сайте. Это полезно для блогов, где важны скорость и стабильность, но есть несколько динамических сценариев, которые нельзя отдавать из статического кеша.
Когда страницу действительно нужно исключать из кеша
Не стоит добавлять в исключения все подряд. Чем больше URL вы выведете из кеша, тем выше нагрузка на PHP и базу. Исключать имеет смысл только те страницы, где HTML зависит от состояния пользователя, времени или запроса.
Типичные сценарии для блога
- страница поиска с персонализированной выдачей или фильтрами;
- страница предпросмотра записи в редакторе WordPress;
- страницы входа, регистрации и восстановления пароля;
- страницы с формами, которые показывают результат сразу после отправки;
- страницы с блоками, зависящими от cookies или авторизации;
- служебные URL плагинов, которые отдают динамический HTML.
Если у вас обычная статья, рубрика или архив, исключать ее из кеша обычно не нужно. Для SEO и скорости это чаще вредно, чем полезно.
Диагностика: как понять, что проблема именно в кеше
Сначала проверьте, действительно ли страница отдается из кеша, а не ломается по другой причине. На практике путаница возникает часто: виноват может быть не кеш, а плагин форм, редирект, CDN или объектный кеш.
Откройте проблемную страницу в режиме инкогнито и сравните ответы сервера в DevTools или через curl. Если в заголовках есть признаки кеша, например cache-control, x-cache, cf-cache-status или аналогичные заголовки вашего плагина/сервера, значит запрос действительно уходит через кеширующий слой.
curl -I https://example.com/problem-page/Ищите не только сам факт кеширования, но и поведение после изменения контента. Если вы обновили страницу, а старый HTML продолжает показываться несколько минут или часов, проблема почти наверняка в слишком агрессивном кешировании или в том, что исключение не сработало.
Пошаговое решение: исключаем отдельные URL из кеша
Есть три рабочих подхода: настройка в плагине кеша, правило на уровне сервера или точечное исключение через код. Выбор зависит от того, чем именно вы кешируете сайт.
1. Добавьте URL в исключения плагина кеша
Если у вас установлен плагин кеширования, начните с его интерфейса. У большинства решений есть список исключаемых страниц, URL или шаблонов. Туда обычно добавляют:
- точный путь, например
/search/или/checkout/; - маску для группы страниц, если плагин это поддерживает;
- отдельные параметры запроса, если проблема в URL с query string.
После сохранения очистите кеш плагина и проверьте страницу в новом приватном окне. Если плагин поддерживает preload, убедитесь, что исключенный URL не попадает в прогрев.
2. Исключите страницу на уровне PHP, если плагин это позволяет
Если плагин кеша умеет читать константы или фильтры, проще всего задать исключение в functions.php дочерней темы или в небольшом mu-plugin. Ниже пример для ситуации, когда нужно отключить кеширование на поиске и на предпросмотре записи.
<?php
add_action( 'template_redirect', function () {
if ( is_search() || is_preview() ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );Это не универсальная магия для любого кеша, но многие плагины и интеграции WordPress ориентируются именно на эту константу. Для служебных страниц ее часто достаточно.
3. Используйте правила сервера для статических исключений
Если кешируется на уровне Nginx, Varnish или reverse proxy, исключение лучше делать там, а не в WordPress. Иначе PHP все равно будет запускаться, а вы просто усложните стек. На практике это особенно важно для страниц входа, поиска и предпросмотра.
Для Apache и Nginx логика разная, но принцип один: не отдавать кеш для конкретного пути или набора путей. Если у вас нет доступа к конфигу сервера, не пытайтесь имитировать это через случайные плагины — лучше ограничьтесь настройкой плагина кеша и проверкой заголовков ответа.
Когда нужен код: исключение по условию, а не по URL
Иногда проблема не в конкретной странице, а в условии. Например, вы хотите отключать кеш только для авторизованных пользователей, для ролей редактора или для страниц с определенным параметром в URL. Тогда нужен код, который ставит запрет на кеширование только в нужный момент.
<?php
add_action( 'template_redirect', function () {
if ( is_user_logged_in() ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );Этот вариант подходит не всегда. Для обычного блога он может слишком сильно снизить пользу кеша, потому что авторизованные пользователи перестанут получать быстрые страницы. Если у вас много редакторов и авторов, лучше ограничить исключение только теми URL, где реально есть персонализация.
Сравнение подходов
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Настройка в плагине кеша | Есть доступ к панели плагина | Быстро, без правок кода | Зависит от возможностей плагина |
PHP-условие через DONOTCACHEPAGE | Нужно исключать по логике WordPress | Гибко, можно точечно | Не все кеширующие слои это учитывают |
| Правило на сервере | Кеш на уровне Nginx/Varnish/CDN | Самый правильный уровень для URL-исключений | Нужен доступ к конфигу |
Проверка результата после внедрения
После настройки не ограничивайтесь визуальной проверкой в браузере. Нужны минимум три теста.
- Откройте страницу в инкогнито и убедитесь, что контент отображается корректно.
- Проверьте заголовки ответа через
curl -Iили DevTools и убедитесь, что страница больше не отдается из кеша. - Измените контент или отправьте форму и проверьте, что результат обновляется сразу, а не после очистки кеша вручную.
Если у вас есть CDN, проверьте еще и его слой. Бывает так, что WordPress уже не кеширует страницу, но CDN продолжает отдавать старую версию.
Частые ошибки и как их исправить
Добавили не тот URL
Часто в исключения попадает не реальный путь, а красивый адрес из меню или редирект. Смотрите именно фактический URL, который отдает сервер. Ошибка в слэше, регистре или параметре запроса ломает правило.
Очистили кеш не везде
Если у вас несколько слоев кеширования, очистка только в плагине не поможет. Проверьте страницу, объектный кеш, CDN и серверный кеш отдельно. Иначе вы будете искать проблему в WordPress, хотя она живет на другом уровне.
Слишком широкое исключение
Иногда в исключения попадает весь раздел блога или все страницы с параметром ?s=. В результате кеш почти не работает, а нагрузка растет. Лучше исключить один конкретный сценарий, чем отключать кеш для половины сайта.
Используют код без проверки условий
Если поставить DONOTCACHEPAGE глобально, вы фактически выключите кеш для всех. Это частая ошибка при копировании фрагментов из форумов. Всегда оборачивайте условие в is_search(), is_preview(), is_user_logged_in() или другое конкретное условие.
Безопасность и производительность: что не стоит делать
Не отключайте кеш «на всякий случай». Для блога это почти всегда удар по TTFB и стабильности под нагрузкой. Если проблема локальная, локальным и должно быть решение.
Если вы правите код, используйте дочернюю тему или mu-plugin, а не файлы основной темы. Так обновление темы не затрет настройку. Перед изменениями сделайте резервную копию и проверьте, что у вас есть доступ к восстановлению, если страница перестанет открываться.
Если вам нужно регулярно чистить блог от дублей, мусорных настроек и лишних служебных страниц, часть задач можно закрыть инструментами вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику исключений лучше понимать и проверять вручную, а не полагаться только на интерфейс.
Мини-чек-лист перед публикацией
- определен точный URL или условие, которое нужно исключить;
- проверен уровень кеша: плагин, сервер, CDN;
- добавлено исключение только для нужной страницы или сценария;
- очищен кеш во всех слоях;
- проверен ответ через
curl -Iили DevTools; - страница обновляется без ручной очистки после изменения контента.
Если после всех проверок страница все еще отдается из кеша, значит исключение задано не там, где реально работает кеширующий слой. В таком случае сначала найдите источник кеша, а уже потом правьте правила.