---
title: "Website Taxonomy: Derive The Structure, Don't Design"
url: https://www.axelerant.com/blog/website-taxonomy-information-architecture
published: 2026-07-10T09:00:00Z
author: "Vivek Radhakrishnan, Digital Solutions Consultant"
lenses: Experience, Data, Activation, Optimization
source: Axelerant Thinking
---

# Website Taxonomy: Derive The Structure, Don't Design

> Website taxonomy that mirrors the org chart fails buyers and search. How to derive information architecture from card sorting, tree testing, and content modeling.

Stage four of eight. The question it answers: what do we call things, and what is allowed to vary across every local site?.

A director of [digital strategy](/what-we-do/strategy) at a manufacturer said it in the first ten minutes of a call: the site's taxonomy is built around how they organize their products, not around how a homeowner wants to explore. She was not describing a design problem. She was describing a structure problem, and she knew the difference.

Most website taxonomy problems sound like that. The navigation reflects the org chart or the catalog. The labels are the internal names for things. The pages that perform live under a heading nobody would think to open. A marketing director once described a large outdoor retailer's site to us where the category labels might as well have been product codes. Nobody shops that way, and nobody searches that way.

The usual response treats navigation as a design deliverable: someone sketches a menu, the team debates it, it ships. That is designing the [information architecture](/what-we-do/design/content-design), and it produces a structure that reflects whoever was loudest in the room.

Website information architecture should be derived. It comes out of research and content modeling, and the menu is the last thing built, not the first. The rest of this piece is how, and what breaks when it is skipped.

![Structure: stage four of the digital brand strategy, where website taxonomy, information architecture, and the content model are derived from research.](https://cdn.sanity.io/images/d78h1a2t/production/ef061bb54b16fde3e8bd62fd829589a1fc2ce957-2048x1152.png)

## Run two tracks at once, and let neither finish alone

Derivation has two tracks.

The [user research](/what-we-do/design/ux-research) track asks how people group and find things. Open card sorting, run per persona, shows how each audience clusters the content when nobody supplies the categories. Tree testing then checks whether people can find specific items inside the clusters that emerged. The output is evidence about mental models, not a menu, and the dendrograms from a card sort routinely surprise the people who wrote the current navigation.

The content modeling track asks what the content actually is. A complete inventory of what exists across every property. An audit of that inventory: what is still relevant, what should be archived, what is duplicated. From the audited inventory, the taxonomy, the shared vocabulary for the estate. Then the content model: the types, fields, and relationships the taxonomy attaches to.

The tracks inform each other. Card-sort clusters suggest taxonomy terms; taxonomy terms shape the labels used in the tree test. Only when both converge does the menu get built, as a prototype, and validated with users before a screen is designed around it.

![How website information architecture is derived: a user research track and a content modeling track run in parallel and converge into a validated menu system.](https://cdn.sanity.io/images/d78h1a2t/production/0dc581c0387ec572784230365cb02bd54656444d-2048x1229.png)

On a global certification body's estate, the card sort and tree test were requested by the client's incoming product leadership, who wanted the navigation decision to rest on user evidence rather than on anyone's judgment. The clusters that emerged became the first menu prototypes. That is the right relationship between research and structure: the research is the client's insurance, not the agency's ritual.

## Approve the boring documents before the expensive ones

A taxonomy built on an inventory nobody signed off gets rebuilt. If the client later decides a content type stays that the audit had archived, every term that depended on that decision moves.

So the modeling track runs with approval gates. The inventory is approved as complete. The audit is approved as the future state, including what will be archived. Only then does taxonomy work begin, drawing on the audited inventory, the card sort results, and the client's own preferred terminology. The approvals feel bureaucratic. They are the cheapest insurance in the whole redesign.

![The structure stage sequence: content inventory, audit, taxonomy, content model, menu prototype, validation, with client approval gates between the first three.](https://cdn.sanity.io/images/d78h1a2t/production/6001572ea10e2032c282aee167620da2c65124a8-2048x1229.png)

The certification body's structure work ran exactly this way, each document approved before the next began. The sequence was slower for the first three weeks and faster for everything after.

## Keep the search view in the room from the first prototype

The menu prototypes from the card sort should never be tested alone. Two other views sit beside them: the structure as it stands, and the structure that search data wants. Where the three disagree is where the real decisions are.

The most useful disagreement is the one marketing brings. On the certification body's project, the marketing team pushed back on renaming links that were performing well in search. They were right to. A label that reads better to a designer and worse to a search engine is a bad trade, and renaming a page that already ranks for the term the business needs is how site equity gets quietly destroyed in a redesign. The team's working principle was blunt: wrong redirect mapping equals authority loss.

Information architecture SEO is therefore not an audit run after launch. It is a constraint on the taxonomy from the day the card sort results come in. Performing pages keep their names or keep their equity through deliberate mapping. The menu that ships is better for the argument.

## Separate structure from content strategy

Two disciplines get conflated in every redesign brief. Information architecture decides the structure: URL patterns, consolidations, content types, navigation. Content strategy decides what goes into the structure: which topics, at what depth, refreshed how often.

Keeping them separate is what lets each be approved on its own. The certification body's team drew the line explicitly: IA owned the property consolidations and the content types; content strategy owned the editorial plan that filled them. When the two are one workstream, the content calendar ends up dictating the taxonomy, and the taxonomy ends up describing this quarter's campaigns.

The same discipline decides when a separate property should stay separate. A domain-level redirect deindexes the source; a discovery-content domain that ranks for the category term should keep its identity and be given a job in the funnel rather than absorbed. Consolidation is a structure decision with a search consequence, and it has to be made with both views present.

## A structure can hide your best content

Sometimes the taxonomy is not wrong so much as blind. An endurance sports brand's news section was a search-filter view: to a search engine or an AI assistant it read as a loose pile of articles rather than a library of topics. Topic pages were bare lists headed "articles tagged with," nothing structured to read. And the training content, the material a first-time athlete most needs, lived under news, because that is where publishing had always happened. Their own team put it plainly: nobody would think to look in news for how to train for their first event.

The structural fix was an intent split. Content someone reads to discover, and content someone reads to do something, are different thought processes and deserve different content types and URL structures. The taxonomy under each, the tagging rules editors follow, and what that did for the brand's [discoverability](/what-we-do/revops-and-growth/discoverability) belong to the next stage, where the same engagement's search and AI visibility work lives.

### Decide what is global and what is local before anyone designs a template

Everything above assumes one site. Multi-location brands have a second structure problem that single-site redesigns never face: what is global, what is local, and what each location is allowed to change.

A manufacturer with dozens of branch sites under one domain does not have one taxonomy problem. It has one taxonomy and dozens of governance questions. Which fields on a branch page are set centrally and locked? Which are set centrally with a local override? Which are local by default? Who approves a change to each? Without answers, the branch sites drift, each restructured by whoever owns it, until the global taxonomy describes nothing that exists.

![Global versus local content governance matrix for multi-location website structure: which fields are locked centrally, which allow local override, which are local by default, and who approves each.](https://cdn.sanity.io/images/d78h1a2t/production/c57babba7493207ce4a1e44937ca13a9d3b1cccc-2048x1229.png)

The matrix is the artifact. Fill it before templates are designed. It tells the [design system](/what-we-do/design/ui-and-design-systems) which components need local variants, tells the CMS team what permissions to build, and tells the branch teams what they own.

The certification body faced the regional version of this. Of the eight or nine regional sites in its estate, only two carried content different enough to justify being separate; the rest could be sections of the main domain under a centralized top-level navigation. The client's own product lead asked for a feature matrix by market before any regional decision was made. Their working principle for localization separated region from language as independent concerns: region detected from location and driving pricing, imagery, promotions, and feature availability; language a user preference that overrides the regional default. Both were structure deliverables, not content-team afterthoughts.

## What the structure stage hands over

The value is in the set, not any single document.

- Content inventory, approved as complete.

- Content audit, approved as the future state, with archive and consolidation decisions.

- Card sort results per persona, with the dendrograms and raw data, not just the summary.

- Tree test results against the emergent clusters.

- Taxonomy sheet: the shared vocabulary, with each term traced to inventory, card sort, or client terminology.

- Content model: types, fields, relationships, and the tagging rules editors will follow.

- Menu system prototype, validated with users, with the as-is and search views documented alongside.

- For multi-location estates, the global-local governance matrix and the region-language model.

Two things this stage does not produce: a homepage design, which belongs to stage seven and inherits the content model from here; and a content calendar, which is content strategy.

## What breaks when the stage is skipped

The homepage designer decides the taxonomy. Navigation gets sketched to fit a hero layout, and the structure describes the company because that is what the designer had to work from.

Search equity is lost in the rename. Pages that ranked are relabeled, moved, or merged without a mapping, and the redesign launches to a visibility drop nobody can explain.

Local sites drift. Without a governance matrix, each branch rebuilds to local taste, and within two years the global structure is a fiction.

None of these are design failures. They are structure failures with design symptoms, which is why they get misdiagnosed and why the next redesign repeats them.

## Where this sits in the sequence

Stage four depends on stages two and three: you cannot run a card sort per persona without the personas, and you cannot know which content matters without the journey work. It feeds stages five and seven directly: discoverability inherits the URL structure and the search view; the design system inherits the content model and the component variants the governance matrix demands.

## Questions we get asked about website taxonomy

### What is the difference between website taxonomy and information architecture?

Taxonomy is the vocabulary: the agreed terms for categories, types, and attributes. Information architecture is how that vocabulary is arranged into something people navigate: URL patterns, hierarchy, navigation, and the relationships between content types. You need the taxonomy before the architecture, and both before the menu.

### How does card sorting differ from tree testing?

Card sorting is generative: participants group content their own way, and the clusters show how they think. Tree testing is evaluative: participants try to find specific items inside a proposed structure, which shows whether it works. Run the card sort first, derive candidate structures, then tree test them.

### How do you redesign site structure without losing SEO?

Keep the search view in the room from the first menu prototype. Map every performing page to its new location before anything is renamed, treat the redirect map as a structural deliverable, and let search data veto label changes that would cost equity. The audit after launch is too late.

### What are website navigation best practices for a multi-location business?

Decide what is global and what is local before designing the navigation, document it in a governance matrix, and build the CMS permissions to match. Local navigation should be a controlled variant of the global structure, not a local reinvention of it.

## Read next in the series

The full sequence is set out in the pillar guide, [Digital Brand Strategy: Eight Stages From Baseline To Proof](/blog/digital-brand-strategy). Each stage has its own article.

- [Stage 01, the target](/blog/website-benchmarking-before-redesign). What are we trying to move, and where does it stand today?

- [Stage 02, the audiences](/blog/persona-research-primary-secondary-audience). How do we serve a second audience without breaking what works for the first?

- [Stage 03, the journey](/blog/customer-journey-analysis-website-redesign). Where does someone fall out between interest and a conversation?

- Stage 04, the structure. What do we call things, and what varies across every local site? You are reading it.

- [Stage 05, being found](/blog/multi-location-seo-discoverability). Strong nationally, weak on near me. How do we fix that specifically?

- [Stage 06, the conversion](/blog/conversion-funnel-analysis-website-redesign). How does a visit become a qualified lead at the right location?

- [Stage 07, the system](/blog/design-system-governance-internal-team). How do we get a design system your own team keeps building with?

- [Stage 08, the proof](/blog/conversion-rate-optimization-testing-after-redesign). How will we know, with data, that any of this worked?

- [The personalization layer](/blog/website-personalization-strategy). What should adapt, for whom, based on which signal?

---

Read on the web: https://www.axelerant.com/blog/website-taxonomy-information-architecture