How to write help center articles people actually find

Most help centers fail the same way: articles written from the company's point of view, titled with the company's vocabulary, organized by the company's org chart. Customers search in their own words, skim, and leave for the chat widget. Then the support team answers the same question forty times a month while a perfectly good article gathers dust.

Writing articles people actually find and actually use is a craft with learnable rules. Here are the ones that matter, in the order they matter.

1. Title with the customer's words, not yours

People search for symptoms and goals, not feature names. Your internal name for something is almost never the phrase a customer types.

• Weak: "Configuring SSO via the Identity Provider panel"
• Strong: "How to let your team log in with Google"

The best source of titles is your support inbox: the literal first sentences customers write are a keyword list nobody outside your company can replicate. Mine it monthly. This is also what makes help content compound for SEO: every well-titled article is a long-tail search page.

2. Answer in the first two sentences

An article is not an essay. The reader arrived mid-task and slightly annoyed. Give the resolution immediately, then explain below for those who want depth:

To change your workspace name: go to Settings, then General, edit the Name field, and press Save. Changes appear for teammates within a minute.

Below: what happens to your workspace URL, and who is allowed to make this change.

3. One task per article

"Everything about billing" is a wiki page, not a help article. Split it: how to change your card, how to download invoices, how refunds work, what happens when payment fails. Small articles rank better for specific searches, are easier to keep accurate, and can be linked directly from support replies. If you find yourself writing "Part 2", split it.

4. Write steps someone can follow with one hand

• Numbered steps, one action each. "Click Save" and "Wait for the confirmation" are separate steps.
• Name UI elements exactly as the interface shows them, in bold.
• State where the reader starts ("From the dashboard sidebar...") and how they know it worked ("You will see a green Saved badge").
• Screenshot only the moments people get lost: pickers, hidden menus, confusing dialogs. Every screenshot is maintenance debt; spend it where it pays.

5. Cover the failure, not just the happy path

The reader who most needs the article is the one for whom it did not work. End task articles with a short "If this did not work" section: the two or three most common causes, in symptom-first language, with the fix or a direct path to support. This section is also where searches like "X not working" land, which is exactly the traffic a help center exists for.

6. Organize shallow, search-first

Deep category trees are where articles go to die. Two levels is plenty: a handful of categories a stranger would understand, articles directly inside. Never file by internal team ownership. Then treat search as the primary navigation: most visitors will never browse, so titles and first paragraphs (which search indexes weigh heavily) do most of the work.

7. Maintain it like code

• Review on release. When a feature changes, its articles change in the same week. Stale screenshots destroy trust faster than missing articles.
• Watch the feedback signal. A "was this helpful" widget with falling scores is a rewrite queue, not a vanity metric. Chattypie's knowledge base tracks per-article helpfulness and view counts for exactly this loop.
• Close the loop from the inbox. Every question that arrives twice deserves either a new article or a better title on an existing one. Support replies should link articles rather than retype them; if agents avoid linking an article, that article needs work.

8. Let the help center feed your AI agent

If you run an AI agent on chat, your help articles are its training material. Everything above doubles as AI hygiene: symptom-phrased titles help retrieval, answer-first paragraphs make quoted responses correct, and one-task articles prevent the agent from blending three procedures into one wrong answer. Teams get measurably better automated answers by fixing their docs, no model tuning involved. Ours works the same way: the AI agent answers from your published articles and hands off to a human when it is unsure.

A checklist to ship with every article

1. Title is a phrase a customer would type.
2. The answer appears in the first two sentences.
3. One task, numbered steps, exact UI names.
4. "If this did not work" section exists.
5. Linked from at least one related article, and used in support replies.
6. Owner and review-on-release noted.

Start with your ten most-asked questions (your inbox already knows which they are), write those ten articles with this checklist, and measure repeat questions a month later. That is the whole strategy; the rest is repetition.