Deleting a WordPress Plugin: What Data You Lose

I would rather see a business owner leave an unused plugin deactivated for a fortnight than delete it on the spot. I say that as someone who spends a fair part of every week telling people to get rid of plugins they no longer use.

Both pieces of advice are right. The trouble is the order.

Deactivating a plugin switches it off. Deleting it is a different act entirely, and WordPress hands the decision about what happens to your data to whoever wrote the plugin. Some keep everything. Some wipe the lot without asking. Some ask you once, in a settings screen you saw two years ago and have long forgotten. And the Delete link looks exactly the same for all of them.

Deactivate and Delete Are Not Two Steps of the Same Thing

Most people treat deactivate-then-delete as one motion with a pause in the middle. WordPress does not see it that way.

The official WordPress Plugin Handbook page on uninstall methods sets it out plainly in a comparison table. Deactivation is meant for flushing temporary cache and resetting permalinks. Removing the plugin's saved options and its database tables belongs to the uninstall routine, and that routine only runs when you click Delete. The handbook adds that less experienced developers sometimes put clean-up code in the deactivation step by mistake, which tells you that not every plugin author follows the rule.

So what does that mean for you? Deactivation is, in almost every case, reversible. Reactivate and everything comes back. Delete runs whatever the developer decided "clean up" should mean, and there is no confirmation screen listing what is about to go. You get one generic warning, you click OK, and the decision is made.

Why this matters more than it used to

Plugins hold far more than settings now. Enquiry forms store submissions. Booking plugins hold appointment histories. Membership plugins hold customer accounts. Loyalty and gift card plugins hold balances people have paid for. Every one of those is business data, and for many small firms it lives nowhere else.

Three Popular Plugins, Three Different Answers

I went through the documentation and the actual uninstall code for three of the most widely installed plugins on the WordPress.org directory. They behave nothing alike.

Plugin	What Delete removes by default	What survives
WooCommerce	The plugin files only	Products, orders, settings and pages
Contact Form 7	Every form you built, permanently	Nothing of the forms; pages keep a dead code tag
WPForms	Depends on one toggle in its settings	Everything, unless that toggle is switched on

WooCommerce: the cautious one

The WooCommerce documentation on uninstalling is clear. Deactivating and deleting the plugin from the Plugins screen removes only the files. Your orders, products and settings remain in the database. To wipe the store data as well, you have to edit a server configuration file before you delete.

That is a sensible default. Your sales history survives an accidental click, which matters the day your accountant asks about a sale from three years ago.

Contact Form 7: the thorough one

Contact Form 7 shows over 10 million active installations on WordPress.org, so the odds are decent you have it. Its uninstall file is short and blunt. It deletes the plugin's settings, then permanently deletes every contact form you have built, bypassing the bin, then drops a leftover database table.

In fairness, Contact Form 7 states in its own readme that it does not write personal data to the database by default. Messages go by email and are not stored. So you are not losing past enquiries. You are losing the forms themselves: every field, every carefully worded dropdown, every email template you set up. And every page that showed a form now shows a line of square-bracketed code to visitors instead, which they read as a broken site.

WPForms: the one that asks, once

WPForms, with over 5 million active installations, takes a third route. Its uninstall code checks a setting labelled "Uninstall WPForms" in the plugin's miscellaneous settings. If that toggle is off, deletion leaves your data alone. If it is on, deletion drops the database tables where form entries are kept.

That is a reasonable design. It also means the outcome of your click depends on a switch somebody may have flicked during setup, possibly a previous web designer, possibly you on a tidy-up afternoon you no longer remember.

Delete runs the plugin author's own clean-up routine, and every author defines clean-up differently.

The Tidy-Up Advice That Gets People Into Trouble

None of this means you should keep dead plugins around. The WordPress hardening guide says it directly: keep plugins updated, and if you are not using one, delete it from the system. We give the same advice in our own WordPress security and backup guide, and I stand by it.

A deactivated plugin still sits on the server as code. If that code has a known vulnerability, it can still be a door, active or not. Leaving fifteen inactive plugins lying around for a year because you are afraid of the Delete link is a security problem of its own making.

So the advice is right. It just arrives with an instruction missing. Delete what you do not use, but only after you know what that plugin is holding.

How it goes wrong in practice

Consider a Westmeath kitchen fitter who, in a quiet week after Christmas, decides to clean up the website a previous designer built. Six plugins are sitting deactivated. One of them is an old quote request form, replaced last spring by a newer one. Off it goes, along with the rest, in one bulk action.

In March a customer rings about a worktop quote from the previous autumn. They want to go ahead at the price they were given. The quote request, with the measurements and the price, was stored in that old form plugin, and the uninstall toggle had been switched on by the designer years before. The fitter now has a choice between honouring a price they cannot verify and arguing with a customer who is about to spend real money with them.

Nothing was hacked. Nothing crashed. A tidy-up did that.

What a Safe Plugin Clear-Out Actually Needs

Strip away the specific plugins and a safe process needs four things.

A way to see what a plugin is holding before it goes. That means reading its settings for any data-removal option, and being able to look at the database for the tables it created.
A restore point taken immediately before the change, not last night, so nothing from today is lost if you need to roll back.
Somewhere to rehearse the deletion where breaking things costs nothing.
A fast, complete rollback if something you needed turns out to have gone.

A good host gives you all four without extra plugins or extra invoices. Web60 includes on-demand manual backups alongside automatic nightly ones, one-click restore, one-click staging environments, and a phpMyAdmin-style database manager in the dashboard, all part of the backups, staging and database tools built into Web60's managed platform. Data sits on Irish infrastructure throughout, which matters when the data in question is your customers' names and phone numbers. If you would rather run your site with that safety net already in place, it all comes in the €60 a year.

A restore point taken minutes before the change is worth more than one from last night.

Retiring a Plugin Without Losing Anything

This is the order I would follow on any business site, whatever the host.

Inventory. Open the plugin's own settings and look for anything labelled uninstall, remove data or delete on uninstall, and note whether it stores entries, bookings or customer records.
Export. If the plugin offers a CSV or spreadsheet export of entries, run it and save the file somewhere outside the website.
Backup. Take a manual, on-demand backup right before you touch anything, so your restore point includes this morning's enquiries.
Deactivate and verify. Switch the plugin off, then browse your key pages, forms and checkout for a few days to confirm nothing depended on it.
Deploy the deletion. Delete it in a staging environment first, verify the result, then delete it in production and confirm the pages still load cleanly.

Keep step four short. Days, not months. A plugin you are still unsure about after a fortnight is a plugin you have not properly inventoried.

What a Backup Cannot Do Here

Now the uncomfortable part. A full-site backup is a blunt instrument for this particular problem.

If you delete a forms plugin on Tuesday and only discover the missing entries three weeks later, restoring the whole site to Monday's backup also rolls back three weeks of new pages, new orders and new enquiries. You get the old data back and lose the new. Going the other way means someone digging the specific tables out of an old backup and putting them back by hand, which is real work and not something to rely on.

That is why steps two and three above matter more than the restore button. An export you saved before the deletion costs nothing to keep and never forces you to choose between old data and new. A backup taken five minutes before the change means a rollback, if you need one, loses five minutes of activity rather than a day. If you want to see how a full restore actually behaves when something important has vanished, our walk-through on getting a deleted WordPress page back covers the trade-offs in detail.

One more honest limitation. Not every plugin cleans up after itself even when it should. Plenty leave tables and settings behind after deletion, so a plugin you removed in 2023 can still be holding customer names and emails in your database today, invisible from the dashboard. Under GDPR's storage limitation principle, personal data should not be kept longer than you need it. Deleting a plugin does not discharge that duty for you, and if leftover data like this concerns you, it is worth a conversation with your data protection adviser rather than assuming the Delete link handled it.

When You Can Ignore All of This

If the idea of managing plugins at all fills you with dread, there is a genuine argument for a closed, all-in-one website builder. Those platforms have no plugin ecosystem in the WordPress sense, so there is no plugin Delete link to get wrong. For a five-page brochure site that will never take an enquiry through anything more complex than an email link, that simplicity is real.

You pay for it in other ways. Fewer features, less control over your data, and a platform that decides what your site can do. For a business that wants booking, quoting, a shop or anything that grows, full WordPress with a proper safety net is the better place to be. That is what roughly four in ten websites run on, according to W3Techs' latest count, and it is why the plugin question is worth getting right rather than avoiding.

Before You Press Delete

Deactivation is the off switch. Deletion is the shredder, and every plugin author sets the shredder differently. Treat them as two separate decisions with a deliberate gap in between.

Find out what the plugin holds. Export it. Take a fresh backup. Switch it off for a few days and watch. Then delete it in staging before you delete it for real. Five small steps, perhaps twenty minutes in total, and the next time a customer rings about a quote from last year, the answer will be sitting exactly where you left it.

Frequently Asked Questions

Does deactivating a WordPress plugin delete its data?

In almost every case, no. The WordPress Plugin Handbook reserves the removal of a plugin's settings and database tables for the uninstall routine, which only runs when you click Delete. Deactivation normally just switches the plugin off, and reactivating it brings everything back. A small number of badly built plugins do clean up on deactivation, so take a backup first if the plugin holds anything important.

Will deleting my contact form plugin delete my enquiries?

It depends entirely on the plugin. Contact Form 7 does not store messages by default, but deleting it permanently removes every form you built. WPForms removes its stored entries only if its Uninstall WPForms setting is switched on. Check the plugin's settings for a data-removal option and export any stored entries before you delete.

Can I get a plugin's data back after deleting it?

Usually, if you have a backup from before the deletion. Restoring the whole site brings the data back but also rolls back every change made since that backup. If time has passed, recovering only the plugin's data means extracting specific tables from the old backup, which is skilled work. An export taken before deletion is far easier to recover from.

Should I delete WordPress plugins I am not using?

Yes, once you have confirmed what they hold. Deactivated plugins remain on the server as code and can still carry security vulnerabilities, which is why the WordPress hardening guide recommends deleting unused ones. Inventory, export, back up and deactivate first, then delete.

Why does my page show code in square brackets after removing a plugin?

That is a shortcode the plugin used to replace with content such as a form or gallery. Once the plugin is gone, WordPress has nothing to swap it for, so visitors see the raw code. Edit the page to remove the shortcode or replace it with the new plugin's equivalent, ideally in staging before production.

Deleting a WordPress Plugin Can Wipe Its Data. Deactivate First, Then Decide.