Create terms and organize content

Retagging and recategorising is one of the jobs MCP is genuinely good at: tedious by hand, mechanical enough to delegate, and mostly reversible.

It also has one irreversible operation, so read to the end before starting.

The tools

All the writes need Allow content writes open and manage_categories on the acting user for term management.

Read the existing vocabulary first

List the existing categories and tags with their IDs and post counts, then stop.

This is the step that prevents the most common problem: an assistant creating "News", "news" and "Company News" because it did not know what already existed.

The counts also tell you which terms matter. A tag on one post from 2019 is not part of your taxonomy in any meaningful sense.

Decide who may create terms

State it explicitly, because the default behaviour is to create what is missing:

Only use the categories that already exist. If a post does not fit any, tell me rather than creating a new one.

Or, when creating is intended:

You may create new tags, but list the ones you intend to create and wait for me to approve them.

An unbounded retagging job with permission to invent terms will reliably produce a messier taxonomy than it started with.

Retagging a set of posts

The shape that works:

1. Count first. wp_count_posts, or list the target set with IDs.
2. Pilot. Do three, show the results, stop.
3. Check the three in WordPress.
4. Continue in batches, with the same boundaries.

Add the "maintenance" tag to the first three posts in the Guides category, show me which ones, then stop.

Writes are capped at 20 per minute, so a large job is paced regardless. Use the pacing to check rather than waiting.

Be explicit about adding versus replacing

"Set the categories" and "add a category" are different operations with different consequences. If existing terms must survive, say so:

Add the "seasonal" tag. Leave all existing tags and categories in place.

Ask for the current terms before the change, so you can restore them if the result is wrong.

Renaming versus creating

Renaming a term with wp_update_term keeps every post attached to it. Creating a new term and moving posts across is a different operation with a different outcome — and leaves the old term behind.

If the goal is "call this something else", rename. If the goal is "split these posts into two groups", create.

Renaming changes the term's slug only if you change it explicitly; a changed slug changes the archive URL, which breaks inbound links.

Deleting terms is the irreversible one

wp_delete_term removes the term and detaches it from every post. The posts survive; the classification does not, and there is no trash for terms.

Before deleting:

• Check the post count. A term with 200 posts is a structural change, not a cleanup.
• Know what happens to those posts. Do they need another term instead?
• Do it on staging first if the term is used by templates, menus or archive pages.

Show me how many posts use the "Uncategorised" tag before deleting anything.

Hierarchy

Categories can nest; tags cannot. When creating a child term, confirm the parent — an assistant that misses the parent argument creates a top-level term with the right name and the wrong position, which looks correct in a list and wrong on the site.

After a taxonomy change

• Check an archive page for one of the affected terms on the front end.
• Check any menu item pointing at a term archive still resolves.
• Purge the cache. Archive pages are exactly what a page cache holds.

See Clear the POM Cache.

Common problems

Related

• Taxonomy tools
• Recover from a failed write