FAQ Sections: Format, Schema and Examples

An FAQ is a closing content element that answers a small, evidence-backed set of questions the page’s main sections do not already resolve. Its questions use the reader’s language, and each 30–60-word answer stands on its own. The live element below is rendered from this page’s [[faq]] frontmatter rather than duplicated in the Markdown body.

The visible questions above and their FAQPage structured data share one source. Editing a frontmatter entry changes both representations, which prevents a polished on-page answer from drifting away from the machine-readable version.

Why this element matters

Readers often reach the end of a page with a narrow uncertainty rather than a need for another full explanation. A buyer may understand what a product does but still wonder whether setup requires a credit card. A person following a procedure may know the steps but need to confirm what happens when a required input is missing. An FAQ gives those high-frequency, late-stage questions a predictable place without forcing every reader through another long section.

The element works because question wording is a recognition cue. A reader scanning “Can I export the data?” can identify their own concern faster than they can interpret a vague heading such as “Additional information.” The answer then resolves that concern immediately. This is reader psychology, not decoration: the component reduces the distance between a specific doubt and its resolution.

An FAQ also creates bounded question-and-answer pairs for machine extraction. Machine extractability means software can isolate a unit and preserve its meaning outside the full page. A real question followed by a self-contained answer is easier for search systems, internal search, support tools, and AI agents to identify than an answer hidden in a miscellaneous closing paragraph. The boundary helps only when the language remains explicit; “Yes, as described above” is visually inside an FAQ but becomes useless when extracted.

Frontmatter is the publishing source because the same records must feed three uses: the visible block, FAQPage structured data, and corpus-level analysis. Corpus-level analysis means querying all pages as a collection—for example, finding every answer about cancellation or checking which page types routinely exceed six questions. Keeping entries in typed [[faq]] records makes those checks possible. Copying the questions into the body creates two editable versions and invites drift.

When to use it

Use an FAQ when research reveals several recurring questions that are relevant to the page but too narrow to justify full sections. Good candidates clarify edge cases, eligibility, compatibility, timing, definitions that readers routinely confuse, purchase objections, or a safe next action. Each question must help the same audience complete the page’s primary decision or task.

Question research comes before writing. Collect exact language from search suggestions, internal site search, support tickets, sales-call notes, community discussions, and tracked AI prompts. Prompt Tracking is useful because it records the questions a business chooses to monitor across AI engines; repeated prompts can reveal how prospects ask about a category, feature, or comparison. The record is evidence of wording and demand, not permission to force an unrelated prompt onto a page.

Do not use an FAQ merely because a template provides one. Invented questions such as “Why is our platform amazing?” are recognizable as marketing copy wearing a question mark. Keyword fragments such as “FAQ schema benefits?” do not sound like a reader. Both weaken trust and teach machines little about an actual information need.

An FAQ is not a dumping ground for paragraphs that did not fit the outline. If an answer introduces a core argument, explains a required step, carries the page’s strongest evidence, or needs more than 60 words, it is doing real work and probably deserves a named section. Move it into the main structure. The FAQ may then answer the smaller follow-up that remains.

Do not repeat the article in question form. “What is X?”, “Why is X important?”, and “How does X work?” are poor closing questions when those are already the page’s first three sections. Repetition makes the page longer without increasing coverage, and it risks producing slightly different answers to the same question.

The common near-miss is a relevant question whose answer is central. On a symptom-style page, “When is this serious?” may look like a natural FAQ, but warning signs affect safety and should appear in the main body where every reader encounters them. The FAQ can repeat neither the warning list nor a weaker summary. Instead, use a narrow unresolved question such as whether one particular circumstance changes the recommended next action.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

FAQ is a closing element because its job is to resolve residual questions after the page has delivered its main answer. Place it after the substantive body, examples, and supporting evidence. Place sources immediately before it when the FAQ depends on those sources; place the primary call to action and related-content links after it. This sequence lets the reader resolve final uncertainty before deciding what to do next.

Do not place the production FAQ directly below the hero, inside the introduction, between steps, or between a claim and its evidence. The live block at the top of this specification is a demonstration required by the element library, not the prescribed placement for normal pages.

Use one FAQ block per page. It may not sit next to a second accordion, a “common questions” section containing the same material, or a recap rewritten as questions. Avoid placing it beside a large glossary list: two dense sets of short entries compete for the same scanning behavior. If both are necessary, keep definitions in the relevant body sections and reserve the closing block for unresolved questions.

Anatomy

The labelled screenshot separates the semantic regions from the visual treatment. The legend stays in this page so its labels remain readable when the image is resized or replaced.

1. Section heading: Names the collection as frequently asked questions; it is a real heading in the document hierarchy.
2. Question: Uses the reader’s words as a complete interrogative sentence and ends with a question mark.
3. Disclosure control: On collapsible variants, the operable button exposes whether its answer is expanded and identifies the controlled answer region.
4. Answer: Gives the direct response first, then one useful qualification, distinction, or next action.
5. Item boundary: Visually and programmatically keeps each question associated with exactly one answer.
6. Frontmatter record: The nonvisual source pairing question and answer; it feeds both presentation and FAQPage output.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

The variants change presentation, not content ownership. Every version reads the same [[faq]] records and preserves the same question-answer pairs.

Standard responsive variant

Desktop shows questions and answers in aligned columns; smaller screens use disclosure controls to conserve vertical space. This is the default when the design system supplies responsive behavior.

Collapsed mobile variant

Questions remain visible as buttons and answers open in place. The control must communicate expanded state, retain keyboard access, and keep the answer adjacent in reading order.

Long-question stress variant

A natural question may wrap to two lines. The layout must preserve the question mark, control target, and answer alignment without truncation.

No-FAQ state

When there are no researched questions, render nothing. Do not show an empty heading, placeholder row, or generic generated content.

Parameters

Parameters are the content contract. Limits exist to keep each pair extractable and to stop the closing element from becoming a second article.

The evidence reference does not need to appear publicly, but it must survive editorial review. A support-ticket identifier, call-note link, query export, or tracked-prompt record is enough. “The writer thought of it” is not.

Syntax and code examples

All three forms treat FAQ entries as structured page metadata. The rendering instruction contains no duplicate questions or answers.

Portable Markdown directive

:::faq{source="frontmatter" heading="Frequently asked questions"}
:::

The portable document model stores the records as page metadata:

[[faq]]
question = "Can I export the report as a CSV?"
answer = "Yes. Export creates a CSV containing the report's current dataset. Check the export scope before sharing it, because screen filters and account permissions can affect which records are included."

Hugo shortcode

{{< faq-side-by-side title="Frequently asked questions" >}}{{< /faq-side-by-side >}}

The Hugo shortcode reads .Page.Params.faq; it receives no JSON body. Adding inline items would create a second source and is forbidden for this element.

WordPress block or shortcode

<!-- wp:amicited/faq {"source":"post-meta","heading":"Frequently asked questions"} /-->

[amicited_faq source="post-meta" heading="Frequently asked questions"]

In WordPress, each question and answer belongs in repeatable post metadata used by both the block renderer and the JSON-LD emitter. Pasting the same pairs into block HTML or shortcode body content fails parity even when the page looks correct.

Examples

Good example

Can I change the reporting period after exporting the report?
Yes. Change the reporting period in the report, then create a new export so the file reflects the revised range. An existing CSV is a static snapshot and will not update automatically when dashboard filters change later.

This works because the question sounds like something a user would ask after encountering the export workflow. The first sentence answers “yes” and states the action. The second explains the consequential boundary: the earlier file does not update itself. At 30 words, the answer is complete without becoming a hidden tutorial.

Bad example

Report export CSV download?
As mentioned above, our powerful platform makes exports easy. See the reporting section for more information about all the great options available to you.

The question is a keyword fragment rather than spoken language. The answer does not state whether export is possible, depends on absent context, adds an unsupported promotional claim, and sends the reader elsewhere. Rephrasing alone is not enough; the writer must verify a real question and provide the actual behavior.

A second bad pattern is a 180-word answer containing prerequisites, five steps, and a warning. Even if every sentence is accurate, that material belongs in a procedure section. The FAQ should answer the narrower residual question or be removed.

Schema markup and accessibility

Schema markup is standardized machine-readable code that identifies the meaning and relationships of page content. FAQ entries map to a Schema.org FAQPage. Each visible question becomes a Question in mainEntity; its answer becomes the acceptedAnswer with type Answer and a text value. The site emits this structure as JSON-LD , a JSON-based format for linked structured data.

Markup must match visible content exactly in meaning and wording. Do not add a schema-only question, shorten the visible answer only in markup, or leave an old answer in JSON-LD after editing the page. The frontmatter-only rule prevents these failures by deriving both outputs from the same record. Structured data describes content; it does not compensate for thin, invented, or hidden content, and it does not guarantee a rich search result.

Accessibility depends on disclosure behavior. A disclosure is a control that shows or hides associated content. The question should be a native button when it toggles an answer, with aria-expanded reflecting the current state and aria-controls pointing to the answer’s unique ID. ARIA, Accessible Rich Internet Applications, supplies states and relationships when native HTML alone does not express them.

Keyboard users must be able to reach every question, open it with Enter or Space, and continue through the page in a logical order. Focus must remain visible. The answer should follow its question in the document order, and headings must not skip levels. Do not rely on a chevron rotation, color, or animation as the only expanded-state signal. If answers are always visible on desktop, they must still remain associated with their questions through dt and dd or an equivalent semantic relationship.

Writing rules

Use four to six questions in a typical FAQ. Four is the practical floor because fewer questions rarely justify a separate closing interface; one to three answers can usually be placed beside the relevant body sections. Six is the practical ceiling because a longer set becomes difficult to scan and often signals that major topics were withheld from the article. Exceptions require evidence: a regulated product may need more narrow eligibility questions, while a concise product page may omit the block entirely.

Phrase every entry as an actual question in the reader’s words. Preserve useful vocabulary from the source, but remove personal data, account-specific details, and conversational noise. Combine true duplicates only when their answers are also the same. “Can I cancel monthly?” and “Will I receive a refund?” may occur in the same sales call, but they represent different decisions and must not be collapsed.

Write 30–60 words per answer. The first sentence answers the question; the second elaborates with the most useful condition, distinction, reason, or next action. Name the subject so the answer survives extraction. Never write “yes, it does,” “see above,” “as discussed earlier,” or “contact us to learn more” as the complete answer.

Use a calm, factual tone. Define a necessary technical term in the answer, but do not stack jargon. Include a link only when the destination enables the next action or supplies essential detail; the visible answer must still be complete without following it. Do not include testimonials, sales slogans, unrelated keywords, nested tables, multi-step procedures, or claims that lack support.

Every post type declares intent categories its FAQ must cover. An intent category is the kind of decision behind a question, not a keyword theme. A symptom-style page might declare cause, self-treatment, seriousness, and purchase categories, with at least one question covering warning signs. Because warning signs affect safety, the main body must still present them; the FAQ category check ensures the closing questions do not discuss only easy commercial topics.

Generalize that method rather than copying those four categories everywhere. A comparison may require switching cost, compatibility, contract, and best-fit categories. A how-to guide may require prerequisites, failure recovery, completion verification, and maintenance. Coverage is successful when the declared categories reflect the page’s search intent and real evidence, not when every page repeats a universal question set.

Post types that use it

The postTypes frontmatter records the registered joins. The table turns each join into a coverage and placement rule; it does not make FAQ mandatory where research finds no useful residual questions.

“Usually” means the post type commonly creates residual questions, not that editors should manufacture them. The evidence threshold still applies.

QA checklist

A reviewer checks the source records before judging the visual styling.

• Single source: Every visible pair comes from [[faq]] frontmatter; no question or answer is duplicated in the Markdown body.
• Real demand: Each question has a traceable source in search suggestions, site search, support, sales, research, or tracked AI prompts.
• Natural phrasing: Every question is a grammatical question in the reader’s language, not a keyword fragment or product claim.
• Direct answer: The first sentence resolves the question; the second adds the most useful qualification or action.
• Standalone meaning: No answer relies on “above,” “earlier,” “this,” or another missing referent.
• Length: Each answer contains 30–60 words; each question stays under 120 characters unless natural wording genuinely requires more.
• Count: The block normally contains four to six entries, with a recorded reason for any exception.
• No displaced sections: No answer contains a core argument, required procedure, major warning, or evidence set that belongs in the main body.
• No repetition: Questions do not restate headings already answered completely, and answers do not summarize the article again.
• Declared coverage: The set covers the post type’s required intent categories, including a risk or warning category where the subject demands one.
• Correct placement: The production block follows substantive content and sources, and precedes the primary CTA and related content.
• Visible-schema parity: FAQPage.mainEntity contains the same questions and answers as the rendered block, with no hidden or stale entries.
• Accessible controls: Toggle buttons expose expanded state, answer IDs are unique, keyboard operation works, focus is visible, and document order remains logical.
• Empty state: A page with no qualified questions renders no FAQ heading or placeholder content.
• Screenshot status: Capture comments remain comments until their named assets exist; no nonexistent path is rendered as an image.

FAQ

The live example at the top and the FAQPage data are generated from the five reviewed [[faq]] records in this page’s frontmatter. They cover necessity, sourcing, answer length, standalone wording, and visible-schema parity without maintaining a second copy here.