Clean up expired transients in wp_options

Symptom

BoltAudit reports a large number of _transient_timeout_* rows with timestamps in the past, or autoloaded wp_options size above 1 MB. The transient API's lazy-cleanup model means stale entries linger until someone reads them.

Impact

• Every request loads autoloaded options into memory; bloated transients mean slower request init.
• Particularly bad with WooCommerce and form plugins that store large payloads in transients.
• Mostly invisible in monitoring — but BoltAudit's autoload weight check makes it explicit.

Manual fix

WP-CLI:

CODE0

Or via SQL:

CODE1

Apply Fix

One-click in the dashboard. The fix deletes only expired transients (and their paired timeout rows) — non-expired entries are left in place so any active code that depends on them keeps working.

Long-term

If the same transient is regenerated and re-expired constantly (autoload weight stays high after cleanup), the actual fix is either to switch to an object cache (so transients live in Redis/Memcache) or to disable autoload on large transients via update_option(..., false).