How to Design a Taxonomy That Improves Retrieval Precision Across Teams and Brands
Two teams tag the same asset three different ways. Marketing files it under "Spring Campaign," the product team calls it "Q2 Launch," and a partner brand buries it under a freeform keyword nobody else searches for.
Two teams tag the same asset three different ways. Marketing files it under "Spring Campaign," the product team calls it "Q2 Launch," and a partner brand buries it under a freeform keyword nobody else searches for. When retrieval runs, whether that is a content editor searching the Studio, a frontend querying by category, or an AI agent pulling context, it returns half of what exists and none of it consistently. The failure is not the search engine. It is the taxonomy underneath it.
Precision degrades quietly. Every mislabeled document, every synonym that should have been one term, every brand that forked the vocabulary adds noise that compounds across teams. By the time someone notices retrieval is unreliable, the mess is distributed across thousands of documents and several editorial groups, and cleanup means reconciling meaning, not just data.
This guide reframes taxonomy as a retrieval problem, not a filing problem. A good taxonomy is a controlled vocabulary that queries can trust. Sanity, the Content Operating System, treats that vocabulary as modeled, queryable content in Content Lake rather than loose tags, which is what lets a single taxonomy stay precise across many teams and brands at once. We will cover how to model it, govern it, and query it so precision holds as you scale.
Why freeform tagging quietly destroys retrieval precision
The most common taxonomy is no taxonomy: a text field where editors type whatever term feels right. It works for the first hundred documents and fails silently forever after. One editor types "onboarding," another types "on-boarding," a third types "getting started." To a human these are obviously the same concept. To a query they are three distinct strings, and a filter on any one of them returns a third of the relevant content. Recall collapses, and because the results that do come back look plausible, nobody realizes precision collapsed with it.
The deeper problem is that freeform tags encode meaning as spelling. There is no shared definition of what a term means, no canonical form, and no way to ask "what else is like this." When a second brand joins the workspace, it forks the vocabulary again, because there is nothing to fork from. Now retrieval has to guess across two overlapping, inconsistent term sets, and the guess is usually wrong.
The fix is a controlled vocabulary: a finite, governed set of terms that every document references rather than restates. Each concept exists once, has one canonical label, and carries its own metadata. A document does not store the string "onboarding," it stores a reference to the onboarding term. Retrieval then filters on identity, not spelling, and identity is exact. This is the shift from tagging as decoration to taxonomy as data, and it is the precondition for everything else in this guide.
Model taxonomy terms as first-class references, not strings
A taxonomy that improves precision has to be modeled, not sprinkled. The move is to make each term a document in its own right and have content point at it. In Sanity you define a `taxonomyTerm` type with `defineType`, give it fields for a canonical label, a slug, a definition, and an array of synonyms, then reference it from your content types instead of storing a string. Because the schema is portable and codegen'd to TypeScript via TypeGen, every consumer of that reference, the Studio, the frontend, and any Function, sees the same shape and the same allowed values.
Modeling terms as references buys you three things a string field cannot. First, a term can carry structure: a definition editors can read before they apply it, a list of synonyms that a query can expand against, and a parent reference that expresses hierarchy. Second, renaming a concept is a single edit to one document, and every referencing document follows automatically, because they never stored the label in the first place. Third, you can validate. A reference field can only point at real terms, so the "on-boarding" typo is structurally impossible to enter.
This is the "model your business" pillar in practice. The taxonomy is not a lookup table bolted onto content; it is content, with the same versioning, validation, and query surface as everything else in Content Lake. Custom input components in `sanity.config.ts` can render the term picker as a searchable tree with definitions inline, so editors choose the right term because the right term is the easy one to choose. Precision starts at authoring time, and a well-modeled reference makes the correct choice the default rather than the disciplined exception.
Reconcile vocabulary across brands with hierarchy and synonyms
Multi-brand and multi-team environments are where flat taxonomies die. Each group has legitimate local vocabulary: a fashion brand's "drop" is a software team's "release" is a publisher's "issue." You cannot force one label on all of them without breaking how each team actually thinks, and you cannot let each team invent freely without shattering retrieval. The resolution is a shared spine with governed local leaves.
Hierarchy provides the spine. A parent reference on each term lets you build a tree where a shared top-level concept has brand-specific children, so a query can filter broadly at the parent level or precisely at the leaf. Synonyms provide the reconciliation. When each canonical term carries an array of alternate labels, a search can match on any of them while still resolving to one identity, which means "drop," "release," and "launch" can all lead a user to the same governed concept without three separate tags existing in the data. The vocabulary stays plural at the surface and singular underneath.
GROQ makes traversing this cheap and exact. The `->` operator dereferences a term to read its parent, its definition, or its synonyms in the same query that fetches the content, so you never round-trip to stitch a term tree together on the client. You can filter documents by any descendant of a parent term, expand a search across a term's synonym array with `match()`, and project exactly the taxonomy fields the surface needs, all in one request. The result is that a single query can serve one brand's narrow view and the whole organization's cross-brand view from the same modeled taxonomy, which is precisely what flat, per-team tagging can never do.
Govern the taxonomy so it stays precise as it grows
A taxonomy is only as precise as its worst-governed term. Left ungoverned, every team adds terms to solve its immediate problem, near-duplicates accumulate, and within a year the controlled vocabulary is as noisy as the freeform tags it replaced. Governance is not bureaucracy here; it is the maintenance that keeps retrieval trustworthy. The goal is to make adding a term a deliberate, reviewable act rather than a side effect of writing a document.
The practical controls are ownership and review. Roles & Permissions can restrict who may create or edit taxonomy terms, so a small stewardship group owns the vocabulary while everyone else references it. That single boundary prevents most vocabulary sprawl, because the people writing content can apply terms but cannot silently mint new ones. When a genuinely new concept is needed, it goes through the stewards, who check it against existing terms and their synonyms before it enters the tree. Audit logs record who changed which term and when, so a drift in precision can be traced to the edit that caused it rather than guessed at.
Changes to a live taxonomy are risky because they ripple across every referencing document at once, and Content Releases let you stage that risk. You can bundle a taxonomy restructure, merging two overlapping terms, promoting a leaf to a parent, retiring a deprecated concept, and schedule it to publish as one reviewable change rather than a scatter of live edits. This is governed editorial workflow applied to the vocabulary itself, and it is the difference between a taxonomy that decays and one that stays precise as it grows across teams and brands.
Query the taxonomy for precision: filters, projections, and similarity
All the modeling and governance exist to serve one moment: the query that has to return exactly the right content. Because the taxonomy lives in Content Lake as structured, referenced data, GROQ can filter on identity rather than string matching. A filter on a term reference is exact, so "return everything tagged with this concept" returns that set completely and returns nothing else. Recall and precision both hold, because the query is asking about a relationship, not a spelling.
GROQ's shape control is what makes cross-team retrieval efficient. In one round trip you filter documents by their taxonomy references, dereference each term with `->` to pull its label and definition, project only the fields the consuming surface needs, and order or score the results. There is no client-side assembly and no second request to resolve what a term means. A frontend rendering a brand's category page and a Function assembling context for a downstream process query the same taxonomy the same way, so they stay consistent by construction.
Where exact filtering is not enough, similarity extends precision without abandoning it. GROQ's `score()` lets you rank by relevance, `match()` expands a query across a term's synonym array, and `text::semanticSimilarity()` can surface conceptually related content even when the exact term was not applied. Layering semantic similarity on top of a governed taxonomy is the strong pattern: the controlled vocabulary keeps results grounded and explainable, while similarity catches the near-misses a strict filter would drop. That combination is what lets retrieval stay both precise and forgiving across many teams and brands, which is the whole point of designing the taxonomy in the first place.