core

Taxonomy

A classification system in WordPress that groups content using categories, tags, or custom groupings you define yourself.

A taxonomy is how WordPress organizes content into groups. Think of it like a filing system. Categories and tags are the two taxonomies WordPress ships with out of the box. But you can create your own — and that’s where things get interesting.

Every taxonomy contains individual items called “terms.” In the Categories taxonomy, each category (like “Security” or “Tutorials”) is a term. Simple enough. The real power shows up when you build custom taxonomies tailored to your site’s content.

How It Works

WordPress registers taxonomies and attaches them to post types. Categories and tags are registered automatically for posts. You can register your own with register_taxonomy().

Say you run a plugin review site. You might want a “License Type” taxonomy so visitors can filter plugins by whether they’re free, freemium, or premium. Here’s how you’d register it:

add_action( 'init', function() {
 register_taxonomy( 'license_type', 'post', [
 'labels' => [
 'name' => 'License Types',
 'singular_name' => 'License Type',
 ],
 'public' => true,
 'hierarchical' => false,
 'rewrite' => [ 'slug' => 'license' ],
 ] );
} );

Once registered, this creates:

  • A new meta box in the post editor where you assign license types
  • Archive pages at URLs like yoursite.com/license/freemium/
  • Query parameters so you can filter posts by license type in templates

The hierarchical parameter matters. Set it to true and your taxonomy behaves like categories — parent-child relationships, nested structure. Set it to false and it behaves like tags — a flat list.

WordPress stores taxonomy data across three database tables: wp_terms, wp_term_taxonomy, and wp_term_relationships. The relationship table links terms to posts. This is worth knowing when you’re debugging slow queries on sites with thousands of terms.

Common Use Cases

Filtering products in WooCommerce. WooCommerce uses custom taxonomies for product categories and product tags. It also creates attribute taxonomies (like Size or Color) prefixed with pa_. Every product filter on the frontend queries these taxonomies.

Building a knowledge base. Documentation sites often register taxonomies like “Topic” or “Difficulty Level” to let users drill down to relevant articles. This beats stuffing everything into categories.

Portfolio organization. Designers and agencies create taxonomies like “Industry” or “Service Type” to let visitors browse work by what matters to them — not by date.

Location-based content. Multi-location businesses register a “Location” taxonomy so the same post type can be filtered by city or region. Paired with a custom post type like “Service Area,” this creates structured, queryable content without plugins.

Why It Matters

Taxonomies directly affect your site’s URL structure and internal linking. A well-planned taxonomy creates logical archive pages that search engines can crawl and index. A messy one creates thin pages with duplicate content that dilute your rankings.

From a security perspective, every public taxonomy creates queryable endpoints. I’ve seen sites where developers registered taxonomies with public => true without thinking about what data that exposed. If your taxonomy contains internal classifications — approval status, client tier, anything sensitive — set public to false and show_ui to true. That keeps it in the admin without creating frontend routes.

Performance is the other concern. WordPress runs a JOIN across those three taxonomy tables on every archive query. On a site with 50,000 terms spread across multiple taxonomies, those queries add up. I’ve audited sites where switching from a catch-all taxonomy to a more focused structure cut page load times in half.

Plan your taxonomies before you start publishing. Renaming or restructuring them later means dealing with redirects, broken links, and confused users. Get it right once. Your future self will thank you.

Back to Glossary