Как очистить transients в WordPress и не сломать кэш сайта

Если сайт начал тянуть старые данные, а после обновления плагина или темы на страницах продолжают всплывать устаревшие блоки, часто проблема не в «битом кэше» как таковом, а в transients. Это временные записи в базе данных, которые WordPress и плагины используют для хранения промежуточных результатов: ответов API, списков постов, фрагментов разметки, служебных данных. Когда их становится слишком много или они не обновляются вовремя, сайт может вести себя странно.

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

Когда transients становятся проблемой

Сами по себе transients — нормальный механизм. Проблема начинается, когда:

• плагин сохраняет слишком много временных записей и не удаляет их после себя;
• после миграции или обновления остаются старые значения, которые уже не соответствуют текущей конфигурации;
• объектный кэш настроен частично: часть данных живёт в базе, часть — в Redis/Memcached, и поведение становится неочевидным;
• в wp_options разрастаются записи с автозагрузкой, что замедляет каждый запрос;
• на сайте видны старые данные, хотя в админке всё уже обновилось.

Типичный симптом — контент в админке свежий, а на фронтенде или в виджетах отображается старое значение. Ещё один признак — медленные запросы к базе, особенно если в таблице wp_options накопились тысячи временных ключей.

Диагностика: что именно мешает

Перед очисткой стоит понять, это действительно transients или проблема в другом слое кэша. Иначе можно удалить временные данные, а старый результат всё равно останется из-за CDN, page cache или object cache.

Проверьте таблицу wp_options

Если есть доступ к базе, начните с поиска transient-записей. В большинстве установок они лежат в wp_options и имеют имена вида _transient_... и _transient_timeout_....

SELECT option_name, LENGTH(option_value) AS size_bytes, autoload
FROM wp_options
WHERE option_name LIKE '\_transient\_%'
ORDER BY size_bytes DESC
LIMIT 20;

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

Отделите transients от page cache

Если после очистки transients страница всё равно показывает старый HTML, значит, дело не в них. Проверьте:

• кэш плагина кеширования страниц;
• серверный кэш на уровне nginx/Apache;
• CDN, если он подключён;
• object cache через Redis или Memcached.

Это важно: очистка transients не должна подменять полноценную проверку всех уровней кэширования.

Как очистить transients безопасно

Есть несколько способов, и выбор зависит от доступа к серверу и масштаба проблемы. Для обычной рабочей среды я бы начинал с самого безопасного варианта — через WP-CLI или через штатный код в админском контексте, если CLI недоступен.

Вариант 1: удалить конкретный transient через код

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

<?php
// Например, в mu-plugin или временно в functions.php дочерней темы.
if ( function_exists( 'delete_transient' ) ) {
    delete_transient( 'my_plugin_remote_data' );
}

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

Вариант 2: массовая очистка через WP-CLI

Если проблема системная и нужно убрать все временные данные, WP-CLI обычно удобнее всего. Команда удаляет только transients, не трогая остальные опции.

wp transient delete --all

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

Вариант 3: очистка через плагин

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

Если вы уже используете Clearfy Pro, у него есть инструменты для чистки сайта и удаления технического мусора, но применять их нужно осознанно: сначала понять, какие данные реально устарели, а какие нужны плагинам для работы.

Пошаговая схема для боевого сайта

1. Сделайте резервную копию базы данных.
2. Проверьте, есть ли object cache и page cache.
3. Определите, какой transient или какой плагин создаёт проблему.
4. Удалите только нужный transient, если ключ известен.
5. Если проблема массовая — очистите все transients через WP-CLI.
6. Сразу после этого проверьте фронтенд, админку и критичные страницы.

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

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

Проверка должна быть не формальной, а практической. Смотрите на то, что было сломано до очистки.

• обновился ли контент на фронтенде;
• исчезли ли старые данные в виджетах и блоках;
• уменьшилось ли число записей _transient_* в базе после повторной генерации;
• не появились ли ошибки в логах плагинов или PHP error log;
• не выросла ли нагрузка на внешние API после очистки.

Если у вас есть доступ к SQL, можно повторно посмотреть количество transient-записей:

SELECT COUNT(*)
FROM wp_options
WHERE option_name LIKE '\_transient\_%';

Важно не ждать, что их станет ноль. WordPress и плагины будут создавать новые временные записи снова — это нормальный рабочий процесс. Задача в том, чтобы убрать устаревшие и проблемные значения, а не запретить механизм целиком.

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

Удалили не только transients, но и полезный кэш

Такое бывает, если использовать слишком агрессивные инструменты очистки. Решение простое: перед массовой чисткой смотрите, что именно удаляет плагин или команда. Если нужен только transient-кэш, не запускайте общую «оптимизацию базы» без понимания последствий.

Проблема вернулась через несколько минут

Значит, источник не устранён. Часто виноват конкретный плагин, который заново создаёт устаревшие данные по старому сценарию. Тогда нужно обновить сам плагин, проверить его настройки или отключить проблемную интеграцию.

После очистки сайт стал медленнее

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

Очистили transients, а страница всё равно старая

Тогда ищите кэш на другом уровне: page cache, CDN, серверный кэш, object cache. Очистка transients не влияет на уже сгенерированный HTML в CDN или на статический кэш страницы.

Что сделать, чтобы проблема не повторялась

Полностью исключить transients нельзя и не нужно. Но можно сократить хаос вокруг них:

• не держать одновременно несколько плагинов, которые решают одну и ту же задачу кэширования;
• после обновления плагинов проверять, не появились ли новые устаревшие ключи;
• не хранить в transients данные, которые должны жить дольше и управляться отдельно;
• следить за размером таблицы wp_options и автозагрузкой;
• для сложных сайтов использовать staging и тестировать очистку там.

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