How to clean up WordPress databases across multiple sites
Back up each site, remove revisions, auto-drafts, trash, spam comments and expired transients, then optimise the database. WordPress admin is fine for a few sites, but WP-CLI or a central maintenance tool is faster and safer for a group.
- 01List sites and make backups
- 02Clean obvious items in WordPress
- 03Use WP-CLI for repeatable cleanup
- 04Limit future database growth
- 05Check every site after cleanup
- 06Centralise the recurring work
What you need
- Administrator access to every WordPress site
- A recent full database and file backup
- SSH and WP-CLI access, or a central WordPress management dashboard
- A list of sites and any content that must be retained
List sites and make backups
Write down the sites you will clean and note any special content, such as client drafts, WooCommerce orders or form entries. Take a current database backup for every site, and keep the files somewhere separate from the live server.
Do not start by deleting unknown tables or rows from phpMyAdmin. A database can contain data owned by plugins, themes and custom post types, and direct SQL deletion can leave related metadata, terms or caches behind. WordPress support guidance recommends using WordPress deletion functions or WP-CLI rather than removing records blindly.
Clean obvious items in WordPress
For a small number of sites, open each dashboard and review the Posts, Pages and Comments screens. Permanently delete items in Trash, empty Spam after checking it, and remove abandoned auto-drafts. Keep genuine drafts and revisions that someone may need to restore.
This route is workable, but WordPress core does not provide one general database-cleanup screen. Revisions are normally reviewed from the individual post or page, so repeating the process across many sites is slow and easy to miss. WordPress stores revisions as saved versions of posts and pages.
Use WP-CLI for repeatable cleanup
From each site’s WordPress directory, export a backup first with wp db export../site-backup.sql. List IDs before deleting them, then run only the commands for data you have approved:
wp post list --post_type=revision --format=ids, followed bywp post delete ID-LIST --forcewp post list --post_status=auto-draft --format=ids, followed bywp post delete ID-LIST --forcewp post list --post_status=trash --format=ids, followed bywp post delete ID-LIST --forcewp comment list --status=spam --format=ids, followed bywp comment delete ID-LIST --forcewp comment list --status=trash --format=ids, followed bywp comment delete ID-LIST --forcewp transient delete --expired
Finish with wp db optimize. Do not replace the ID list with every draft or every post: legitimate editorial work and live content can be deleted. WP-CLI supports these post, comment, transient and database operations, including permanent deletion with --force.
Limit future database growth
In wp-config.php, consider limiting revisions rather than disabling them completely, for example define( 'WP_POST_REVISIONS', 5 );. Set a suitable trash-retention period with define( 'EMPTY_TRASH_DAYS', 14 ); if your workflow does not need the default 30-day recovery window.
Do not set either value without checking the site’s editorial and recovery requirements. Revisions may be needed to restore important content, while reducing the trash period removes the recovery window sooner.
Check every site after cleanup
Open the front end and dashboard for each site. Test a contact form, login, search, checkout if applicable, scheduled content and any key integrations. Check that recent posts, pages, media and orders are still present.
Compare database sizes after the cleanup, but do not expect the file size to fall by the exact amount of deleted data. Table optimisation changes storage layout; it does not fix a plugin that is continually creating unwanted rows. If the database grows again quickly, identify the plugin or feature responsible before running another purge.
Centralise the recurring work
For several separate WordPress installations, MainWP Maintenance can run the selected cleanup tasks across connected child sites from one dashboard. Use its on-demand maintenance screen to choose revisions, auto-drafts, trash, spam and other supported items, or create a schedule after you have confirmed the first run on each site. Its documented maintenance options also include expired transients and database table optimisation.
Keep backups outside the sites you are cleaning and review the selected actions before running them in bulk. If you use its table-optimisation option, check the database engine first; the extension documentation specifically says that feature is not recommended for child sites running MariaDB.
Let MainWP Maintenance do it
Bulk-removes revisions, drafts, trash, and spam across connected sites; ideal for centralized multi-site maintenance.
Sources
- wordpress.org /support/topic/how-can-i-delete-post-revisions-for-pages/?ut…
- wordpress.org /documentation/article/revisions/?utm_source=openai
- developer.wordpress.org /cli/commands/post/delete/?utm_source=openai
- developer.wordpress.org /advanced-administration/wordpress/wp-config/?utm_source=ope…
- mainwp.com /mainwp-maintenance-extension/?utm_source=openai
- mainwp.com /add-on/maintenance/?utm_source=openai
Questions
- Can I clean several WordPress databases from one dashboard?
- Yes, but WordPress itself does not provide a central cleanup screen for separate installations. You can run the same WP-CLI commands over SSH on each site, or connect the sites to a management dashboard such as MainWP Maintenance. The central route is useful when you need the same selected cleanup tasks and schedule applied across many child sites.
- Is it safe to delete all WordPress revisions?
- Deleting revisions is usually safe after a backup, but it removes the ability to compare or restore older versions of posts and pages. Keep revisions if editors rely on them, and consider limiting future revisions instead. Never delete rows from the posts table based only on a guessed table name; use WordPress-aware tools so related data and deletion routines are handled properly.
- Should I delete all drafts during database cleanup?
- No, delete only abandoned auto-drafts or drafts you have explicitly approved. A normal draft may be an unpublished article, landing page, product or client deliverable. Before bulk deletion, list the IDs and review titles, authors and dates. A command that targets every draft can remove legitimate work in seconds and may not be recoverable without restoring the backup.
- Does optimising database tables remove database bloat?
- Optimising tables can tidy storage after rows have been deleted, but it does not identify or remove unwanted content by itself. First clean revisions, trash, spam, expired transients and confirmed plugin leftovers. If the database grows again, find the feature creating the data. On some hosting setups, table optimisation can also require extra disk space or may be unsuitable for the database engine.
- How often should I clean WordPress databases?
- Run a review monthly or quarterly, depending on how often the sites publish, receive comments or create revisions. Schedule only low-risk tasks after checking a manual run, such as deleting expired transients and old spam. Treat revisions, drafts, unused plugin tables and orphaned metadata as review items rather than automatic deletions unless you have a documented retention policy.