What happens to taxonomies when you change post type

What happens to taxonomies when you change post type depends on how the source and destination post types are registered. Changing a WordPress post from one type to another does not automatically guarantee that its categories, tags or custom taxonomy relationships still make sense afterward.

A post may belong to taxonomies that the destination post type does not support. Another post type may use different taxonomies that happen to contain terms with similar names. Some relationships may need to be preserved, some mapped, some recreated and others removed entirely.

This is why changing a post type should be treated as a content migration rather than a one-column database edit.

This guide explains how WordPress connects post types and taxonomies, what happens to existing term relationships when a post type changes, why unsupported taxonomy relationships can remain in the database, how to decide whether terms should be kept, matched, mapped or dropped and what else should be reviewed during a post type conversion.

What is a taxonomy in WordPress?

A taxonomy is a system for grouping or classifying WordPress content.

The two most familiar built-in taxonomies are:

• Categories;
• Tags.

WordPress can also register custom taxonomies for custom content structures.

Examples include:

Property Type
Location
Brand
Course Topic
Documentation Version
Portfolio Category

The official WordPress custom taxonomies documentation explains how taxonomies can be used to organize different kinds of content.

Taxonomies are registered for specific object types

A taxonomy does not automatically apply to every post type on a WordPress site.

When a taxonomy is registered, WordPress associates it with one or more object types.

For example:

category
→ post

post_tag
→ post

A custom taxonomy might instead be registered as:

property_type
→ property

The official register_taxonomy() documentation explains that the taxonomy registration includes the object types the taxonomy applies to.

WordPress also provides register_taxonomy_for_object_type() for attaching an already registered taxonomy to another object type.

A post type and its taxonomies are separate structures

This distinction is essential.

A WordPress post contains a post_type value.

For example:

post
page
product
portfolio
course
documentation

Taxonomy relationships are stored separately.

Conceptually:

Post ID 123
Post type: post

Terms:
Category → Tutorials
Category → WordPress
Tag → Security

Changing:

post_type = post

to:

post_type = page

does not automatically inspect whether the new post type supports category or post_tag.

Changing post_type alone can leave old taxonomy relationships behind

This is the part that often surprises developers.

Imagine a standard post:

Post:
WordPress Security Guide

Post type:
post

Categories:
Security
Tutorials

Tags:
WordPress
Hardening

Now suppose the database value is changed directly:

post_type:
post → page

Standard WordPress pages do not normally use Categories or Tags.

However, merely changing the post_type value does not inherently mean every existing term relationship has been cleaned up.

The result can be a page that still has historical category and tag relationships in the taxonomy tables even though the Page editing interface no longer exposes those taxonomies.

Why can unsupported term relationships still exist?

WordPress stores object-term relationships separately from the registration that determines where a taxonomy is available.

The wp_set_object_terms() documentation describes how WordPress creates relationships between an object ID and taxonomy terms.

The taxonomy registration separately determines which object types are supposed to use that taxonomy.

This means:

Relationship exists in database

and:

Taxonomy is registered for current post type

are related concepts, but they are not the same fact.

How can you check which taxonomies belong to a post type?

WordPress provides get_object_taxonomies().

For example:

$taxonomies = get_object_taxonomies( 'post' );

might return:

category
post_tag

The official get_object_taxonomies() documentation explains that the function returns the taxonomies registered for a requested object type.

A conversion system can therefore compare:

Source taxonomies
vs.
Destination taxonomies

before changing anything.

Example: converting a Post to a Page

Consider:

Source type:
post

Taxonomies:
category
post_tag

and:

Destination type:
page

Taxonomies:
none by default

If you convert the content to a Page, several questions appear immediately:

• Should the old categories remain attached?
• Should tags be removed?
• Should any terms be copied somewhere else?
• Does the destination use a custom taxonomy that could represent the same classification?

There is no universal correct answer.

That is why a safe converter needs an explicit taxonomy strategy.

Example: converting between two custom post types

Suppose the source type is:

course

with:

course_category
difficulty

and the destination type is:

tutorial

with:

tutorial_category
difficulty

Now the situation is different.

The difficulty taxonomy is shared and may be preserved directly.

But:

course_category

does not automatically become:

tutorial_category

even if both contain terms such as:

Beginner
WordPress
Development

The taxonomy names are different and WordPress treats them as separate classification systems.

Matching by term name can sometimes make sense

Imagine:

Source taxonomy:
course_category

Term:
WordPress

and:

Destination taxonomy:
tutorial_category

Existing term:
WordPress

A migration tool may decide to match the source term to the destination term based on its name.

This produces:

course_category: WordPress
        ↓
tutorial_category: WordPress

The relationship changes, but the human classification remains conceptually similar.

Matching by name is not always safe

Two terms with identical labels do not necessarily mean the same thing.

For example:

Source taxonomy:
Department

Term:
Support

and:

Destination taxonomy:
Article Type

Term:
Support

The same word represents completely different concepts.

Blindly matching terms because the labels happen to be identical can therefore produce logically incorrect classification.

Explicit taxonomy mapping is safer for complex conversions

A more deliberate conversion can define mappings such as:

Source:
course_category → WordPress

Destination:
tutorial_topic → WordPress

or:

Source:
property_region → Veneto

Destination:
location → Verona Area

This requires more work, but it preserves meaning instead of merely preserving strings.

Sometimes the correct choice is to drop the taxonomy relationship

Not every piece of source metadata belongs on the destination post type.

Suppose:

Source:
News Article

Taxonomy:
News Desk

Term:
Politics

is converted into:

Documentation

The original editorial desk classification may have no meaning in the documentation system.

In that case, removing the old relationship is cleaner than forcing it into an unrelated destination taxonomy.

TheOneWP Post Type Converter uses four taxonomy strategies

TheOneWP Post Type Converter analyzes the taxonomy differences before changing the post type and allows a decision to be made for each taxonomy.

The available strategies are conceptually:

• Keep: preserve the relationship where the taxonomy is compatible with the destination;
• Match: find corresponding destination terms by name;
• Map: explicitly map source taxonomy terms to destination taxonomy terms;
• Drop: remove taxonomy relationships that should not survive the conversion.

This avoids treating every taxonomy relationship as though it should automatically follow the post.

Keep is appropriate for shared taxonomies

Suppose both post types use:

topic

and the original content has:

topic:
Performance

If the same taxonomy is registered for both source and destination types, the term relationship can often remain valid.

The important point is that the taxonomy itself is genuinely shared.

WordPress can register one taxonomy for several post types

A taxonomy is not restricted to exactly one post type.

For example:

topic
→ post
→ guide
→ documentation

can be a perfectly valid architecture.

The register_taxonomy_for_object_type() API exists specifically to associate an existing taxonomy with another object type.

If two types deliberately share the taxonomy, preserving those terms during conversion is much simpler.

Match can reuse corresponding destination terms

Match mode becomes useful when the destination uses a different taxonomy but the classification vocabulary is similar.

For example:

Source taxonomy:
blog_category

Source term:
Performance

Destination taxonomy:
guide_topic

Destination term:
Performance

The conversion can associate the content with the destination’s existing Performance term rather than leaving it connected to a taxonomy that the new post type does not use.

Map is useful when taxonomies are structurally different

Sometimes there is no simple one-to-one name relationship.

For example:

Source:
service_category → Web Development

Destination:
department → Digital

Source:
service_category → SEO

Destination:
department → Marketing

These relationships require a deliberate mapping.

Automatic matching would not know that the concepts should be translated this way.

Drop is important because preservation is not always correct

Migration tools sometimes assume that preserving more data is always safer.

It is not.

Keeping irrelevant taxonomy relationships can leave the database carrying classifications that:

• are no longer exposed in the editor;
• cannot be meaningfully queried through the destination type;
• produce confusing future migrations;
• misrepresent the content;
• create misleading term counts or archive expectations.

Clean removal can be more correct than historical baggage.

Term relationships and term existence are different things

Removing a post’s relationship to a term does not necessarily mean deleting the term itself.

For example:

Term:
Performance

Used by:
Post A
Post B
Post C

If Post A is converted and no longer belongs to that taxonomy, removing its relationship should not delete Performance when Posts B and C still use it.

WordPress separates the taxonomy terms themselves from the object-term relationships.

Do not delete terms just because one converted post stops using them

A migration should normally operate on relationships rather than globally deleting taxonomy terms.

Otherwise converting one post could unintentionally modify the classification of hundreds of unrelated posts.

This is especially dangerous on large editorial sites where terms are widely shared.

Taxonomy archives may be affected by conversions

Taxonomies can create public archive URLs.

For example:

/category/security/

/topic/performance/

If a large number of posts move away from a taxonomy, those archive pages may change significantly.

They could:

• contain fewer entries;
• become empty;
• lose important content;
• stop serving a useful search intent.

For the broader SEO implications of custom taxonomy archives, see WordPress custom post types and SEO.

Check taxonomy archive URLs before bulk conversion

Suppose a taxonomy page currently ranks and receives traffic:

/category/wordpress/

If hundreds of Posts are converted to a custom post type that no longer participates in category, the archive may suddenly lose most of its content.

The conversion may therefore affect more than the individual post URLs.

Review important taxonomy archives before a large migration.

Taxonomy term counts can change

WordPress keeps counts associated with taxonomy terms.

If relationships are removed or moved, term counts need to reflect the new set of associated objects.

WordPress’s taxonomy APIs update these relationships and counts as terms are added or removed.

Using normal WordPress APIs is therefore safer than manually deleting arbitrary rows from taxonomy tables.

Do not edit wp_term_relationships blindly

WordPress taxonomy storage spans several related tables.

Direct SQL changes can work, but they bypass the abstraction and hooks WordPress normally uses to maintain relationships and caches.

For normal development, functions such as wp_set_object_terms() and related APIs provide a safer way to update object-term relationships.

Changing post type can also change the permalink

Taxonomies are only one part of a post type conversion.

Consider:

Source:
post

URL:
/blog/example/

converted to:

Destination:
guide

URL:
/guides/example/

The content may preserve most of its metadata while still receiving a completely different public URL.

That requires a redirect decision independently of the taxonomy migration.

301 vs. 302 vs. 410: which redirect to use explains which response should be used when URLs move or disappear.

Permanent permalink changes normally need a 301

If the converted content permanently moves from:

/blog/example/
→
/guides/example/

the old address should normally redirect to the new one.

Post Type Converter can integrate with Redirect Manager to create a 301 when the conversion changes the permalink.

For the complete process, see How to migrate WordPress URLs safely.

Post hierarchy may also stop making sense

Taxonomies are not the only post-type-specific property.

A Page may have a parent:

Services
└── Web Development

If that child Page is converted to a non-hierarchical post type, the parent relationship may no longer be valid for the destination.

A good conversion tool needs to analyze that separately from taxonomy relationships.

Page templates can become invalid

A Page may use:

template-services.php

After conversion to another post type, that page template may not apply or may not even appear in the destination editing interface.

Again, changing the post type alone does not tell WordPress how every dependent property should be transformed.

Post formats may become irrelevant

Some post types support post formats while others do not.

A source Post might have:

Format:
Gallery

If the destination type does not support post formats, retaining that metadata may provide no useful behavior.

Sticky status is another post-specific property

WordPress Posts can be marked sticky.

A custom post type or Page may not use the same concept.

Post Type Converter therefore treats conversion as a larger compatibility analysis rather than assuming every source property belongs on the destination.

Featured images usually survive because they are not taxonomy terms

A featured image is stored as post metadata rather than as a taxonomy relationship.

Changing the post type does not inherently require removing it.

However, whether the destination template actually displays that featured image is a separate design question.

Custom fields usually survive too, but meaning can change

Custom fields are also separate from taxonomies.

For example:

price
duration
subtitle
location

may remain attached to the same post ID after a conversion.

But the destination type may not use those fields.

Preserving data and preserving semantic meaning are not the same thing.

Why keeping the same post ID matters

A post type conversion can often keep the same underlying WordPress post ID.

For example:

Before:
ID 123
post_type = post

After:
ID 123
post_type = guide

This means metadata, featured images and other relationships can remain associated with the same object unless the conversion explicitly changes them.

Taxonomy compatibility still needs to be evaluated because the destination post type may not support the same classification systems.

Analyze taxonomies before bulk conversion

For one post, a taxonomy mistake is inconvenient.

For 5,000 posts, it becomes a migration project.

Before bulk conversion, identify:

• source taxonomies;
• destination taxonomies;
• taxonomies shared by both types;
• source-only taxonomies;
• destination-only taxonomies;
• term name overlaps;
• terms requiring explicit mapping;
• relationships that should be removed.

Create a taxonomy conversion matrix

A simple planning table can be represented as:

Source taxonomy      Destination          Action

category             guide_topic          Match
post_tag             none                 Drop
difficulty           difficulty           Keep
department           business_area        Map

This makes the migration logic explicit before data starts changing.

Do not assume Categories and Tags should always be preserved

Standard Posts often accumulate years of categories and tags.

When converting that content into a purpose-built post type, carrying every historical classification into the new structure may defeat the purpose of the new architecture.

A cleaner migration may deliberately consolidate or remove old taxonomy relationships.

Sometimes adding the taxonomy to the destination is the correct solution

Suppose:

post
→ uses topic

guide
→ does not use topic

but after reviewing the architecture you decide Guides should also participate in the same topic taxonomy.

Instead of mapping the terms elsewhere, you can register that taxonomy for the destination post type.

WordPress supports this through register_taxonomy_for_object_type().

The resulting design becomes:

topic
→ post
→ guide

and existing topic relationships can remain meaningful.

Do not register taxonomies for a post type only to avoid migration work

Architecture should drive registration.

If the destination post type conceptually should not use Categories, attaching Categories merely so old relationships remain visible creates technical convenience at the expense of a coherent content model.

Ask whether editors and visitors genuinely need that taxonomy on the new content type.

Taxonomies affect WordPress queries

Taxonomy relationships are often used by templates and custom queries.

For example:

Show all guides
where guide_topic = security

If a conversion fails to move the relevant terms into guide_topic, the converted posts may disappear from that listing even though the posts themselves still exist.

Taxonomies can affect navigation and filtering

Sites commonly use taxonomy terms for:

• filter interfaces;
• archive navigation;
• related content;
• faceted search;
• breadcrumbs;
• URL structures;
• dynamic menus.

A taxonomy migration error can therefore appear as a frontend navigation bug rather than an obvious database problem.

Check related-content systems after conversion

If a related-content component groups posts by shared taxonomy terms, converted content may stop appearing if those relationships change.

Test:

• related posts;
• archive pages;
• filters;
• search facets;
• breadcrumbs;
• dynamic blocks.

Do not limit QA to opening the converted post itself.

Taxonomy changes can affect SEO

Search engines do not care about WordPress’s internal database terminology, but they do care about the public architecture produced from it.

Changing taxonomy relationships can alter:

• archive pages;
• internal links;
• breadcrumbs;
• crawl paths;
• sitemap membership;
• related-content links.

WordPress custom post types and SEO covers those broader effects.

Check XML sitemap behavior after structural changes

If custom taxonomy archives are included in the site’s XML sitemap, changing the content associated with those terms can alter the value of those archive URLs.

Review whether the affected taxonomies should remain included.

TheOneWP XML Sitemap provides controls for supported post types and taxonomies in sitemap output.

Review SEO metadata for the destination post type

A newly converted post type may have different SEO configuration.

Check:

• SEO title behavior;
• meta descriptions;
• canonical URLs;
• robots directives;
• Open Graph metadata;
• structured data.

TheOneWP SEO Meta provides these controls across selected WordPress post types.

Take a backup before bulk post type conversion

A conversion can affect:

• post type;
• taxonomy relationships;
• hierarchy;
• templates;
• post formats;
• sticky status;
• permalinks;
• redirect rules.

That is enough moving parts to justify a backup.

TheOneWP Backup Manager can create a recovery point before large structural changes.

Test the conversion on staging first

For high-volume migrations, test the process on a staging copy.

Check:

• taxonomy mapping;
• new edit screens;
• frontend templates;
• archives;
• URLs;
• redirects;
• sitemaps;
• queries;
• filters.

WordPress staging site best practices covers how to isolate this kind of structural testing from production.

A practical post type taxonomy conversion workflow

A safe workflow can look like this:

1. Identify the source post type.
2. Identify the destination post type.
3. List the taxonomies registered to both.
4. Identify shared taxonomies.
5. Identify incompatible taxonomies.
6. Decide which relationships should be kept.
7. Decide which terms can be matched by name.
8. Create explicit mappings where required.
9. Drop relationships that no longer make sense.
10. Check hierarchy, templates, formats and sticky state.
11. Calculate whether the permalink changes.
12. Create a 301 if the public URL moves permanently.
13. Test archives and taxonomy-based queries.
14. Check sitemap and SEO output.
15. Verify the converted content on the frontend.

Example: Post to Guide

Suppose:

Source:
post

Taxonomies:
category
post_tag
topic

and:

Destination:
guide

Taxonomies:
guide_category
topic

A migration plan might be:

category
→ guide_category
→ Match terms by name

post_tag
→ no equivalent
→ Drop

topic
→ topic
→ Keep

If the URL changes:

/blog/example/
→ /guides/example/

create a 301 from the old permalink to the new one.

Example: Page to Landing Page

Suppose both source and destination have no public taxonomies.

Then taxonomy migration may require no action at all.

However, you still need to review:

• parent hierarchy;
• page template;
• URL structure;
• custom fields.

The absence of taxonomy complexity does not make every other post-type property disappear.

Example: Product to Archive Item

Suppose:

Source:
product

Taxonomies:
product_cat
product_tag
brand

becomes:

Destination:
archive_item

Taxonomies:
brand
archive_category

You might decide:

brand
→ Keep

product_cat
→ Map to archive_category

product_tag
→ Drop

This is a content-model decision, not merely a technical conversion.

Common post type taxonomy migration mistakes

Changing only the post_type database column

Taxonomy compatibility is never reviewed.

Assuming old terms disappear automatically

Existing relationships can remain even when the destination does not expose the taxonomy normally.

Keeping every taxonomy by default

Some source classifications have no meaning for the destination.

Matching terms only by name

Identical labels can represent different concepts.

Deleting taxonomy terms instead of relationships

Other posts may still depend on those terms.

Ignoring taxonomy archives

Bulk conversions can dramatically change archive content.

Ignoring frontend filters

Converted posts may disappear from taxonomy-based interfaces.

Ignoring permalink changes

A technically successful conversion can still leave the old URL returning 404.

Ignoring custom post type SEO settings

The destination type may have different canonical, sitemap or metadata behavior.

Running a large conversion directly on production

Apparently testing on thousands of live records remains irresistible to some members of our species.

Post type taxonomy conversion checklist

• List source taxonomies.
• List destination taxonomies.
• Identify taxonomies shared by both types.
• Identify source-only taxonomies.
• Identify destination-only taxonomies.
• Review existing terms.
• Keep shared relationships where appropriate.
• Match terms only where the meaning is genuinely equivalent.
• Map structurally different taxonomies explicitly.
• Drop relationships that no longer make sense.
• Do not delete shared terms unnecessarily.
• Check term archive pages.
• Check taxonomy-based queries and filters.
• Check breadcrumbs and related content.
• Review hierarchy and parent relationships.
• Review page templates.
• Review post formats and sticky state.
• Check custom fields.
• Check permalink changes.
• Create a 301 when a permanent URL move occurs.
• Review XML sitemap behavior.
• Review SEO metadata.
• Test the migration on staging.
• Create a backup before bulk conversion.

Related WordPress post type and taxonomy guides

For the other parts of restructuring WordPress content, continue with:

• WordPress custom post types and SEO
• 301 vs. 302 vs. 410: which redirect to use
• How to migrate WordPress URLs safely
• Post Type Converter
• Redirect Manager
• XML Sitemap
• SEO Meta
• Backup Manager

Final thoughts

Changing a WordPress post type does not automatically transform its taxonomy structure into something appropriate for the destination.

Post types, taxonomy registrations and object-term relationships are separate parts of WordPress. A relationship can exist historically even when the destination post type no longer exposes that taxonomy, which is why a conversion needs to inspect compatibility rather than blindly changing post_type.

TheOneWP Post Type Converter handles that decision explicitly through keep, match, map and drop strategies for taxonomies, while also checking other post-type-specific properties and whether the permalink changes.

If the destination genuinely shares a taxonomy, keep it. If another taxonomy contains equivalent terms, match or map them deliberately. If the old classification no longer makes sense, remove the relationship instead of carrying historical clutter into the new content model.

The safest conversion is not the one that preserves the greatest possible number of database rows. It is the one that preserves the meaning of the content after its type changes.