If your WordPress site feels sluggish even after a caching plugin and a CDN, the problem might not be your theme or your host. It might be sitting inside your database. A proper WordPress database cleanup removes years of leftover revisions, spam comments, expired transients, and orphaned metadata that MySQL has to scan through on every single page load.
This guide is an evergreen, practical how-to, not breaking news. It walks you through a safe, step-by-step WordPress database cleanup you can run today, whether your site has 20 posts or 20,000.
This is written for site owners and admins who manage their own WordPress install, whether that’s one blog or a handful of client sites. If you’re on a fully managed host that already optimizes databases for you, some of these steps may be redundant, and your host’s support team can confirm that before you duplicate the work.
What a WordPress Database Cleanup Actually Does
A WordPress database cleanup is the process of removing data your site no longer needs from its MySQL (or MariaDB) tables. That includes old post revisions, spam comments, expired transients, orphaned post meta, and unused term relationships.
None of that data shows up on your site. But every row still has to be read, indexed, and scanned by queries on the back end. A bloated database means slower admin screens, slower page generation, and in some cases, timeouts on shared hosting.
This is different from the page-speed work covered in Core Web Vitals guides. Those focus on what loads in the browser. A WordPress database cleanup focuses on what happens on the server before a single byte reaches the browser.
Why Your Database Slows Down Over Time
WordPress autosaves a revision every time you edit a post, by default every 60 seconds while you’re typing. A post edited 40 times over its life can easily carry 40 extra rows in wp_posts.
Plugins add to this. Many write transients (temporary cached data) into wp_options and never clean them up if they’re deactivated improperly. Contact form plugins, SEO plugins, and page builders are common offenders.
Comments add more weight. Spam caught by Akismet or similar tools still sits in your database until you empty it. On a site that gets hundreds of spam attempts a day, that table can grow into the tens of thousands of rows within a year.
None of this is a WordPress core flaw. It’s just the natural result of years of content, plugins, and visitor activity. A periodic WordPress database cleanup is routine maintenance, similar to clearing cache or updating plugins.
How to Measure the Impact Before and After
Before you run a WordPress database cleanup, it helps to have a baseline. Install Query Monitor (free) and check the admin footer for total database query time on a typical page load. Write that number down.
Run the same check again after each major step, especially after Step 5 (optimizing tables) and Step 6 (auditing autoloaded options). Those two steps tend to produce the most visible change in query time, since they affect how much data MySQL has to read on every request.
You don’t need a dramatic drop to call it a success. Even shaving 50 to 150 milliseconds off database query time on every page load adds up across thousands of monthly visits, and it reduces the load on your server during traffic spikes.
Before You Start: Back Up Your Database
Do not skip this step. Every step below modifies or deletes rows in your live database, and a mistake in a manual SQL query can break a site in seconds.
Take a full database backup before you touch anything. Your host likely offers one-click backups in its control panel. If not, a plugin like UpdraftPlus or Duplicator can export a .sql file you can download and store safely.
If you’re comfortable with the command line, wp db export WP-CLI can create a backup in seconds. Either way, confirm the backup file actually downloaded and opens before you proceed with the cleanup.
Step 1: Remove Excess Post Revisions
Post revisions are the single biggest source of database bloat on content-heavy sites. WordPress keeps every autosave by default, with no built-in limit.
To check how bad it is, a simple query shows the count:
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';
It’s common to see this number in the thousands on a site that’s been live for a few years. To trim revisions as part of this WordPress database cleanup, you have three safe options.
Three ways to handle revisions
First, a plugin such as WP-Optimize or Advanced Database Cleaner gives you a one-click button to delete revisions, with a preview of how many rows will be removed.
Second, WP-CLI users can run wp post delete $(wp post list --post_type='revision' --format=ids) to clear every revision in one command.
Third, to stop the problem from coming back, add this line to wp-config.php: define('WP_POST_REVISIONS', 5);. This caps revisions per post at five instead of unlimited, which keeps future bloat under control without disabling the feature entirely.
Step 2: Delete Spam and Trashed Comments
Spam and trashed comments sit wp_comments indefinitely unless you empty them manually. WordPress does not auto-delete trashed comments after a set period in most default configurations.
From your dashboard, go to Comments, filter by Spam, and click Empty Spam. Repeat for the Trash filter. On a site with a lot of history, this alone can remove tens of thousands of rows.
If Akismet is active, also check its settings to confirm it’s set to delete the spam it catches after a reasonable window, such as 15 days, instead of holding it forever.
Step 3: Clear Expired Transients
Transients are WordPress’s built-in temporary cache, stored as rows in wp_options with an expiration timestamp. In theory they expire and get cleaned up automatically. In practice, many plugins create transients that never expire properly, especially after a plugin is deactivated or a site changes hosting.
You can check for stuck transients with: SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_%';.
A plugin like WP-Optimize includes a dedicated “clean transients” action. Alternatively, WP-CLI’s wp transient delete --expired command clears only the ones past their expiration date, which is the safer option if you’re not sure what’s currently in use.
Step 4: Clean Up Orphaned Metadata
Orphaned data is metadata left behind after its parent object (a post, a comment, a user) was deleted, but the related rows in wp_postmeta, wp_commentmeta, or wp_term_relationships were not removed with it.
This happens most often when a plugin is uninstalled without using its proper uninstall routine, or when posts are deleted directly through a database tool instead of through WordPress itself.
Most reputable cleanup plugins include an “orphaned data” or “unused data” scan as part of their WordPress database cleanup tools. Run the scan, review what it flags, and only then approve the deletion. Avoid any plugin that deletes orphaned rows automatically without showing you a preview first.
Step 5: Optimize Your Database Tables
Deleting rows does not automatically reclaim disk space or rebuild indexes in MySQL’s default MyISAM or InnoDB storage engines. That’s what table optimization does, and it’s the step most people skip.
Run OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options; (adjust for your actual table names) through phpMyAdmin, Adminer, or WP-CLI’s wp db optimize command.
This step defragments the tables and rebuilds their indexes, which is what actually speeds up queries after a WordPress database cleanup. Skipping it means you deleted the clutter but didn’t get the performance benefit.
Step 6: Audit Autoloaded Options
This is the step most guides skip, and it’s often the one with the biggest impact. Some rows in wp_options are marked autoload = 'yes', meaning WordPress loads every single one of them into memory on every page load, whether it’s needed or not.
On a site with a lot of plugins, autoloaded options can balloon to several megabytes. That data gets pulled into memory on every request, before a single piece of your actual content loads.
Check the size with: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';. Anything over 1MB is worth investigating. Query Monitor shows you which specific options are autoloaded and how large each one is, so you can see exactly what’s responsible.
If you find a large, unused option left behind by a deactivated plugin, you can set its autoload flag to 'no' or delete it outright, but only after confirming no active plugin still depends on it.
Step 7: Automate Future WordPress Database Cleanup
A one-time cleanup helps, but the bloat comes back. The real fix is making WordPress database cleanup a recurring task instead of a rescue mission you run once a year.
Most cleanup plugins, including WP-Optimize, let you schedule automatic cleanups on a weekly or monthly basis. Set revisions, spam comments, and expired transients to clear automatically, but leave orphaned data and autoloaded options as manual reviews, since those carry more risk if deleted blindly.
If you manage multiple WordPress sites, a WP-CLI cron job that runs wp db optimize and clears expired transients on a schedule keeps every site consistent without logging into each dashboard individually.
Which Tool Should You Use: Plugin, WP-CLI, or Hosting Panel
For most site owners without server access, a plugin is the right call. WP-Optimize and Advanced Database Cleaner are both well maintained, show previews before deleting anything, and handle revisions, spam, and transients in one place.
If you’re comfortable with the command line, WP-CLI gives you more control and is faster on large databases, since it skips the WordPress admin’s overhead entirely.
Many managed WordPress hosts, including Kinsta, WP Engine, and SiteGround, run their own background database maintenance and may already handle some of this for you. Check your host’s knowledge base before installing a plugin that duplicates work your host already does.
Whichever route you pick, the goal of a WordPress database cleanup stays the same: fewer unnecessary rows, smaller tables, and faster queries, without touching the content your visitors actually see.
For developers, the official WordPress Transients API documentation explains exactly how transients are stored and expired, which is useful background before you start deleting them manually.
While you’re doing general maintenance, it’s also a good time to confirm your WordPress core and plugins are on a secure, current version. We cover what to check after a security-related release in our WordPress 7.1.2 security update guide and in our breakdown of WordPress 7.1 update problems and how to avoid them.
If slow queries are only part of your speed problem, pair this WordPress database cleanup with the server-response-time work in our guide to optimizing TTFB, since a clean database and a fast time-to-first-byte usually go hand in hand.
FAQ
Is a WordPress database cleanup safe to run on a live site?
Yes, as long as you back up first and use a reputable plugin or WP-CLI command rather than writing raw SQL by hand. Stick to the order in this guide: backup, revisions, comments, transients, orphaned data, then optimize.
How often should I clean up my WordPress database?
For most small to mid-size sites, once every one to three months is enough. High-traffic sites with heavy comment activity or frequent content edits benefit from a monthly or automated weekly cleanup.
Will a WordPress database cleanup fix slow page speed on its own?
It helps, but it’s one piece of a larger picture. If your Largest Contentful Paint or Time to First Byte are still slow after cleanup, the bottleneck is more likely hosting, caching, or unoptimized images rather than database bloat alone.
Do I need a plugin, or can I clean the database manually?
A plugin is safer for most people because it previews changes before deleting anything. Manual SQL through phpMyAdmin works, but a single mistyped query can delete the wrong rows, so only do this if you’re confident reading SQL and you have a tested backup.
Next Step
Start with the backup, then run steps one through five today. They’re low-risk and take under 20 minutes on most sites. Save the autoloaded options audit (Step 6) for a quiet afternoon when you can review each large option carefully, and set up the automation in Step 7 once you’re confident the manual process didn’t break anything.
Treat this WordPress database cleanup as a recurring item on your maintenance calendar rather than a one-time fix. A database you clean every few months stays fast on its own; a database you ignore for three years turns a 20-minute job into an afternoon.
Leave a response