How to Write an FAQ Page

By the time you finish you will have an FAQ built from questions customers genuinely asked, each answered in its first sentence, with the procedural ones promoted to proper articles - and a rule for what gets deleted, which is the part that keeps an FAQ useful after its first year.

Before you start

Get access to three sources of real questions: your support inbox, the search log from your help centre or website, and whoever talks to customers before they buy. An FAQ written in a meeting is a list of things the company wishes people asked.

Decide what the page is for. An FAQ that answers pre-sale hesitations belongs near the pricing page and is a different document from one that answers "how do I do X", which belongs in the help centre.

Real FAQs are collected, not invented in a meeting.

Steps

1. Pull the actual questions from tickets and search logs.
   Export a few hundred and read them. The wording matters as much as the subject, because the wording is what people type into search boxes.

2. Group them and count.
   Ten phrasings of "how do I cancel" is one entry with a clear priority. Frequency ordering is the only ordering that reflects what readers came for.

3. Write each question in the customer's words, not the company's.
   "Can I get a refund?" is the question. "What is the refund policy?" is a document title, and it matches nothing anybody types.

4. Answer in the first sentence.
   Yes, no, or the number. Context follows the answer. An entry that opens with background before the answer is a paragraph the reader has to search for the answer inside.

5. Keep each answer to about eighty words.
   Anything longer is an article that has been squeezed into an accordion, and the accordion is why nobody can find it later.

6. Promote every procedural question to its own article.
   If the answer contains numbered steps, the FAQ entry becomes a one-line answer plus a link. Procedures need their own page, their own title and their own search result.

7. Answer the awkward questions honestly.
   Pricing limits, missing integrations, data location, what happens on cancellation. An FAQ that only contains flattering questions is read as marketing and stops being consulted.

8. Group entries into sections once you pass about a dozen.
   Billing, account, security, getting started. An unsectioned list of thirty questions is scanned for four seconds and abandoned.

9. Put each question and answer in the page's HTML, not in a widget.
   A heading and a paragraph is what gets read, by people and by crawlers. Do not spend time on FAQ structured data: Google removed FAQ rich results from its search pages in June 2026, and its May 2026 guide to optimising for generative AI features says no schema markup is needed to appear in its AI answers either.

10. Delete entries nobody asks any more.
    Review against a fresh export every quarter. A question that no longer appears in tickets or search logs is either fixed in the product or was never real, and both mean it goes.

Common mistakes

Writing the questions internally. The result is a page of questions phrased in product vocabulary, answering objections rather than problems, that ranks for nothing.

Using the FAQ as an overflow area. Content with no obvious home ends up as an FAQ entry, and after a year the page is a landfill that is easier to ignore than to sort.

Answering with a bare link. "See the documentation" makes the reader take another step to find out whether the answer is even there. Answer, then link for detail.

Papering over a confusing product. Three questions about the same screen is a design bug being documented rather than fixed. Note them, and pass them on.

Hiding everything behind accordions. Google indexes collapsed content, so the cost falls on readers: in-page search finds nothing because the text is not rendered until clicked, and a page of closed accordions shows no answers at all until someone starts opening them.

When this stops scaling

An FAQ page is a good format for a small, stable set of high-frequency questions. It fails as a knowledge base, and the transition is gradual enough that most teams miss it.

The practical limit is around twenty-five entries. Past that, the page is longer than anybody scrolls, in-page search becomes the primary navigation, and the format's one advantage - everything visible at once - has already gone. The second limit is change: an FAQ is a flat file with no per-answer ownership, so nothing indicates which of the forty answers stopped being true when the pricing changed.

The signal that you are past the threshold is support answering the same question the FAQ already covers, because staff cannot find the entry either. At that point the questions need to become individually addressable articles, each findable on its own, and the FAQ shrinks back to the handful of genuinely frequent ones. Knowing which questions to write next is the hard half: SupportPages logs the questions a help centre could not answer and ranks them. Under twenty-five entries, a hand-maintained FAQ reviewed quarterly is a perfectly good system.