Tags and categories start out as a helpful shortcut: a way to group content, power filters, and give editors a shared vocabulary. Then the site grows. A few people add “How-To,” someone else adds “How to,” another adds “Guides,” and soon every list page feels incomplete because half the content is filed under slightly different words.
The problem is rarely the CMS. It is usually the lack of a simple, enforceable model. The goal is not a perfect information architecture that predicts every future content type. The goal is a taxonomy that can survive normal growth: new topics, new editors, and new user needs.
This post lays out a practical approach you can apply in almost any CMS, from a lightweight blog to a multi-author documentation site. It includes a model, a checklist, and a few guardrails that reduce entropy without creating bureaucracy.
What a taxonomy is (and why it fails)
A taxonomy is a controlled way to label content so humans and software can reliably find, group, and reason about it. In a CMS, it typically shows up as categories, tags, topics, industries, formats, products, or any other “choose from a list” attribute.
Taxonomies fail for predictable reasons:
- Labels drift. The same idea gets multiple names, or the meaning of a tag changes over time.
- Everything becomes a tag. Editors add one-off labels for minor details that do not help navigation.
- No one owns it. There is no clear rule for when to create, merge, or retire terms.
- It is built for the org chart. The taxonomy mirrors internal teams instead of user tasks.
The fix is not “use fewer tags” in the abstract. The fix is to define which kinds of tags exist, what they are for, and what decisions they are allowed to power.
Start with users: jobs, not departments
Before you design any structure, write down what your audience is trying to accomplish. This keeps the taxonomy anchored to real usage instead of internal naming debates.
A useful exercise is to list 5 to 10 “jobs” your content supports. Examples:
- Learn a concept (explanations and glossaries)
- Choose an option (comparisons and decision aids)
- Complete a task (how-tos and step-by-step guides)
- Troubleshoot a problem (diagnostics and FAQs)
- Evaluate a provider (service pages and case studies)
Then map each job to how someone would browse. Do they filter by “Format” (guide, checklist, video)? By “Use case” (onboarding, security, reporting)? By “Audience” (developer, manager)? These are candidates for your stable facets.
A lightweight tagging model that scales
The most durable approach for small to mid-sized sites is a two-layer model: a small number of high-signal core categories, plus a few structured facets that answer consistent questions. Everything else stays in the body text, not in the taxonomy.
Core categories vs facet tags
Core categories should be few, mutually distinct, and stable. They are your “shelves.” Most sites do well with 4 to 8 categories. Examples: Documentation, Tutorials, Case Studies, Announcements, Reference.
Facet tags are structured labels that support filtering, related-content modules, and landing pages. A facet answers a single question consistently, such as:
- Topic: What is this about?
- Audience: Who is it for?
- Product/Feature: What does it apply to?
- Industry: Who is it relevant to?
- Format: What kind of content is it?
Pick 2 to 4 facets that match how users browse. More facets mean more editor effort and more chances for inconsistency.
Controlled vocabulary and synonyms
For each facet, maintain a controlled vocabulary: a predefined list of allowed terms. If your CMS supports it, configure facets as selectable options rather than free text.
Synonyms should be treated as a search concern, not a tagging concern. For example, decide whether you will standardize on “API” or “Integrations,” then configure search to handle the other phrasing. If you allow both as tags, you permanently split your content graph.
A simple way to document this is to keep a small “term record” with each tag. It does not need to be fancy, but it should answer what the term means and when to use it:
{
"facet": "Topic",
"term": "Automation",
"useWhen": "Content primarily about reducing manual work via workflows",
"avoidWhen": "Content is about general productivity without systems",
"synonymsForSearch": ["workflow", "automate", "ops automation"]
}Even if you never store this JSON in your CMS, writing it once prevents repeated debates and inconsistent usage.
- Keep core categories small (4 to 8) and treat them like stable shelves.
- Use 2 to 4 facets that match how users browse (Topic, Audience, Product, Format).
- Prefer controlled vocabularies over free-text tags to prevent drift.
- Handle synonyms in search, not by creating duplicate tags.
- Assign ownership: define who can create, merge, and retire terms.
Implementation checklist (copy/paste)
Use this as a lightweight “definition of ready” for adding or changing taxonomy terms. It is intentionally short so it can survive real editorial pressure.
- Define your shelves. Create 4 to 8 core categories that cover nearly all content.
- Pick your facets. Choose 2 to 4 facets that directly support navigation and filtering.
- Write facet rules. For each facet: what question it answers, and what a term must represent.
- Set term naming conventions. Decide capitalization, pluralization, and whether acronyms are allowed (then stick to it).
- Create a “new term” policy. A term can be added only if (a) at least 3 pieces of content will use it within a quarter, and (b) it powers a filter or landing page.
- Assign ownership. Name a taxonomy owner (often an editor) who approves new terms and merges duplicates.
- Add guardrails in the CMS. Use dropdowns, limit the number of tags per post, and hide deprecated terms from new content.
- Schedule a cleanup. Quarterly or twice yearly: review term usage, merge near-duplicates, retire dead terms.
- Measure usefulness. Are people using tag pages? Do filters reduce bounce? Do editors find related content faster?
If you run a small site, the single highest-leverage step is the “new term” policy. It prevents the long tail of one-off tags that never earn their keep.
Common mistakes (and how to avoid them)
Mistake: too many one-off tags
One-off tags feel harmless, but they create empty or thin tag pages and make tagging decisions harder over time. Fix it with the “3 pieces of content” rule and by limiting how many tags a post can have per facet.
Mistake: mixing multiple questions in one tag list
If “Beginner,” “Security,” and “CRM” all live in one tag bucket, editors have to choose between incomparable terms and users cannot filter cleanly. Split them into facets: Audience (Beginner), Topic (Security), Product (CRM).
Mistake: no lifecycle for terms
Taxonomy entropy is natural. Without a merge and retire process, you end up with “API,” “Apis,” and “Integrations” forever. Add a simple lifecycle:
- Proposed: not selectable until approved
- Active: selectable for new content
- Deprecated: kept for old content but hidden from new selection
- Retired: removed after content is re-tagged
Mistake: using tags for campaigns or temporary initiatives
Campaign labels expire by definition. If you need them, store them in a separate field (for internal reporting) or keep them as free-form metadata that does not power navigation. Your public taxonomy should represent stable concepts.
When not to invest in a fancy taxonomy
A good taxonomy pays for itself when it improves discovery and reduces editorial friction. Sometimes the best move is to keep things simple.
Consider avoiding a complex tagging system if:
- You have fewer than 30 pieces of content. Search and a small set of categories may be enough.
- Your content changes shape constantly. If topics are experimental, wait until patterns stabilize.
- No one will maintain it. A taxonomy without an owner will rot faster than no taxonomy at all.
- Users do not browse by tags. If analytics show almost no interaction with tag pages, prioritize better navigation and internal linking first.
In these cases, focus on clear page titles, strong internal links, and a consistent content format. You can always add facets later once you see repeatable patterns.
Real-world example: a 200-page services site
Imagine a local services company that has grown a content-heavy site: 60 service pages, 80 blog posts, 30 troubleshooting articles, and 30 case studies. Editors complain that “related articles” are irrelevant, and users struggle to find the right service for their situation.
A durable taxonomy for this site might look like:
- Core categories (content type): Services, Troubleshooting, Guides, Case Studies
- Facet 1 (Topic): Installation, Maintenance, Repair, Safety, Compliance
- Facet 2 (Audience): Homeowner, Property Manager, Contractor
- Facet 3 (System/Area): Heating, Cooling, Ventilation, Controls
Now the CMS can power useful experiences:
- A troubleshooting page can automatically show “Guides” with the same System/Area and Topic.
- Service landing pages can filter case studies by System/Area.
- Editors can spot gaps by looking at Topic coverage inside each category.
The site avoids “campaign tags” and one-off labels like “Spring Special.” Those can live in promotional modules or internal fields, without contaminating the navigation structure.
The result is not a perfect ontology. It is a system where editors can make the same decision twice and users can predict where things will be.
Conclusion
A taxonomy that lasts is less about cleverness and more about constraints: a few stable categories, a small set of facets tied to user browsing behavior, and a lightweight lifecycle that prevents duplication.
If you implement only two things, make it these: controlled vocabularies (no free-text tag sprawl) and a clear owner who can merge and retire terms. Your future content team will thank you.
FAQ
Should I use categories or tags?
Use both only if they serve different purposes. Categories work best as a small set of “shelves” (content types or top-level groupings). Tags work best as facets (Topic, Audience, Product) that support filtering and related content.
How many tags should a post have?
Enough to be findable, not enough to be ambiguous. A practical rule is 1 core category plus 1 to 2 terms per facet you use. If editors regularly want more, it is a sign your facets are unclear or your terms are too broad.
When is it worth adding a new term?
Add a term when it will be used repeatedly and will improve discovery. A simple policy: create it only if at least 3 pieces of content will use it soon and it supports a filter, landing page, or meaningful related-content grouping.
What if I already have duplicate tags?
Pick the preferred term, mark the others as deprecated, and retag content over time. If your CMS supports redirects for tag pages, keep the old URLs pointing to the preferred term to avoid broken navigation.