Generate a working register_taxonomy() call
Fill in the form and it writes the PHP for you — labels, rewrite rules, REST support and all. Everything runs in your browser; nothing is uploaded.
Paste the result into your theme's functions.php or, better, a small site-specific plugin. The section below explains the decisions the form is asking you to make, because two of them are very hard to reverse later.
Taxonomy or custom field?
Use a taxonomy when the value is shared across posts and worth browsing by — "Genre", "Brand", "Difficulty". Each term gets its own archive page and its own URL.
Use a custom field when the value is unique to one post and nobody would ever want a list of everything sharing it — a price, a serial number, an event date. Making that a taxonomy generates thousands of near-empty archive pages, which is a genuine SEO problem rather than a tidiness one.
The decisions that matter
The taxonomy key is permanent in practice
It is stored against every term relationship in the database. Change it later and every existing assignment silently disappears — the terms remain, but nothing is attached to them any more.
Rules: maximum 32 characters, lowercase, letters, numbers and underscores only. Avoid post_tag, category, type, name, and author, which WordPress reserves. Prefixing your own (acme_genre) prevents collisions with plugins that register a taxonomy of the same obvious name.
Hierarchical or flat
Hierarchical behaves like categories: parent and child terms, checkbox interface. Flat behaves like tags: a free-text field where editors type and terms are created on the fly.
The practical difference is who is entering the data. A flat taxonomy handed to several editors produces "Sci-Fi", "Sci Fi" and "scifi" as three separate terms within a week. If the vocabulary should be controlled, make it hierarchical even when you never intend to nest anything — the checkbox UI is what keeps it clean.
Show in REST
Required for the block editor. Without it, your taxonomy simply will not appear in the Gutenberg sidebar, and the usual reaction is to assume the registration code is broken. It also exposes the taxonomy to the REST API for headless front ends and JavaScript.
Leave it on unless you have a specific reason to keep the taxonomy out of the API.
If your term archives 404
This is the most common problem after adding a taxonomy, and it is not a bug in your code. WordPress caches its rewrite rules; a new taxonomy adds URL patterns that the cache does not yet contain.
Fix: visit Settings → Permalinks and press Save once. That regenerates the rules. No settings need to change.
Do not call flush_rewrite_rules() on every page load, which plenty of tutorials suggest. It is an expensive database write on every single request. Flush on plugin activation, or by hand.
Where to put the code
- Register on the
inithook. Earlier and WordPress is not ready; later and the taxonomy is missing when queries run. The generated code does this already. - Prefer a site-specific plugin over functions.php. Code in a theme dies when the theme is switched — taking your content structure with it. A tiny plugin survives redesigns.
- Register the taxonomy before you attach it to a custom post type, or the association silently fails.
- Save permalinks once after adding it.
Related tools
- Custom Post Type Generator
Create the post type this taxonomy will be attached to.
- wp-config.php Generator
Turn on safe debug logging while you develop the registration code.
Frequently asked questions
Why do my taxonomy archive pages return 404?
WordPress caches rewrite rules, and a newly registered taxonomy adds URL patterns the cache does not include yet. Go to Settings then Permalinks and click Save once - you do not need to change anything. If archives still 404 afterwards, check that the taxonomy is registered on the init hook and that its rewrite slug does not collide with an existing page slug.
Should I use a taxonomy or a custom field?
A taxonomy if the value is shared between posts and people would want to browse everything that shares it - genre, brand, region. A custom field if the value belongs to one post alone, like a price or a serial number. Turning unique values into taxonomy terms creates a large number of archive pages with one post each, which dilutes your site rather than organising it.
Can I change the taxonomy key later?
Not safely. The key is stored against every term relationship in the database, so renaming it in code detaches every existing assignment - the terms survive but nothing is linked to them. Changing it requires a database migration. Choose the key carefully at the start, keep it under 32 characters, and prefix it to avoid clashing with plugins.
Why doesn't my taxonomy appear in the block editor?
Almost always because show_in_rest is not enabled. The block editor talks to WordPress through the REST API, so a taxonomy that is not exposed there never renders in the sidebar even though the registration is otherwise correct. Enable it in the form above and regenerate the code.
Where should the generated code go?
A small site-specific plugin is better than the theme's functions.php. Content structure should not depend on which theme is active - if the registration lives in a theme and someone switches it, the taxonomy disappears and every assignment becomes invisible. A plugin with a few lines in it survives redesigns.
Maintained and reviewed
Last reviewed 2026-07-21. Generated code targets current WordPress taxonomy registration, including REST support for the block editor.