You removed a plugin you were sure you no longer needed. Now a page that used to show a comparison table shows this instead:
[acme_table id="4"]
Or a gallery has become a line of square brackets. Or an entire section of a page is simply not there any more.
The first thing worth saying, because it is the thing people most want to know: your posts and pages have not been deleted. What has happened is more specific than that, and it determines whether the content is recoverable and how.
Three different things people mean by "my content is gone"
They have different causes and different outcomes, and mixing them up is why advice on this subject is so unsatisfying.
Type 1: The shortcode is now visible as text. The plugin registered a shortcode. Your post stored the shortcode, not the output. With the plugin gone, nothing translates it, so WordPress prints the raw text. Your post content is completely intact. What you have lost is the renderer, not the writing.
Type 2: A section has vanished entirely. The plugin stored the content itself, in its own database tables or as a custom post type, and your page only referenced it. Sliders, form definitions, table builders and testimonial managers commonly work this way. The reference is intact; whether the referenced content survives depends on whether the plugin removed its own data on uninstall.
Type 3: The page looks broken but the words are all there. The plugin provided styling or a layout wrapper. This is the least serious case, and it is fixed by editing the page rather than by recovering anything.
Work out which type you have before you do anything, because type 1 needs an editing session, type 2 may need a restore, and type 3 needs neither.
Why deleting removes data at all
It seems like an overreach until you see the reason. WordPress asks plugins to clean up after themselves when they are uninstalled, because the alternative is that every plugin any site has ever tried leaves tables and settings behind forever.
So a well-written plugin, on deletion, drops the tables it created and deletes the options it stored. That is correct behavior, not a bug, and it is the reason deactivating is reversible and deleting is not. Deactivating leaves everything in place. Deleting runs the cleanup.
Some plugins offer a setting controlling this, often worded as "delete all data on uninstall". If you still have the plugin installed and are reading this before deleting, that setting is worth finding first.
Type 1: fixing visible shortcodes
Nothing is lost, so this is work rather than recovery.
Find every instance. Search your site for the shortcode name. The site search box will find it in post content, which is where most of them are. Also check widgets, your theme's template parts, and any page built with a builder.
Decide what replaces it. Frequently a core WordPress block now does the job. Tables, buttons, columns, galleries, accordions and tabs have all moved into core over successive releases, and a shortcode from an old plugin is often standing in for something the editor now does natively.
Then delete the shortcode text. Do not leave it sitting under the replacement. It will still be visible.
If you want the old plugin's output back rather than a replacement, reinstalling the plugin makes every shortcode work again immediately. That is a legitimate answer, especially as a temporary measure while you convert pages at your own pace.
Type 2: recovering content the plugin was holding
This is the case where a backup matters, and the honest position is that your options depend entirely on whether you have one.
If you have a backup from before the deletion, restore it to a staging copy rather than over the live site. Then reinstall the plugin there, confirm the content is present, and export it in whatever format the plugin offers. That gives you a file you can import into the live site once the plugin is installed again, without rolling back everything else that has happened since.
If you have no backup, the content held in the plugin's own tables is very likely gone. Check the media library first, because uploaded images usually survive independently, and check whether the plugin used a custom post type, because custom post types live in the standard posts table and may still be there even though nothing is displaying them.
That second check is worth doing before concluding anything. Reinstalling the plugin, without restoring anything, sometimes brings the content straight back, because the data was never in the plugin's own tables at all.
Type 3: the layout is wrong
Edit the page. There is nothing to recover. The plugin was providing spacing, columns, or styling, and core blocks will do it.
Worth checking whether the plugin also enqueued a stylesheet that other parts of the site relied on, because that produces subtle wrongness across many pages rather than obvious breakage on one.
The rule this all points at
Deactivate first, wait, then delete. A deactivated plugin produces exactly the type 1 symptom, visible shortcodes and missing sections, without touching any data. It is a full preview of what deletion will do, and it is completely reversible.
Sit with the site in that state for a few days. Fix the pages. Convert the shortcodes. Confirm nothing else depended on it. Then delete, when the deletion has nothing left to break.
The people who arrive at this page in a hurry are almost always people who did the two steps as one.
A note about what an update does, by contrast
Updating a plugin does not do any of this. An update replaces the plugin's code and leaves its data alone, which is why updates are routine and deletions are not. The same distinction runs through WordPress generally, and what actually happens during a WordPress update sets out which parts of a site an update replaces and which it deliberately does not touch.
If a plugin has been abandoned by its developer and you are removing it for that reason rather than because you stopped using the feature, the same sequence applies, and the conversion work in type 1 is the real cost of the move.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. The uninstall behavior described here is long-standing core behavior, not a 7.x feature. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19. The shortcode example above uses an invented plugin name and is illustrative. No plugin is named or recommended anywhere on this page.
