Write and maintain a useful website FAQ

Collect actual questions

Gather emails, calls, internal searches and staff observations. Group different wording for the same issue, then retain a phrasing a visitor would naturally use. Avoid questions invented only to carry a keyword.

For each question, identify who owns the answer and which page provides more depth. Pricing answers should point to a clear offer; technical answers can lead to a guide. The site FAQ illustrates these connections.

• Question origin known.
• Similar questions combined.
• Answer owner identified.

Answer directly with limits

Give an immediate answer followed by conditions that change the decision. Fictional example: for “Do you work at weekends?”, identify the services and times actually offered, then explain how to obtain confirmation. “It depends” is insufficient: name the information needed. Keep exceptions close to the short answer so it does not become a general promise.

Cite a source when it matters and date time-sensitive facts. Have commercial, technical or regulatory claims approved by the relevant person. The source-checking guide distinguishes fact, example and assumption.

• Direct answer first.
• Conditions visible.
• Source and approval fit the topic.

Build useful navigation

Group questions by need and add search when the list becomes long. Titles should make sense outside the surrounding page. Avoid repeating one question in several places with conflicting answers; link related pages instead.

Test accordion controls with a keyboard, anchors and phone reading. If an answer is essential to an offer, it belongs at the point of decision as well as in the FAQ.

A visible FAQ, optional FAQPage markup and a search engine’s rich presentation are different layers. Google announced the end of FAQ rich results from 7 May 2026, then removed their documentation in June. Do not sell adding this markup as a way to obtain that display. Schema.org still describes the FAQPage type; that does not create a Google feature.

Evaluate the answer by the task it helps complete: finding a condition, understanding a limitation or reaching the right service. Decisive text must be readable on the page, including when presented in an accordion. When an answer changes, review other occurrences and the structured data describing it. Markup must follow actual content without introducing a promise or answer absent from the interface.

• Needs-based groups.
• Accessible accordions.
• Decisive facts shown on relevant pages.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

• Google Search Central : Documentation updates

  Consulted on 22 October 2026; May and June 2026 announcements about the end of FAQ rich results.

• Schema.org : FAQPage

  Consulted on 22 October 2026; type definition is independent of a search engine’s support.

Plan maintenance

Connect each answer to its owner, verification and review trigger. Fictional example: a new package includes a previously optional visit; find the corresponding question in the FAQ, service pages and translations. Have the new rule approved before publishing and remove questions that no longer describe the offer. A recent date cannot replace that approval.

Review searches with no results and questions that still arrive after people see the FAQ. Correct the answer or the journey accordingly. The content operations guide suggests a simple review cycle.

• Review owner and date.
• Duplicates combined.
• Unresolved questions used to improve content.