---
title: "How to Organise a Help Centre"
canonical: https://supportpages.io/guides/organise-a-help-centre
updated: 2026-08-27
---

You will finish with a section structure derived from the questions your customers ask, with every article filed in exactly one place and a redirect behind every URL that moved. The method is a card sort with a small number of people, which is unglamorous and reliably better than a structure argued about in a meeting.

## Before you start

You need a full list of articles, your top site search queries and ticket subjects from the last quarter, and the ability to set redirects. You also need five to eight people who are not on your team and who resemble your customers - colleagues from sales or finance will do if customers are not available. Their unfamiliarity is the instrument.

## Steps

1. **List every article as the question it answers.**
   Not the title, the question. "Connecting a payment provider" becomes "how do I take payments?". Working from questions is what stops the structure mirroring your product's internal shape.

2. **Write each question on a card.**
   Physical cards or a shared board. One question per card, no categories yet, no ordering.

3. **Ask each participant to group the cards into piles that make sense to them.**
   Individually, not as a group. Give them no category names - naming those is the next step and seeding it here contaminates the result.

4. **Ask each participant to name their own piles.**
   Their words are your section names. This is the highest-value ten minutes in the process.

5. **Look for the groupings that repeat across participants.**
   Five to eight people is enough for the stable groups to emerge clearly; beyond that you are confirming what you already saw. The cards that land in a different pile every time are the ambiguous ones, and they need a naming decision rather than a filing decision.

6. **Assign each article to exactly one section.**
   Multiple filing feels helpful and reliably makes things harder to find, because the same article appears in two places and readers cannot tell whether they are the same page. Cross-link instead.

7. **Order sections by the reader's journey, then by traffic.**
   Setup and getting started first, troubleshooting near the end, billing and account somewhere in the middle. Alphabetical ordering is a decision not to decide, and it puts "Account" above "Getting started" on every help centre that uses it.

8. **Fix the number of top-level sections before naming them.**
   Five to nine fits on one screen without scrolling; the arithmetic for your article count is in [how many categories a help centre should have](/guides/how-many-categories-should-a-help-centre-have).

9. **Redirect every URL that changed.**
   Reorganising is a bulk move. Produce the old-to-new map as a table, apply it in one change, and check a sample of old URLs afterwards.

10. **Test with five findability tasks.**
    Give five people a task each - "find out how to add a teammate" - and watch where they click first. Anything that takes more than two clicks or sends them straight to search is a section name that is not working.

![Two structures compared: one mirroring the product's internal services, one following what users are trying to do.](/images/guides/figures/organise-a-help-centre.webp)

*Repository boundaries are engineering seams. Users do not have them.*

## Common mistakes

**Mirroring the product's navigation.** Your interface is organised around objects; customers arrive with goals. The two coincide often enough to be tempting and diverge exactly where people are stuck.

**Mirroring the org chart.** Sections named after the teams that wrote them - Platform, Growth, Trust and Safety - are invisible to customers, who have no way of knowing which team owns their problem.

**Filing articles in several categories.** It doubles the maintenance and confuses readers who cannot tell duplicate listings from duplicate articles. One home, plus links.

**Reorganising without redirects.** Every internal link, in-app help link, support macro and search result pointing at the old URLs breaks at once, and the damage arrives days later as tickets nobody connects to the restructure.

## When this stops scaling

A card-sorted structure holds up to roughly one hundred to a hundred and fifty articles across a dozen sections. That is about the point where a person can still see the whole set at once, which is what makes the sorting judgement possible.

Above that, two things change. Sections drift out of balance faster than anyone rebalances them - one grows to forty articles while another sits at three - and the browse path stops being the main way anyone arrives. Most sessions start with a query, so the taxonomy becomes a filing convenience for the team rather than a navigation aid for the reader.

The third limit is entropy. Every new article needs a filing decision, and those decisions are made by whoever is publishing, in a hurry, without the card sort in front of them. Six months later the structure reflects a hundred small individual judgements rather than the one you tested.

[SupportPages](https://supportpages.io) proposes the section structure from the codebase before writing any articles, so new content arrives with a home rather than being filed after the fact. At your current size, a card sort and a re-test each year will keep you ahead of the drift.