How to write an FAQ page

Most FAQ pages are not frequently asked questions. They are things the company wanted to say, rewritten with question marks. "Why should I choose BrandName?" is not a question anyone has ever typed.

A real FAQ page reduces support load and gets found in search, and it does both for the same reason: it uses the words the customer actually uses.

Find the real questions

Do not invent them. Collect them.

• Support tickets and chat logs. Sort by frequency. The top twenty are your page.
• Search queries on your own site. Especially the ones that return nothing.
• What sales gets asked on every call.
• Reviews and social replies, including the complaints — an FAQ that addresses a genuine objection is more persuasive than any marketing copy.
• Search suggestions for your product category.

Then write each question in the customer's words, not yours. Customers ask "how do I get my money back?" They do not ask "what is your refund policy?" Use their phrasing as the visible question; you can mention your internal term in the answer.

Write the answers

Answer in the first sentence. Yes or no, or the number, or the direct instruction. Then explain. A reader who has to work through three sentences of context to find "no" has been mistreated.

Be specific. Not "refunds are processed promptly" but "within five working days of us receiving the item".

Say no clearly when the answer is no. Evasion generates a support ticket, which is the exact thing the page exists to prevent.

Keep each answer short — 40 to 100 words. Anything longer belongs on its own page, with the FAQ giving the short answer and a link.

One question, one answer. Do not bundle three related things; people search for one.

Structure

Group by theme once you have more than about eight questions: ordering, delivery, returns, account, billing. Order the groups by how common they are, not by your internal org chart.

Put the top three to five questions at the very top, before the groups, if the data is that lopsided — and it usually is.

Include a search box on a long page, and make sure each question is a linkable anchor so support staff can send someone to the exact answer.

End with a clear route to a human. An FAQ page with no escape hatch is a wall.

Accordions and findability

Collapsible sections are fine and are usually the right pattern for a long list, provided the answer text is present in the HTML rather than loaded on click — otherwise it will not be found by in-page search or indexed reliably.

Add FAQPage structured data if the questions and answers are genuinely visible on the page. It is the one place where marking up your content can produce a rich result, and it is straightforward.

Keeping it alive

An FAQ page is not a launch task. Review it quarterly against current support volume. Add questions that are now being asked; remove ones that stopped, because a dead question about a discontinued feature undermines trust in the rest.

Track which answers precede a support ticket anyway — those answers are failing, and that is the most valuable signal the page produces.

Common mistakes

Invented questions that serve marketing. Corporate phrasing instead of customer phrasing. Burying the answer. Answers that are three paragraphs long. No route to a human. Never updating it. Duplicating a whole help centre in one page. Using the FAQ as a substitute for fixing a confusing product — if forty people a week ask the same thing, the answer is a design change, not a better paragraph.

Practical tips

• Export three months of tickets and count. Do not guess.
• Write the question exactly as the last customer phrased it.
• Read each answer and ask "would this stop me contacting support?"
• Link between related answers; people rarely have only one question.
• If an answer keeps growing, promote it to its own guide and link.