Structuring a Knowledge Base People Can Actually Navigate

Every knowledge base starts organized and ends up as a junk drawer. Not because anyone stopped caring, but because structure decisions get made one document at a time, by whoever happens to be writing, at the moment of writing — which is exactly the wrong person at exactly the wrong moment. The author knows where the document "belongs" in their mental model. The reader, six months later, does not share that mental model. They share a search box and about eight seconds of patience.

This guide covers the structural decisions that determine whether people can navigate your knowledge base: how to design the hierarchy, how to name things, when tags beat folders, how to build entry points for different kinds of readers, and how to audit the whole thing before rot sets in. It assumes you already believe documentation matters; if you need the case for that, start with our complete guide to knowledge management and come back.

Why knowledge bases become unnavigable

The failure is predictable enough to be a law. A knowledge base degrades through four stages:

1. The clean start (0–50 documents). A founder or team lead sets up a sensible structure. Everything has a home. Navigation works because the whole thing fits in one person's head.
2. The sprawl (50–300 documents). More writers join. Each interprets the structure slightly differently. Duplicates appear because writing a new doc is faster than finding the old one. The original curator can no longer review everything.
3. The archaeology era (300–1,000 documents). New hires are told "it's in the wiki somewhere." Search returns four versions of the vacation policy, three of them outdated. People start asking in chat instead of looking, because a human answer is more trustworthy than a stale document.
4. The reboot (any size). Someone proposes migrating to a new tool, because the new tool will surely stay organized. It will not. The structure problem migrates with the content.

The reboot stage is worth dwelling on, because it reveals the core mistake: teams treat navigability as a tool property when it is a design property. The same team that let a wiki rot will let its replacement rot, on the same schedule, unless the structural decisions change. Everything below is about those decisions.

The three root causes

Storage thinking instead of retrieval thinking. Writers file documents where they were produced ("Marketing > Q3 > Campaign planning > Notes") rather than where they will be sought ("How we run campaigns"). A knowledge base organized by provenance is an archive; one organized by future questions is a knowledge base.

Mirroring the org chart. Top-level sections named after departments feel natural and fail immediately, because readers' questions do not respect departmental boundaries. "How do I get reimbursed for a conference?" touches Finance (the policy), HR (the approval), and possibly your own team (the budget). Which department folder does it live in? All three teams will answer differently, and the reader will guess wrong. Org charts also reorganize every 18 months, breaking every path.

No named owner for structure. Individual documents have authors; the hierarchy usually has nobody. Structure without an owner degrades one reasonable-seeming exception at a time.

Design for retrieval: start with questions, not content

Before drawing a tree, collect the questions your knowledge base needs to answer. Not hypothetically — actually collect them:

• Pull 30–50 real questions from your chat history (search for "does anyone know," "where is," "how do I").
• Ask each team for their ten most-asked questions from new hires.
• If you have search analytics, export the top 50 queries.

Now do a lightweight card sort: write each question on a card (physical or a whiteboard tool), and have three or four people — crucially, including at least one recent hire — group them into clusters and name the clusters. The cluster names people naturally produce are your candidate top-level sections. This exercise takes 90 minutes and prevents months of restructuring, because it derives the hierarchy from reader questions instead of writer output.

Two patterns emerge from almost every card sort:

1. Questions cluster by task and topic, not by department. "Getting paid and reimbursed," "Our product," "How we ship," "Working here."
2. A surprising fraction of questions — often a quarter — are about finding people and status, not documents ("who owns billing?", "what's the state of project X?"). Those belong in a directory and status reporting, not prose documents. Knowing what your knowledge base should not contain is half of structure.

Hierarchy design: shallow, capped, and task-oriented

With clusters in hand, the tree design follows a few firm rules.

Keep it shallow

Every level of depth is a decision the reader must make with incomplete information, and each decision is a chance to guess wrong. Three levels is the practical maximum for a team knowledge base: section → page group → page. If a document sits five clicks deep, it is effectively unreachable by browsing and survives only through search or links.

Depth is also where duplicates breed. When a writer cannot quickly determine which deep branch a document belongs in, they create a new page at whatever level they are currently viewing. Shallow trees make the right location findable in one glance, which is the single best duplicate prevention there is.

Cap the top level at seven, give or take

A top level with 20 sections is a wall of doors. Aim for five to nine top-level sections — enough to be meaningful, few enough to scan in one pass. A structure that fits most 20–200 person companies:

Section	Contains	Primary audience
Start here	Onboarding, tool access, glossary, how the KB itself works	New hires
Working here	Policies, benefits, PTO, expenses, travel	Everyone
Our product	What we sell, positioning, roadmap summaries, FAQs	Everyone
How we work	Engineering/design/marketing practices, SOPs, runbooks	Practitioners
Teams	One hub page per team: mission, members, key links	Everyone
Decisions	Decision records, RFCs, post-mortems, in date order	Practitioners
Archive	Everything retired, clearly labeled	Nobody, on purpose

Notice that "Teams" survives — but as one hub page per team linking outward, not as a container hiding half the content. Team identity gets a home without the org chart becoming the taxonomy.

Name sections by the reader's task

Section names should complete the sentence "I need to know about ___." "How we ship" beats "Engineering Processes & Standards." "Working here" beats "Human Resources." If a section name would look at home in a corporate org chart, rename it in the reader's language. This is the same title-as-query principle that governs individual pages, covered in depth in our guide to search and findability.

Decide placement rules once, in writing

The hierarchy needs a one-page constitution: what each section is for, one example of what belongs there, one example of what does not, and who to ask when unsure. This page lives in "Start here." Without written placement rules, every writer re-derives the structure from whatever examples they happen to see, and drift is guaranteed.

Naming: the highest-return 60 characters

A document's title does more navigational work than its entire location in the tree, because titles are what search matches, what link previews show, and what readers scan in lists. Rules that pay off immediately:

Write titles as the reader's query. "How to request time off" beats "PTO Process." "Set up your local development environment" beats "Dev env." Ask: what would someone type into search when they need this? That phrase is the title.

Front-load the distinguishing words. Lists and search results truncate. "Expense reimbursement — international travel" survives truncation; "International travel guidelines for the submission of expense reimbursements" does not.

Standardize patterns per document type. Consistency turns titles into an interface:

• How-to guides: start with a verb. Deploy a hotfix. Request contractor access.
• Reference pages: noun phrases. Brand colors. API rate limits.
• Decision records: date plus decision. 2026-01: Switch billing provider to X.
• Meeting notes: date plus meeting name. 2026-01-06 — Product weekly.
• Runbooks: the alert or scenario name, verbatim.

Ban abbreviations that are not in the glossary. "CX QBR prep" is findable only by the four people who already know where it is. Spell things out; search does not expand acronyms, and neither do new hires.

Never put status in the title. "Onboarding guide FINAL v2 (updated)" is how version control looks when a knowledge base does not have any. Status belongs in metadata or a status banner; the title stays stable so links stay stable.

Hierarchy vs tags: the honest answer

Teams regularly ask whether they should organize by folders or by tags. The honest answer: hierarchy for location, tags for cross-cutting retrieval — and hierarchy is the one you cannot skip.

	Hierarchy (tree)	Tags (labels)
Answers	"Where does this live?"	"What else is like this?"
Cardinality	Exactly one home per doc	Many labels per doc
Browsing	Excellent — supports scanning	Poor — flat result lists
Cross-cutting themes	Poor — one path only	Excellent
Maintenance cost	Low once designed	High — vocabularies sprawl
Failure mode	Wrong guess about the one home	Synonym chaos: on-boarding, onboarding, new-hires

A document needs exactly one home so that writers know where to put it and readers develop spatial memory ("policies live under Working here"). Tags then handle the questions a tree structurally cannot: show me everything about security across engineering practices, policies, and vendor docs; everything relevant to managers; everything related to customer-x.

Tags only work under discipline that most teams skip:

1. A controlled vocabulary. Tags come from a maintained list (20–40 for most teams), not free entry. Free-form tagging produces a graveyard of one-use synonyms within a quarter.
2. A named tag owner. Someone approves new tags and merges duplicates, quarterly, in about half an hour.
3. Tags describe topics, not status or team. Status belongs in metadata; team belongs in the owner field. Tags answer "what is this about?"

If your tool supports only one mechanism, choose hierarchy and compensate for cross-cutting themes with hub pages — which brings us to entry points.

Entry points: nobody starts at the root

The structural work above assumes a reader browsing from the top. Most readers never do that. They arrive through one of four doors, and each door needs deliberate design:

Search. For established teams, the majority entry point. Structure helps search indirectly — good titles, no duplicates, archived rot — but the key design act is making sure the words people search for appear in titles and first paragraphs.

Links from where work happens. The best entry point is a link at the moment of need: the runbook linked from the alert, the expense policy linked from the expense tool, the style guide linked in the PR template. Every recurring "where is the doc for X?" question in chat is a missing link from a workflow.

Hub pages. A hub page is a hand-curated map of one topic: the ten most useful links, ordered by usefulness, with one line of context each — not an auto-generated list of every child page. Hubs are how you serve cross-cutting themes and new-joiner journeys without deepening the tree. Every top-level section deserves a hub at its root, and so does every major project. Budget: a good hub takes 30 minutes to make and 10 minutes a quarter to maintain, and it is routinely the most-visited page in its section.

The "Start here" page. New hires get one page that sequences their first exposure: read these five docs in this order, here is the glossary, here is how to search, here is where to ask questions. Without it, new hires meet the knowledge base as a wall of hundreds of undifferentiated pages, and their lasting habit — ask a human instead — is set in week one.

A useful exercise: for each of your five most important documents, count the number of paths that reach it (search terms in the title? linked from a hub? linked from a workflow? reachable in ≤3 clicks from the root?). Important documents should be reachable through at least three doors. One-door documents are one broken link away from invisible.

Status and lifecycle: structure includes time

Navigation fails not only in space but in time: the reader finds a page and cannot tell whether it is current. Every page needs three visible pieces of temporal metadata:

• Status: Draft / Current / Needs review / Archived. A colored banner or a consistent header line — anything visible without scrolling.
• Owner: a team (not a person — people leave, and ownerless pages are unmaintainable).
• Last reviewed date: distinct from last edited. A typo fix updates "edited"; only a human confirming "this is still true" updates "reviewed."

The Archive section deserves special defense. Deleting old content feels dangerous, so teams keep everything live, and readers pay the price in stale search results. The archive resolves the tension: nothing is lost, but archived pages are clearly labeled, excluded from default search where the tool allows, and never linked from hubs. Moving a page to the archive should be a five-second, guilt-free action. When retiring a page that people may still have bookmarked, leave a stub behind: one line pointing to the replacement.

The quarterly audit: how structure stays alive

Structure is not a project; it is a garden. A quarterly audit — two hours, done by the knowledge base owner plus one rotating volunteer — keeps it from returning to junk-drawer state. The agenda:

1. ROT sweep (45 minutes)

ROT = Redundant, Outdated, Trivial. Sort all pages by last-reviewed date and walk the oldest 10%:

• Redundant: duplicate or overlapping pages → merge, leave a stub redirect.
• Outdated: describes reality that changed → fix if under 15 minutes, else tag "Needs review" and assign to the owning team.
• Trivial: meeting notes from 2024, empty stubs, "test page" → archive without ceremony.

Illustrative math for motivation: if your team creates 15 pages a week and never retires any, you add roughly 750 pages a year. At even a 20% annual staleness rate, that is 150 new wrong-answers-in-search per year. The ROT sweep is how the denominator stays honest.

2. Search log review (30 minutes)

Pull the top 30 search queries (or, lacking analytics, the quarter's "where is..." questions from chat). For each: does a page exist? Does its title contain the query words? Did the searcher plausibly find it? Every miss becomes one of three tickets: write the page, retitle the page, or add the missing link.

3. Structure exceptions (30 minutes)

Walk the top two levels of the tree. Flag: sections that grew past ~15 direct children (split or add a hub), pages filed against the placement rules (move them, then ask why the rule was unclear), and any new top-level sections that appeared without discussion (there is always one).

4. Metrics check (15 minutes)

Three numbers, tracked quarter over quarter, are enough:

1. Percentage of pages reviewed within the last 6 months — target above 70%.
2. Search success proxy — of the top 30 queries, how many have an obvious right answer in the top results.
3. Chat deflection — count of "where is / does anyone know" questions in a sample week. This is the number your knowledge base exists to reduce.

Publish the audit results in a short post. Visible maintenance builds trust, and trust is what makes people check the knowledge base before asking a human.

Structure in practice: mapping to your tools

Everything above is tool-agnostic, but tools shape which structures are cheap. Two honest observations:

Nested-page tools (Notion-style docs) make deep trees frictionless, which is a feature and a trap — the tree grows downward one convenient sub-page at a time until nothing is reachable by browsing. If you use one, enforce the three-level rule socially, since the tool will not. Flat-page wikis with strong linking (classic wiki style) push you toward hubs and links, which ages better but demands more deliberate curation. The tradeoffs between the two models run deeper than structure — see Wiki or docs? Choosing the right home for team knowledge for the full comparison.

In Openbook, teams typically split the difference by composition: a Docs room (nested pages, block editor) for living team documentation with a deliberately shallow tree, a Wiki room (Markdown) for reference material like runbooks and decision records, and hub pages in each linking across rooms — with global ⌘K search spanning all of it, so the hierarchy only has to be good enough for browsing, not perfect. Because rooms live inside spaces with their own membership, the "Teams" problem solves itself: each team's space holds its working documents, and the company space holds only what everyone needs. You can see how rooms compose on our product page.

Next steps

You do not need a migration or a committee. You need four sessions:

1. This week (90 min): Run the card sort on 40 real questions. Draft a top level of five to nine task-named sections.
2. Next week (2 hours): Write the one-page placement constitution and the "Start here" page. Retitle your 20 most-important documents as queries.
3. Week 3 (2 hours): Build hub pages for your three busiest sections. Create the Archive and move the ten most obviously dead pages into it — enjoy how good that feels.
4. Week 4 (30 min): Put the quarterly audit on the calendar with a named owner. Structure without a recurring appointment is a New Year's resolution.

A navigable knowledge base is not the one with the cleverest taxonomy. It is the one where a new hire, on day three, types a question the way they would ask it, finds one current page with a clear title, and stops needing to ask a human — and where that stays true next year because someone audits the garden every quarter.

If your knowledge base is currently scattered across tools, Openbook gives you docs, wiki, Q&A, and global search in one workspace — free to start at openbook.work.