---
title: "How Many Categories Should a Help Centre Have?"
canonical: https://supportpages.io/guides/how-many-categories-should-a-help-centre-have
updated: 2026-08-13
---

A defensible number of top-level sections for your help centre, based on how many articles you have rather than on how many features you ship. For most help centres the answer is between five and nine, and the reasoning below is what tells you which end of that range you are at.

## Before you start

Count your published articles, and estimate how many you expect to have in a year. Both numbers matter: a structure built for today's forty articles collapses at a hundred, and a structure built for a hundred looks empty at forty. If the growth estimate is a guess, use double your current count - it is wrong less often than any other guess.

## Steps

1. **Count what you have published, excluding drafts.**
   Drafts do not need a home yet and counting them inflates the structure before the content exists to fill it.

2. **Divide by ten to get your starting number of sections.**
   Forty articles suggests four sections, ninety suggests nine. Ten articles per section is the middle of the comfortable range and a reasonable place to begin.

3. **Constrain the result to between five and nine.**
   Below five, sections are so broad that the name stops narrowing anything. Above nine, the list needs scanning rather than reading, and readers switch to search - which means the effort you put into the structure goes unused.

4. **Check each section holds between five and fifteen articles.**
   Under five, the section is not carrying its weight. Over fifteen, the landing page becomes a list nobody reads to the bottom of, and the useful articles at the end are effectively hidden.

5. **Add a second level only where a section exceeds fifteen.**
   Subcategories inside one oversized section, not across the whole help centre for consistency. Uniform depth applied to sections that do not need it adds a click to every journey.

6. **Merge any section with fewer than three articles.**
   A section holding one article is a link wearing a costume. Fold it into the nearest larger section and keep the article's URL unchanged.

7. **Never go three levels deep.**
   Two levels is the practical limit for a help centre. At three, the breadcrumb is longer than most article titles and nobody can hold the location in their head.

8. **Leave headroom in the names.**
   "Billing and plans" accommodates next quarter's invoicing articles. "Stripe setup" does not accommodate anything. Names that describe a topic rather than an implementation survive the product changing underneath them.

9. **Re-count once a quarter and rebalance.**
   Fifteen minutes with a spreadsheet. Sections grow unevenly by nature, and the only cheap moment to split one is before it reaches twenty-five articles.

![Three help centre structures compared: two categories, six, and eighteen.](/images/guides/figures/how-many-categories-should-a-help-centre-have.webp)

*Too few and nothing is findable. Too many and neither is the category.*

## Common mistakes

**One category per feature.** It produces twenty sections, most holding two articles, and it guarantees a restructure as soon as the product is renamed. Categories describe what people are trying to do, not what you built.

**A section with a single article.** Every visitor who opens it feels misled, and the section list is longer for no gain. One article belongs inside a larger section.

**A section with forty articles.** Whatever is below the fifteenth item is functionally unfindable by browsing. Split it, even if the split feels arbitrary at first.

**Nesting for symmetry.** Adding subcategories to every section because one section needed them costs a click on every other journey and communicates nothing.

**Creating "Other" or "Miscellaneous".** It is where filing decisions go to be avoided, and it grows every month until it is your largest section and your least useful one.

## When this stops scaling

The arithmetic works to roughly a hundred and fifty articles. Below that, sections of five to fifteen articles cover the whole corpus at one or two levels, and a quarterly count keeps them balanced.

Past that, per-section counts drift faster than a quarterly rebalance corrects them. A section that was twelve articles in January is twenty-eight in June because that is where the product invested, and the split you then need is not the split you would have chosen from a blank page. Restructures at that size are expensive: every move is a redirect, and browse traffic dips while the index catches up.

There is a second threshold that has nothing to do with counting. Once search rather than browse is how most people arrive - which happens somewhere around the same size - the category structure stops being a navigation aid and becomes an organising convenience for the team. That does not make it worthless, but it does mean the returns on agonising over it fall sharply.

[SupportPages](https://supportpages.io) derives sections from the codebase and keeps proposing where new articles belong as the product grows, which is the rebalancing problem rather than the counting one. Until a hundred and fifty articles, a spreadsheet and a quarterly quarter-hour is genuinely all this needs.