Если на сайте есть REST API, AJAX-эндпоинты или внешняя интеграция, кэш иногда начинает мешать сильнее, чем помогает. Типичный симптом — в браузере или в приложении приходят старые данные, хотя в админке запись уже обновлена. При этом сам сайт может работать нормально: проблема проявляется только на запросах к /wp-json/ или к кастомным endpoint'ам.
Ниже разберём, как точечно отключить кэш для API-запросов в WordPress, не выключая кэширование всего сайта. Это важнее, чем просто очистить кэш вручную: если запросы динамические, они будут снова и снова попадать в кеширующий слой, пока вы не зададите исключение.
Когда кэш ломает REST API и AJAX
Сначала стоит убедиться, что проблема действительно в кэше, а не в логике самого запроса. Для API это обычно выглядит так:
- в ответе REST API не меняются поля после сохранения записи;
- AJAX-метод возвращает старый HTML-фрагмент или старый статус;
- внешний сервис получает данные с задержкой, хотя WordPress уже сохранил обновление;
- в DevTools видно, что ответ приходит быстро, но содержимое явно неактуально;
- после очистки кэша всё работает, но только до следующего запроса.
Что проверить до правок
Перед изменением кода полезно локализовать слой, который кэширует ответ. Это может быть плагин кэширования страниц, серверный reverse proxy, объектный кэш или CDN. Важно не лечить симптом не тем инструментом.
- Откройте проблемный URL в режиме инкогнито и сравните ответ с обычной сессией.
- Проверьте заголовки ответа в DevTools или через
curl -I. - Посмотрите, не отдает ли сервер заголовки вроде
Cache-Control,Age,X-Cache,CF-Cache-Status. - Временно отключите плагин кэширования и повторите запрос.
Если после отключения плагина ответ стал актуальным, значит исключение нужно делать именно для API-URL или для конкретного типа запроса.
Какие варианты есть: плагин, сервер или код
Для WordPress обычно есть три рабочих подхода. Выбор зависит от того, где именно возникает кэширование.
| Подход | Когда подходит | Минус |
|---|---|---|
| Исключение URL в плагине кэширования | Если кэширует плагин страниц | Нужно вручную поддерживать список путей |
Заголовки no-store / no-cache | Если можно управлять ответом на уровне PHP | Не всегда перекрывает серверный кэш |
| Отключение кэша для конкретного endpoint'а | Если нужен точечный контроль | Требует правки темы, плагина или mu-plugin |
Если у вас обычный плагин кэширования страниц, часто достаточно исключить REST API и AJAX-обработчики. Если же проблема в серверном или CDN-кэше, одного PHP-кода может быть мало — тогда нужно настраивать правила на уровне прокси или панели хостинга.
Пошаговое решение через PHP
Самый практичный способ — отправлять для API-ответов заголовки, запрещающие кэширование, и отдельно отключать кэш для REST-запросов, если это допустимо для конкретного сценария.
1. Добавьте заголовки для REST API
Этот вариант подходит, когда вы контролируете код темы или собственного плагина. Для REST API можно добавить заголовки через фильтр rest_post_dispatch. Это не выдуманный хук: он есть в WordPress и позволяет изменить объект ответа перед отправкой.
<?php
add_filter( 'rest_post_dispatch', function( $result, $server, $request ) {
if ( ! $request instanceof WP_REST_Request ) {
return $result;
}
// Только для нужных маршрутов, например для кастомного API.
$route = $request->get_route();
if ( strpos( $route, '/myplugin/v1/' ) !== 0 ) {
return $result;
}
$result->header( 'Cache-Control', 'no-store, no-cache, must-revalidate, max-age=0' );
$result->header( 'Pragma', 'no-cache' );
$result->header( 'Expires', 'Wed, 11 Jan 1984 05:00:00 GMT' );
return $result;
}, 10, 3 );Здесь важно ограничить действие только своим маршрутом. Не стоит отключать кэш для всего REST API без необходимости: часть запросов может быть безопасно кэшируемой и от этого только выиграет производительность.
2. Отключите кэширование для AJAX-обработчика
Если у вас admin-ajax.php или отдельный endpoint, можно отправлять заголовки прямо в обработчике. Это особенно полезно для запросов, где ответ зависит от авторизации, nonce или состояния сессии.
<?php
add_action( 'wp_ajax_my_dynamic_data', 'my_dynamic_data_handler' );
add_action( 'wp_ajax_nopriv_my_dynamic_data', 'my_dynamic_data_handler' );
function my_dynamic_data_handler() {
nocache_headers();
$data = array(
'time' => current_time( 'mysql' ),
'user' => get_current_user_id(),
);
wp_send_json_success( $data );
}Функция nocache_headers() — штатная, и для таких задач она подходит лучше, чем ручная сборка заголовков. Но если ответ уже перехватывается на уровне CDN, этого может быть недостаточно.
3. Исключите URL в плагине кэширования
Если вы используете плагин кэширования страниц, найдите раздел исключений и добавьте туда:
/wp-json/— если API не должен кэшироваться вообще;- конкретный маршрут, например
/wp-json/myplugin/v1/data; /wp-admin/admin-ajax.php— если плагин вообще пытается его кэшировать, что бывает не всегда, но проверить стоит.
В некоторых плагинах можно задать исключения по маске URL или по фрагменту пути. Это удобнее, чем отключать кэш для всего сайта.
Если нужен контроль через код темы или mu-plugin
Для стабильности лучше вынести такую логику не в functions.php активной темы, а в mu-plugin. Тогда исключение не пропадёт после смены темы и не затеряется при обновлении.
<?php
/**
* Plugin Name: API Cache Exceptions
*/
add_action( 'send_headers', function() {
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
$uri = $_SERVER['REQUEST_URI'] ?? '';
if ( strpos( $uri, '/wp-json/myplugin/v1/' ) !== false ) {
nocache_headers();
}
}
} );Этот вариант грубее, чем фильтр rest_post_dispatch, но иногда удобен, если нужно быстро закрыть проблему на уровне всего маршрута. Для точной настройки всё же лучше работать через REST-фильтр и конкретный endpoint.
Проверка результата после внедрения
После правок важно не ограничиваться визуальной проверкой в браузере. Нужен тест, который покажет, что ответ действительно больше не берётся из кэша.
- Сделайте запрос к endpoint'у два раза подряд и сравните ответ.
- Проверьте заголовки: для отключённого кэша не должно быть признаков хранения ответа на стороне промежуточного кэша.
- Если используете CDN, посмотрите его служебные заголовки и статус кэширования.
- Обновите данные в админке и сразу повторите API-запрос без ручной очистки кэша.
Для быстрой проверки удобно использовать curl:
curl -I https://example.com/wp-json/myplugin/v1/data
curl https://example.com/wp-json/myplugin/v1/dataЕсли ответ меняется сразу после сохранения данных, а заголовки не показывают кэширование, значит исключение работает. Если же ответ всё равно старый, ищите кэш на другом уровне: сервер, CDN, объектный кэш или сам плагин интеграции.
Частые ошибки и как их исправить
Отключили кэш слишком широко
Самая частая ошибка — выключить кэш для всего /wp-json/, хотя проблемен только один маршрут. В результате вы теряете производительность на всех API-запросах. Лучше сузить правило до конкретного namespace или endpoint'а.
Добавили заголовки, но CDN их игнорирует
Некоторые CDN и reverse proxy могут хранить ответ, если правило уже задано на их стороне. Тогда PHP-заголовки не решают проблему полностью. Нужно проверить настройки кэша на сервере и в панели CDN, а не только в WordPress.
Использовали admin-ajax.php для всего подряд
AJAX через admin-ajax.php удобен, но для часто вызываемых публичных запросов он не всегда лучший вариант. Если запросов много, лучше вынести их в REST API и отдельно управлять кэшированием и заголовками.
Забыли про авторизацию и nonce
Если endpoint возвращает персональные данные, отключение кэша само по себе не делает его безопасным. Проверяйте права доступа, nonce и контекст пользователя. Иначе вы просто ускорите утечку данных, если логика проверки написана с ошибкой.
Практические советы по безопасности и производительности
Точечное отключение кэша — это компромисс. Чем меньше область исключения, тем лучше для скорости сайта. Поэтому полезно придерживаться нескольких правил:
- не отключайте кэш для публичных неизменяемых данных;
- для динамики используйте отдельные endpoint'ы, а не переиспользуйте один маршрут для всего;
- для ответов с персональными данными всегда отправляйте
nocache_headers()и проверяйте права; - если API вызывается часто, подумайте о серверной оптимизации, а не только об исключениях в плагине;
- после обновления плагина кэширования повторно проверьте список исключений — он может сброситься или измениться по формату.
Если на сайте уже есть плагин для технической чистки и SEO-оптимизации, например Clearfy Pro, имеет смысл проверить, не конфликтуют ли его настройки с вашим кэш-плагином. Но саму логику API-кэша всё равно лучше держать в отдельном коде и тестировать на конкретном маршруте.
В итоге рабочая схема обычно такая: определить проблемный endpoint, ограничить исключение только им, добавить правильные заголовки, проверить ответ через curl и убедиться, что сервер или CDN не перехватывают кэширование поверх WordPress.