EmDash CMS treats taxonomies differently than WordPress. Instead of a freeform system where you create categories and tags as loose terms, EmDash makes every taxonomy part of a content type’s schema. You define the structure first, then assign content to it. That shift changes how you organize content—and it eliminates the mess of orphaned terms and inconsistent tagging that plagues most WordPress sites after a few years.
This guide walks through creating custom taxonomies in EmDash, explains why the schema-first approach wins for data integrity, and addresses the one real objection: “But WordPress taxonomies are simpler for non-technical users.”
EmDash's taxonomy model is not just a technical choice—it's a philosophy.
What Makes EmDash Taxonomies Different
WordPress has two built-in taxonomies: categories and tags. You can register custom taxonomies via register_taxonomy()codecodecode in PHP. Terms are stored in a separate table (wp_termscodecodecode) and linked to posts via wp_term_relationshipscodecodecode. There’s no enforced schema—a term is just a name and slug. You rely on plugins like Advanced Custom Fields to add metadata to terms.
EmDash inverts this model. Every “taxonomy” is actually a field on a content type. You create a content type (e.g., “Product”), then add a field of type “Select” or “Relationship” that points to another content type (e.g., “Category”). The category itself is a content type with its own fields—description, image, SEO meta. This means:
- Terms are structured content. A category can have a featured image, a custom URL pattern, or a hierarchical parent-child relationship natively.
- No separate taxonomy table. Data lives in the same storage layer as every other content type. Exports, imports, and backups treat everything consistently.
- Validation at the schema level. You cannot assign a term that doesn’t exist. No orphaned references.
The built-in “Categories” and “Tags” content types in EmDash are pre-configured examples of this pattern. You can use them as-is or create your own.
Creating a Custom Taxonomy Step by Step
This process assumes you have EmDash running locally or on Cloudflare. The admin interface is at /admincodecodecode.
Step 1: Create the Term Content Type
Navigate to Admin → Content Types and click Create new content type. Name it “Category” or whatever your taxonomy is—”Department,” “Genre,” “Region.” EmDash automatically generates a plural label and slug.
Add fields that define the term. At minimum:
- Title (auto-generated)
- Slug (auto-generated from title)
- Description (rich text or plain text)
- Featured Image (media field)
- Parent Category (relationship field, pointing to the same content type) — for hierarchy
Save the content type. You now have a structured term repository.
Step 2: Add the Taxonomy Field to Your Main Content Type
If your main content type is “Post” or “Project” or “Product,” go to Admin → Content Types, edit that content type, and add a new field.
Choose a field type that suits your taxonomy:
- Select (single) — for a one-to-one relationship (e.g., every post belongs to exactly one department).
- Relationship (many) — for many-to-many (e.g., a post can have multiple tags).
- Checkboxes — for a fixed list of predefined options.
Configure the field to reference the “Category” content type you created. You can also limit the selection to a specific subset by adding a filter condition.
Step 3: Populate Terms
Go to the content type for your terms (e.g., “Categories”) and create entries. Each entry is a full content item: title, description, image, parent. You can manage them just like posts.
Step 4: Assign Terms to Content
When editing a post or project, the taxonomy field appears as a select or relationship picker. Select the terms you want. Because the terms are content types, you can also use EmDash’s API or MCP server to assign them programmatically.
Using EmDash’s Built-in Categories and Tags
EmDash ships with two content types: “Categories” and “Tags.” They work out of the box. You can customize their fields, rename them, or delete them if they don’t fit your model.
The key advantage: if you need a hierarchical taxonomy like WordPress categories, you add a “Parent” field (relationship to self) on the Category content type. If you need a flat taxonomy like tags, you leave it without hierarchy. Both are content types—no separate code required.
The Defensible Position: Schema-First Taxonomies
Here’s the position I’ll defend: EmDash’s schema-first approach to taxonomies is superior to WordPress’s freeform system for any site that will be maintained for more than six months or will have multiple content authors.
In WordPress, categories and tags are easy to create—any author can type a new tag on the fly. That convenience is also the problem. Over time, you accumulate:
- Misspelled tags (“WordPress,” “wordpress,” “wp”)
- Duplicate categories (“News,” “Latest News,” “Breaking News”)
- Orphaned terms after posts are deleted
- Inconsistent formatting (“SEO,” “seo,” “Search Engine Optimization”)
Fixing this mess requires migration scripts or manual cleanup. In most agency migration projects from WordPress, taxonomies often accumulate thousands of orphaned terms that require manual cleanup. I’ve seen projects where 40% of tags had zero posts attached. EmDash prevents this at the architectural level. You define the terms upfront. Authors cannot create new terms on the fly—they must pick from the curated list. That enforces consistency without requiring discipline.
The Strongest Counterargument
Critics will say: “WordPress’s freeform taxonomy creation is simpler for non-technical users. A content author shouldn’t need to ask a developer to create a new tag. That kills editorial agility.”
It’s a fair point. In WordPress, an editor can type “NewProduct” as a tag and it appears instantly. In EmDash, someone with the appropriate role must create a new term content item first.
Why that argument fails for any serious content operation: The editorial agility gained by letting anyone create terms is outweighed by the data quality cost. Every tag or category is a structural element of your site. Terms drive navigation, filters, related content queries, and SEO metadata. A misspelled or duplicate term breaks all of those. The 30 seconds it takes to create a new category in EmDash is a trivial overhead compared to the hours of cleanup later. Moreover, EmDash’s admin is not locked to developers. You can grant “Contributor” or “Author” roles the ability to create new term entries. The process is a few clicks—not a code change. The real friction is cultural, not technical.
Managing Taxonomies via Code or Agents
EmDash is built for programmatic management. If you prefer to define taxonomies in code rather than the admin UI, you can:
- Create a content type definition in your Astro configuration file (e.g.,
astro.config.mjscodecodecode). - Define fields and relationships there.
- Deploy the changes. The content type appears in the admin automatically.
The built-in MCP server means AI coding agents can create or modify taxonomies on your behalf. You can say: “Add a ‘Region’ content type with fields for name, slug, and a parent region relationship.” The agent reads the skills file and executes the change.
Best Practices for Custom Taxonomies in EmDash
- Use content types, not loose fields. If you need a “Department” taxonomy, create a Department content type, not a text field on posts. This keeps data normalized.
- Add a description field. Even for simple tags, a brief description helps authors choose correctly.
- Set up hierarchical relationships explicitly. Use a self-referencing relationship field for parent-child taxonomies.
- Limit term creation to editors or above. Use user roles to control who can create new term entries.
- Plan for portability. EmDash stores taxonomies as structured JSON. If you ever migrate to another system, the data is self-documenting and machine-readable.
Closing: The Shift Toward Structured Taxonomies
EmDash’s taxonomy model is not just a technical choiceaa—it’s a philosophy. Content is not a dumping ground of unstructured text and arbitrary tags. Every piece of metadata has a defined shape. As AI agents become the primary content managers (writing posts, generating summaries, organizing archives), structured taxonomies are the difference between a system that can be automated and one that requires constant human oversight. EmDash taxonomies are built for that future. The current version (0.1.0) already supports the core patterns; the missing pieces are tooling and community plugins, not the architecture itself.
- How do EmDash taxonomies differ from WordPress?EmDash makes every taxonomy a field on a content type, while WordPress stores terms in a separate table with no enforced schema.
- What are the steps to create a custom taxonomy in EmDash?First, create a term content type with fields like title, slug, description, and parent category. Then, add a field to your main content type that references the term content type.
- Can AI agents manage taxonomies in EmDash?Yes, EmDash's built-in MCP server allows AI coding agents to create or modify taxonomies on your behalf.
