WordPress taxonomies beyond posts and pages

WordPress taxonomies beyond posts and pages are one of the most useful parts of the WordPress data model, yet taxonomies are often treated as if they were merely the Category and Tag boxes shown beside a blog post.

They are much more flexible than that.

A taxonomy is a classification system. WordPress can use one to group posts, pages, custom post types and even attachments, which are themselves a built-in WordPress post type.

This means the same underlying taxonomy system that powers blog categories can also organize:

• portfolio projects by industry;
• products by collection;
• events by location;
• documentation by topic;
• properties by region;
• courses by difficulty;
• Media Library attachments by department, project or campaign.

Taxonomies can also be hierarchical like categories or flat like tags, shared between multiple post types, queried through WP_Query, exposed through the REST API and extended with their own metadata.

This guide explains how WordPress taxonomies work beyond standard posts and pages, which object types they can classify, how custom taxonomies are registered, how attachment taxonomies work, how terms are stored and queried, when taxonomies are preferable to custom fields and where the native WordPress taxonomy model stops.

What is a WordPress taxonomy?

A taxonomy defines a way of grouping objects according to shared characteristics.

The two familiar WordPress examples are:

Category
Post Tag

Both classify posts, but they behave differently.

Categories are hierarchical

A hierarchical taxonomy can have parent-child relationships.

For example:

Development
├── WordPress
│   ├── Security
│   └── Performance
└── JavaScript

This creates a tree.

Tags are non-hierarchical

A non-hierarchical taxonomy generally behaves as a flat collection of terms:

wordpress
security
performance
php
javascript

There is no parent-child structure between those terms.

A taxonomy is not the same thing as a term

This distinction matters.

The taxonomy is the classification system:

Genre

The terms are values inside that taxonomy:

Science Fiction
Fantasy
History
Biography

Likewise:

Taxonomy:
Project Industry

Terms:
Healthcare
Finance
Hospitality
Automotive

WordPress categories and tags are only two taxonomies

A common misconception is:

WordPress taxonomies =
Categories + Tags

A better model is:

WordPress taxonomy system
        │
        ├── category
        ├── post_tag
        ├── built-in internal taxonomies
        └── any custom taxonomies
            registered by themes/plugins

Custom taxonomies can classify custom post types

Suppose a site has a custom post type:

project

You could create:

project_industry

with terms:

Healthcare
Retail
Education
Technology

and:

project_service

with terms:

Web Design
SEO
Branding
Ecommerce

Now one project might be classified as:

Industry:
Healthcare

Services:
Web Design
SEO

This is different from creating another post type

A post type answers:

What kind of content is this?

A taxonomy answers:

How should this content be classified?

For the broader distinction between content types, see WordPress post types vs. custom post types.

Post type vs. taxonomy

Consider a real-estate website.

The post type might be:

property

Taxonomies might include:

property_type
property_location
property_feature

with terms such as:

Property Type:
Apartment
Villa
Office

Location:
Rome
Milan
Verona

Features:
Garden
Garage
Pool

The property itself is content.

The terms describe how that content belongs within a classification system.

Custom fields solve yet another problem

A property could also have metadata such as:

price = 450000
bedrooms = 3
floor_area = 140

Those values are generally better represented as structured metadata rather than taxonomy terms.

Taxonomy vs. custom field

A useful distinction is:

TAXONOMY

Designed for:
grouping
classification
filtering
shared reusable values


CUSTOM FIELD

Designed for:
properties
attributes
individual values
structured data

Ask whether the value should be shared between objects

If dozens of properties belong to:

Verona

then:

Location → Verona

works naturally as a taxonomy term.

If one property costs:

€427,500

creating:

Price taxonomy term:
427500

would be an impressive misuse of a perfectly innocent classification system.

The official API is register_taxonomy()

WordPress provides register_taxonomy() for registering taxonomies.

A basic custom taxonomy might look like:

register_taxonomy(
    'project_industry',
    array( 'project' ),
    array(
        'label'        => 'Industries',
        'public'       => true,
        'hierarchical' => true,
        'show_in_rest' => true,
    )
);

The second argument determines the associated post types

In:

register_taxonomy(
    'project_industry',
    array( 'project' ),
    ...
);

the taxonomy is associated with:

project

objects.

One taxonomy can belong to multiple post types

For example:

register_taxonomy(
    'industry',
    array(
        'project',
        'case_study',
        'client'
    ),
    $args
);

Now the same:

industry

taxonomy can classify several different content types.

This can create a shared vocabulary

Suppose the taxonomy contains:

Finance
Healthcare
Retail
Hospitality

A:

project

and a:

case_study

can both use the same:

Healthcare

term.

Shared taxonomies can improve information architecture

Instead of creating:

project_industry
case_study_industry
client_industry

with three duplicated collections of identical terms, one:

industry

taxonomy can sometimes provide a cleaner model.

But sharing a taxonomy should be intentional

Do not reuse a taxonomy merely because two term names happen to look similar.

For example:

Course Level:
Advanced

Customer Segment:
Advanced

probably does not mean these concepts belong to the same taxonomy.

The meaning of a taxonomy should remain consistent

A useful test is:

If I see the term without knowing
the associated post type,
does it still mean the same thing?

If yes, sharing may make sense.

Pages can use taxonomies too

WordPress pages do not use standard post categories and tags by default.

But page is a built-in post type, and a taxonomy can be associated with it.

For example, the existing Category taxonomy can be registered for pages using register_taxonomy_for_object_type():

add_action( 'init', function() {
    register_taxonomy_for_object_type(
        'category',
        'page'
    );
} );

But adding categories to pages is not automatically good architecture

The technical question:

Can WordPress do this?

is different from:

Should this website do this?

Pages often represent relatively stable hierarchical site structure rather than editorial content.

Adding blog-style classification to every page can create unnecessary complexity.

Custom taxonomies can often be cleaner than reusing Category

Instead of applying generic:

category

to a specialized content model, create a taxonomy whose meaning matches the project.

For example:

documentation_section
service_area
project_industry
resource_topic

WordPress taxonomies can classify attachments

This is one of the most useful examples of taxonomies beyond ordinary editorial posts.

WordPress media files are represented by the built-in:

attachment

post type.

The official register_taxonomy() documentation lists attachment among WordPress’s built-in post types.

This means attachments can participate in taxonomies

You can register:

media_category

for:

attachment

and assign terms such as:

Brand
Products
Team
Blog
Campaigns
Downloads

The files do not need to move

This is an important architectural benefit.

Suppose:

/uploads/2026/08/logo.svg

is assigned to:

Brand

The physical file can remain:

/uploads/2026/08/logo.svg

while WordPress stores a taxonomy relationship between the attachment and the Brand term.

Taxonomy organization is logical, not filesystem organization

Conceptually:

Attachment #1842
        │
        ├── file:
        │   /uploads/2026/08/logo.svg
        │
        └── media_category:
            Brand

No folder relocation is required.

This is how Media Categories can organize the Media Library

TheOneWP Media Categories adds a category system around WordPress attachments so administrators can group files without changing attachment IDs or direct file URLs.

Categories can represent concepts such as:

• project;
• department;
• campaign;
• content type;
• brand;
• client;
• workflow.

Why attachment taxonomies are useful

The default Media Library primarily gives you information such as:

• filename;
• date;
• media type;
• uploader;
• attachment relationship.

These fields do not necessarily express the editorial meaning of an asset.

A filename is not an organizational system

Consider:

homepage-final.jpg
homepage-final-2.jpg
client-new.png
banner-old-final.jpg

Now compare a taxonomy structure:

Client:
Acme

Campaign:
Spring 2026

Asset Type:
Hero Image

The second model carries much more useful information.

Attachment taxonomies become valuable at scale

For a Media Library containing:

50 attachments

searching manually is usually manageable.

For:

25,000 attachments

a classification layer can significantly improve retrieval.

See Organizing a large WordPress media library and Keeping a WordPress media library organized at scale for the wider media-management strategy.

WordPress provides attachment-specific taxonomy APIs

The core get_attachment_taxonomies() function retrieves taxonomies associated with a specific attachment.

WordPress also provides get_taxonomies_for_attachments() to retrieve taxonomies registered for attachments generally.

WordPress even recognizes MIME-specific attachment object types

Core’s attachment-taxonomy handling can recognize object type patterns such as:

attachment:image
attachment:video

This allows taxonomy registration logic to become more specific about the kinds of media it targets.

Attachments are not special exceptions to the post model

Internally, many things WordPress users do not normally describe as “posts” are represented using the posts system.

Built-in post types include examples such as:

post
page
attachment
revision
nav_menu_item
custom_css
customize_changeset

This is one reason the WordPress data model can initially seem stranger than the admin interface suggests.

A post type is a database/content-model concept

The word:

post

inside:

post type

does not mean:

blog article

It refers to the broader WordPress content-object system.

This explains why taxonomies can reach beyond blog content

If an object is represented by a supported WordPress post type, it can potentially participate in the taxonomy system where that architecture makes sense.

Not every built-in post type should receive public taxonomies

Technically knowing that:

revision

is a post type does not mean you should immediately invent:

Revision Categories

and unleash them on unsuspecting editors.

Internal post types often exist for implementation purposes rather than editorial classification.

Use taxonomies where classification creates value

Strong candidates include:

• posts;
• pages where appropriate;
• custom post types;
• attachments;
• other editorial object types that genuinely need reusable groupings.

Hierarchical vs. non-hierarchical taxonomies

When registering a taxonomy, one major design decision is:

hierarchical = true

or

hierarchical = false

Hierarchical taxonomies behave more like Categories

For example:

Products
├── Clothing
│   ├── Shirts
│   └── Jackets
└── Accessories
    ├── Bags
    └── Watches

This works well when the classification itself genuinely contains levels.

Non-hierarchical taxonomies behave more like Tags

For example:

red
summer
sale
featured
waterproof

Each term exists at the same conceptual level.

Do not create fake hierarchy merely because WordPress supports it

This:

Italy
└── Red
    └── Featured
        └── PDF

probably represents several unrelated dimensions accidentally forced into one tree.

Use separate taxonomies for separate dimensions

A cleaner model might be:

Country:
Italy

Color:
Red

Status:
Featured

Asset Type:
PDF

Taxonomies are most useful when each one answers a clearly defined classification question.

Term relationships are many-to-many

One object can have multiple terms.

For example:

Project:
Hotel redesign

Industries:
Hospitality
Travel

Services:
Web Design
Branding

And one term can belong to many objects:

Hospitality
├── Project A
├── Project B
├── Case Study C
└── Project D

This makes taxonomies different from a simple field

A field often describes:

this object has this value

A taxonomy creates a reusable relationship network:

many objects
↕
shared terms

How WordPress stores taxonomy data

At database level, the taxonomy system primarily uses tables including:

wp_terms
wp_term_taxonomy
wp_term_relationships
wp_termmeta

wp_terms stores the basic term identity

Conceptually:

term_id:
42

name:
Healthcare

slug:
healthcare

wp_term_taxonomy connects a term to a taxonomy

This layer identifies that:

Healthcare

belongs to:

industry

rather than another taxonomy.

wp_term_relationships connects objects to terms

Conceptually:

Project #500
        ↓
Healthcare term

or:

Attachment #1842
        ↓
Brand term

wp_termmeta stores metadata about terms

Terms can themselves have properties.

For example:

Term:
Brand

Color:
#8044e3

Icon:
folder

Priority:
10

This makes taxonomy systems extensible

Suppose a media-category interface wants each category to have a color.

The color belongs conceptually to:

the category term

not to every attachment assigned to that category.

Term metadata provides a suitable place for that additional information.

WordPress supports term metadata APIs

WordPress provides APIs such as:

get_term_meta()
add_term_meta()
update_term_meta()
delete_term_meta()

and register_term_meta() can define registered term metadata for a specific taxonomy.

Term metadata and object metadata solve different problems

Consider:

Media Category:
Client A

The category’s:

color = purple

belongs to term metadata.

An individual attachment’s:

photographer = Jessica

would belong to attachment/post metadata.

Do not duplicate taxonomy information into every object’s metadata

If 4,000 attachments belong to:

Client A

you generally do not need 4,000 copies of:

client_name = Client A

when a reusable taxonomy relationship is the actual structure you need.

How to retrieve the taxonomies for a post type

WordPress provides get_object_taxonomies().

For example:

$taxonomies = get_object_taxonomies(
    'post'
);

normally returns taxonomies including:

category
post_tag

You can request taxonomy objects instead of names

For example:

$taxonomies = get_object_taxonomies(
    'project',
    'objects'
);

This gives access to information about each registered taxonomy rather than only its slug.

Taxonomies can be attached after registration

Sometimes a taxonomy already exists and another post type needs to use it.

WordPress provides:

register_taxonomy_for_object_type()

for this purpose.

For example:

register_taxonomy_for_object_type(
    'industry',
    'case_study'
);

This is useful in modular plugin architectures

One plugin might register:

industry

while another component later registers:

case_study

The relationship can then be established after both exist.

Registration timing matters

Taxonomies and post types are normally registered on:

init

or through an equivalent correctly ordered initialization flow.

If code attempts to associate a taxonomy with a post type before the relevant objects exist, registration can fail or behave unexpectedly.

Register taxonomies explicitly

A reliable architecture avoids assuming that:

because the taxonomy exists,
the post type automatically knows about it

The relationship should be deliberately registered.

This matters particularly for tax_query

WordPress uses taxonomy relationships in queries through structures such as:

tax_query

Query posts by taxonomy

A basic example:

$query = new WP_Query(
    array(
        'post_type' => 'project',
        'tax_query' => array(
            array(
                'taxonomy' => 'industry',
                'field'    => 'slug',
                'terms'    => array(
                    'healthcare'
                ),
            ),
        ),
    )
);

This asks:

Give me projects
assigned to the Healthcare
industry term.

Multiple taxonomy conditions can be combined

For example:

Industry:
Healthcare

AND

Service:
Web Design

can be expressed using multiple taxonomy-query clauses.

Taxonomies are therefore powerful for filtering interfaces

A frontend could provide:

Industry:
[ Healthcare ]

Service:
[ Web Design ]

Location:
[ Europe ]

and construct a WordPress query based on those selected terms.

This is often cleaner than text search

Text search asks:

Does the content happen to contain
the word Healthcare?

A taxonomy query asks:

Was this object explicitly classified
as Healthcare?

Those are very different questions.

Taxonomy queries also work with attachments

Because attachments are post objects, a taxonomy-based media query can conceptually request:

post_type:
attachment

taxonomy:
media_category

term:
brand

This provides the underlying architecture for filtered media-management interfaces.

Attachment status requires special attention

Attachments generally use:

post_status = inherit

rather than the familiar:

publish

status used by ordinary public posts.

This can matter for taxonomy term counting and custom queries.

For the deeper issue, see WordPress attachment status and term counts, explained.

Term counts are not always as obvious as they appear

A taxonomy term may show a count representing associated objects.

But exactly which objects count can depend on:

• post type;
• post status;
• taxonomy configuration;
• custom callbacks;
• the counting logic used by WordPress.

Do not assume a zero count means no relationship exists

This becomes particularly relevant with attachments and unusual object states.

Inspect the actual taxonomy relationships before building important logic around an administrative count alone.

Taxonomies can have public archives

A public taxonomy can potentially create URLs such as:

/industry/healthcare/

/topic/wordpress/

/location/verona/

These archive pages can list objects associated with the term.

Not every taxonomy needs public URLs

A taxonomy might exist purely for backend organization.

For example:

media_category

may only help administrators organize attachments.

There may be no reason for:

/media-category/brand/

to become a public indexable page.

Separate administrative taxonomy from frontend taxonomy requirements

Ask:

Do visitors need this classification?

Do search engines need this archive?

Or is this purely an editorial tool?

The answer should influence registration arguments such as:

public
publicly_queryable
rewrite
show_ui
show_in_nav_menus

Internal organization does not require indexable archives

A taxonomy can be extremely valuable for editors even when its terms should never become public landing pages.

Public taxonomy archives can be useful for content architecture

For a project portfolio:

/industry/healthcare/

could be a useful landing page containing all healthcare projects.

For another site it might create a thin archive that nobody needs.

SEO value depends on implementation

Taxonomy archives are not inherently:

good SEO

or:

bad SEO

They are URLs.

The relevant questions are whether those URLs provide useful, differentiated, crawlable content and fit the site’s information architecture.

Custom post types and taxonomies should be planned together

See WordPress custom post types and SEO for the broader search implications of custom content structures.

A strong site architecture often begins by mapping:

Content types
↓
Classification systems
↓
Public archives
↓
URLs
↓
Internal linking

Do not create a taxonomy for every possible property

A common custom-development mistake looks like:

color taxonomy
weight taxonomy
width taxonomy
height taxonomy
SKU taxonomy
price taxonomy
stock taxonomy
publication date taxonomy

Some of these are reusable classifications.

Others are clearly metadata.

A taxonomy should normally have a meaningful vocabulary

Good:

Language:
English
Italian
German

Good:

Difficulty:
Beginner
Intermediate
Advanced

Good:

Region:
Europe
Asia
North America

Less compelling:

Word Count:
1847
1923
2011
2038

Use taxonomy for finite or reusable classification dimensions

This is not an absolute rule, but it is a useful design heuristic.

If values are deliberately reused and users benefit from grouping objects by them, taxonomy is often a good candidate.

Use metadata for object-specific properties

See WordPress user meta, explained for a related explanation of WordPress’s metadata model.

The storage layer differs between object types, but the broader architectural question is similar:

classification
or
property?

What about taxonomies for users?

This requires an important clarification.

The native register_taxonomy() object-type relationship is designed around WordPress post types.

Users are not post types.

Therefore WordPress does not provide first-class user taxonomies through the same standard registration path used for:

post
page
attachment
custom post types

Plugins can implement taxonomy-like user systems

Developers can build custom relationships or adapt the taxonomy tables for additional object models.

But this is no longer the ordinary, native post-type taxonomy workflow.

Do not describe custom user taxonomies as if Core supports them exactly like post taxonomies

This distinction matters for:

• queries;
• admin screens;
• REST support;
• capabilities;
• term counts;
• relationship cleanup;
• plugin compatibility.

User meta is often sufficient for user properties

Suppose you need:

Department:
Marketing

for a relatively simple user profile.

User metadata may be sufficient.

If you need complex reusable user classification with term archives, filtering and many-to-many relationships, you need to design that architecture deliberately rather than assuming register_taxonomy() will solve everything.

The same caution applies to comments

Comments are their own WordPress object type rather than a post type.

The standard post-taxonomy registration path does not automatically turn comments into taxonomy-enabled objects.

“Taxonomy can classify anything” is therefore too broad

A more accurate statement is:

WordPress provides a flexible taxonomy
system deeply integrated with post types.

Developers can build additional relationship systems, but those should not be confused with first-class native support.

Taxonomies can be exposed through the REST API

When registering a custom taxonomy, you can use:

'show_in_rest' => true

The official WordPress REST API documentation explains how custom taxonomies can expose REST endpoints.

A REST-enabled taxonomy can support modern interfaces

For example:

/wp-json/wp/v2/industry

or another configured REST base can provide terms to:

• JavaScript interfaces;
• headless frontends;
• mobile applications;
• custom admin screens;
• external integrations.

The taxonomy endpoint exposes structural information too

WordPress REST endpoints can expose information such as:

• taxonomy name;
• description;
• hierarchical status;
• labels;
• associated object types;
• REST base.

The official Taxonomies REST API reference documents that schema.

Term metadata can also participate in the REST API

Registered term metadata can be exposed by configuring:

show_in_rest = true

where appropriate.

This means a taxonomy term can carry more than:

name
slug
description

when the application genuinely needs additional structured data.

REST exposure should be intentional

Do not enable REST visibility merely because it is fashionable to add:

'show_in_rest' => true

to every configuration array.

Consider:

• whether the editor needs it;
• whether a frontend consumes it;
• whether term metadata is sensitive;
• what capabilities control modification;
• how the endpoint fits the application’s architecture.

show_in_rest is particularly relevant to the Block Editor

Modern WordPress editor interfaces rely heavily on REST APIs.

A custom taxonomy expected to integrate into Block Editor workflows generally needs appropriate REST support.

Taxonomy capabilities can be customized

Taxonomy registration includes capabilities controlling operations such as:

• managing terms;
• editing terms;
• deleting terms;
• assigning terms.

Term management and term assignment are different actions

A user might be allowed to:

assign existing industries

without being allowed to:

create or delete industries

This distinction can be valuable in editorial teams.

Do not give term-management capabilities more broadly than required

If every contributor can create:

Healthcare
health-care
Health Care
healthcare-industry
Healthcare 2

your carefully designed taxonomy may rapidly evolve into performance art.

Controlled vocabularies benefit from governance

For important taxonomies, decide:

• who can create terms;
• who can rename terms;
• who can delete terms;
• who can assign existing terms;
• which naming conventions apply.

Taxonomy quality affects search and filtering

A taxonomy containing:

Web Design
web-design
Webdesign
Website Design
Web

may technically work, but editors and frontend filters now need to understand five overlapping concepts.

Plan the vocabulary before the library grows

Changing a taxonomy containing:

20 terms
and
200 relationships

is straightforward.

Cleaning:

6,000 duplicate terms
and
400,000 relationships

is a considerably less charming afternoon.

Taxonomy slugs are technical identifiers

A taxonomy might use:

project_industry

internally while displaying:

Industries

to users.

Do not casually rename taxonomy keys after production launch

Changing:

project_industry

to:

industries

does not automatically migrate every existing relationship to what WordPress now considers a different taxonomy.

The key is part of the data model

Human-facing labels can be changed relatively freely.

The registered taxonomy slug/key should be treated much more carefully.

Term slugs matter for public URLs

If a public taxonomy uses:

/industry/healthcare/

changing the term slug to:

health-sector

can change the public URL.

Plan redirects for important public taxonomy URL changes

Classification refactors can therefore become URL migrations.

This is another reason backend taxonomy architecture and frontend SEO architecture should not be designed independently.

What happens when a post changes post type?

This becomes particularly interesting when content already has taxonomy relationships.

Suppose:

Post #500

Post type:
post

Category:
WordPress

and you convert it into:

documentation

The relationship may remain stored even when the destination type does not use that taxonomy

The database relationship and the currently registered post-type/taxonomy relationship are related but distinct concepts.

This means post-type conversion needs deliberate taxonomy handling.

See What happens to taxonomies when you change post type for the detailed behavior.

Post Type Converter must account for taxonomy architecture

TheOneWP Post Type Converter handles content restructuring where taxonomy relationships may need to be preserved, mapped, removed or otherwise considered during conversion.

This is why post type conversion is not simply changing one database string

A content object participates in a broader model involving:

post type
taxonomies
metadata
URLs
templates
capabilities
archives

Shared taxonomies can make conversion easier

If both:

post

and:

documentation

use:

topic

then existing topic relationships can remain conceptually meaningful.

Unshared taxonomies require a decision

If:

post

uses:

category

but:

documentation

uses:

documentation_section

then you need to decide whether to:

• remove old relationships;
• preserve them internally;
• map terms;
• create equivalent terms;
• leave them untouched for rollback.

Taxonomy design therefore affects future migrations

A clean reusable classification model makes content restructuring easier years later.

Taxonomies can drive navigation

A term archive can become a navigation destination.

For example:

Industries
├── Healthcare
├── Finance
├── Retail
└── Hospitality

could form part of a site’s navigation architecture.

But a taxonomy does not automatically deserve a menu item

Some taxonomies exist purely to:

• filter admin interfaces;
• power recommendations;
• organize assets;
• build application logic.

Public navigation should reflect visitor needs, not the fact that a developer successfully called register_taxonomy().

Taxonomies can power related-content systems

Suppose an article has:

Topic:
WordPress

Difficulty:
Advanced

A recommendation system can retrieve other content sharing those terms.

Shared terms create explicit semantic relationships

This can be more reliable than attempting to infer every relationship from text similarity alone.

Taxonomies can also power faceted filtering

An ecommerce-like directory could expose:

Region
Industry
Service
Technology

as separate filter dimensions.

Be careful with excessive combinations

If every possible combination produces an indexable public URL:

region/europe/
region/europe/?industry=healthcare
region/europe/?industry=healthcare&service=seo
...

the site can create enormous numbers of low-value crawlable states.

Classification architecture and indexation architecture are separate

A taxonomy may be useful internally without every filter combination becoming:

an SEO landing page

Keep public taxonomy archives intentional

Strong public archives usually have:

• a clear search intent;
• useful introductory content;
• meaningful child content;
• stable internal links;
• purposeful metadata.

Taxonomies can simplify templates

A template can ask:

Is this project in Healthcare?

rather than inspecting arbitrary strings inside custom fields.

But do not use term names as authorization rules

This:

if term == "Private"
then block access

is not automatically a robust authorization architecture.

Taxonomies classify content.

Access control should rely on explicit permission logic.

Media categories demonstrate this distinction clearly

A media taxonomy might classify:

Internal Assets

but the taxonomy itself does not make those files private.

For the difference between visibility and file protection, see Hiding vs. restricting access to WordPress media.

Media Visibility can use category structure for another purpose

TheOneWP Media Visibility can work with Media Categories to apply visibility rules to groups of attachments.

The taxonomy defines:

which files belong together

while visibility logic defines:

which roles should see them
inside supported media interfaces

This is a good example of taxonomy as infrastructure

A single classification layer can support:

• organization;
• filtering;
• bulk management;
• visibility rules;
• administrative workflows.

The taxonomy itself remains focused on classification.

What happens when a taxonomy is unregistered?

If plugin code that registers a taxonomy disappears, WordPress no longer knows that taxonomy during normal execution.

That does not necessarily mean every underlying database row is immediately deleted.

Unregistering and deleting taxonomy data are different operations

Conceptually:

Unregister taxonomy
→ WordPress no longer exposes it normally

Delete terms/relationships
→ remove stored taxonomy data

Do not assume disabling a plugin performs a complete data cleanup unless the plugin explicitly does so.

This matters when removing taxonomy plugins

Before deleting a plugin that owns an important taxonomy, determine:

• which post types use it;
• how many terms exist;
• how many relationships exist;
• whether public URLs depend on it;
• whether another plugin will register the same taxonomy;
• whether the data needs migration.

Taxonomy ownership should live in the right component

If a taxonomy is essential to the site’s content model, it usually belongs in:

a site-specific plugin
or
a durable application component

rather than only in a theme.

Why avoid theme-only taxonomy registration?

Suppose a theme registers:

project_industry

and the site accumulates:

3,000 projects

using that taxonomy.

Then somebody changes the theme.

The underlying content model should not disappear merely because the site’s typography changed.

Content architecture should generally survive theme changes

A theme controls presentation.

Core business content structures generally belong somewhere more durable.

Taxonomy registration checklist

Before registering a taxonomy, decide:

• What exactly does it classify?
• Which post types should use it?
• Should terms be hierarchical?
• Should the taxonomy be public?
• Should term archives exist?
• Should rewrite rules exist?
• Should it appear in the admin?
• Should it appear in the REST API?
• Who can create terms?
• Who can assign terms?
• Will term metadata be needed?
• Will multiple post types share the vocabulary?

Taxonomy modeling checklist

• Use a taxonomy for reusable classification.
• Use metadata for object-specific properties.
• Avoid duplicate taxonomies representing the same concept.
• Avoid one taxonomy representing several unrelated dimensions.
• Use hierarchy only when a real hierarchy exists.
• Plan term naming conventions.
• Control who may create new terms.
• Treat taxonomy keys as durable technical identifiers.
• Plan public URLs before publishing archives.
• Do not assume every taxonomy requires an indexable frontend archive.

Attachment taxonomy checklist

• Remember that attachments are a WordPress post type.
• Use attachment taxonomies for logical organization rather than moving files unnecessarily.
• Preserve attachment IDs when classification changes.
• Preserve direct URLs unless another workflow intentionally changes them.
• Check attachment inherit status when investigating counts.
• Apply taxonomy filters consistently in Grid and List interfaces.
• Do not mistake taxonomy membership for file access control.
• Consider category-based visibility as a separate permission layer.

Common WordPress taxonomy mistakes

Assuming taxonomies mean only Categories and Tags

Those are simply the two most visible built-in examples.

Creating a custom post type when you only need classification

A new content type and a new taxonomy solve different problems.

Using custom fields for every shared classification

You can lose the reusable term and relationship model taxonomies already provide.

Using taxonomies for arbitrary numeric values

Not every value deserves to become a term.

Creating one enormous taxonomy for unrelated attributes

Separate concepts deserve separate dimensions.

Adding standard categories to every post type automatically

Technical possibility is not architecture.

Making every taxonomy public

Backend organizational taxonomies do not necessarily need frontend archives.

Allowing everyone to create terms

Controlled vocabularies stop being controlled surprisingly quickly.

Renaming taxonomy keys after launch

A taxonomy slug is part of the stored data model, not merely a label.

Assuming taxonomy archives are automatically useful for SEO

Thin archives remain thin archives regardless of how elegantly they were registered.

Assuming attachments cannot use taxonomies

Attachments are a built-in WordPress post type and can participate in the taxonomy system.

Assuming Media Library categories move physical files

Taxonomy relationships are logical organization and do not require filesystem relocation.

Assuming user taxonomies are first-class Core taxonomies

The standard taxonomy/object-type registration path is centered on post types. User classification needs its own deliberate architecture.

Assuming disabling a taxonomy plugin deletes its data

Registration state and stored relationships are separate concerns.

Ignoring taxonomy compatibility during post-type conversion

Existing term relationships may no longer belong to taxonomies registered for the destination post type.

A practical taxonomy decision tree

Do multiple objects share
the same reusable value?
│
├── No
│   └── Consider metadata
│
└── Yes
    │
    └── Do you need grouping,
        filtering or relationships
        around that value?
        │
        ├── Yes
        │   └── Consider a taxonomy
        │
        └── No
            └── Metadata may still
                be simpler

A second decision tree: taxonomy or post type?

Does this represent
a piece of content?
│
├── Yes
│   └── Consider a post type
│
└── No
    │
    └── Does it classify
        pieces of content?
        │
        ├── Yes
        │   └── Consider taxonomy
        │
        └── No
            └── Consider metadata
                or another model

A third decision tree: public or internal?

Do visitors need taxonomy pages?
│
├── Yes
│   └── Consider public archives,
│       URLs and SEO
│
└── No
    └── Keep taxonomy focused
        on administration/filtering

Example: portfolio website

Content:

Post type:
project

Classification:

Industry:
Healthcare
Finance
Hospitality

Service:
Web Design
Branding
SEO

Technology:
WordPress
Laravel
React

Properties:

Completion date
Project budget
Client URL

The model now separates:

content
classification
metadata

cleanly.

Example: online course platform

Post type:

course

Taxonomies:

Subject
Difficulty
Instructor Specialty

Metadata:

duration
price
lesson_count

Example: Media Library

Post type:

attachment

Taxonomy:

media_category

Terms:

Brand
Products
Blog
Client A
Client B
Downloads

Metadata:

alt text
image metadata
attachment metadata
custom workflow values

Example: documentation site

Post type:

documentation

Taxonomies:

documentation_section
product
version

Metadata:

last_reviewed
minimum_version
estimated_reading_time

Example: events website

Post type:

event

Taxonomies:

event_type
location
audience

Metadata:

start_date
end_date
ticket_price
venue_address

The taxonomy system is ultimately about relationships

The power of a taxonomy is not that WordPress displays another metabox.

It is that the site gains a reusable semantic relationship:

Object A
Object B
Object C
        ↓
shared term
        ↓
a meaningful group

That relationship can then power many interfaces

The same taxonomy can support:

• admin filtering;
• frontend archives;
• related content;
• navigation;
• faceted search;
• REST applications;
• bulk actions;
• media organization;
• workflow rules.

Related WordPress taxonomy and content-structure guides

For the wider WordPress content-modeling, taxonomy and Media Library cluster, continue with:

• WordPress post types vs. custom post types
• WordPress custom post types and SEO
• What happens to taxonomies when you change post type
• WordPress attachment status and term counts, explained
• Organizing a large WordPress media library
• Keeping a WordPress media library organized at scale
• WordPress Media Library: grid view vs. list view
• WordPress user meta, explained
• Hiding vs. restricting access to WordPress media
• Media Categories
• Media Visibility
• Post Type Converter

Final thoughts

WordPress taxonomies are not merely the Category and Tag controls beside a blog post.

They are a reusable relationship system for classifying WordPress post-type objects.

That includes standard posts and pages, but it also includes custom post types and built-in post types such as attachments. This is why the same underlying taxonomy architecture can organize portfolios, directories, documentation, products and entire Media Libraries.

The most important design decision is knowing when a taxonomy is actually the right model.

If a value describes what an individual object is like, metadata may be better.

If a reusable term describes what multiple objects belong to, taxonomy is often the cleaner choice.

TheOneWP Media Categories provides a practical example: attachments remain at their original file paths and keep their attachment IDs, while taxonomy relationships create an organizational layer that can support filtering, bulk management and other Media Library workflows.

The same principle scales to custom content architecture. A well-designed taxonomy gives WordPress a vocabulary. Objects can then share that vocabulary consistently across queries, archives, REST APIs and administration interfaces.

Just resist the temptation to turn every field into a taxonomy because register_taxonomy() happened to work. If your taxonomy eventually contains 17,000 unique prices, invoice numbers and timestamps, the API has not failed you. You have merely discovered that WordPress will often let humans express terrible ideas with impeccable technical consistency.