Админка WordPress «тупит», хостинг пишет, что база раздулась, в поиске советуют «почистить transients», но страшно нажать «удалить всё» и сломать магазин, кэш плагинов или вход в кабинет. Вы не обязаны лезть в SQL: сначала полный бэкап, потом удаление только просроченных записей через плагин или WP-CLI у поддержки хостинга, затем проверка заказа, формы и ключевых плагинов. За 10-15 минут без терминала можно вернуть живую админку и не трогать активные лицензии.
Transients в WordPress — это временный кэш с сроком жизни: плагины кладут туда ответы API, списки и служебные данные, часто в таблице wp_options парами _transient_ и _transient_timeout_. Просроченные строки ядро не всегда убирает сразу — они могут годами лежать в базе и замедлять каждый запрос к админке. Безопасный путь: только expired, не «delete all». С WordPress 4.9 есть delete_expired_transients(), но при Redis или Memcached она может не трогать MySQL — тогда помогает wp transient delete —expired.
Марина ведёт интернет-магазин на WooCommerce: после двух новых плагинов вкладки «Заказы» и «Товары» грузятся по 8-10 секунд. Подруга сказала «почисти transients в базе». Марина открыла плагин оптимизации, увидела кнопку «Delete all transients» и замерла — в прошлый раз после «полной очистки БД» слетели виджеты. Ей нужен был путь: только просроченное, бэкап и проверка корзины. Вы не программист — вам нужна живая админка, а не лекция про wp_options на полчаса.
Transients — не настройки сайта: это записки с датой «действительно до». Срок вышел — запись должна исчезнуть, но часто остаётся до следующего обращения к ключу, отсюда раздутый бэкап и тяжёлые списки в админке.
- Узнайте, почему тормозит админка и при чём тут transients
- Найдите transients в таблице options без паники
- Сравните: что можно удалять, а что нельзя
- Подготовьте бэкап и замерьте объём до клика
- Очистите transients без SSH: плагин и русская админка
- Попросите хостинг выполнить WP-CLI, если в базе остался legacy после Redis
- Проверьте сайт после очистки и зафиксируйте успех
- Настройте профилактику, чтобы мусор не копился снова
- Что сделать дальше
- Частые вопросы
- Можно ли удалять все transients разом?
- Чем transients отличаются от object cache (Redis)?
- Нужно ли чистить transients каждую неделю?
- Влияет ли очистка на витрину для покупателей?
- Почему после очистки transients снова появляются?
- Можно ли чистить через phpMyAdmin?
- Нужен ли отдельный плагин навсегда?
Узнайте, почему тормозит админка и при чём тут transients
Типичная ошибка — списать всё на «много плагинов» и не смотреть в базу. Если в wp_options тысячи строк _transient_, каждый заход в «Заказы» тянет лишний вес. Симптомы: долгая админка после обновлений, рост бэкапа без нового контента. Рядом бывают ревизии и autoload, но expired transients — один из первых безопасных шагов.
Найдите transients в таблице options без паники
В базе без Redis вы увидите пары _transient_{имя} и _transient_timeout_{имя} с UNIX-временем. Не путайте их с настройками темы. Счётчик expired в плагине оптимизации запишите до очистки — так виден эффект, а не ощущение «нажала и непонятно».
Сравните: что можно удалять, а что нельзя
| Действие | Риск для магазина и плагинов | Когда уместно |
|---|---|---|
| Удалить только expired (просроченные) | Низкий: срок уже вышел, данные плагин создаст заново при необходимости | Раз в месяц, после обновления плагинов, при раздутой базе |
| Delete all transients | Высокий: активные лицензии, сессии, кэш API могут сброситься | Почти никогда без инструкции разработчика |
| Полная «очистка БД» в плагине | Может затронуть не только transients | Только с бэкапом и пониманием, что именно чистится |
| wp transient delete —expired (WP-CLI) | Низкий при флаге —expired; —all отдельный рискованный режим | Есть SSH или помощь поддержки хостинга |
Итоговый вердикт: для владельца магазина без программиста держитесь режима «только просроченные». Кнопки «удалить все» из старых плагинов вроде clearalltransients на GitHub — контрастный пример того, чего избегать: они задумывались для другой эпохи и другого стека.
Подготовьте бэкап и замерьте объём до клика
Боль «боюсь сломать плагины» закрывается подготовкой, а не отменой очистки. Сделайте свежий бэкап файлов и базы — через хостинг, UpdraftPlus или ваш привычный сценарий из гайда по автоматическому бэкапу WordPress. Запишите размер базы и число expired, если плагин это показывает.
- Выберите тихое окно: не в пик заказов и не во время массовой рассылки.
- Сохраните бэкап отдельно от сервера, если хостинг позволяет скачать архив.
- Откройте сайт в другой вкладке: главная, одна товарная карточка, корзина — чтобы потом сравнить.
- Выйдите и снова войдите в админку — зафиксируйте, сколько секунд грузится проблемный раздел.
- Только после этого запускайте инструмент очистки в режиме expired.
На практике пропуск бэкапа — главная причина паники после «я нажала не ту кнопку». Даже безопасная очистка не заменяет копию базы. Добавьте в календарь ориентир: раз в месяц сверяйте счётчик expired, а не ждите письма от хостинга. Если хостинг даёт staging, сначала повторите сценарий там: expired на копии, затем те же шаги на боевом сайте в тихий час.
Очистите transients без SSH: плагин и русская админка
Без терминала используйте Delete Expired Transients (wordpress.org), Transient Cleaner или блок в WP-Optimize. Ищите expired / просроченные; избегайте кнопки «удалить все transients».
- Установите один инструмент, не три сразу — иначе не поймёте, кто что удалил.
- Запустите анализ или предпросмотр, если он есть.
- Выберите удаление expired transients и orphaned timeouts (висячие таймауты без данных).
- Дождитесь сообщения об окончании и не жмите второй раз «на всякий случай».
- Откройте тот же экран через день: число просроченных должно быть заметно меньше, если источник мусора не вернулся мгновенно.
Сначала разовая уборка и проверка; cron включайте, когда expired снова копятся из-за редкого расписания, а не сломанного плагина.
Попросите хостинг выполнить WP-CLI, если в базе остался legacy после Redis
С WordPress 4.9 ядро чистит просроченное через delete_expired_transients(), но при Redis или Memcached функция может не трогать MySQL. Legacy-строки снимает wp transient delete —expired. Попросите поддержку хостинга выполнить команду в корне сайта; —all без бэкапа не используйте.
Схема безопасной очистки:
Понять симптом → бэкап → замер expired → удалить только просроченное (плагин или WP-CLI) → проверить вход, заказ, форму → при необходимости еженедельный cron expired
Проверьте сайт после очистки и зафиксируйте успех
Вы поймёте, что очистить transients wordpress удалось без поломки, если выполняются такие критерии:
- Перед очисткой был свежий бэкап, а удалили только expired, не «всё подряд».
- Вход в админку, оформление тестового заказа или отправка формы работают как до процедуры.
- Ключевой плагин (оплата, CRM, доставка) не просит заново лицензию без причины.
- Повторный заход в инструмент очистки показывает меньше просроченных строк, чем до первого запуска.
- Списки заказов или записей открываются быстрее или хотя бы не стали хуже.
Site Health: новые критические ошибки — откат бэкапа. Ревизии чистите отдельным шагом, не в одном клике с transients.
Настройте профилактику, чтобы мусор не копился снова
Lazy deletion: просроченное исчезает при следующем обращении к ключу, иначе лежит годами. Раз в месяц смотрите счётчик expired или cron с wp transient delete —expired. Быстрый рост базы за неделю — повод найти плагин-источник; autoload и ревизии — в общей оптимизации БД.
Что сделать дальше
Не делайте так: не жмите «delete all» ради цифры в отчёте плагина. Шаг workflow на будущее: бэкап → expired → проверка витрины → ориентир в календаре. Нужна помощь с базой и скоростью админки на вашем хостинге — услуги или форма на сайте (мессенджер, без созвона). Ещё материалы: статьи блога, канал t.me/DikiiTelegram.
Материал проверен: Андрей Дикий — создаёт сайты и продвигает их статьями (SEO/GEO).
Источники и проверка: WordPress.org Transients API и delete_expired_transients(), WP-CLI wp transient delete, плагин Delete Expired Transients, материалы Kualo и Tweakswp про lazy deletion и риски «delete all», gist по структуре _transient_ / _transient_timeout_; частотность запросов — по Яндекс Вордстат на 2026-09-29 (MCP недоступен, LSI из SERP).
Частые вопросы
Можно ли удалять все transients разом?
Технически кнопки и —all существуют, но для магазина и платных плагинов это риск: слетают активные кэши и токены. Держитесь режима expired и бэкапа.
Чем transients отличаются от object cache (Redis)?
При Redis данные могут жить в памяти, а не в MySQL, но старые строки в wp_options после миграции часто остаются. Очистка expired в базе и кэш на сервере — разные слои; не путайте «почистил Redis» с «почистил options».
Нужно ли чистить transients каждую неделю?
Не всем сайтам. Если счётчик expired снова растёт быстро — настройте еженедельную задачу или найдите плагин-источник. Стабильный магазин часто достаточно проверять раз в месяц.
Влияет ли очистка на витрину для покупателей?
Обычно слабо: больше страдает админка и тяжёлые списки. После expired-очистки проверьте корзину и кэш фронта (LiteSpeed и аналоги) — один раз, без паники.
Почему после очистки transients снова появляются?
Плагины создают их постоянно — это норма. Проблема в накоплении просроченных, когда cron редкий или object cache не даёт ядру убрать legacy в MySQL.
Можно ли чистить через phpMyAdmin?
Только с бэкапом и безопасным шаблоном DELETE. Новичку проще плагин expired или WP-CLI у хостинга.
Нужен ли отдельный плагин навсегда?
Часто нет: разовая уборка и редкий cron достаточны, если нет плагина, который снова забивает базу.
