Can You Undelete a WordPress Category?
You deleted a WordPress category and now every post that used it has lost its grouping. Maybe you clicked the wrong row in a bulk action. Maybe a client asked you to “clean up the categories” and you took out one they still needed. Either way, the question is the same: can you get it back?
The short answer is yes, often, but WordPress doesn’t make it obvious how. There’s no dedicated “undo” button for taxonomy terms the way there is for posts and pages. Recovery depends on how quickly you act and what safety nets you already had in place before the deletion happened. This guide walks through every realistic recovery path, from the five-second fix to the last-resort database dig, plus how to stop this from happening again.
What Actually Happens When You Delete a Category
Categories in WordPress are stored as taxonomy terms in the wp_terms, wp_term_taxonomy, and wp_term_relationships database tables. When you delete a category, WordPress removes the term itself and, critically, deletes the relationships linking that term to your posts. The posts themselves are not deleted. They simply lose that category assignment and typically fall back to your default category (usually “Uncategorized,” unless you’ve changed the default).
This is the part that catches people off guard: your content is safe, but the organizational structure and any SEO value tied to that category’s archive page is not automatically preserved. If your category page had earned backlinks or ranked for a search term, deleting it breaks that URL, and anything pointing to it now 404s unless you set up a redirect.
Unlike posts and pages, which move to a Trash folder with a 30-day grace period before permanent deletion, categories in stock WordPress have no trash bin at all. Once you confirm the delete action, the term record is gone from the terms table immediately. This is the single biggest misconception people have: they go looking for a “Trash” tab under Posts > Categories the way they’d expect from post deletion, and it isn’t there.
Why This Matters Beyond Organization
A missing category is not just a cosmetic problem. Three concrete things break when a category disappears:
Navigation and menus. If that category was linked in your main navigation menu, WooCommerce shop menu, or a widget, the menu item now points to a dead URL. Visitors clicking it get a 404.
SEO equity. A category archive page that Google has indexed and ranked carries its own authority. Deleting the category deletes that page. Any inbound links, whether from your own internal linking or external sites, now point nowhere.
Post discoverability. Posts that relied on that category to surface in “Related Posts” widgets or theme-level category loops silently drop out of those sections. Nothing errors out. The content just quietly stops showing up where it used to.
Recovery Method 1: Check If It’s Actually Still There
Before assuming the category is gone, rule out the most common false alarm: you didn’t delete it, you just can’t find it. Go to Posts > Categories and check whether you have pagination enabled with a filter applied, or whether the category was renamed rather than deleted. Search the category list using the search box at the top of the screen. A surprising number of “deleted category” support tickets turn out to be a category that’s alphabetically further down the list than expected, or one that got merged into a parent category during a reorganization.
If you’re confident it’s genuinely gone, move to the recovery methods below, roughly in order of how likely they are to work without technical intervention.
Recovery Method 2: Recreate It Manually
This is the fastest fix and works for the majority of cases, especially if the category had a small number of posts. Recreating the category doesn’t restore the old term ID, but it restores the functional outcome: a working category with the right posts attached.
- Go to Posts > Categories and add a new category with the exact same name and slug the original had. Getting the slug to match matters if you want the URL to resolve the same way it did before.
- Open each post that used to belong to that category (you likely remember which ones, or can identify them by checking which posts fell back to Uncategorized around the time of the deletion) and reassign the new category to them.
- If you use Rank Math, Yoast, or another SEO plugin, re-check the category’s SEO title and meta description, since these are stored per-term and won’t carry over automatically to a newly created term with the same name.
For a handful of posts, this takes a few minutes. For a category spanning hundreds of posts, it’s impractical without the bulk tools covered below.
Recovery Method 3: Restore From a Backup
This is the most reliable method if you have a backup taken before the deletion, and it’s the reason “back up before making structural changes” is not just boilerplate advice. Plugins like UpdraftPlus and BlogVault (Jetpack’s VaultPress Backup works too) capture the full database, which includes the terms tables.
You generally have two options once you locate a usable backup:
Full site restore. If the deletion was recent and you don’t mind losing other changes made since the backup, restoring the entire database rolls everything back, including the category. This is heavy-handed if you’ve published new content or received new orders since the backup was taken, since a full restore would undo those too.
Selective database restore. Most managed hosts (Cloudways, WP Engine, Kinsta, SiteGround among them) let you spin up a temporary staging copy of an old backup without touching your live site. Restore the backup to staging, export just the relevant rows from wp_terms, wp_term_taxonomy, and wp_term_relationships, and import those specific rows into your live database. This preserves everything you’ve done since, while only bringing back the deleted category and its post relationships.
If you don’t already have a backup plugin running, this is the point where you learn the hard way why one matters. Install UpdraftPlus or BlogVault today, even after the fact, so the next accidental deletion doesn’t leave you guessing.
Recovery Method 4: Direct Database Recovery via phpMyAdmin
If you have no backup and the category had enough posts that manual recreation isn’t practical, a direct database look is the next option. This requires comfort with SQL and carries real risk if done carelessly, so back up your current database before touching anything, even though you’re trying to recover from a prior mistake.
- Log in to your hosting control panel and open phpMyAdmin (or Adminer, depending on your host).
- Select your WordPress database and open the
wp_termstable. Categories, tags, and any custom taxonomy terms all live here together, distinguished by their entries inwp_term_taxonomy. - Because WordPress deletes the term record outright rather than soft-deleting it, you generally will not find the old row still sitting in the table marked as deleted. What you’re actually checking for is whether the deletion truly removed the row, or whether it only removed the taxonomy relationship while leaving an orphaned term entry behind, which happens occasionally due to plugin conflicts or interrupted requests.
- If you find an orphaned term (a row in
wp_termswith no matching row inwp_term_taxonomy), you can often repair it by manually inserting the missing taxonomy row withtaxonomy = 'category'and the correct parent and count values. - If the row is genuinely gone with no trace, database recovery from the live table won’t help. Your remaining options are a backup restore or manual recreation.
This is also where a raw SQL-level database backup (distinct from a plugin-based backup) becomes valuable, since some hosts retain automatic daily database snapshots for a rolling window even if you never installed a WordPress backup plugin. Ask your hosting provider whether they keep server-level snapshots before assuming nothing is recoverable.
Recovery Method 5: Ask a Developer or Your Host’s Support Team
If the category was central to your site’s structure, held hundreds of posts, or SEO value is on the line, it’s worth the cost of bringing in someone who does this regularly rather than experimenting on a live production database. A WordPress developer can often reconstruct the term relationships from post revision history or cached versions of your site (Google’s cache and the Wayback Machine can sometimes still show what category a post belonged to). They may also spot a partial backup that a DIY restore process would miss.
Your hosting provider’s support team is also worth contacting, particularly if you’re on managed WordPress hosting. Many hosts keep automated backups going back further than you’d expect, sometimes 30 days or more, independent of any plugin you have installed.
Bulk Reassignment With WP-CLI
If you’re recreating a category and need to reassign it to a large number of posts, doing it one post at a time through the block editor is slow enough that it invites mistakes. If your host gives you SSH access, WP-CLI turns a multi-hour manual slog into a single command.
First, identify the posts that need reassignment. If you know they’re currently sitting in Uncategorized because that’s where WordPress dumped them after the deletion, list them:
wp post list --category=uncategorized --field=IDOnce you’ve confirmed that list is actually the set of posts you want (be careful here if Uncategorized already had legitimate posts in it before the deletion happened), assign the new category to all of them in one pass:
wp post term set <post_id> category "your-category-slug"For a genuine bulk operation across many post IDs, wrap the command in a loop from the command line, or export the ID list to a file and pipe it through a small script. This is also the point where it’s worth double-checking your new category’s slug matches the WP-CLI command exactly, since a typo here silently creates a second near-duplicate category instead of erroring out.
Fixing the SEO Fallout
Even after you restore the category functionally, don’t skip the SEO cleanup. If Google had indexed the old category archive URL and it 404’d for any length of time, check Google Search Console’s Coverage report for crawl errors tied to that URL. If the new category has a different slug than the original (which happens if you didn’t recreate it with an exact slug match), set up a 301 redirect from the old URL to the new one so any lingering backlinks and search rankings aren’t wasted.
Resubmit the category’s XML sitemap entry if your SEO plugin generates one, and manually request re-indexing for the category page through Search Console once it’s live again. This speeds up Google noticing the page is back rather than waiting for the next natural crawl.
Preventing This From Happening Again
Recovery is a one-time fire drill. Prevention is the part that actually saves you time long-term.
Automate your backups and verify them. A backup you’ve never tested restoring is a backup you’re only assuming works. Schedule at least daily backups with UpdraftPlus or BlogVault, and store copies off-site somewhere separate from the server itself, whether that’s Dropbox or a cloud storage bucket like Amazon S3. Test a restore on a staging environment periodically so you know the process actually works when you need it.
Restrict who can delete taxonomy terms. Not every contributor or editor on your site needs the ability to delete categories. Review your user roles under Users and consider tightening permissions with a role management plugin like Members or User Role Editor so that only admins or a trusted senior editor can touch the category structure.
Merge instead of delete when possible. If your real goal is consolidating overlapping categories rather than removing one outright, WordPress lets you reassign a category’s posts to another category before deleting the now-empty one, through the “Categories” list screen’s bulk actions. This avoids the scramble of manually reassigning dozens of posts after the fact.
Keep a taxonomy map. For sites with more than a handful of categories, keep a simple spreadsheet documenting each category’s name, slug, and rough post count. It sounds unnecessary until the day you need to recreate one from memory and realize you’re not sure what the original slug was.
Frequently Asked Questions
Does deleting a category delete the posts inside it?
No. Posts are never deleted when you remove a category. They stay in your database and are automatically reassigned to your site’s default category, which is Uncategorized unless you’ve changed it under Settings > Writing.
Is there a Trash for categories like there is for posts?
Not in core WordPress. Posts and pages get a 30-day Trash period before permanent deletion, but categories and other taxonomy terms are removed immediately when you confirm the delete action. Some third-party plugins add a trash mechanism for taxonomy terms, but it isn’t there by default.
Can I recover a category without any backup at all?
Sometimes. If the deletion only broke the term relationships but left an orphaned row in the terms table (which can happen due to plugin conflicts), a direct database fix in phpMyAdmin can restore it. If the row itself is gone, your options narrow to manual recreation, checking whether your host keeps server-level snapshots independent of any backup plugin, or asking a developer to reconstruct the category from cached versions of your site.
Will recreating a category with the same name give it the same URL?
Only if the new category’s slug matches the old one exactly. WordPress generates the slug from the name by default, but if the original slug was customized, or if WordPress appends a number because it thinks the slug is already in use, you’ll need to manually edit the slug field to match. Check the old URL structure (via your browser history, Google’s cache, or the Wayback Machine) before assuming the auto-generated slug will match.
How long does it take Google to reindex a restored category page?
It varies, typically anywhere from a few days to a few weeks depending on your site’s crawl frequency. Submitting the URL manually through Google Search Console’s URL Inspection tool and requesting indexing speeds this up considerably compared to waiting for a natural recrawl.
Should I use a page builder or custom taxonomy instead of default categories to avoid this risk?
Not really, since custom taxonomies carry the exact same deletion risk as default categories; they’re stored the same way in the database. The actual fix for this risk is process, not a different taxonomy system. Backups and tighter delete permissions cover most of it. The rest is a habit: merge overlapping categories instead of deleting them outright.
The Real Fix Is Prevention
Category recovery is almost always possible if you catch it fast and have a backup to lean on. It gets harder, slower, and more expensive the longer you wait and the fewer safety nets you had running beforehand. If you’ve just been through this and recovered successfully, use it as the prompt to actually set up automated backups and tighten who on your team can delete taxonomy terms. Filing the lesson away and hoping it doesn’t happen twice is how it happens a second time.
Interesting Reads
