WordPress Taxonomies: 5 Types You Need to Know

Master WordPress taxonomies — categories, tags, custom types, and WooCommerce attributes — and build a content architecture that scales without breaking.

What Is a WordPress Taxonomy and Why It Matters

Before diving into the different types of WordPress taxonomies, it’s worth clarifying what a taxonomy actually is. Simply put, a taxonomy is a classification system. WordPress uses it to group related content so that both visitors and search engines can navigate and understand the structure of a site.

Without a well-thought-out taxonomy, a site with 200 or 2,000 posts turns into a jumbled mess. Taxonomy as a discipline has existed since the 18th century, when Linnaeus classified living organisms. WordPress adopted the concept to organize posts, pages, and any custom content type (custom post type).

What many people don’t realize is that WordPress isn’t limited to categories and tags. The taxonomy system is extensible by design, making it possible to create custom classifications for virtually any need. Understanding how the different WordPress taxonomies work — and when to use each one — is the foundation for building a content architecture that scales without friction.

Native WordPress Taxonomies: Categories and Tags

WordPress ships with two taxonomies registered by default for posts: categories (category) and tags (post_tag). Although they may seem similar, they behave differently — and that has direct consequences for navigation, URLs, and SEO.

Categories: Hierarchical Classification

Categories are hierarchical. This means a category can have subcategories (child categories), creating a tree structure. For example:

• Web Development
  • WordPress
  • Shopify
• Design
  • UX/UI
  • Branding

WordPress requires every post to have at least one category assigned. If you don’t assign one manually, the default category is used (typically “Uncategorized”). This ensures that every piece of content has an anchor point within the site’s structure.

On the technical side, each category generates its own archive page with a URL like /category/wordpress/. This means categories function as site sections — something search engines index and rank independently.

Tags: Flat Classification

Tags are non-hierarchical. They have no parents or children — they’re standalone terms that group posts across different topics. If categories are the chapters of a book, tags are the entries in the thematic index at the back.

A post about “How to optimize images in WordPress” might belong to the “WordPress” category and carry the tags “performance,” “images,” and “optimization.” Tags allow cross-connections between different categories.

The common pitfall: many sites create hundreds of tags that are only used once. This generates archive pages that are empty or contain a single post, diluting the site’s authority and confusing crawlers. A practical rule of thumb: a tag should group at least three pieces of content to justify its existence.

Hidden WordPress Taxonomies: Post Formats and Link Types

WordPress internally registers other taxonomies that most users never see in the admin panel. These are known as internal or private taxonomies.

post_format

Post formats are a taxonomy registered with register_taxonomy() just like categories, but marked as internal. They allow posts to be classified as “gallery,” “video,” “quote,” “audio,” and so on. Few modern themes implement them, but they’re technically still present in the WordPress core.

nav_menu

Navigation menus also use an internal taxonomy. Every menu you create under Appearance > Menus is a term within the nav_menu taxonomy. WordPress handles this transparently, but understanding that a menu is technically a taxonomy helps illustrate how flexible the system really is.

link_category

A holdover from older versions of WordPress that included a link manager. It’s deprecated but still registered in the source code — a good example of how WordPress taxonomies evolve alongside the platform.

Knowing about these hidden taxonomies isn’t just an academic exercise: when you’re building custom plugins or themes, you need to know which taxonomy names are reserved in order to avoid conflicts.

Custom WordPress Taxonomies: The Real Power

This is where the different types of WordPress taxonomies truly shine. The register_taxonomy() function lets you create entirely new taxonomies and associate them with any content type.

When You Need a Custom Taxonomy

The key question to ask is: “Do I need to filter or group this content in a way that categories and tags don’t cover?” Here are some real-world examples:

• Project portfolio: a “Project Type” taxonomy (corporate website, e-commerce, landing page) and a “Technology” taxonomy (WordPress, React, Shopify).
• Recipe directory: taxonomies for “Main Ingredient,” “Cuisine Type,” “Difficulty,” and “Preparation Time.”
• Product catalog (without WooCommerce): taxonomies for “Material,” “Color,” and “Season.”
• Knowledge base: taxonomies for “Difficulty Level,” “Related Product,” and “Department.”

Each of these WordPress taxonomies generates its own archive pages, can be exposed as front-end filters, and is queryable via WP_Query or the REST API.

Hierarchical vs. Non-Hierarchical: Decision Criteria

When registering a custom taxonomy, the hierarchical parameter determines its behavior:

• hierarchical = true: behaves like categories. Checkbox interface in the editor, support for parent/child terms. Ideal when the classification has logical levels (e.g., “Location” > “Country” > “City”).
• hierarchical = false: behaves like tags. Free-text field with autocomplete. Ideal for flat, open classifications where there are no levels (e.g., “Skill,” “Ingredient”).

The most common mistake is defaulting to hierarchical “because it looks more organized.” If the terms don’t have a genuine parent-child relationship, a flat taxonomy is more efficient and easier to maintain. This decision directly affects the day-to-day experience of whoever is managing the content.

Key Parameters When Registering a Taxonomy

Beyond hierarchical, there are parameters that many developers leave at their defaults without thinking through the consequences:

• public: Should the taxonomy be visible on the front end and generate archive pages? If it’s for internal use only (e.g., for classifying content in the admin without surfacing it to visitors), set public = false.
• show_in_rest: Required if you want the taxonomy to work with the block editor (Gutenberg) and the WordPress REST API. Without this parameter enabled, the taxonomy will only appear in the classic editor.
• rewrite: Controls the URL structure for archive pages. You can customize the slug, disable pagination, or modify permalink behavior.
• show_admin_column: Adds a column showing assigned terms in the post type list table. A small detail that dramatically improves the editorial experience.

WooCommerce Taxonomies: A Special Case

WooCommerce registers several of its own taxonomies to manage products. It’s one of the best examples of how custom WordPress taxonomies solve complex, real-world needs.

• product_cat: Product categories. Hierarchical. The classic catalog structure.
• product_tag: Product tags. Flat.
• pa_* (product attributes): Each global attribute (color, size, material) is registered as an independent taxonomy with the pa_ prefix. This enables front-end product filtering by attributes and, more importantly, powers the product variations system.
• product_visibility: An internal taxonomy that controls whether a product is featured, excluded from search, or hidden from the catalog.
• product_shipping_class: Shipping classes, used to assign different shipping rates based on product type.

When planning an online store, the design of product taxonomies is one of the decisions with the greatest long-term impact. A catalog with 5,000 products and poorly structured taxonomies becomes unmanageable — both for the editorial team and for the customer trying to find what they’re looking for.

Criteria for Designing WordPress Taxonomies Correctly

Knowing that different types of WordPress taxonomies exist is just the first step. The real challenge is designing a coherent taxonomy system for a specific project. These are the criteria that separate a solid content architecture from a category disaster.

1. Start with Content, Not the Tool

Before touching any code or installing a plugin, take inventory of the content the site will have. How many content types will there be? How does the end user want to navigate them? What filters make sense? Taxonomies should answer real navigation and search needs — not mirror the developer’s mental model.

2. Avoid Redundancy Between Taxonomies

If a category already classifies content by “topic” and you then create a custom taxonomy called “subject” that does the same thing, you’re creating confusion for editors and duplicate content for search engines. Each taxonomy must add a distinct dimension of classification.

3. Plan for Scalability

A taxonomy with 5 terms today could have 500 in two years. Will the system still hold up? Hierarchical taxonomies with many levels of depth (more than three) become difficult to manage. Flat taxonomies with hundreds of terms need solid autocomplete and internal search.

4. Think About SEO From the Start

Every public taxonomy generates indexable URLs. That can be an advantage (well-ranking category pages) or a liability (thin content if archives have very few posts). Decide upfront which taxonomies you want search engines to index and which ones you don’t, using meta robots or your chosen SEO plugin.

5. Document the Usage Rules

If you have an editorial team, you need a document that explains: what taxonomies exist, what each one is for, how many terms can be assigned to a post, and who can create new terms. Without these rules, taxonomies degrade within months.

Common Mistakes When Working with WordPress Taxonomies

After years of working with WordPress, here are the problems I see repeated from project to project:

• Using categories as tags: Creating a category for every keyword instead of using tags or a custom flat taxonomy. The result is a category tree with 200 entries where none has more than two posts.
• Not setting show_in_rest: The taxonomy works in the classic editor but disappears in Gutenberg. Editors get confused, skip assigning the taxonomy, and content gets published unclassified.
• Conflicting slugs: Registering a taxonomy with a slug already used by a custom post type or a native taxonomy. WordPress doesn’t show an error — it simply breaks permalinks silently.
• Forgetting templates: Creating a public taxonomy without designing the corresponding archive template. Visitors land on /project-type/ecommerce/ and see a generic, unstyled list with no context.
• Taxonomies with no associated content: Registering taxonomies “just in case” that no one ever uses. Every empty taxonomy is noise in the admin and potential thin content on the front end.

Taxonomies and Custom Post Types: The Key Relationship

WordPress taxonomies don’t exist in a vacuum. They’re always associated with one or more content types. By default, WordPress links categories and tags to the “post” post type — but when you create custom taxonomies, you can associate them with any post type, including custom ones.

The decision of which taxonomy maps to which post type has deep implications:

• A taxonomy shared across post types allows content of different natures to be grouped under the same term. For example, an “Industry” taxonomy attached to both “Case Studies” and “Blog Posts” creates useful cross-connections for the user.
• A taxonomy exclusive to one post type keeps things cleanly separated. Product attributes (pa_color) only make sense in the context of WooCommerce products; attaching them to blog posts would be illogical.

The key is that the relationship between post types and taxonomies should reflect the logic of the business — not the convenience of the moment.

Plugins vs. Code for Managing WordPress Taxonomies

There are two paths to creating custom taxonomies: GUI plugins (such as CPT UI, Pods, or ACF) or direct code using register_taxonomy() in functions.php or a dedicated plugin.

GUI plugins:

• Advantage: fast for prototyping, accessible to non-technical users.
• Disadvantage: plugin dependency. If the plugin is deactivated, the taxonomies disappear (the data persists in the database, but the taxonomy registration is lost).

Direct code:

• Advantage: full control, no external dependencies, easier to version with Git.
• Disadvantage: requires PHP knowledge and a solid understanding of the official WordPress documentation to avoid errors.

For professional, long-term projects, direct code is usually the most robust option. GUI plugins are excellent for exploring and validating ideas, but in production they add a dependency layer that can become problematic.

Checklist: Taxonomy Design for a WordPress Project

Before registering a single taxonomy, answer these questions:

1. What content types will the site have? List them all.
2. How will users navigate that content? Map the flows.
3. What filters does the front end need? Each filter usually corresponds to a taxonomy.
4. Do native categories cover any of those needs? Don’t duplicate them.
5. For each new taxonomy: is it hierarchical or flat? Justify your choice.
6. How many terms will each taxonomy have in 12 months? In 36?
7. Which taxonomies should be public (indexable) and which should be internal?
8. Do they need to work with Gutenberg and the REST API? Enable show_in_rest.
9. Is there an editorial team? Document the usage rules for each taxonomy.
10. Have you verified that slugs don’t conflict with existing post types or taxonomies?

This checklist prevents 90% of the problems that arise when a project grows and the initial taxonomies fall short or generate conflicts.

Frequently Asked Questions About WordPress Taxonomies

How many custom taxonomies can I create?

There’s no technical limit imposed by WordPress. You can create as many as you need. The real limit is usability: too many taxonomies confuse editors and complicate maintenance. In practice, most projects work well with between 2 and 6 taxonomies per post type.

Do WordPress taxonomies affect site performance?

On their own, not significantly. WordPress stores taxonomies in the wp_term_taxonomy table and relationships in wp_term_relationships, both of which are indexed. Performance issues arise when you run complex queries filtering by multiple taxonomies simultaneously in very large catalogs (tens of thousands of posts). In those cases, database optimization and caching become essential.

Can I convert a category into a custom taxonomy?

Technically yes, but it involves migrating terms and their relationships from one taxonomy to another. Plugins like “Taxonomy Switcher” make the process easier, though you should always take a full backup before any migration of this kind.

What’s the difference between a taxonomy and a custom field?

A taxonomy classifies and groups content: it generates archives, enables filtering and searching. A custom field (meta) stores data specific to an individual post — a price, a date, a URL. If you need to group content by a criterion, use a taxonomy. If you need to store a unique data point for each post, use a custom field.

Do custom taxonomies get lost when I switch themes?

It depends on where they’re registered. If they live in the theme’s functions.php, yes — they’ll be lost when you switch themes. If they’re in a standalone plugin (an mu-plugin or a custom plugin), they persist regardless of the active theme. That’s why the general recommendation is to always register WordPress taxonomies in a plugin, never in the theme.

If you’re planning a WordPress project that requires a solid content architecture — with custom taxonomies, custom post types, and a structure built to scale — you can see how I approach this kind of work on my services page.

// About the author

fernandodomecq

Freelance WordPress developer specializing in WooCommerce, integrations and AI. I write about web projects, agencies and technical best practices.

View all articles →