How to plan a knowledge base category structure

A useful knowledge base category structure reflects the way customers think about their work. It does not need to match your company chart or product code. A customer who wants to invite a teammate should not need to know which internal team owns permissions.

Start with a small structure based on real questions. Test it with people who did not design it. Then change it as your product and article library grow.

Choose one clear organizing idea

Most small help centers can start with categories based on the customer journey or major product areas.

A journey structure may look like this:

1. Get started
2. Set up your account
3. Complete core tasks
4. Manage billing
5. Fix a problem

A product-area structure may use names such as Projects, Reports, Team settings, Integrations, and Billing. This works when customers already recognize those areas in the interface.

You can combine the two with care. Keep Get started and Troubleshooting as task-based categories, then use stable product areas for the middle. HelpDocs recommends a small, scannable set of top-level categories. The exact number matters less than whether a new customer can predict where an answer belongs.

Use customer language for category names

Name a category with a short noun or task that appears in the product. Avoid broad names such as Resources, General, Other, or Solutions. They make readers open several pages to understand what is inside.

Check each proposed name against ticket language. If customers say “invoices” and your team says “revenue documents,” use invoices. If two names mean the same thing, choose one and use the other as a search term inside relevant articles.

Each category needs a short description. State what readers will find there. For example: “Invite teammates, change roles, and manage access.” This helps a customer choose between Team settings and Account settings.

Keep the hierarchy shallow

Deep category trees make browsing slow and create hard placement choices. Start with a category and its articles. Add one subcategory only when a category has distinct groups that readers can name and each group has enough useful content.

Use this test before you add a level:

• Can a reader name the group without seeing its articles?
• Does the group solve a distinct set of tasks?
• Will the group contain several current articles?
• Can an article have one clear primary home?

If the answer is no, keep the articles together and improve their titles. Search and contextual links can express relationships without another folder.

Run a simple card sort

Write one real article title on each card or spreadsheet row. Ask three to five people who know the customer but did not build the structure to place each card under a proposed category.

Note where people disagree or create a new group. A disagreement often points to one of three problems: an unclear article title, overlapping categories, or a category name that uses internal language.

After the sort, give each person five tasks. Ask where they would look for “change my password,” “download an invoice,” or another real question. Record the first place they choose. Do not coach them. Their wrong turns show what the labels need to fix.

Give each article one main home

An article can relate to several topics, but it should have one primary category. Duplicate copies create update risk. One version can link from related articles and appear for relevant search terms.

For example, “Connect Slack” belongs in Integrations. A team-settings article can link to it when that task is a common next step. The customer support article template includes a related-articles section for this purpose.

Create a short placement rule for writers. It can be one sentence: “Choose the category that matches the customer's goal at the start of the article.” This keeps new content from slowly rebuilding your org chart.

Review the structure with evidence

Review categories when you launch a major product area, when one category becomes hard to scan, or when search and ticket data show repeated confusion. Do not reorganize only because a new structure looks tidy. URL changes and moved articles can disrupt customers and links.

During a review, check:

• Category names match current navigation and customer words.
• Every category has a clear purpose.
• Empty and one-article categories have a reason to exist.
• Similar articles sit together.
• Old product names are gone or explained.
• Important setup and troubleshooting content is easy to browse.
• Moved pages keep a working destination when URLs change.

A full knowledge base content audit can combine this structure review with checks for accuracy, duplication, and missing answers. If you are starting the whole support process, follow the small-team help desk setup guide.

See Support Station's help desk features or start with the free plan.