Как отключить кэш для admin и визуального редактора в WordPress

Если на сайте включён кэш, но в админке появляются старые данные, не обновляется предпросмотр записи или визуальный редактор ведёт себя странно, проблема часто не в самом WordPress, а в том, что кэширование затронуло лишние URL и запросы. Для публичной части сайта кэш полезен, но для /wp-admin/, wp-login.php, REST API и страниц предпросмотра он обычно только мешает.

Ниже разберём, как понять, что именно кэшируется неправильно, где это отключать в популярных плагинах и как сделать точечное исключение на уровне кода, если плагин не даёт нужной гибкости.

Когда проблема действительно в кэше

Симптомы обычно повторяются по одному сценарию: вы сохраняете запись, а на фронтенде или в редакторе видите старую версию; после выхода из аккаунта всё выглядит нормально; в режиме инкогнито страница обновляется, а в обычной вкладке — нет. Ещё один частый признак — предпросмотр черновика открывается с ошибкой, а REST-запросы в редакторе Gutenberg возвращают устаревший ответ или 403/500 после агрессивной оптимизации.

Что проверить первым делом

• Отключается ли проблема после очистки кэша плагина и CDN.
• Повторяется ли ошибка только для авторизованного пользователя.
• Есть ли в ответах заголовки X-Cache, CF-Cache-Status, Age или аналогичные признаки отдачи из кэша.
• Не кэшируется ли /wp-admin/, /wp-json/, ?preview=true и страницы входа.
• Не включено ли minify/combining JS/CSS, которое ломает редактор или панель управления.

Какие URL и запросы нельзя кэшировать

Для большинства сайтов достаточно исключить административную часть, авторизацию, REST API и страницы предпросмотра. Если этого не сделать, кэш может отдавать устаревшие nonce, ломать формы, мешать сохранению блоков и показывать неактуальные данные в редакторе.

Что исключить	Почему	Типичное решение
/wp-admin/	Админка должна быть динамической	Не кэшировать вообще
wp-login.php	Форма входа зависит от сессии и nonce	Исключить из page cache
/wp-json/	REST API нужен редактору и плагинам	Не трогать page cache, проверить заголовки
?preview=true	Предпросмотр должен показывать черновик	Снять кэширование для query string

Настройка в плагине кэширования

В большинстве плагинов логика одна и та же: есть список URL-исключений, отдельные правила для cookies и возможность не кэшировать авторизованных пользователей. Названия пунктов отличаются, но смысл одинаковый.

Если используется WP Super Cache

В WP Super Cache проверьте, что кэш для авторизованных пользователей отключён, а страницы входа и админка не попадают в статический кэш. Для этого обычно достаточно стандартных настроек плагина и списка исключений. Если на сайте есть нестандартные шаблоны предпросмотра или отдельные AJAX-эндпоинты, их тоже нужно вывести из кэширования.

Если используется другой плагин

В плагинах вроде LiteSpeed Cache, WP Rocket, Cache Enabler или аналогах ищите настройки типа Never cache URLs, Exclude pages, Do not cache cookies, Cache logged-in users. Не включайте кэш для авторизованных пользователей без явной необходимости: это часто приводит к тому, что редактор видит чужие данные или устаревшие nonce.

Точечное исключение через код

Если плагин не умеет исключать конкретный запрос, можно добавить проверку на уровне темы или mu-plugin. Это полезно, когда нужно отключить кэш для отдельных сценариев: предпросмотр, REST-запросы, пользовательские AJAX-обработчики.

<?php
/**
 * Plugin Name: Cache exclusions for admin and preview
 */

add_action( 'init', function () {
    if ( is_admin() ) {
        return;
    }

    if ( isset( $_GET['preview'] ) && 'true' === $_GET['preview'] ) {
        if ( ! defined( 'DONOTCACHEPAGE' ) ) {
            define( 'DONOTCACHEPAGE', true );
        }
    }

    if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
        if ( ! defined( 'DONOTCACHEPAGE' ) ) {
            define( 'DONOTCACHEPAGE', true );
        }
    }
} );

Этот код не «отключает кэш везде», а только помечает отдельные запросы как не подлежащие page cache. Для большинства плагинов этого достаточно, но если кэширование идёт на уровне сервера или CDN, нужны ещё правила в конфигурации веб-сервера или панели CDN.

Если кэш ломает редактор Gutenberg

Когда редактор блоков начинает зависать, не сохраняет изменения или показывает ошибки загрузки, проблема часто в оптимизации JavaScript, а не в page cache. Особенно это заметно, если плагин объединяет скрипты, откладывает загрузку критичных файлов или вмешивается в REST API.

Что обычно помогает:

• отключить combine/minify для wp-admin и редактора;
• не откладывать загрузку скриптов, связанных с Gutenberg и wp-api-fetch;
• проверить, не режет ли кэш заголовки no-cache и no-store для админских запросов;
• очистить кэш после изменения настроек, а не только после публикации записи.

Пошаговое решение

1. Очистите весь кэш: плагин, серверный кэш, CDN.
2. Проверьте, кэшируются ли /wp-admin/, wp-login.php, /wp-json/ и предпросмотр.
3. Добавьте исключения для этих URL в настройках плагина.
4. Если нужно, добавьте проверку DONOTCACHEPAGE для предпросмотра и REST-запросов.
5. Отключите агрессивную оптимизацию JS/CSS для админки и редактора.
6. Снова проверьте поведение в обычной вкладке и в инкогнито.

Как проверить, что всё сработало

Проверка должна быть не «на глаз», а по конкретным признакам. Откройте страницу в обычной вкладке и в инкогнито, затем сравните заголовки ответа и поведение после сохранения записи.

• После публикации страница обновляется без ручной очистки всего кэша.
• Предпросмотр черновика показывает актуальный контент.
• В админке не появляется старое значение мета-полей и блоков.
• REST API отвечает без ошибок, а редактор не теряет соединение.
• Заголовки ответа для админки и предпросмотра не содержат признаков page cache.

Для быстрой проверки можно использовать curl:

curl -I https://example.com/wp-login.php
curl -I 'https://example.com/?preview=true'
curl -I https://example.com/wp-json/

Если в ответах видны заголовки кэша там, где их быть не должно, значит исключения настроены не полностью.

Частые ошибки и как их исправить

Кэш очищают, но не исключают URL

Это самая частая ошибка. Очистка решает проблему только временно: следующий запрос снова попадёт в кэш. Нужен именно список исключений, а не ручное «обнуление» после каждого изменения.

Исключают только страницу входа

Этого мало. Если в кэш попадает /wp-json/ или предпросмотр, редактор и формы могут продолжать ломаться даже при корректной странице логина.

Включают кэш для авторизованных пользователей

На новостных и корпоративных сайтах это почти всегда лишнее. Авторизованный пользователь видит персональные данные, а кэш может подменять их чужими или устаревшими значениями.

Смешивают page cache и object cache

Redis или Memcached не заменяют page cache и наоборот. Если проблема в предпросмотре или админке, сначала исключайте page cache и оптимизацию фронтенд-скриптов, а уже потом трогайте object cache.

Что делать для безопасности и производительности

Не отключайте кэш глобально ради удобства редактирования. Правильнее сузить исключения до тех URL и запросов, которые действительно должны оставаться динамическими. Это сохраняет скорость на фронтенде и не ломает админку.

Если вы ведёте сайт на нескольких редакторах, имеет смысл документировать список исключений в репозитории или хотя бы в заметке для команды: так настройки не потеряются после обновления плагина. Для сайтов с активной публикацией полезно отдельно проверить, как кэш ведёт себя после смены темы, обновления плагинов и включения CDN.

Если нужен более широкий набор инструментов для чистки дублей, управления SEO-метками и технической оптимизации, иногда удобнее закрыть часть задач одним плагином, чем держать несколько конфликтующих решений. Но принцип остаётся тем же: сначала понять, что именно кэшируется, потом исключить только проблемные сценарии.