To convert WordPress categories to a custom taxonomy, first register the new taxonomy for the relevant post types, then explicitly migrate the category terms and their post assignments. Registration alone does not move existing data. Test term structure, archives, URLs, and site integrations on a copy before making the change on a live site.
What changes when you convert categories?
A taxonomy is a classification system; categories and tags are built-in taxonomies, while a custom taxonomy gives you a separate system with its own name and settings. Its individual entries are called terms. WordPress stores taxonomy terms and the relationships between terms and posts, so creating a custom taxonomy does not automatically transfer category assignments. See the WordPress guide to working with custom taxonomies and its overview of categories, tags, and custom taxonomies.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Professional WordPress: Design and Development | $6.04 | Buy on Amazon |
This distinction matters when, for example, a site needs a “Courses” taxonomy alongside ordinary categories. As WordPress’s Plugin Handbook puts it, “The main advantage of using Custom Taxonomies is that you can reference ‘Courses’ and ‘Ingredients’ independently of Categories and Tags.” A custom taxonomy can be hierarchical, like categories, or flat, like tags.
Plan the migration before changing the site
Inventory existing categories and dependencies
Record the categories and subcategories you intend to move, their slugs and parent-child relationships, and which posts use them. Also note category archive URLs and where the site displays or queries categories, including theme templates, editor blocks, REST API consumers, and plugins. This inventory gives you a baseline for checking the result; the exact dependencies vary by site.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
- Used Book in Good Condition
Choose the destination taxonomy settings
Decide on a unique taxonomy key, its singular and plural labels, and the post types that should use it. Choose hierarchy deliberately: a hierarchical taxonomy supports parent-child terms and category-like selection, while a non-hierarchical taxonomy is closer to tags. Set admin UI, REST API visibility, public querying, archive behavior, capabilities, and rewrite settings to match how the site will use the taxonomy. WordPress documents these options in the register_taxonomy() reference.
Put durable functionality in a plugin
Register the taxonomy in a plugin when it represents site content that should remain available if the active theme changes. WordPress’s Theme Handbook recommends keeping this functionality in a plugin so “when the user changes their website’s design, their content is preserved in the plugin.” See the Theme Handbook’s guidance on custom content types.
Register the custom taxonomy
WordPress’s documented pattern is to call register_taxonomy() on the init action and associate the taxonomy with one or more post types. The Plugin Handbook provides a registration example and explanation of taxonomy settings. Adapt the labels, taxonomy key, post types, hierarchy, visibility, and rewrite behavior to your site rather than copying example values unchanged.
Use a valid, unique taxonomy key and choose a public-facing rewrite slug intentionally. The registered taxonomy must exist before editors can assign its terms or queries can use it. Registration defines the destination system; it does not migrate the source categories or their relationships.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Migrate terms and post assignments explicitly
Plan how each source category maps to a destination term. Decide whether to retain names and slugs, preserve parent-child structure, reuse an existing destination term, and handle categories with no posts. Check for duplicate names or slugs and any term metadata your plugins or custom code rely on.
WP-CLI documents term operations such as creating, listing, deleting, recounting, and managing metadata, as well as a wp term migrate subcommand described as migrating a term from one taxonomy to another. The WP-CLI term command reference does not define a complete site-wide category conversion recipe or guarantee how a migration should handle every collision, hierarchy, metadata field, or assignment. Test the specific command or code path on a copy and compare the result with your inventory.
Test the result and account for URLs
Verify terms, editors, and integrations
- Confirm the taxonomy appears for the intended post types and editors can assign the expected terms.
- Compare term names, slugs, parent relationships, and post assignments with the inventory.
- Check term counts, archives, templates, queries, editor blocks, API consumers, and plugins that previously depended on categories.
These checks matter because taxonomy behavior depends on the registration settings and on the site’s theme, plugins, and custom code. Validate on a staging site or another copy before applying the migration to production.
Compare old and new archive paths
A custom taxonomy can use its own rewrite base and term paths, so its archive URLs may differ from the category URLs it replaces. For example, WordPress’s handbook example uses a /course/ base; your production taxonomy may use another slug. Test both the new paths and the old ones, and arrange redirects where existing links should continue to work.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteWhen rewrite settings change, WordPress says rewrite rules may need to be flushed. Its documented options include resaving the Permalink Settings page; flush once after setting up the taxonomy, not on every page load. See the Plugin Handbook’s taxonomy and rewrite guidance.
Quick Recap
Common pitfalls to avoid
- Assuming registration transfers data: registering a taxonomy creates the destination system, but term and post relationships need a migration step.
- Changing URLs without checking existing links: a new rewrite base can change archive paths; test routing and plan redirects as needed.
- Registering the taxonomy only in a theme: if it is part of the site’s content model, a theme switch could make that functionality unavailable.
- Skipping site-specific checks: templates, queries, plugins, editor integrations, and APIs may depend on categories in ways that are not covered by a generic migration command.
- Running an unverified bulk change on the live site: test the exact migration and confirm terms and assignments on a copy first.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
