Safely Cleaning WordPress Transients with WP-CLI

What Are WordPress Transients and Why Do They Accumulate?

A transient is a temporary value with an expiration period. WordPress stores it under a separate key and returns it to a plugin or theme until it expires. For example, transients can be used to cache exchange rates, external API responses, product lists, complex query results, or widget data.

Without a persistent object cache, transients are generally stored in the wp_options table. For each value, WordPress may create a primary record and a separate metadata record containing the expiration time. A large number of these records increases the table size, complicates database maintenance, and may add unnecessary operations when working with options.

Important: a large number of transients does not always indicate a problem. Some may still be valid, while the actual slowdown may be caused by a specific plugin, a caching error, or the overly frequent creation of unique keys.

• caching responses from external services and APIs;
• temporarily storing the results of expensive SQL queries;
• caching page fragments or widget data;
• storing service values while plugins are running.

Why You Should Not Delete Transients with Direct SQL

Deleting rows directly from wp_options may seem like a quick solution, but it bypasses the WordPress API. As a result, you could remove valid values, service keys, or records that a plugin is still using. Another risk is an incorrect SQL filter that affects not only transients but also other site settings.

Transient key names may use prefixes belonging to specific plugins, while the format and creation logic vary. Even when a record has expired, it is better to remove it through WP-CLI or WordPress functions rather than relying on the internal structure of the table.

SQL may be appropriate during a specialized recovery or migration procedure when you have a current backup, a rollback plan, and a clear understanding of the data structure. It should not be the default method for routine site maintenance.

• do not delete all records matching _transient_% without verification;
• do not run cleanup on a production site without a backup or a way to restore it;
• do not confuse transients with regular plugin settings stored in wp_options.

Preparing to Clean Transients with WP-CLI

Before running the command, verify that WP-CLI works in the WordPress installation directory and has access to the required site and database. On a server hosting multiple sites, make sure you do not confuse the document root or configuration of a particular environment.

Back up the database, or confirm that you have a recent copy from which the site can be restored. This is especially important before deleting all transients, because plugins will start rebuilding their caches afterward.

Before cleanup, it is useful to record baseline metrics: response time, PHP errors, server load, and the number of records. This helps determine whether the procedure actually improved the situation rather than simply changing the symptoms.

• verify SSH access and that the wp command works;
• make sure the command targets the correct WordPress site;
• if possible, schedule the operation for a period of lower traffic;
• inform the team if cleanup is expected to cause a temporary increase in API requests.

wp --info
wp core is-installed
wp transient list --fields=name,expiration --format=table

How to Delete Only Expired Transients

For a cautious standard cleanup, use the command that removes only transients whose expiration time has passed:

This is the best first step when you see temporary records accumulating but have no reason to reset the entire cache. Valid values remain available, so the number of repeated API requests and cache rebuilds will be lower.

After running the command, review its output and check how the database size, response time, and error logs have changed. If expired records reappear quickly, the problem may not be the cleanup itself but a plugin that creates too many unique keys.

• run the command with the permissions of a user who can access the required WordPress site;
• avoid interrupting the process unnecessarily on a large database;
• after cleanup, check key pages, forms, the cart, authentication, and features that depend on APIs.

wp transient delete --expired

When Is It Appropriate to Delete All Transients?

A complete deletion may be used during diagnostics, after changing the caching configuration, before a migration, or when temporary data must be rebuilt from scratch. The command removes all transients, not only those that have expired:

The site does not lose permanent WordPress settings, but plugins and the theme must recreate their caches. Initial requests may require more processing: they may call external APIs, run complex SQL queries, or generate page data.

Do not schedule a complete cleanup at a fixed cron interval without analyzing the consequences. If the cache is deleted every hour or every day, the system will constantly operate in rebuild mode instead of using already prepared values. This can increase the load on PHP, MySQL, and third-party APIs.

• use the command only after assessing its impact on the site;
• do not run it at the same time as large imports, email campaigns, or peak traffic campaigns;
• after cleanup, monitor errors, response time, and the number of requests to external services.

wp transient delete --all

What Changes When Redis or Another Object Cache Is Used?

If Redis, Memcached, or another persistent object cache is configured on the server, transients may be handled differently than in the standard setup where they are stored only in MySQL. Some data may reside in the object cache, while the database may not provide a complete picture.

The wp transient delete command works through the WordPress API, making it safer than manually clearing database tables. However, the exact behavior depends on the object-cache implementation and plugin configuration. Do not automatically clear all of Redis with a command such as FLUSHALL: it could delete the cache of other sites, services, or applications on the same server.

If values continue to reappear after transients are deleted, check the object-cache settings, key prefixes, and logs. Sometimes old data remains in a separate caching layer; in other cases, a plugin recreates it during the first request.

• confirm whether a persistent object cache is enabled;
• do not clear all of Redis without confirming the boundaries of the specific site;
• check whether page caching, a CDN, or a proxy-level cache is also active;
• review PHP and Redis logs if the result differs from what you expected.

wp plugin list --status=active
wp transient list --format=count

Verifying the Result and Finding the Cause of Repeated Accumulation

Cleaning transients does not fix the reason they were created. If the database grows quickly again after the procedure, identify the plugin or theme creating the records. Useful indicators include the same key prefix, a large number of unique names, and records that are constantly created with a short expiration period.

Check the PHP log for timeout errors, API problems, and repeated requests. For stores and sites with external integrations, monitor API limits separately: after a complete cleanup, many simultaneous visitors may trigger a wave of identical requests.

Evaluate the result not only by the number of deleted records. More important indicators include the stability of site features, response time, PHP and database load, the number of errors, and how quickly the cache is repopulated.

• compare the site state before and after cleanup;
• check pages that use external integrations;
• see whether the number of identical requests increases after the cache reset;
• if transients return too quickly, inspect the relevant plugin's code or settings.

Common Cleanup Mistakes

The most common mistake is performing a complete cleanup instead of removing only expired values. For routine maintenance, start with --expired and reserve --all for justified cases.

The second mistake is expecting the site to become faster immediately. If the problem is caused by a slow plugin, an inefficient query, or an overloaded API, deleting transients only removes the cache and may temporarily increase the load.

The third mistake is setting up a regular cron job that unconditionally deletes all transients. Expired-data cleanup can be automated, but its effect should still be monitored, and the process should not run more often than the actual accumulation justifies.

• do not use a direct DELETE query on wp_options as the first method;
• do not clear the entire object cache without understanding its boundaries;
• do not ignore backups and logs;
• do not evaluate optimization solely by the size of the wp_options table.