Ситуация типичная: запись в админке уже отредактирована, а на сайте по-прежнему открывается старая версия страницы. Иногда меняется только заголовок, иногда — текст, а иногда кеш не сбрасывается вообще. В случае с WP Super Cache проблема обычно не в самом плагине, а в том, что событие обновления контента не приводит к очистке нужных файлов или очистка срабатывает не там, где ожидается.
Ниже — практический разбор: как диагностировать причину, как настроить сброс кеша на обновление записи и как проверить, что всё работает без лишней нагрузки на сайт.
Когда проблема действительно в кеше
Сначала стоит убедиться, что вы смотрите именно на кешированную страницу, а не на другой источник задержки. Иногда старый контент отдает CDN, браузер, серверный кеш или даже оптимизатор HTML. Если сразу менять настройки WP Super Cache, можно потратить время впустую.
Признаки, что кеш не обновился
- в админке запись сохранена, но на фронтенде видна старая версия;
- после ручной очистки кеша страница обновляется;
- проблема повторяется только для части страниц, а не для всего сайта;
- в режиме инкогнито и обычном окне результат одинаково старый;
- в заголовках ответа есть признаки кеширования, а HTML не меняется.
Что проверить до правок в коде
- не включен ли отдельный серверный кеш на nginx, LiteSpeed или у хостинга;
- не стоит ли CDN с собственным кешем HTML;
- не использует ли тема или плагин отложенную подгрузку контента через AJAX;
- не меняется ли запись через кастомный тип записи, который не попадает под стандартный сброс кеша.
Почему WP Super Cache может не очищать нужную страницу
WP Super Cache умеет очищать кеш при сохранении записи, но в реальных проектах этого часто недостаточно. Причины обычно такие:
- контент обновляется не через стандартное сохранение записи, а через импорт, REST API или кастомный обработчик;
- страница зависит от связанных сущностей: рубрики, метки, произвольного поля, блока с выводом последних записей;
- кеш очищается только для текущей записи, а список, главная или архив остаются старыми;
- включены дополнительные уровни кеша, которые не сбрасываются вместе с WP Super Cache;
- плагин очистки или минификации вмешивается в заголовки и поведение страницы.
Если у вас именно такой сценарий, лучше не пытаться “лечить” проблему частой полной очисткой кеша. Это ухудшает производительность и маскирует источник ошибки.
Пошаговое решение: сбрасывать кеш при обновлении записи
Самый надежный вариант — привязать очистку кеша к событию сохранения записи и явно указать, какие URL нужно сбрасывать. Для обычных постов этого часто достаточно, но при наличии архивов и связанных страниц список лучше расширить.
Вариант 1. Очистка кеша через сохранение записи
Добавьте код в мини-плагин или functions.php дочерней темы. Так вы не потеряете логику при обновлении темы.
<?php
add_action( 'save_post', 'wpsc_clear_cache_on_post_update', 20, 3 );
function wpsc_clear_cache_on_post_update( $post_id, $post, $update ) {
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
if ( ! $update ) {
return;
}
if ( ! in_array( $post->post_type, array( 'post', 'page' ), true ) ) {
return;
}
if ( function_exists( 'wp_cache_post_change' ) ) {
wp_cache_post_change( $post_id );
}
if ( function_exists( 'wp_cache_clear_cache' ) ) {
wp_cache_clear_cache();
}
}Здесь используются реальные функции WP Super Cache. wp_cache_post_change() помогает отметить изменение записи, а wp_cache_clear_cache() очищает кеш. В некоторых конфигурациях этого достаточно, чтобы обновилась не только сама запись, но и связанные страницы.
Вариант 2. Сбрасывать кеш для конкретных URL
Если у вас большой сайт, полная очистка кеша после каждой правки — плохая идея. Лучше сбрасывать только нужные страницы: саму запись, главную, архив рубрики или страницу, где выводится связанный блок.
<?php
add_action( 'save_post', 'wpsc_clear_related_urls_on_update', 20, 3 );
function wpsc_clear_related_urls_on_update( $post_id, $post, $update ) {
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
if ( 'post' !== $post->post_type ) {
return;
}
if ( function_exists( 'wp_cache_post_change' ) ) {
wp_cache_post_change( $post_id );
}
$urls = array(
get_permalink( $post_id ),
home_url( '/' ),
);
$categories = get_the_category( $post_id );
if ( ! empty( $categories ) ) {
foreach ( $categories as $category ) {
$urls[] = get_category_link( $category->term_id );
}
}
foreach ( array_unique( $urls ) as $url ) {
if ( function_exists( 'wp_cache_clear_url_cache' ) ) {
wp_cache_clear_url_cache( $url );
}
}
}Функция wp_cache_clear_url_cache() есть не во всех сценариях и версиях окружения, поэтому перед использованием важно проверить, что она доступна в вашей установке. Если её нет, оставайтесь на wp_cache_clear_cache() или используйте очистку через админку WP Super Cache.
Если обновление идет не через обычное сохранение
На практике контент часто меняется не руками редактора, а через импорт, синхронизацию или REST API. В этом случае save_post может не сработать так, как вы ожидаете, либо сработает только частично.
Импорт и массовое обновление
Если записи обновляются пачкой, не очищайте кеш на каждом сохранении без разбора. Лучше после завершения импорта вызвать одну очистку кеша. Это можно сделать в конце собственного скрипта или обработчика.
<?php
if ( function_exists( 'wp_cache_clear_cache' ) ) {
wp_cache_clear_cache();
}Для массовых операций это безопаснее, чем десятки или сотни отдельных сбросов. Но если сайт большой, лучше ограничить очистку конкретными разделами, а не всем кешем целиком.
Обновление через REST API
Если запись меняется через REST API, проверьте, вызывается ли стандартная логика обновления поста. Иногда данные пишутся в метаполя или кастомные таблицы, а кеш страницы остается прежним. В таком случае нужно повесить очистку на тот код, который реально завершает обновление данных.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по повторяемому сценарию. Иначе легко перепутать обновление кеша с обычной перезагрузкой страницы.
- Откройте нужную страницу в режиме инкогнито.
- Сохраните запись с заметным изменением, например замените один заголовок или абзац.
- Обновите страницу на фронтенде без очистки браузерного кеша.
- Проверьте, что HTML изменился именно после сохранения записи.
- Если используется CDN, очистите и его кеш отдельно и сравните результат.
Полезно также посмотреть заголовки ответа. Если сервер отдает старую версию HTML, проблема все еще в кешировании. Если HTML новый, а на экране старое содержимое, значит мешает не кеш страницы, а другой слой — например, JS, который подменяет блоки после загрузки.
Что смотреть в заголовках
Cache-Control— не слишком ли агрессивный срок жизни;Age— отдает ли промежуточный кеш старый ответ;X-Cacheили аналогичный заголовок CDN/прокси;- наличие разных версий ответа для авторизованного и гостевого пользователя.
Частые ошибки и как их исправить
Очищают кеш на каждом сохранении без фильтрации
Это приводит к лишней нагрузке и постоянному прогреву кеша. Исправление простое: исключите автосохранения, ревизии и неподходящие типы записей. Для массовых операций делайте один сброс в конце процесса.
Ожидают, что WP Super Cache сбросит всё сам
Плагин работает в рамках своей логики, но не знает о ваших кастомных архивах, блоках и внешних источниках данных. Если страница собирается из нескольких сущностей, нужно явно перечислить связанные URL для очистки.
Не учитывают CDN и серверный кеш
Даже идеальная настройка WP Super Cache не поможет, если старый HTML продолжает отдавать CDN или reverse proxy. В таких случаях очистка должна идти по всей цепочке: WordPress, сервер, CDN.
Ставят очистку в неподходящий хук
Если код срабатывает слишком рано, данные еще не сохранены. Если слишком поздно — кеш уже успел отдать старую версию. Для стандартных записей обычно достаточно save_post с проверкой ревизий и автосохранений.
Сравнение подходов: плагин, код, ручная очистка
| Подход | Когда подходит | Минус |
|---|---|---|
| Ручная очистка из админки | Редкие правки на небольшом сайте | Легко забыть, не масштабируется |
| Очистка через код | Регулярные обновления контента, кастомные сценарии | Нужно аккуратно поддерживать логику |
| Полный сброс кеша после каждого изменения | Только для отладки или очень маленьких сайтов | Сильно бьет по производительности |
Если сайт живой и контент обновляется часто, кодовый вариант обычно надежнее. Он дает контроль над тем, что именно сбрасывается, и не заставляет каждый раз прогревать весь кеш заново.
Практические советы по безопасности и производительности
Не кладите такой код в основной файл темы, если тема часто меняется. Лучше оформить маленький mu-plugin или отдельный плагин для технических правок. Так вы не потеряете настройку при обновлении шаблона.
Если на сайте много контента, избегайте полного сброса кеша на каждое изменение. Это особенно важно для новостных сайтов, блогов и каталогов. Сначала попробуйте точечную очистку: запись, главная, рубрика, связанные архивы.
Если вам нужно регулярно чистить дубли, мусорные страницы и технические хвосты, имеет смысл посмотреть в сторону инструментов для технической оптимизации, например Clearfy Pro от WPShop: https://wpshop.ru/plugins/clearfy. Но это не замена корректной логике очистки кеша — только вспомогательный инструмент для чистки и SEO-настроек.
Короткий чек-лист перед публикацией правки
- исключены ревизии и автосохранения;
- проверен тип записи, для которого срабатывает очистка;
- понятно, какие URL должны сбрасываться вместе с записью;
- отдельно учтен CDN или серверный кеш;
- проверка выполнена в инкогнито и после реального сохранения записи;
- не используется без необходимости полный сброс кеша.
Если после этого страница все еще не обновляется, проблема почти наверняка лежит не в WP Super Cache как таковом, а в другом слое кеширования или в том, как именно меняется контент. В таких случаях помогает не расширять очистку наугад, а пройти цепочку от сохранения записи до ответа сервера и найти, где именно остается старая версия.