Custom Taxonomies in WordPress

Browse manual On this page × Wordpress Manual WordPress Fundamentals Toggle WordPress Fundamentals section What Is WordPress? WordPress.org vs WordPress.com What Can You Build with WordPress? How WordPress Works WordPress Core, Themes, Plugins and Content Essential WordPress Terminology How to Plan a WordPress Website Domains, Hosting, DNS and HTTPS Explained How to Choose WordPress Hosting…

3 min read

  • Article
  • 3 minutes read
  • Reviewed August 3, 2026

A custom taxonomy is a classification system registered for the concepts used by a specific website or plugin. It gives editors a predictable vocabulary instead of forcing every project into Categories and Tags.

Examples include Location for events, Industry for case studies, Difficulty for courses and Product Type for a catalogue.

Why Use a Custom Taxonomy?

A named taxonomy communicates meaning. Editors understand that Location and Topic describe different dimensions even if both use a list of terms.

Custom taxonomies can also have separate permissions, interfaces, REST routes, rewrite slugs, templates and archives.

Registering a Taxonomy

Developers use register_taxonomy() and associate the taxonomy with one or more object types. Registration should occur on or before the init action, and relationships should be declared consistently.

add_action( 'init', function () {
    register_taxonomy( 'event_type', array( 'event' ), array(
        'label'        => __( 'Event Types', 'example' ),
        'public'       => true,
        'hierarchical' => true,
        'show_in_rest' => true,
        'rewrite'      => array( 'slug' => 'event-type' ),
    ) );
} );

The Taxonomy Key

The internal taxonomy key is used by code, queries, REST responses and database relationships. Choose a stable, namespaced identifier and avoid changing it after content has been assigned.

The public rewrite slug can be different from the internal key, but it also becomes part of the URL contract.

Hierarchical Behaviour

A hierarchical taxonomy behaves like Categories and can use parent-child terms. A non-hierarchical taxonomy behaves more like Tags and uses a flat vocabulary.

The choice affects both meaning and the default editor interface. Do not choose hierarchy only because one interface looks more convenient.

Associating Taxonomies with Post Types

One taxonomy can classify several post types when the terms have the same meaning across them. A Topic taxonomy might apply to articles, resources and documentation.

Avoid reusing a taxonomy merely because term names look similar. Type for events and Type for products may represent unrelated concepts and should often be separate systems.

Public URLs and Archives

A public taxonomy can generate an archive for each term. Plan whether those pages provide useful navigation and whether they should be indexed.

The archive template should explain the term and present an appropriate query. A default title plus an unfiltered list may not satisfy the visitor’s intent.

Term Metadata

Terms can have metadata such as an icon, colour, image or external identifier. This can support richer archive templates and integrations.

Do not use term metadata to hide a second unrelated object model inside a taxonomy. When the term needs extensive content and workflow, consider a post type.

Capabilities and Term Management

Taxonomies define capabilities for managing, editing, deleting and assigning terms. A user may be allowed to assign existing terms without creating new ones.

This distinction is valuable when a controlled vocabulary must remain consistent across a large editorial team.

REST API and Editor Integration

Setting show_in_rest to true exposes standard taxonomy and term endpoints and supports modern editor interfaces. Applications still need appropriate authentication and permissions for protected operations.

Custom Taxonomy Checklist

  • Define the classification question the taxonomy answers.
  • Choose hierarchical or flat behaviour based on meaning.
  • Create a stable internal key and public slug.
  • Associate only post types that use the same concept.
  • Decide whether terms need public archives.
  • Define who may manage and assign terms.
  • Plan REST exposure and term metadata.
  • Create a vocabulary and duplicate-term policy.

Frequently Asked Questions

Can one custom taxonomy be used by several post types?

Yes. Reuse it when the terms represent the same concept for every associated type.

Can custom taxonomy terms have custom fields?

Yes. WordPress supports term metadata, and interfaces can expose those values to editors.

Do custom taxonomies need public archive pages?

No. A taxonomy can support administration and querying without public term URLs.

Continue Learning

Next: Hierarchical and Non-Hierarchical Taxonomies