Previously on the CogitActive Saga:
Interestingly, I also found remnants of a plugin I tested in my previous post—the troublesome Katorymnd Reaction Process Plugin—still lingering in the database. This discovery might mean I’ll need to use a dedicated database cleanup plugin after all.
There I was, eyes locked on phpMyAdmin, heart racing. One wrong move—delete the wrong table—and it could all go dark. No wires to cut, no timer ticking down. Just rows and rows of cryptic entries and the sinking feeling that something in here doesn’t belong. But what?
What should have been a straightforward plugin reinstall turned into something else entirely. I expected a clean slate. Instead, I found a stubborn trail of digital breadcrumbs pointing straight back to my previous setup. I went in manually, combing through file directories and database entries. And while I managed to scrub most of it out, the process was tedious and nerve-racking—an experience I wasn’t eager to relive.
And yet, while digging, I unearthed other debris. Ghost tables. Orphaned options. Traces of plugins I knew I had deleted—one of which, ironically, was so bad I uninstalled it quicker than I added it. And if two plugins had left behind junk… how many 1 others were still lurking?
It’s more than likely you’ll test out and compare a few different ones to accomplish tasks or solve problems on your site. When you’re done with one, you simply uninstall it by deactivating and deleting it right? Wrong, the issue with doing it this way is that it can leave behind tables and rows in your WordPress database, and over time this can add up quite quickly, which in turn can affect your site’s performance and even cost you money on disk space.Brian Jackson
It’s time to track down that junk, without blowing up my site in the process. This is my deep dive into purging the mess left behind by old plugins.
Why plugins leave junk behind
Most WordPress users—my past self included—assume that deleting a plugin removes it entirely. But under the surface, the reality is far messier. Many plugins leave behind a trail of data—custom tables, rows in wp_options, orphaned metadata—cluttering up your database long after the plugin is gone.
As explained by Brian Jackson at Kinsta 2, one of the most common reasons is convenience. Developers often preserve settings in case a user reinstalls the plugin. This can feel like a feature: reinstall the plugin later, and your preferences are still there, like nothing ever changed. For me, it was an unwelcome one. While this makes life easier for casual plugin swappers, it leaves lingering data that slowly bloats your database 3.
The longer your site lives—and the more plugins you’ve tested—the more this cruft accumulates.
Another culprit? Developer oversight. As the WordPress plugin handbook notes, the best practice is to use an uninstall hook to clean up data. But that requires care, and not every developer gets it right. Some mistakenly use a deactivation hook instead, which means when you delete the plugin, it simply shuts down and leaves everything behind. Other times, cleanup simply isn’t prioritized, especially for free or one-off plugins with minimal support.
Add to that WordPress’s lack of a consistent uninstall flow—no built-in prompt saying “delete plugin and data?”—and users are left guessing. Unless the developer has actively provided and documented a full removal process, you’re on your own.
A properly-developed plugin will have an option for a complete uninstall inside its settings.Lora Raykova
Here’s the twist: many plugins do offer proper cleanup methods. The issue is they’re rarely obvious. Sometimes, cleanup is buried in the settings panel. Other times, it’s a checkbox you need to enable before deactivating the plugin. And occasionally—if you’re lucky—there’s documentation explaining a manual SQL process.
The result? A patchwork of behavior across plugins: some wipe everything clean, others leave it all behind, and many land somewhere in between. That inconsistency is exactly what makes cleanup so difficult: figuring out what’s junk, what’s useful, and how to tell the difference, without torching your database.
Uninstalling WordPress plugins is remarkably simple. The hard part comes after, when you have to make sure they didn’t leave any extra unwanted data behind.WP Engine
The manual way with phpMyAdmin
As you may guess, if you follow this blog, I naturally lean toward the first. While manual cleanup requires more technical know-how, it also gives you more precise control. Besides, installing another plugin to clean up after old ones, come on… Now, I’ve done it once already when I manually erased every trace of the TotalRating plugin from my database. It wasn’t fun. It wasn’t fast. But it worked.
You can also manage your WordPress database using a plugin. Although a database WordPress plugin can make accessing your database simpler, I would advise against managing your database in this manner as it is a large security risk.Kevin Muldoon
Interestingly, several sources I consulted—from Kinsta to WP Engine to Jetpack—favored the manual method as well. Why? Because it gives you total control and avoids the risk of automated tools deleting the wrong data. But let’s not romanticize this. Manual cleanup requires precision, patience, and a strong stomach. You’ll be spelunking through wp_options, peeking inside wp_usermeta, and asking existential questions about cryptic table names.
phpMyAdmin is a free, open-source tool written in PHP that provides a web-based interface for managing MySQL 4 and MariaDB databases. It allows users to perform various database operations—such as running SQL queries, browsing and editing tables, importing/exporting data, and managing users—without needing to use the command line (while you still have the ability to directly execute any SQL statement
).
It has become one of the most popular MySQL administration tools. It is indeed widely supported by web hosting providers and often comes pre-installed with cPanel or similar hosting control panels.
The majority of local development environments or hosting companies use a free tool called phpMyAdmin. phpMyAdmin is a web-based tool that allows you to interact with your WordPress database using a web browser.Learn WordPress
If you are using SiteGround, the application can be opened from Site Tools > Site > MySQL> phpMyAdmin.
So, let’s try going down that road again…
Step 1: back up everything
Before even thinking about deleting a table or row, create a full database backup (external link). phpMyAdmin lets you export your entire database as an SQL file. Save it. Store it like treasure. Because if anything goes wrong during cleanup, this file is your only way back.
After you make your backup, go ahead and restore it so you can see what it’s like before you get in an emergency situation. Remember, if you have an untested backup system, you don’t have disaster recovery, you have hopes and wishes.Cal Evans
The database is the heart of your WordPress site—every post, page, comment, setting, and user account lives here. The themes and plugins? They’re just the face. The real structure, the content, the soul of your site—it’s all in the database. One wrong deletion and you’re not fixing layout issues—you’re recovering from data loss.
That makes a fresh backup non-negotiable. Don’t skip it. Just do it.
Step 2: check /wp-content/plugins/
After uninstalling a plugin from the WordPress dashboard, it’s easy to assume it’s gone. But sometimes, traces linger in the file system too. It’s rare, but it does happen—and it’s worth a look. When you’re hunting ghosts, don’t forget to check under the floorboards.
Because deletion doesn’t always mean removal, navigate to your /wp-content/plugins/ directory (via FTP or your host’s file manager) and double-check that the plugin folder is truly gone. While most plugins clean up properly, a few may leave behind:
- Residual folders
- Helper files
- Orphaned uninstall.php scripts
- Custom files created outside the plugin’s folder
“I did check the /wp-content/plugins/ folder. There was nothing there, other than the folders of the plugins I currently have installed. Next”
Step 3: search the database itself
Once you’ve confirmed your plugin folders are gone and backups are safely stored, it’s time to dive into the database. Most plugin leftovers fall into one of two categories:
- Dedicated plugin tables that were added during installation and never removed
- Residual entries buried in core WordPress tables (like wp_options, wp_usermeta, etc.)
Plugin-specific tables
Some plugins create custom tables to store large amounts of data independently. These are often easy to spot. They typically share a clear naming pattern based on the plugin’s name. And because they aren’t used by WordPress core (see Box 2), they stand out in a sea of expected tables.
Knowing what belongs helps you spot what doesn’t.
WordPress uses a database to store, retrieve, and display all the content that you create on your website. This includes a mix of all your site’s essential content, including themes, plugins, comments, posts, pages, and revisions.
The WordPress database is made up of many tables, each storing a different type of data for your website. A standard, single-site WordPress installation includes 12 core tables. These are fundamental to WordPress functionality and should never be deleted:
wp_posts: all posts, pages, and custom post types.
wp_postmeta: metadata related to posts.
wp_users: user account information.
wp_usermeta: user-specific settings and preferences.
wp_options: site-wide settings (plugin config often lands here).
wp_comments: comment content.
wp_commentmeta: metadata for comments.
wp_terms: categories, tags, and taxonomies.
wp_termmeta: metadata related to terms.
wp_term_taxonomy: defines the taxonomy of each term.
wp_term_relationships: connects posts to terms.
wp_links: blogroll entries (mostly unused in modern sites).
Each table has the same prefix, which is defined in the wp-config file. By default, the prefix is wp_, but you can change this to anything you like during the WordPress installation process.Learn WordPress
If you’re running a Multisite setup, you’ll find a full set of these tables for each site—usually using this format: wp_2_posts, wp_2_options, etc., one full set per site ID. Additionally, Multisite introduces network-wide tables, such as:
wp_blogs: tracks each site in the network.
wp_site: network-level data (deprecated, but still present).
wp_sitemeta: metadata for the network as a whole.
wp_signups: pending or unconfirmed registrations.
wp_blog_versions: stores WordPress version info per site.
Anything outside of these expected patterns—especially tables with plugin names or mysterious prefixes—could be debris left behind by uninstalled plugins. These are the ones you’ll want to scrutinize.
But here’s the caveat: this depends heavily on how well the plugin was developed. A well-crafted plugin will prefix its tables clearly and consistently. But some plugins—especially older or hastily built ones—might use cryptic or inconsistent names, or even reuse common prefixes unrelated to their purpose. In those cases, identifying orphaned tables becomes a guessing game.
If you’re unsure about a table’s origin:
- Search its name online—it might be mentioned in a plugin’s documentation or support thread
- Look inside the table (via Browse) to inspect its contents—you may spot plugin-specific patterns
- Cross-check the list of your current plugins: if nothing matches, the table might be leftover debris
So while spotting full plugin tables is often the easiest part of the cleanup, it still requires scrutiny. Sometimes, even junk hides in plain sight. Even with a good grasp of the core WordPress tables, it can be hard to tell which belong to active plugins and which are leftovers.
“Out of the 84 tables in my multisite database, I could quickly pick out the core WordPress ones, along with a few tied to my currently installed plugins. The Katorymnd Reaction Process Plugin—the one that sparked this whole investigation—stood out with seven clearly labeled tables. But then came the head-scratchers: a handful of tables that didn’t quite match anything I recognized. Were they remnants of long-forgotten plugins? Or part of something still active? That uncertainty is exactly what makes this cleanup so tricky.”
Manually deleting tables with phpMyAdmin, is best left to experienced users. It requires a solid understanding of the default WordPress database structure. You’ll need to identify tables unrelated to WordPress core functionality and pinpoint which tables belong to specific plugins. This process can be quite complex.Website Helper
wp_options: the usual suspect
This table is where many plugins—perhaps most—stash their configuration settings, preferences, and feature toggles. It’s also where a lot of junk goes to hide after a plugin is deleted. Worse still, many of these entries remain autoloaded, which means they’re loaded on every page of your site, whether they’re needed or not.
The conventional approach would be to start with a query like:
SELECT * FROM wp_options WHERE option_name LIKE '%pluginname%';Using the Search tab in phpMyAdmin, I entered terms I knew were plugin-related. Starting with “katorymnd”, I found 14 matches in total. Surprisingly, only 6 of them were actually in the wp_options table. None appeared in the 7 katorymnd_ tables I had identified earlier. One match showed up in the TotalRating table—odd, considering the plugin should’ve had nothing to do with Katorymnd. Two entries were in wp_posts, which made sense (I have two posts in which I mention the plugin). And the remaining five were tucked away in wp_usermeta.
Names vary—some are self-explanatory, and others are ambiguous enough to warrant digging into the actual option values for context.
Here’s the thing: for a plugin I was specifically looking for, I still had to sift through results and make judgment calls. While it’s sometimes obvious what’s legitimate—like my blog posts—figuring out what’s junk isn’t always so straightforward. And that’s with a known plugin. Imagine doing this blind.
Keep in mind, though—you should never delete any rows unless you’re absolutely sure they’re unnecessary. Deleting rows that are in use can break your website, so be extra careful.WP Engine
Be extremely careful here. WordPress core and many active plugins store essential data in this table. Deleting the wrong row can disable major site functions—or worse.
Other tables worth searching
Not all plugin footprints stay confined to the usual suspects. Depending on what the plugin did, it might have left traces in other standard WordPress tables, like wp_postmeta or even wp_terms. If it interacted with user roles, preferences, or settings, you might find leftovers in wp_usermeta (see the above example). Less commonly, plugins that touch the comment system—think spam filters, like buttons, and threaded replies—could have deposited data in wp_comments or wp_commentmeta.
Rather than hunting through each one individually with separate queries, I found that a global search (see above) is far more efficient. You still have to evaluate each result, but at least you get a bird’s-eye view of what’s lurking where.
What you find will likely range from obvious to bewildering.
Messing with your database can be dangerous. Delete just one wrong thing, and you could end up breaking your website completely.KeriLynn Engel
Yes, it’s possible to clean your database manually—if you know what you’re doing. I did it (partly) once. When done right, the result is a site that’s leaner, faster, and genuinely under your control. But make no mistake: this isn’t “spring cleaning.” It’s digital forensics. You’re combing table by table, field by field, separating junk from gold. And without absolute certainty, one wrong deletion can do real damage.
If that sounds intense… that’s because it is. Which brings us to the next question: Could a plugin help—without becoming part of the problem?
To be continued…
1 If you’ve followed this blog, you know I prefer to do things manually whenever possible. I’m not in the habit of piling on plugins. That means the amount of junk in my database is probably limited. My reaction plugin misadventure was, however, an exception— I had to test (and quickly reject) quite a few… ^
2 Brian Jackson (2023) How to Uninstall a WordPress Plugin (the Proper Way) (external link). Kinsta. ^
3 Some plugin creators may downplay the effects of leftover data, claiming it’s insignificant. But over time, old plugin tables and autoloaded rows (especially in the wp_options table) can cause noticeable slowdowns, database bloat, and even increased hosting costs due to disk usage. ^
4 MySQL is a free, open-source database management system that is used by many popular web applications, including WordPress. ^