Take your FAQ questions from what people actually ask: support tickets, sales calls, and the search queries that bring people to the page. Phrase each question the way a customer says it, answer it in the first sentence, and delete any question invented in a meeting.
An FAQ built from real questions reduces support volume. One built from imagination adds page length and nothing else.
Where the questions come from
Three sources, all of which you already have.
- Support and sales: anything asked more than twice is a question
- Search Console: the queries bringing people to the page tell you what they expected to find
- The related questions box on the results page for your main term
Phrase them as customers do
Write the question in the customer's words, not the company's. Do you deliver to my area rather than shipping coverage. What happens if it does not fit rather than returns policy.
This matters for two reasons. A visitor scanning for their question recognises their own phrasing instantly, and search engines match the page to the query more readily when the query is on the page.
Answer first, then explain
Every answer should open with the answer. Yes. No. Within three working days. It costs this much.
Then add the qualification if there is one. The pattern of two sentences of preamble before a yes is what makes FAQ pages exhausting, and it is what causes the person to contact support anyway.
Answer the awkward ones
The questions worth including are the ones you would rather not: why it costs more than the alternative, what it does not do, what happens if it goes wrong, how to cancel.
Those are the questions people actually have. Answering them plainly builds more trust than any amount of reassurance, and refusing to answer them does not make anyone stop wondering.
An FAQ where every question has a comfortable answer is recognisably promotional and gets skipped.
Where to put them
In context, near the decision, rather than on a separate page. Delivery questions belong on the product page. Billing questions belong near the pricing.
A standalone FAQ page is worth having as a catch-all and it will always be read less than an answer placed where the doubt occurs.
If you mark up genuine questions with FAQ structured data, they can appear directly in search results. Mark up only what is visible on the page, since marking up hidden content is a violation.
Keep it pruned
An FAQ grows and is never trimmed, which is how it becomes forty questions nobody scrolls through.
Review twice a year. Remove anything nobody asks any more. If a question is asked constantly, the answer probably belongs in the main page copy rather than buried in a list, and the fact it is asked so often may mean the product or page is unclear.
Common questions
- Where do FAQ questions come from?
- Support tickets, sales calls, and the search queries bringing people to the page. Anything asked more than twice is a question. Delete anything invented in a meeting.
- How should I phrase FAQ questions?
- The way a customer says it, not the way the company does. Do you deliver to my area rather than shipping coverage. A visitor scanning for their question recognises their own phrasing instantly.
- Should FAQs be on their own page?
- Put them in context near the decision instead. Delivery questions on the product page, billing questions near the pricing. A standalone FAQ page is worth having as a catch-all and will always be read less.
Keep reading