How to structure a knowledge base

A knowledge base usually does not fail because the team lacks information. It fails because the information is there, but no one can reliably find it, trust it, or remember where it lives.

Structure is the quiet layer that makes everything else work. Search helps when people know what to type. Navigation helps when they do not. A good structure gives readers a mental map: a small set of entry points, predictable page types, and clear paths from broad topics to specific answers.

If you are new to the basics, start with what a knowledge base is. This article focuses on how to shape the content so it stays usable as it grows.

What “structure” means in practice

When teams say their docs are “messy,” they usually mean one of these is true:

• There are too many top-level buckets, so no one knows where to start.

• Important pages are buried five levels deep.

• Different page types are mixed together (policies, meeting notes, drafts, official answers).

• Pages are titled inconsistently, so search returns noise.

• The same concept exists in three places, and no one knows which is canonical.

Structure is how you prevent those failure modes with a few intentional constraints.

Three principles that keep a KB navigable

1) Start with a small number of entry points

A knowledge base should feel like a handful of doors, not a hallway of unlabeled drawers. In practice, this means starting with 5 to 7 top-level categories. Fewer forces clarity. More creates indecision.

A rule that helps: do not create a category unless it will hold at least five pages soon. Empty categories invite dumping grounds because people stop respecting them.

2) Prefer shallow depth over perfect nesting

Deep trees look tidy, but they hide information. Most teams are better served by a shallow structure with strong internal links. If readers have to click through four parent pages to reach an answer, they will often ask in chat instead.

A common target is 2 to 3 levels deep for most content, with exceptions for dense areas like product docs or long onboarding sequences.

3) Separate “truth pages” from “working pages”

The fastest way to lose trust is to mix official instructions with exploratory notes. Your structure should signal intent:

• Knowledge base pages are owned, verified, and meant to be followed.

• Wiki-style pages capture evolving context: decisions, meeting notes, research, and drafts.

If you want a clear way to draw this line, see knowledge base vs wiki (and when you need each).

Pick a taxonomy: three patterns that work

There is no universal taxonomy. But there are a few patterns that repeatedly work because they match how people look for answers.

Pattern A: By team (good for internal knowledge)

Use this when knowledge is owned by functions and the audience is primarily employees.

• People Ops

• Engineering

• Support

• Sales

• Marketing

Where it breaks: cross-functional processes (onboarding, incident response, shipping) can end up duplicated across teams. If you use a team taxonomy, add a shared “How we work” hub for cross-cutting practices.

Pattern B: By workflow (good for action-oriented knowledge)

Use this when the primary intent is “help me do the thing.”

• Onboarding

• How we ship

• Incident response

• Security

• Tools and access

Where it breaks: people sometimes do not know which workflow they are in. Pair this with strong hub pages and “related reading” links.

Pattern C: By product area (good for external KBs and help centers)

Use this when customers think in terms of features and modules.

• Getting started

• Accounts and billing

• Integrations

• Permissions and security

• Troubleshooting

Where it breaks: certain questions are not “feature questions” (for example, “How do I export data?”). Create a home for cross-cutting tasks like migrations, troubleshooting, and account management.

A practical hybrid that often wins

Many teams end up with a hybrid:

• Team spaces for ownership and depth.

• Shared hubs for the things everyone needs (Onboarding, How we ship, Security, Support FAQs).

This reduces duplication without forcing everything into one taxonomy.

Design hub pages that act like reliable entry points

Hub pages are where structure becomes visible. They are the pages you want people to land on when they do not know where to start.

A good hub page typically includes:

• A short “what this area contains” paragraph.

• The 5 to 12 most-used child pages (curated, not exhaustive).

• Links grouped by page type (SOPs, runbooks, policies, FAQs).

• A clear owner and a last reviewed date.

When hubs are well maintained, they reduce the pressure on perfect taxonomy. People can browse, orient, and move laterally through links.

Standardize a few page types (so the KB feels consistent)

Structure is not only where pages live. It is also how pages read once someone opens them.

At minimum, define a small set of page types for “truth pages,” such as:

• How-to (task steps, prerequisites, expected outcome)

• SOP (repeatable internal process, with roles and checks)

• Runbook (incident or operational response under pressure)

• Policy (rules, scope, exceptions, escalation)

• FAQ (fast answers to repeated questions)

Then treat everything else as wiki-style content by default. This makes it easier for readers to know what to trust, and it makes it easier for writers to keep pages tidy.

Keep titles and naming conventions boring on purpose

Teams often name pages for the person who wrote them, the meeting they came from, or an internal joke. That is fine for personal notes. It does not work for a shared knowledge base.

Simple conventions tend to beat cleverness:

• Use titles that match the words someone would search for.

• Prefer “How to…” and “Troubleshooting…” for task pages.

• Make “one page, one intent” the goal. If a page is trying to be both a policy and a history lesson, split it.

• If two teams use different terms for the same thing, pick one as the canonical term and add synonyms in the first paragraph.

A lightweight starting structure for small teams

If you are building a knowledge base from scratch, start with something you can keep clean. Here is a simple internal setup that works for many startups:

• Start here (orientation, glossary, key links)

• Onboarding (setup, first week, expectations)

• How we work (shipping, meetings, decision-making)

• Runbooks (incidents, operational procedures)

• People Ops (policies, benefits, time off)

• Tools and access (accounts, permissions, requests)

• Support FAQs (internal or external, depending on your needs)

This is not meant to be perfect. It is meant to be stable enough that you can add pages without constantly redesigning the tree.

Common mistakes (and the small fixes that prevent them)

Creating a “Misc” or “General” bucket

This becomes a dumping ground and makes structure meaningless. If you need a catch-all, use “Inbox” with a rule: anything in Inbox gets triaged weekly.

Letting structure mirror your org chart too closely

Org charts change. A knowledge base should reflect how people seek answers, not just reporting lines. If you do use team categories, stabilize them with shared hubs that do not change often.

Storing multiple versions of the same answer

If two pages explain the same process, pick one canonical page and link to it from everywhere else. Consolidation is a structural decision as much as a writing decision.

Assuming structure alone will keep things trustworthy

Structure makes things findable, but maintenance keeps them correct. If you need a simple system for ownership and review cycles, use best practices for maintaining a knowledge base.

A quick checklist before you call the structure “done”

• Can a new hire find the top 10 operational answers in under two minutes?

• Do you have 5 to 7 top-level categories (not 20)?

• Are most pages reachable within 2 to 3 clicks from a hub?

• Do high-impact pages have an owner and a last reviewed date?

• Do your “truth pages” look and feel consistent?

• When there is duplication, do you have one canonical page and links pointing to it?