Choose FAQ questions from real enquiries

Collect questions by the task behind them

Use an online workshop as a planning example. Separate questions about enrolment conditions, access after purchase, schedule changes and receiving materials. Record the point where the customer’s task stopped. Do not copy entire support conversations into a publication sheet; extract the task and required answer first. Record the review period, intake channels and classification count, avoiding repeated replies from one conversation being counted as independent demand. These counts help select FAQ candidates. They are not search-volume estimates and should not be presented as evidence of wider market demand.

• Prepare an evidence-based editorial brief

Group questions that require the same decision

Questions such as “Can I watch on my phone?” and “Do I need an app?” may support the same device-compatibility decision. “The video will not open” may instead be a post-purchase fault requiring another route. Group by the required conditions, answer and next action, not merely similar words. Record a representative question, included cases and excluded cases. Do not turn slight wording variations into separate pages just to increase the article count. Make the scope of each answer explicit so a reader can tell whether it applies to their situation.

Assign an answer owner and evidence

Attach an answer owner and supporting material to each question. Access expiry may come from current terms, device support from the usage guide and schedule changes from the booking process. Confirm the answer against what customers are actually shown, rather than relying only on someone’s memory. If a condition is unresolved, explain the confirmation route instead of filling the gap with a plausible answer. Record the review date and the triggers for another check, such as a price revision, new lesson format or changed registration process.

Write a direct answer and a specific next step

Begin with the answer and its conditions, then provide the next action. For example, explain where the access email is sent and what information to provide if it is missing. A long troubleshooting procedure should normally have one maintained destination rather than being copied in full into several FAQ answers. Use a link label that names the action available at that destination instead of an unexplained “here.” Decide which page owns the detailed rule and which FAQ points to it, making future corrections easier to apply consistently.

• Compare search queries with article content

Remove private details and exceptional arrangements

Review examples for names, order identifiers, email addresses and sensitive personal circumstances. A one-off accommodation or exceptional refund must not become a general promise to every customer. Separate public rules from decisions that require identity confirmation and a support conversation. If an image of an enquiry interface is used, inspect it for unnecessary personal information. Some questions are better addressed through an improved internal support procedure than a public answer. Selection for the FAQ should depend on a reusable customer need, not the existence of an interesting support story.

Build for readers rather than a retired search feature

As of October 2026, Google’s documentation updates state that FAQ rich results are no longer displayed in Search. Do not budget for a promised question expansion or click-through improvement from adding FAQPage markup. Prioritize ordinary readable HTML and useful links from product or registration pages. Any retained structured data should still match the visible content. The value of answering a customer’s question is separate from support for a particular search presentation. Check current documentation instead of copying an older SEO article’s eligibility claims into a new implementation.

Publish a small set and test the customer route

Begin with a small selection covering pre-purchase decisions, first access and common difficulties. Test whether the answer can be found on the published page. On mobile, check long headings and, where accordions are used, keyboard-operable controls. Provide a contact route when the answer does not resolve the issue. Budget separately for classifying enquiries, verifying answers, publishing and maintaining them. An existing CMS page may support a small FAQ; identify actual needs such as shared editing or internal search before subscribing to a dedicated FAQ platform.

Ask someone considering enrolment to reach the relevant answer from the registration page and identify the conditions needed for their decision. If the same clarification is still required after reading it, revise that answer and its destination before adding more questions to the list.

Review answer usefulness and update decisions

Review repeated support questions, movement to detailed instructions and correction requests as well as FAQ visits. A frequently opened answer may indicate confusion rather than successful resolution. Follow the site’s existing consent and data-collection policy, and avoid sending support conversation text or personal information into analytics. Search Console can help review the relevant URLs and queries, while support review explains the customer task. At the next revision, remove obsolete answers or move instructions to their proper pages instead of treating growth in the number of questions as the only sign of progress.

• Collect service feedback for review