---
title: "How to Name Help Centre Categories"
canonical: https://supportpages.io/guides/name-help-centre-categories
updated: 2026-08-13
---

Section names that a stranger can route on without opening anything, tested with a filing exercise rather than agreed in a meeting. The test is the important half: names always look obvious to the person who wrote them, and that is exactly why naming discussions produce bad names.

## Before you start

You need your current section list with the articles under each, your site search queries, and a sample of ticket subject lines. You also need two people who have never seen the help centre. Ten minutes of their time is worth more than an hour of your team's opinions, because they are the only ones who can tell you what the names communicate to someone who does not already know.

## Steps

1. **Write the question each section answers.**
   One sentence per section, in a customer's voice. If you cannot write it, the section is not about anything and its name is describing a container rather than a topic.

2. **Use the reader's noun, not your feature's name.**
   Your tickets and search logs contain the vocabulary. If customers write "invoice" and your interface says "billing document", the section is Invoices.

3. **Prefer concrete topics to abstract qualities.**
   "Billing and invoices" routes people. "Essentials", "Resources", "Advanced" and "Fundamentals" do not - they describe how you feel about the content rather than what is in it.

4. **Keep names to one to three words.**
   Long names are truncated in navigation, in breadcrumbs and on mobile, and the truncation lands mid-phrase where the distinguishing word usually is.

5. **Make the set mutually exclusive.**
   Account, Settings and Profile are three names for overlapping ideas, and any article touching one could plausibly live in all three. Where two names could hold the same article, one of them is wrong.

6. **Avoid naming by content type.**
   "Videos", "PDFs" and "Tutorials" group by format, so a reader looking for a billing answer has to check all of them. Format is a filter, not a category.

7. **Run the filing test.**
   Take ten articles, hide their current sections, and ask two strangers to file each one using only your names. Every disagreement is a naming problem, and the article that both file differently from you is telling you something specific.

8. **Check the name survives becoming a URL.**
   `/getting-started` reads well. `/tips-tricks-and-more` does not, and it will be in every link you publish for the next five years.

9. **Check the name against what your interface says.**
   If the product calls it Workspaces and the help centre calls it Teams, every article in the section starts by translating. Match the product, and if the product's own word is poor, fix it there first.

![Category names compared: internal system names against the words users would type.](/images/guides/figures/name-help-centre-categories.webp)

*Name the category after the job, not the subsystem.*

## Common mistakes

**Internal jargon in a public name.** Sections named after subsystems, project codenames or team names mean nothing to a customer and are usually the last thing anyone thinks to review.

**"Getting started" containing advanced material.** The name sets an expectation about difficulty, and filling it with configuration reference punishes exactly the readers who most need the reassurance.

**Ambiguous pairs.** Account and Settings, Guides and Tutorials, Integrations and Apps. Each pair forces a filing coin-toss on every article and a search on every reader.

**Clever names.** Puns, alliteration and in-house humour cost recognisability, and the reader in a hurry is the person paying that cost. Plain naming is what serves them.

**Naming once and never re-testing.** Products rename features constantly. A section name that matched the interface two releases ago is now a small translation task on every visit.

## When this stops scaling

Names do not decay by themselves. A well-tested set stays correct for as long as the product's vocabulary does, which for most teams is a year or two - so re-running the filing test annually is normally enough.

The threshold is rename frequency. If the product renames a user-facing concept more than once or twice a year, every rename orphans a section name, and the mismatch between interface and help centre accumulates quietly. Nobody files a ticket about a category name, so the drift is only ever discovered during the next restructure.

The second threshold is authorship. One person naming twelve sections produces a coherent set. Four people naming sections over three years produces a list where each name is defensible individually and the set has no consistent logic - some named by task, some by object, some by audience. That mixture is harder to fix than any single bad name, because correcting it means moving articles.

[SupportPages](https://supportpages.io) proposes the section set from the codebase in one pass, so the names are decided together rather than accumulated. If your current list contains two names you would not choose today, that is the accumulation problem showing.