A taxonomy in WordPress is a system for grouping content. The word comes from the science of classification, and that is exactly what taxonomies do: they let you sort posts into named groups called terms, so that visitors and search engines can find related content in one place. WordPress ships with three visible taxonomies built in: categories, tags and post formats. Categories and tags are the two you work with daily, and they follow different rules that are worth understanding, because misusing them is one of the most common structural mistakes on WordPress sites. On top of the built-in ones, developers can register custom taxonomies for any content type, which is where taxonomies turn from a blogging feature into a serious information architecture tool.
What is a taxonomy in WordPress?
Technically, a taxonomy is a named grouping system, and the individual entries inside it are called terms. The taxonomy is the drawer cabinet, the terms are the drawers. The category taxonomy might contain the terms News, Tutorials and Reviews; the tag taxonomy might contain hundreds of small keywords. Posts get terms assigned, and WordPress automatically generates an archive page for every term that lists all content carrying it, at URLs like /category/tutorials/ or /tag/security/.
WordPress registers several taxonomies out of the box:
- Categories (internal name category): hierarchical, can have parent and child terms, mandatory for posts.
- Tags (internal name post_tag): flat, no hierarchy, entirely optional.
- Post formats (internal name post_format): a fixed set of presentation hints like aside, gallery or quote, used by some classic themes and largely irrelevant in block themes.
- Internal taxonomies such as nav_menu, which WordPress uses under the hood to store navigation menus. You never touch these directly, but they show how central the taxonomy system is to WordPress itself.
Categories vs tags: what is the difference?
The classic analogy still works best: categories are the table of contents of your site, tags are the index at the back of the book. Concretely:
| Categories | Tags | |
|---|---|---|
| Structure | Hierarchical, parent and child terms | Flat, no hierarchy |
| Required? | Yes, every post gets at least one (the default category if none is chosen) | No, completely optional |
| Scope | Broad sections, the site structure | Specific details of a single post |
| Typical count | A handful for the whole site | Many across the site, few per post |
| Default URL | /category/term/ | /tag/term/ |
If a post about a WooCommerce security update lands in the category Security, its tags might be woocommerce, update and vulnerability. The category answers the question which section of the site the post belongs to. The tags answer what the post specifically mentions.
How to use categories and tags correctly
The taxonomy system does not enforce discipline, so sites accumulate structural debt over the years. These rules keep it clean:
- Keep categories few and stable. A handful of categories, ideally between five and ten for a typical site, defined once and rarely changed. If you regularly need a new category, your categories are too specific.
- One category per post as the default. Two is acceptable when a post genuinely belongs to two sections. More than that usually means the categories overlap and should be merged.
- Rename the default category. Fresh installations assign Uncategorized to every post without a category. Rename it to something real in Settings, or set a sensible default, because Uncategorized archives on a live site look exactly as neglected as they are.
- Tags are for repetition, not description. Before creating a tag, ask whether other posts will ever share it. A tag used by a single post creates an archive page with one entry and helps nobody.
- Never duplicate a category as a tag. A Security category plus a security tag produces two competing archives for the same topic.
- Prune occasionally. Merging synonymous tags (woo, woocommerce, woo-commerce) and deleting orphaned terms is boring and worth it.
What are term archive pages, and why do they matter for SEO?
Every term automatically gets an archive page, and these pages are indexable content. That cuts both ways. Well-maintained category archives are strong landing pages: they collect topical content under a descriptive URL and concentrate internal links, which is exactly what search engines reward. Neglected term archives do the opposite. Dozens of one-post tag archives are thin content, and several near-identical tag archives compete with each other and with your category pages for the same queries.
Practical consequence: treat category archives as first-class pages (some themes let you add an intro text to them, which is worth doing), and be deliberately stingy with tags. Many SEO plugins let you set tag archives to noindex if the tag system has already grown wild, which is a defensible cleanup move, but the better long-term fix is tag discipline. Details on how indexing directives work are in our robots.txt and meta robots articles.
How to create a custom taxonomy in WordPress
Custom taxonomies shine in combination with custom post types. A book post type with a genre taxonomy, a portfolio with a client-industry taxonomy, an event type with a venue taxonomy: whenever content needs its own classification apart from blog categories, register_taxonomy() is the tool. The WordPress developer handbook documents every argument; the essential registration looks like this:
// Register a hierarchical genre taxonomy for the book post type
add_action( 'init', function () {
register_taxonomy( 'genre', 'book', array(
'labels' => array(
'name' => 'Genres',
'singular_name' => 'Genre',
),
'hierarchical' => true, // true behaves like categories, false like tags
'public' => true,
'show_in_rest' => true, // required for the block editor
'rewrite' => array( 'slug' => 'genre' ),
) );
} );Two arguments deserve attention. hierarchical decides whether the taxonomy behaves like categories (checkbox tree in the editor) or like tags (free text field). show_in_rest must be true for the taxonomy to appear in the block editor at all, which is one of the most common why-is-my-taxonomy-missing bugs. Like custom post types, taxonomy registrations belong in a plugin rather than the theme, so the structure survives a theme switch.
How InspectWP helps you keep your site structure healthy
Taxonomy problems surface as SEO problems: thin archive pages, competing URLs, missing canonical signals. The InspectWP report checks the SEO fundamentals that decide how well your structure is understood by search engines, including the canonical tag, the robots meta directives, the XML sitemap and the heading hierarchy of the crawled page. If you are restructuring categories or cleaning up years of tag growth, a report before and after the cleanup shows you that the technical signals still point the right way.