Guide WordPress

How to remove a WordPress plugin properly

Deactivating a plugin leaves its files and often its database tables behind. Here is how to remove one completely.

iFastHosting Support Team Updated 26 August 2026 6 min read Beginner

Clicking "Deactivate" on a WordPress plugin turns it off. It does not remove it. The plugin's files stay in wp-content/plugins, its settings usually stay in your database, and in some cases scheduled tasks it registered keep running in the background indefinitely. None of that shows up anywhere in wp-admin once the plugin is deactivated, which is exactly why it accumulates unnoticed.

An inactive plugin is not neutral. Its code is still on the server, still readable, and still a potential target if a vulnerability is later found in it — an inactive plugin can still be exploited through a direct file request in some circumstances, because "inactive" is a WordPress-level state, not a filesystem one. If you are not using a plugin, remove it rather than leaving it switched off.

Step 1: deactivate, then check the site

Turn the plugin off first and load the site through, front end and admin area both. This confirms nothing else on the site was quietly depending on it — a shortcode inserted into a page, for instance, or a template file calling one of its functions directly — before you commit to removing it for good.

Do not deactivate and delete a caching or security plugin blind

Some caching plugins write rules into your .htaccess file, and some security plugins do the same. Removing the plugin does not always clean those rules up automatically. Check .htaccess afterwards if the site behaves oddly — see fixing WordPress permalinks returning 404 if pages stop resolving.

Step 2: delete it from wp-admin, not just by FTP

In Plugins, find the deactivated plugin and click Delete. This matters more than it looks: WordPress runs the plugin's own uninstall.php file at this point, if it has one, which is the plugin's chance to clean up its own database tables and options properly. Deleting the plugin folder directly over FTP skips that step entirely and guarantees leftovers.

Step 3: confirm the files are actually gone

Connect over FTP or SFTP and open wp-content/plugins. The folder for the plugin you removed should no longer be there. Occasionally a delete fails partway through — usually a file permissions issue — and leaves a partial folder behind. If you see one, remove it manually.

Step 4: check the database for what was left behind

Not every plugin cleans up after itself even when its uninstall routine runs. Two places to check, using phpMyAdmin from your control panel:

The wp_options table. Search for rows whose option_name clearly matches the plugin's name or prefix. A handful of stray rows here is harmless, but a plugin that stored large amounts of data as a serialized "autoloaded" option can measurably slow down every page load, because autoloaded options are pulled into memory on every request whether anything uses them or not.
Custom tables. Look through your table list for a name matching the plugin — a forms plugin, for example, commonly creates its own tables for submissions. If you are certain you no longer need that data, these can be dropped. If you might, export them first with exporting a database before deleting anything.

Only touch rows and tables you can positively identify

Table and option names are not always self-explanatory, and deleting the wrong one can break a plugin you are still using. If a name is ambiguous, leave it — a handful of unused rows costs you nothing measurable, and a wrongly deleted table can cost you an afternoon.

Step 5: check for orphaned scheduled events

Plugins that run background tasks — sending digest emails, checking for updates, cleaning up their own data — usually register those tasks with WP-Cron. Deleting the plugin does not always cancel the scheduled event, which then fires on schedule forever, calling a function that no longer exists and doing nothing except wasting a page load's worth of processing each time.

If you have WP-CLI access, list scheduled events and look for anything referencing the removed plugin:

wp cron event list
wp cron event delete <hook-name>

Without command-line access, a "cron control" plugin can show you the same list from wp-admin, though installing one purely to clean up after another plugin is only worth it if you have several leftover events to deal with.

Doing this at scale

If you are working through a site that has accumulated a dozen unused plugins over the years, do them one at a time rather than all at once. Deactivate one, confirm the site still works, delete it, then move to the next. Removing several plugins in a single pass makes it much harder to work out which one was responsible if something does break.

See finding the plugin that is slowing your site if the goal is performance rather than tidiness, and cleaning up and optimising the WordPress database for dealing with everything else that accumulates over time, not just plugin leftovers.