Cleaning and tuning the WordPress database after an AI migration
A practical guide by an IT expert to cleaning, indexing and tuning the WordPress database after importing an AI-built website.
Convert2WP – convert your AI website to WordPressClick here
Why the database deserves attention
When a site comes out of an AI builder, the content is often imported in large batches. Importers create revisions, temporary options, orphaned metadata and sometimes duplicate posts. On the first day nobody notices. Six months later the admin area feels slow, backups take ages and a simple search query takes seconds.
I treat database hygiene as part of the migration, not as an optional extra. A clean database is faster, smaller to back up and much easier to debug when something goes wrong.
Start with a measurement
Before deleting anything, I measure. I note the total database size, the size of each table and the number of rows in wp_posts, wp_postmeta and wp_options. I also check how many options are autoloaded and how large that autoloaded data is, because WordPress loads it on every single request.
These numbers give a baseline. After cleanup I measure again, which makes the benefit concrete for the client and helps me spot any table that keeps growing unexpectedly in the months after launch.
Revisions, drafts and leftovers
Import tools and editors generate revisions for every save. For a site with a few hundred pages that can mean tens of thousands of rows. I keep a limited number of revisions per post, usually five, and remove the rest after a full backup. Auto-drafts and trashed items left over from the import go as well.
I then look for orphaned metadata: rows in wp_postmeta or wp_termmeta that belong to posts or terms which no longer exist. A careful SQL query or WP-CLI command removes them. On one migration this alone reduced the postmeta table by forty percent.
The autoload problem
The options table is where many slow sites hide their problem. Plugins store settings there with autoload enabled, and some never clean up after themselves when uninstalled. I have seen autoloaded data of several megabytes, loaded on every page view before a single line of the theme runs.
I list the largest autoloaded options, identify which plugin owns them and decide case by case. Data from removed plugins is deleted. Large settings that are only needed in the admin area are switched to non-autoload. The goal is to keep autoloaded data well under one megabyte.
Transients and expired cache
Transients are temporary cache entries stored in the database when no object cache is available. Expired transients are supposed to disappear, but in practice many linger. After an import with many API calls or feed fetches, there can be thousands of them.
Clearing expired transients is safe and quick. The more lasting solution is a persistent object cache such as Redis, which moves transients out of the database entirely. Most decent hosts offer it, and it noticeably improves admin performance on content-heavy sites.
Indexes and table engines
Old or badly configured servers sometimes still run tables on MyISAM. I convert everything to InnoDB, which handles concurrent writes and crashes far better. I also check the character set, because emoji and many non-Latin scripts need utf8mb4 to be stored correctly. That matters a lot for multilingual sites.
For large sites I review indexes on wp_postmeta. A well-known improvement is adding an index on meta_key and a prefix of meta_value when plugins query metadata heavily. I only do this after confirming with slow query logs which queries are actually the problem.
Keeping it clean afterwards
A one-time cleanup is only half the job. I schedule a monthly maintenance task that removes old revisions, expired transients and spam comments, and logs the database size. If the size jumps suddenly, it is usually a plugin misbehaving, and the log tells you when it started.
I avoid all-in-one cleanup plugins that run aggressive operations automatically. A small WP-CLI script under version control is more predictable and does exactly what you decided, nothing more.
Backups before every step
Every operation in this guide starts with a fresh, tested backup. Database cleanup is safe when done carefully, but a wrong query can remove content permanently. I export the database, verify the export can be imported into a test environment, and only then make changes.
Remember that the converter moves your pages and design, not the backend logic of the AI builder. Some data you see in the old platform may simply not exist in WordPress. Small inconsistencies after import are normal and can usually be corrected later, often with a plugin or a short script.