How to Undelete a WordPress Category

WordPress has no trash bin for categories. When you click Delete under Posts → Categories, the term row is removed from the database immediately, and the posts inside it are quietly moved to your default category. You can still get it back, but the method depends on what you have: a recent backup, a database copy, or only your memory of how the category was set up.

This guide walks through what WordPress actually does when a category is deleted, the three realistic recovery routes (backup restore, targeted database recovery, manual rebuild), how to fix the SEO fallout, and how to make sure it does not happen again.

What WordPress does when you delete a category

Understanding the mechanics tells you what is recoverable. A category lives across three tables:

• wp_terms holds the name and slug.
• wp_term_taxonomy holds the taxonomy type (category), description, parent ID and post count.
• wp_term_relationships links each post ID to the term.

When you delete a category, WordPress runs wp_delete_term() (wrapped by wp_delete_category()). It removes the rows from all three tables. Two side effects matter:

1. Posts are reassigned, not deleted. Any post that would be left with no category at all gets the default category from Settings → Writing (Uncategorized on most sites). A post that also belonged to a second category keeps that one and is not moved.
2. Child categories move up a level. Sub-categories of the deleted term are re-parented to the deleted term’s parent (or become top-level). They are not deleted.

So your posts are safe. What you have lost is the term itself, its slug, its description, any term meta (SEO titles from Yoast, custom fields, category images from a theme), and the relationship rows that said which posts belonged to it. That last part is the painful one on a large site, because WordPress keeps no record of which posts were moved to Uncategorized by the deletion versus which were always there.

Step one: stop and check what you have

Before doing anything in the dashboard, take a fresh backup of the current state. Recovery sometimes involves restoring an older database, and you will want a way back if that goes wrong.

Then answer three questions:

• Do you have a database backup from before the deletion? Check your host’s control panel (most managed hosts keep 14 to 30 days of daily backups), your backup plugin (UpdraftPlus, BlogVault, Jetpack VaultPress Backup, Duplicator), or a staging site that has not been synced recently.
• How many posts were in the category? Ten posts can be reassigned by hand in two minutes. Four hundred posts need a database approach.
• Was the category URL getting traffic? Check Google Search Console → Performance, filter by page containing /category/your-slug/. If it was ranking, the slug and redirect handling matter more than the description text.

Method 1: Restore from a backup (the clean way)

A full restore is the simplest route if the deletion happened minutes ago and nothing else has changed since. On an active site that is rarely true. Restoring a day-old database would also roll back new posts, comments, WooCommerce orders, form entries and user registrations. In most of our client work we avoid full restores for a single deleted term.

The better pattern is a partial restore: pull the old backup onto a staging site, extract only the category data, and import it into production.

1. Restore the pre-deletion backup to a staging environment (most hosts offer one-click staging; UpdraftPlus and BlogVault can restore to a different URL).
2. On staging, go to Posts → Categories and note the exact name, slug, parent and description of the lost category. Hover over it to see the tag_ID in the URL; that is the term_id.
3. On production, recreate the category with the same name, slug, parent and description (see Method 3). Note its new term_id.
4. On staging, export the list of post IDs that belonged to the old category. A WP-CLI one-liner does it:

wp post list --post_type=post --post_status=any --category_name=your-slug --field=ID --format=csv > category-posts.csv

5. On production, reattach those posts to the recreated category:

for id in $(cat category-posts.csv); do
  wp post term add $id category your-slug
done

This keeps everything that happened after the deletion intact and restores only the one relationship you lost. If WP-CLI is not available, the same list can be obtained from phpMyAdmin on staging (see the SQL in Method 2) and reapplied with the bulk edit screen in production.

Method 2: Recover from a database dump with SQL

If you have a .sql file but no staging site, you can read the relevant rows straight out of it. Open the dump in a text editor (or import it into a local MySQL database) and look for the term.

To find the term_id in the old dump:

SELECT t.term_id, t.name, t.slug, tt.parent, tt.description
FROM wp_terms t
JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id
WHERE tt.taxonomy = 'category' AND t.slug = 'your-slug';

Then list the posts that belonged to it:

SELECT tr.object_id
FROM wp_term_relationships tr
JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
WHERE tt.term_id = 123;   -- replace with the term_id from the first query

With those post IDs in hand, recreate the category in production, find its new term_taxonomy_id (Posts → Categories, hover the category, read tag_ID, then look up the matching row in wp_term_taxonomy), and insert the relationships:

INSERT IGNORE INTO wp_term_relationships (object_id, term_taxonomy_id)
VALUES (45, 987), (46, 987), (52, 987);   -- object_id = post ID, 987 = new term_taxonomy_id

Two follow-ups are required after a direct insert. First, the posts are still also attached to Uncategorized, so remove those relationships for the affected IDs if you do not want both. Second, the term count is now wrong; fix it with wp term recount category or by opening and re-saving one post in the category, which triggers wp_update_term_count().

If you did not change the table prefix from wp_, the queries work as written. If your prefix is different, adjust every table name. Back up before running any INSERT or DELETE, and run them in a transaction or on a copy first if you are not comfortable with SQL.

Should you try to reuse the old term_id?

Usually not. Plugins that stored the term_id (Yoast term meta, a theme’s category image option, a menu item pointing to the category) will still reference the old number. If you can insert the term back with its original term_id and term_taxonomy_id, those references resolve again without edits. That is only safe when no new term has taken that ID in the meantime, and it is an advanced move. For most sites, recreating the category and fixing the two or three places that reference it is quicker and less risky.

Method 3: Rebuild the category by hand

No backup at all? You can still get most of the way back, and for small categories this is the fastest option anyway.

1. Go to Posts → Categories → Add New Category. Enter the exact original name and, more importantly, the exact original slug. The slug drives the URL, so getting it right preserves inbound links and rankings. If you are unsure of the slug, check the Wayback Machine, your sitemap history in Search Console, or any internal links that still point at the old URL.
2. Set the parent category if it had one, and paste the description back in if your theme displays it.
3. Go to Posts → All Posts and filter by Uncategorized using the Categories dropdown, then Filter. Raise Screen Options → Number of items per page to 200 to reduce paging.
4. Tick the posts that belong to the restored category, choose Bulk actions → Edit → Apply, tick the category in the Categories box, and click Update. Bulk edit adds the category; it does not remove Uncategorized. If you want Uncategorized gone, Quick Edit each post or run wp post term remove <ID> category uncategorized.
5. Re-add the category to any menus (Appearance → Menus, or the Navigation block in the Site Editor) and widgets that listed it.

Deciding which posts belonged where is the slow part. Sorting Uncategorized by date often helps, because posts that landed there from a deletion cluster around the same publish dates and topics. If you use Yoast or Rank Math, their SEO titles and focus keyphrases can also hint at the original topic grouping.

Comparing the three approaches

Method	Needs	Restores	Risk	Best when
Partial restore via staging	Pre-deletion backup plus staging site	Term, slug, description, every post link	Low	Medium or large categories on a busy site
SQL from a dump	A .sql backup and database access	Everything, including term meta if you copy it	Medium (manual SQL)	You are comfortable in phpMyAdmin and have no staging
Manual rebuild	Nothing	Term and slug; post links only as accurately as you remember them	Low	Under about 30 posts, or no backup exists

Fixing the SEO and navigation fallout

Restoring the term is half the job. The deleted archive URL was returning a 404 while it was gone, and a few things may have drifted:

• Redirects. If you had to use a different slug, add a 301 from the old /category/old-slug/ to the new one. Yoast Premium, Rank Math and the free Redirection plugin all handle this.
• Term meta. Yoast and Rank Math store category SEO titles and descriptions against the term_id. After a rebuild, open the category in Posts → Categories → Edit and re-enter them.
• Sitemaps. Both SEO plugins regenerate category sitemaps automatically. Request reindexing of the archive URL in Search Console → URL Inspection once it returns 200 again.
• Internal links and blocks. Query Loop blocks filtered by category, and category-based widgets, reference the term_id. Open the templates in Appearance → Editor and reselect the category.
• Counts. If the category page shows the wrong number of posts, run wp term recount category.

Preventing the next accidental deletion

We have seen this happen most often on sites with several editors, where someone mistakes the category list for a cleanup task. A few guardrails help:

• Restrict the capability. Deleting categories requires manage_categories. Remove it from the Editor role with a role plugin (Members, User Role Editor) or a short snippet:

add_action( 'init', function () {
    $role = get_role( 'editor' );
    if ( $role ) {
        $role->remove_cap( 'manage_categories' );
    }
} );

Run that once and then remove it; capabilities are stored in the database.

• Log the change. WP Activity Log and Simple History both record term deletions with the user, time, and term name, which is exactly the information you need for a rebuild.
• Keep more database restore points. Daily backups with 30 days of retention cost little. If your host only keeps 7 days, add a plugin-based schedule that stores off-site.
• Snapshot before cleanup sessions. If you are about to reorganise taxonomy, export the term structure first: wp term list category --format=csv > categories-before.csv. It takes one second and makes any rebuild trivial.
• Change the default category. Setting a meaningful default under Settings → Writing means orphaned posts land somewhere visible instead of an “Uncategorized” bucket nobody checks.

FAQ

Does deleting a category delete the posts in it?

No. Posts are reassigned to the default category if they have no other category. Nothing about the post content, comments or meta changes.

Why is there no trash for categories like there is for posts?

Terms have no post_status column, so WordPress has nowhere to mark them as trashed. There have been long-running core tickets discussing a term trash, but as of WordPress 6.9 it does not exist. Capability restrictions and backups are the practical substitute.

Can a plugin undelete a category?

Not after the fact, unless the plugin was already installed and logging or snapshotting before the deletion. Backup plugins with partial restore (BlogVault, UpdraftPlus Premium) are the closest thing, and activity loggers at least tell you what was deleted and when.

Will recreating the category with the same slug bring back my rankings?

Usually yes, if the URL is back within a few days and the same posts are attached. Google treats the URL as the identity, not the internal term_id. The longer the archive 404s, the more likely it drops from the index and has to be re-crawled.

What about custom taxonomies or WooCommerce product categories?

Exactly the same mechanics apply. Product categories are terms in the product_cat taxonomy; deleting one reassigns products to the default product category set under Products → Categories. All the SQL above works with taxonomy = 'product_cat', and WP-CLI uses wp term list product_cat.

Where to start

Check for a backup first. If one exists and the category had more than a couple of dozen posts, do the staging-based partial restore; it is the only method that gets every post relationship back exactly. If there is no backup, recreate the category with the original slug today so the URL stops returning 404, then reassign posts in bulk as you identify them. Either way, take the five minutes afterwards to remove manage_categories from roles that do not need it and add an activity log. If your site has grown to the point where a single click can cause this kind of cleanup, a maintenance plan with off-site backups and monitoring is cheaper than the afternoon you will spend on the next recovery. For the underlying behaviour, the wp_delete_term() reference in the WordPress developer handbook documents the reassignment rules described here.