Custom Taxonomies in WordPress: Modelling Content Properly

Ask whether visitors or editors need a stable set of shared values and a way to retrieve items assigned to each value. An industry grouping can serve both a project filter and a curated archive. A client's purchase-order number usually describes one item and does not need a term page.

Some values require more thought. A location could be a shared taxonomy when visitors browse regional resources, or structured metadata when the application needs coordinates and distance queries. A price is generally numeric data with range logic, not thousands of individual terms. Choose the model from the operations you need rather than the appearance of the editing field.

Sketch sample content and queries before registration. Include an item with several terms, an unclassified item and a term with no items. Decide whether the grouping is editorial, public or both. The custom fields comparison helps distinguish storage choices from the interface a plugin happens to provide.

<?php
/** Plugin Name: Example Project Topics */
add_action( 'init', function () {
    register_taxonomy( 'acme_project_topic', array( 'acme_project' ), array(
        'labels' => array(
            'name' => 'Project topics',
            'singular_name' => 'Project topic',
        ),
        'public' => true,
        'hierarchical' => true,
        'show_in_rest' => true,
        'show_admin_column' => true,
        'rewrite' => array( 'slug' => 'project-topic' ),
    ) );
} );

Keep content-model registration independent of presentation when the data should survive a theme change. A small site-specific plugin can register the taxonomy, its labels and its capabilities in version control. A maintained registration UI plugin can also be suitable when its configuration is delivered and recoverable.

The illustrative example attaches a prefixed taxonomy to an existing prefixed project post type. Replace the example post type with the one your site actually registers. The taxonomy identifier and the URL slug serve different purposes; choose both deliberately and avoid collisions with existing pages, post types or another plugin.

This example exposes a public taxonomy with REST support and an admin column. That is appropriate only if those are the intended requirements. An internal classification may need different public and query settings. A plugin containing this snippet still needs the normal project review, activation process and compatibility checks for the site's supported WordPress versions.

A hierarchical taxonomy can express parent and child relationships, while a flat taxonomy behaves more like tags. The hierarchy should describe the content rather than act as a substitute for page layout. Test whether editors can consistently choose the intended term without creating near-duplicates such as Health care and Healthcare.

Write useful singular and plural labels and decide who can create, edit and assign terms. The default capability mapping may not match a custom editorial role. REST exposure makes the taxonomy available to supported API and editor workflows; it does not bypass the need for permissions on writes. Test with the real editor role as well as an administrator.

Agree naming and deletion rules before importing terms. A controlled list may suit a business catalogue better than letting every author create new labels. If several post types share the taxonomy, check the editing experience and the meaning of terms across all of them. Sharing a taxonomy is a data decision, not merely a convenient way to reuse a dropdown.

A public taxonomy can create term archive URLs, so decide what those pages will show. A page listing one unrelated item with no context may not be a useful search destination. A curated industry page with relevant projects, a clear description and navigation can serve a distinct purpose.

Check the applicable template hierarchy for the theme type. Classic themes can use taxonomy templates in PHP; block themes use the supported block-template hierarchy. Confirm the actual selected template rather than assuming that a filename in the wrong directory will be loaded. Include pagination, empty results and an appropriate heading.

Refresh rewrite rules through a supported one-time activation or permalink-settings step when the registration or URL structure requires it. Do not flush rewrite rules on every request. Before launch, check the chosen base against existing URLs. After launch, changing the base may require an old-to-new redirect map and internal-link updates.

$projects = new WP_Query( array(
    'post_type' => 'acme_project',
    'posts_per_page' => 12,
    'tax_query' => array( array(
        'taxonomy' => 'acme_project_topic',
        'field' => 'slug',
        'terms' => array( 'healthcare' ),
        'include_children' => false,
    ) ),
) );

Use a taxonomy query when the classification is stored as taxonomy relationships. Decide whether a query matches any selected term or all selected terms, and whether child terms should be included. A hierarchical term picker and a filter UI can imply different behaviour unless those rules are written down.

The example queries one term slug on the illustrative project post type and deliberately excludes descendants. It is not a universal query for every site. If the archive should include child topics, choose that behaviour explicitly. Add appropriate pagination and inspect performance with representative data instead of loading every matching item at once.

Taxonomy relationships can avoid some inappropriate metadata-query patterns, but they do not guarantee that every query is fast. The number of conditions, result size, other filters and database configuration still matter. Measure the actual archive and any custom filters. Keep term IDs, slugs and labels distinct when exchanging data through integrations.

Choose which archives provide distinct useful content and should be discoverable. Check titles, descriptions, canonical URLs and pagination behaviour for those destinations. Avoid assuming that creating a taxonomy is an SEO improvement by itself; it can also create many thin or overlapping pages.

If a classification is internal, configure its public behaviour accordingly. If a public archive should not be indexed, use a coherent indexing policy through the site's supported SEO controls and verify the actual response. A robots.txt block can prevent a crawler from seeing a noindex instruction, so those controls need to be considered together.

Review overlap with ordinary pages and product or blog categories. Two destinations with almost identical purpose may need consolidation or clearer roles. The duplicate-content guide explains those decisions. A canonical signal should reflect the actual preferred resource, not hide an unresolved content-model problem.

Before a bulk import, migrate a small set of representative items into staging. Check term creation, assignment, hierarchy and updates, including what happens if an incoming label changes. Keep a mapping from the old values to the new terms so the process can be reviewed and repeated safely.

Verify the editor controls with the intended role, the REST representation where needed, public archives, filters and a missing term URL. Confirm that switching presentation does not remove the registration. Keep a backup and a tested recovery approach before changing production relationships or URL structures.

Document who owns the term vocabulary and how a new term is approved. Include the rewrite base, template location and query assumptions in the handover. A successful registration call is a small part of the deliverable. The result should be a model that editors understand and future developers can query without reconstructing an undocumented convention.