What Is a Taxonomy in Information Architecture?

Ask three people on the same team to file the same document and you'll get three answers. One calls it Onboarding, one calls it Getting Started, one calls it New Hire Setup. The document now exists in all three places, and search returns the stalest copy. Nobody made a bad decision here. There was no agreement about what the categories are or what they're called, and that agreement is a taxonomy — the part of information architecture that gets skipped.

What a taxonomy is

A taxonomy is the controlled set of categories a system files things under, plus the labels for those categories and the rules for how they relate. Biology's kingdom-phylum-class is the famous example, but the useful definition for product work is narrower: it's the shared vocabulary that decides where a thing goes and what it's called when it gets there.

That covers the categories themselves (Billing, Security, Integrations), the exact labels for them, chosen once and reused everywhere, and the rules for which categories sit inside which and what's allowed to belong to two places at the same time. Most teams produce the categories and leave the labels and the rules implicit. It comes apart the first time someone files against a rule nobody wrote down.

A taxonomy is also not your navigation menu. The menu is one rendering of it, and a lossy one — open your CMS and compare the category list against the number of slots in the nav. The same taxonomy drives your search facets, your URL structure, your CMS fields, your related-content module, and the filters on your listing pages. Which is why changing it after launch is expensive: you're not renaming a link, you're renaming a contract that six surfaces depend on.

Taxonomy vs. ontology vs. folksonomy

These three get used interchangeably in meetings. They describe different machinery.

A taxonomy classifies. It says this article is a Billing article and Billing sits under Account. The relationships it expresses are mostly one kind: parent and child.

An ontology describes. It defines the types of things in a domain and the many kinds of relationship between them — a Course is taught by an Instructor, requires a Prerequisite, awards a Credential. Schema.org is the ontology most product teams touch without noticing, every time they add structured data to a page. An ontology can express "is taught by"; a taxonomy can only ever express "is inside."

A folksonomy emerges. It's the vocabulary that appears when users tag things freely, with no controlled list. Thomas Vander Wal coined the term in 2004 on an IA Institute mailing list, for exactly that bottom-up tagging behavior. Folksonomies are excellent evidence and poor infrastructure. They tell you the words real people reach for, including the ones you'd never have written down. They also give you email, e-mail, emails, and mail as four separate tags with a quarter of the results each.

Use all three in their right places: mine the folksonomy for language, encode a taxonomy for structure, and reach for an ontology only when your relationships stop being hierarchical.

The three shapes a taxonomy takes

Flat. One level, no nesting. A blog with eight categories and nothing underneath them. Flat looks unserious in a design review. Under a few dozen items it's still the right call — a hierarchy there adds a click and buys nothing.

Hierarchical. Parents and children, the shape most people picture. It works when items have one obvious home. The moment an item has two, it starts to strain. The other failure mode is depth: every level you add is a decision the user has to get right, and a wrong turn at level two hides everything below it. Two or three levels covers most products. Past four, the deepest levels usually turn out to name teams.

Faceted. Multiple independent axes applied at once — a shoe that is simultaneously running, size 10, waterproof, and under $120. Facets earn their keep whenever an item belongs to several categories at once, because they let someone assemble a path instead of guessing which one you filed it under. The idea long predates ecommerce: S. R. Ranganathan built facet analysis into his Colon Classification in the 1930s, on the argument that any single filing order is arbitrary. NN/g draws the line this way in filters and facets: facets are metadata-driven, mutually compatible, and derived from the taxonomy. Filters are controls that narrow a list.

Most real systems are hybrids, a shallow hierarchy for browse over a faceted layer for search. Watch for the version where the published hierarchy is the one nobody files against. The real classification accumulates in an untended tag field, and the two drift until search stops agreeing with browse.

Build it from card sorts, not from a whiteboard

Categories invented in a room with colleagues inherit the colleagues' knowledge of the product. By construction they're never confusing to the people who wrote them, which is why a whiteboard session can produce a structure everyone in the room can navigate and nobody outside it can. Watching outsiders group the same items is the correction.

An open card sort gives you the categories and the words together: participants group items and name the groups themselves. The words are the half people skip. A closed card sort tests categories you already have. NN/g's guidance on card sorting is the standard reference for running one, and the method is cheap enough that there's no honest excuse for a taxonomy that's never seen a participant.

Then test the structure separately from the labels. Tree testing hands someone a bare hierarchy with no visual design and a task like find the refund policy, then records where they go. It's the cleanest signal you'll get about whether your categories are findable, precisely because there's no navigation styling left to compensate for them.

Controlled vocabulary is the part that decides whether this survives

A category set with no vocabulary rules degrades as fast as people can add terms to it. Somebody adds Getting Started next to Onboarding, somebody else adds Setup, and the taxonomy quietly forks. A controlled vocabulary is the list of terms that are allowed, plus the synonyms that map onto them.

Write down four things:

• Preferred terms. One label per concept. Onboarding, and nothing else.
• Synonym rings. The words users type that resolve to the preferred term: setup, getting started, first steps all route to Onboarding. This is what makes search forgiving of the vocabulary you didn't choose.
• Scope notes. One sentence per category saying what belongs in it and what doesn't. This is the highest-leverage artifact in the whole exercise, because it settles the argument the next person is about to have — the one where two people each hold a defensible reading of the word Account. Write the exclusions too.
• An owner. Someone responsible for adding terms, or everyone will.

The Dublin Core metadata element set has fifteen general-purpose fields and has been in use since the mid-90s. Count your own draft against it before you decide you need a custom schema.

A workflow that produces a usable taxonomy

1. Inventory what exists. Every page, article, or product, in one spreadsheet. The count alone usually settles the flat-versus-hierarchical question.
2. Mine the existing language. Search logs, support tickets, and any free-tag field. These are your folksonomy, the words people already use.
3. Run an open card sort. Let participants form and name groups. Look for the groupings that recur across participants.
4. Draft categories and write scope notes. One sentence each, including what's excluded.
5. Tree-test the draft. Bare hierarchy, real tasks, note the wrong turns.
6. Decide the polyhierarchy rule. Whether an item may live in two places, and if so how the canonical URL is chosen. Deciding this late is how duplicate content happens.
7. Assign an owner and a review cadence. Quarterly is enough for most products.

Frequently asked questions

What's the difference between a taxonomy and a tag? A taxonomy is the controlled list; a tag is one application of a term from it. Tags with no taxonomy behind them are a folksonomy, which is how the same concept ends up spelled four ways.

How many levels deep should a taxonomy go? Two or three for most products. Depth costs a decision per level, and a wrong turn early hides everything beneath it. If you're past four, check whether the extra levels describe your content or your internal teams.

Can one item belong to two categories? Yes, that's a polyhierarchy, and it's normal in faceted systems. Just decide up front which location is canonical for URLs and breadcrumbs, or you'll ship the same page at two addresses and split its search signal.

Do we need a taxonomy for a small site? You need the vocabulary, not the machinery. Twenty pages don't need a hierarchy. They still benefit from one agreed label per concept and a note on what each one covers.

Is a taxonomy the same as a sitemap? No. The taxonomy is the classification; the sitemap is one arrangement of pages that reflects it. The taxonomy also shows up in facets, filters, and metadata that never appear in a sitemap at all.

When should we redo one? When the scope notes stop settling arguments, people keep filing things in the wrong bucket, and the proposed fix is always "add a category." At that point the shape is wrong, and another bucket only defers the same conversation.

For how classification connects to labeling, navigation, and findability across a product, see the information architecture hub.