The FAQ Section That AI Actually Cites

The question-answer format is the native structure of AI model responses. When a buyer asks an LLM a question, the model constructs a response by finding pages that answer that question directly. An FAQ page that asks the same question in its heading and answers it in the body is already aligned with how the model retrieves and synthesises information. No other format on your website has this structural advantage by default.

This matters because the alternative is that the model has to extract answers from pages not structured around questions. A product page, a blog post, a capabilities overview. These pages might contain the answer, but the model has to work harder to find it, extract the relevant passage, and determine whether the passage actually addresses the buyer’s query. An FAQ answer that matches the question directly reduces the model’s extraction cost to near zero.

The problem is that most FAQ pages squander this advantage. They answer questions nobody asks an AI model (“What are your office hours?”), they answer in two sentences that contain no evidence, and they hide answers inside accordion elements that AI crawlers do not reliably expand. The format is right. The content is wrong. The structure is missing. And the metadata is either absent or copied from the rest of the site.

The rest of this guide covers two things. The architecture the FAQ section needs to support both user navigation and AI retrieval, and the four-phase content brief that produces each per-question page. If you have not used the Content Plan yet, the Content Plan guide walks through the full workflow.

The mental model worth fixing before anything else. An FAQ section is not one long page with a list of accordion items. It is a content architecture with two layers, and both layers are necessary. Treating the FAQ as a single page sacrifices retrievability for AI engines. Treating every question as its own page sacrifices discoverability for users. The hybrid is the answer.

The hub

A single FAQ entry point at /faq (or/help,/support. The exact path matters less than that the path is persistent and discoverable). The hub lists every question, grouped by category, and does one of two things per entry.

Short answers stay inline on the hub. Capability questions (“Does the platform support SAML SSO?”), policy questions (“What is your refund window?”), and simple mechanics (“How do I download an invoice?”) get a one to three sentence inline answer right on the hub. No separate page. These are the questions where the short answer is the complete content.

Substantive answers preview, then link out. For questions that warrant depth, the hub shows the question, a one sentence preview of the answer, and a link to the dedicated page where the full answer lives.

The hub uses FAQPage schema for the inline-answered questions, plus Article schema for the hub page as a whole. Two schemas, two jobs.

The per-question pages

Every substantive question lives at its own URL. Examples: /faq/onboarding-timeline,/faq/data-residency-by-region,/faq/integration-with-your-identity-provider. One question per URL. Each page contains a single, fully developed answer.

Per-question pages use Article schema, not FAQPage. FAQPage schema tells the engine to expect a list of multiple Q&A pairs; a page with one question and one answer does not contain that list and should not claim to. Each per-question page has a self-referencing canonical, a natural-language slug that carries the buyer’s question shape, and a mesh of internal links back to the hub and across to related per-question pages.

On URL path conventions

The path convention matters less than which convention you commit to./faq/ reads as user-facing self-service. /help/ and /support/ lean toward post-purchase troubleshooting. For B2B sites where the same per-question page serves both pre-purchase evaluation and post-purchase troubleshooting, /faq/ is the cleanest default. Whichever you choose, keep it. Moving from /faq/onboarding-timeline to/help/onboarding-timeline six months later breaks the URL’s earned citation history and forces a redirect map you do not need.

Which questions earn their own page

A question deserves a dedicated URL when one or more of the following is true.

• The honest answer is substantive, around two hundred words or more of content the buyer actually needs to make a decision.
• The question represents a recurring buyer concern with stakes attached. Objections that could kill a deal, misconceptions AI is repeating in your category, structural questions that recur across customer conversations.
• The answer benefits from supporting evidence the hub cannot carry. Tables, named customer references, data points, comparison structures, embedded charts.
• Buyers query the question (or close paraphrases of it) directly into Google or AI. The URL itself has retrieval value because the slug mirrors the buyer’s actual phrasing.

Questions that fail all of those criteria stay inline on the hub. The architecture’s discipline is not to add pages. It is to add pages only where the page does work no other surface can do.

Why the hybrid works for both audiences

A user lands on the hub, scans the categorised list, finds the question shape they are holding, and gets the short answer if it is quick. If they need depth, they click through to the dedicated page and get the full answer in one read. They never have to scroll through fifty unrelated answers to find the one they came for.

An AI engine asked a substantive question by a buyer retrieves the dedicated page directly. The page presents exactly one extractable answer, with its own canonical, schema, and slug. The engine does not have to parse a long FAQ page and disambiguate which Q&A pair is the one that matters. The retrieval target is unambiguous, and the citation that follows is clean.

The internal-linking mesh between the hub and the dedicated pages, and across dedicated pages where the topic relationship is real, is what propagates topical authority through the architecture. Hub-and-spoke linking, where every dedicated page links only back to the hub, starves the dedicated pages of authority. Mesh linking, where dedicated pages reference each other at contextually relevant points, feeds them. The mechanics of mesh linking specifically are in the internal linking technique.

The rest of this guide covers two things in order. First, how to design the hub page so it serves user navigation without sacrificing the per-question pages underneath it. Second, the four-phase brief that produces each per-question page well. The hub design comes first because the hub is what a buyer lands on and what an AI engine encounters before it reaches any individual answer. Get the hub wrong and the per-question pages underneath it lose the discoverability and schema scaffolding that makes them retrievable.

The hub has one job for users and one job for AI engines, and the two jobs do not conflict if the design is right. For users, the hub is a navigation surface that lets a buyer find the question shape they are holding without scrolling through answers they did not come for. For AI engines, the hub is a structured index that points to per-question pages and carries the small number of inline answers worth extracting at the hub level itself.

Five elements carry the design. Each one has a reason that traces back to user testing, accessibility guidance, or AI retrieval mechanics. Skip any of them and the hub starts working against the per-question pages it is supposed to support.

1. An H1 in buyer language

The hub’s H1 is not FAQ as a category label. It is the phrase a buyer would use to describe what they came for. Frequently Asked Questions about [product category] is workable. [Product name] FAQ is workable.Help Centre is also workable when the hub mixes evaluation and troubleshooting content. The H1 should match the path convention you committed to at /faq/, /help/, or /support/ so the URL, the H1, and the navigation label tell the same story.

2. A search field, prominently placed

User testing on FAQ and help-centre interfaces is consistent on the same finding. A meaningful share of users start with the search field rather than browsing categories, and that share rises once the question count exceeds twenty. Nielsen Norman Group’s FAQ research treats search as a baseline requirement once the hub crosses that threshold. Baymard’s on-site search research adds the design specifics. The field should be visible above the fold, sized so it accepts a full question without truncation, and labelled with placeholder text that prompts the user to type a question rather than a keyword. Baymard’s testing has documented that users struggle to activate search when it is hidden behind a magnifier icon, and that the design of the search field itself shapes how users approach the rest of the page.

Hiding search behind a magnifier icon costs you measurable engagement on a surface where engagement is already the bottleneck. The search field is the only element on the hub that handles the question the buyer arrived with verbatim. Treat it as the primary navigation, not as a fallback.

3. A topic-grouped category grid, goal-based

Below the search field, the hub presents a grid of category cards. Five to nine categories is the working range. Fewer than five and the grouping is not doing real work. More than nine and the buyer falls back to scanning rather than choosing. Each card carries the category label, a one-line description, and the count of questions it contains.

Group categories around the buyer’s goal, not your product’s structure. Getting started, Pricing and billing, Security and compliance, Integrations, Account management are goal-based. Module A, Module B, Module C are product-based and force the buyer to translate their question into your taxonomy before they can navigate. Goal-based grouping shortens that translation step, which is the step where buyers drop off.

Avoid dropdowns and hidden menus at the category level. Hidden navigation consistently produces higher drop-off in NN/g’s usability studies. The category grid should be visible in full on first render, with no interaction required to see what is available.

4. Question items in two display modes

Inside each category, questions appear in one of two display modes, matching the architectural decision from the previous section.

Mode A: short answer inline. The question is rendered as an h3 (or an h4, depending on the depth of the category headings). Directly underneath, one to three sentences answer the question on the hub itself. No accordion, no “read more” toggle. The answer is in the DOM and visible by default. These are the entries that go into the FAQPage schema on the hub.

Mode B: question, preview, link. The question is rendered as an h3 with a link to the dedicated per-question page. Underneath, a one-sentence preview of the answer, followed by a Read full answer link that goes to the per-question URL. The full answer never appears on the hub. These entries are not in the FAQPage schema on the hub, because the schema would be claiming a complete answer is present when it is not.

Mixing the two modes inside one category is fine and expected. The criterion for which mode a question gets is the same one that decides whether it earns its own URL: answer depth, plus whether the answer benefits from supporting evidence the hub cannot carry.

5. A footer block for unanswered questions and recency

At the bottom of the hub, two pieces of content close the page. A short block that addresses the buyer who did not find their question, with a path to a person (chat, email, or a structured form) and a path to ask the question publicly so it can be added to the hub. And a Last updated date for the hub itself, separate from the dates on individual per-question pages.

The unanswered-question block is operational, not decorative. It is the channel that produces the next round of FLUQs, the friction-inducing latent unasked questions that should drive the next set of per-question pages. The recency stamp is a small AI-retrieval signal that the hub is maintained, which is read by engines when they weigh sources for citation.

Visual hierarchy: topic above question above answer

NN/g’s FAQ guidance is specific about the typographic hierarchy that lets a buyer scan a hub at speed. The topic (category) reads heaviest, the question reads next, the answer reads lightest. In practice this means category headings are h2, question headings are h3, and answer text is body weight. Skipping a level, or weighting questions heavier than topics, defeats the scan pattern.

Mobile pattern

On mobile, the category grid collapses to a vertical list rather than a two-column or three-column layout. The search field remains above the fold. The category cards lose their counts to save horizontal space but keep their one-line descriptions. Mode A and Mode B question entries render the same as on desktop, with the preview text wrapping to two lines if needed.

Schema on the hub

Two schemas live on the hub. FAQPage schema, listing only the Mode A entries (question + complete inline answer). Article schema for the hub page as a whole, with the H1 as the headline and the Last updated date as the dateModified. The Mode B entries are not in the FAQPage schema because their complete answers are not on the hub. The per-question pages they link to carry their own Article schema separately.

One note on FAQPage schema specifically. In August 2023 Google narrowed FAQ rich results to government and health sites. On May 7, 2026 Google fully deprecated FAQ rich results across all sites, including the government and health domains that retained them after 2023. The Search Console FAQ reports were removed in June 2026, and FAQ data in the Search Console API was removed in August 2026.

The schema itself remains valuable regardless. AI engines parse structured data as part of how they identify and extract citation-worthy content, and a clean FAQPage block on the hub still helps engines recognise which questions carry a complete answer they can quote directly. Treat the schema as AI-citation scaffolding, not as a Google rich-result lever.

What the hub does not do

The hub does not carry sales copy, product positioning, or comparison content. Those belong on the per-question pages where the answer requires them. The hub is a navigation surface plus a small set of inline answers. Keeping it narrow is what makes the per-question pages underneath it discoverable in the first place.

The questions on your FAQ page should not come from your support inbox or your sales team’s guesses. They should come from the signals AI models surface when buyers ask about your market. IIH Nordic coined a useful term for the most valuable category of these: FLUQs, or Friction-Inducing Latent Unasked Questions: the concerns buyers never type into a search bar but that still determine whether they convert. These map directly to the objection and fit question types below. Each signal type produces a different kind of question, and each kind requires a different answer structure.

In Seedli, these signals appear in the Content Plan with a priority score. The higher the score, the more urgently buyers are asking about this topic and the more competitors are failing to address it. Here are the five question types, the signals that trigger them, and where to find them in your data.

Each type also implies an architectural decision: whether the question stays inline on the hub or earns its own per-question page. Objection, comparison, process, and substantive fit questions almost always earn dedicated pages because the honest answer requires depth, evidence, and elimination-defence weight. Simple capability questions are split. A capability question with a yes/no answer (“Does the platform support SAML SSO?”) stays inline on the hub. A capability question with a substantive answer (“How does the platform enforce data residency for backups?”) earns its own page. The criterion is answer depth, not question category.

Before drafting a per-question page, the brief surfaces three pieces of information that decide whether the page will be retrievable at all: the title the buyer would actually search, the position the page commits to, and the intent family the model is running behind the buyer’s single visible query. Get these wrong and the rest of the page is decoration.

Title (H1)

The page’s promise to the buyer, expressed in the buyer’s language. AI engines read the title as one of four signals (alongside the meta description, the URL slug, and the visible snippet near the query term) when deciding whether to retrieve the page in the first place. The title is also the H1 the reader sees first when they arrive.

For an FAQ per-question page, the pattern that works is to use the question itself as the title, phrased the way the buyer phrases it. Not a category label, not a vendor-internal name for the topic. Does the platform support data residency in the EU? is a title. EU Data Residency Information is a category label. The label is invisible to the buyer who is typing the question into AI; the title is the question they typed.

The same discipline rules out clever titling. The Truth About Data Residency reads as editorial flair but does not match anything a buyer types. Why Our Architecture Solves Residency for You is vendor language pretending to be buyer language. AI engines have absorbed enough of the gap between marketing copy and unguarded buyer language to discount titles that read as one written to look like the other.

Position

The one claim the page commits to and defends. A page with no position (here are the options, you decide) is the content AI engines deprioritise. A page that takes a stance, with the evidence for that stance available on the page, is the content the engine cites.

The position has two parts. The claim is the one sentence the page argues for. EU data residency is delivered through region-pinned tenants on European infrastructure, audited annually under ISO 27018. The defensible-because line is the evidence or logic the page returns to when the claim is challenged. Region-pinning is verifiable from the customer admin panel and from independent SaaS infrastructure transparency reports. Without the defensible-because line, the position is an assertion. With it, the position is a testable hypothesis the engine can quote.

Hedge-laden positions undermine citation value. Many platforms address residency one way or another, depending on your needs is the writing that produces the noncommittal “both X and Y are strong choices” AI answer the architecture itself is trying to avoid. If the page does not take a stance, the engine has nothing to lift out as the brand’s position.

Intent family

Buyers do not search with one query. When answering a buyer’s question, AI engines generate two to three fan-out queries the buyer never sees, and synthesise the response from the results of all of them. The intent family is the primary buyer question the page is written to answer, plus the two to three sub-questions the engine is also running behind the scenes.

For the residency question, the intent family looks like this:

• Primary: Does the platform support EU data residency for customer data?
• Fan-out: Which third-party audits validate the platform’s EU residency claims?
• Fan-out: How is region-pinning enforced for backup and disaster-recovery copies?
• Fan-out: What happens to logs and metadata that are not customer data?

The per-question page does not need a separate section for each fan-out query. The discipline is to answer all of them inside the page’s argument so that whichever fan-out the engine retrieves on the buyer’s behalf, the page is a match. Pages that answer only the primary query lose retrievability against the fan-out searches the engine is also running, which is the part most “FAQ for AI” guidance misses.

The brief generates the primary plus the fan-out set automatically from the buyer-language corpus Seedli observes across the four customer-facing engines. The author’s job is to write a page that satisfies all four queries in one read, not to chase each fan-out as a separate sub-article. Where the fan-out coverage appears structurally is in Phase 2.

With the title, position, and intent family settled, Phase 2 turns the inputs into the page’s skeleton. Two things come out of this phase: the four to five H2 sections the page is built from, and a one-sentence framing direction that tells the writer how to open, what to lead with, and how to close.

Structure (the H2s)

The four to five major sections of the article, each phrased as a specific claim or question, not a topic label. The reason for the claim-or-question pattern is mechanical. AI engines extract an H2 and the content that follows it as a standalone answer when constructing a response to a related buyer query. An H2 that reads Architecture is a label; the engine has to work to figure out what claim the section makes. An H2 that reads How region-pinning is enforced for backup and disaster-recovery copies is a claim the engine can lift directly. The label version costs the engine effort. The claim version pays the engine a citable unit.

For the EU residency page from Phase 1, the H2 structure looks like this.

• H2: What the platform’s regional infrastructure actually covers, and which services are pinned to which region
• H2: How region-pinning is enforced for production data, backups, and disaster-recovery copies
• H2: Which third-party audits validate the platform’s residency claims, and how to read each one
• H2: What happens to logs, metadata, and operational data that are not strictly customer data
• H2: How to verify residency for your tenant in under fifteen minutes without contacting support

Each H2 is a specific question or claim the section answers in full. None are category labels. Each one maps to either the primary buyer query or one of the fan-out queries identified in Phase 1, and together they cover the full intent family. This is the answer to where the fan-out coverage shows up in the page. The H2 set is the structural placement Phase 1 deferred to Phase 2.

Four to five H2s is the working range. Fewer than four risks under-covering the intent family. More than five usually signals the page is trying to be two pages, which is the moment to consider whether the second topic deserves its own per-question page in the hub-and-per-page architecture from the opening section, rather than being compressed into this one.

Framing

A single-sentence editorial direction for the writer. The brief uses it to communicate the article’s emotional arc and the order the writer should move through the evidence. Not the whole writing plan. One sentence that tells the writer how to open, what evidence to lead with, and how to close.

For the residency page, the framing might read: Open with the specific region-pinned architecture and a one-sentence statement of the position, then walk through enforcement at each data class (production, backup, metadata) with named audit references, and close by showing the reader the exact admin-panel path they can use to verify residency on their own tenant. That single sentence tells the writer the arc (declaration first, evidence by data class in the middle, reader-actionable verification at the close) without prescribing every paragraph.

Why the framing is one sentence and not three. The writer needs latitude inside the H2 structure to find the natural voice for their section. An overprescribed framing produces stilted copy. An underprescribed framing produces a page that argues different things in different sections. One sentence is enough to set the arc and leave the writer the room to execute against it.

The framing is also where the editorial voice of the brand survives brief generation. Two pages on the same topic with the same H2 structure and the same data will land differently if one is framed validate the buyer’s frustration first, then present the evidence and the other is framed open with the numbers and let the data carry the page. The framing is the one place in the brief where the brand voice is allowed to be deliberate.

With the inputs from Phase 1 and the structure from Phase 2 locked, Phase 3 produces the elements that go inside the body of the page. Five sub-elements, each with a specific job. None of them is “the body itself.” The body is what the writer drafts against the H2 structure. These five are the surrounding elements that decide whether the body gets cited.

Intro Key Takeaways

A hook sentence, three to five bullets, and an optional bridge sentence, placed at the top of the page, right under the H1. Each bullet is a self-contained claim AI engines can cite independently of the rest of the article. The block is skimmable for users and extractable for machines, and it does the same job a well-written executive summary does: it tells the reader what they will learn without making them earn it.

For the residency page, the takeaways block looks roughly like this.

Each bullet leads with a bold claim that holds up as a single-sentence quote. The body of each bullet does the supporting work, but the bold claim is what an AI engine lifts when constructing a buyer’s answer.

Key Snippet

The roughly one hundred character answer to the primary buyer query, placed early in the article body. The snippet is what AI engines see when scanning the page to decide whether to cite it. It should answer the question directly, in buyer language, in a single sentence the engine can extract verbatim. For the residency page:

The discipline is to keep the snippet to one sentence, lead with the answer, and include the verification path inside the sentence wherever the page is structured around a verifiable claim. The snippet appears once, near the top of the body, in plain prose. Repeating it elsewhere dilutes the signal.

Internal Linking

Two suggested internal links with relational anchor text, placed at the specific points in the body where the connection is most useful. The anchor text explains why the linked page matters at that point, not just what the destination is called. For the residency page, the two links Seedli would suggest:

• “the platform’s complete subprocessor list, kept current and dated”, placed in the H2 section on what happens to logs and operational data, from the sentence that references the chain of services touching non-customer data.
• “the most recent ISO 27018 audit attestation and how to read each control area”, placed in the H2 section on third-party audits, from the sentence that names the audit.

Both anchors carry relational context. The platform’s subprocessor list tells the reader and the engine what the destination is for. Click here would not. The first anchor is an implementation link (this is the concrete artifact that supports the claim). The second is an evidence link (this is the document that proves the claim). Two links, two contexts, no repetition. The full method is in the internal linking topology technique.

Earned-Citation Hooks

One to three quotable standalone lines designed to travel beyond the page itself, into Reddit threads where buyers debate the topic, into YouTube transcripts where independent reviewers cite the brand, into third-party articles where analysts reference the platform’s position. The hooks make the article more citable from earned surfaces, which is where the majority of AI citations are sourced. For the residency page:

• Region-pinned residency only counts when the backup and disaster-recovery copies inherit the same pin. Most “EU residency” claims do not survive that test.
• The Residency Audit Framework: before accepting any vendor’s residency claim, ask which audit names the configuration, where the backup copies live, and how a customer can verify the pin without contacting support.
• Customers who self-verify their tenant’s region pin before signing the contract avoid the residency-compliance escalation that arrives nine months later from procurement or legal.

Each hook is a standalone sentence that can be lifted out of the article and quoted on its own. When the brand promotes the article on LinkedIn or shares it in a sales conversation, the first line of the share is one of these hooks. They are also the lines a reviewer or analyst is most likely to quote when referencing the page, which is the mechanism by which earned-surface citations propagate.

Recency Requirements

Whether the article needs current data and which sources to refresh. AI engines weight fresh content heavily. Roughly half of the top-cited content across major engines is less than thirteen weeks old, and the recency window keeps moving. The recency requirements line in the brief flags which named sources the writer must check before publishing and references freshness in the article text where it matters.

For the residency page, recent data is applicable, with named refresh windows. The sources to refresh are the most recent ISO 27018 audit attestation (annually; the publication date should appear in the audits H2 section), the platform status page filtered for residency-specific incidents (quarterly; reference any open incidents in the production-data H2 section), and the subprocessor list (on every quarterly review; the article should link to the dated list, not embed a snapshot that will go stale).

The recency block is the article’s defense against staleness. A residency page that does not name its audit date or the freshness of its subprocessor list will be deprioritised against a competitor page that does. The freshness signal is not a bonus. It is structural.

The final phase carries everything that lives outside the visible body of the page but decides whether the page gets retrieved, displayed correctly in search and social, and parsed as the right kind of content by the engines reading it.

Slug

The URL path of the page. Four to seven natural-language words that mirror the buyer’s question shape, not a generic content-type label like guide, checklist, or overview. Per Profound’s analysis, natural-language slugs of this shape earn approximately 11.4 percent more citations than parameter-heavy or label-style slugs. The mechanism is straightforward: the slug is one of the four signals the engine reads when deciding to cite (alongside title, meta description, and snippet), and slugs that semantically match the buyer’s query produce a stronger match score than slugs that describe the article’s format.

For the EU residency page in the hybrid architecture, the slug pattern is /faq/eu-data-residency-region-pinning or /faq/eu-customer-data-residency-architecture. Both are five-word natural-language slugs that mirror what a buyer would type or what an engine would generate as a fan-out query. What the slug should not be: /faq/article-23, /faq/data-residency-faq, /faq/residency-guide. The first is opaque. The second repeats faq twice. The third uses the generic content-type label guide in place of the question shape.

The slug should not change after publication. Moving from /faq/eu-data-residency-region-pinning to /faq/european-residency-compliance six months later resets the URL’s earned-citation history and forces a redirect map. The slug is a long-term commitment; treat the brief’s slug suggestion as a decision, not a draft.

Meta Description

The page’s pitch, 280 to 320 characters, with two audiences. The first 150 characters display in Google search results and are read by users deciding whether to click. The rest is read by AI engines that pull the full meta description into their evaluation when deciding whether to cite the page. Same tag, two readers.

For the residency page:

That is 296 characters. The first 150 characters end at “...this page documents what the platform’s region-pinning”, a complete thought that surfaces the page’s promise. The rest of the description (“...actually covers across production, disaster-recovery copies, and audited evidence, with the admin-panel verification path...”) is the part AI engines read to decide whether the page warrants citation.

The discipline is to front-load the buyer hook in the first 150 characters and use the remaining 130 to 170 characters to surface evidence the engine cares about. Verified, audited, named source, and self-verify are signal words that perform well in the AI-read portion.

OG and Twitter Description

Auto-derived from the meta description for social sharing. Truncated at a sentence break around 200 characters. The brand should appear in the first 150 characters of the meta description so it survives the truncation when the page is shared on LinkedIn or X. For the residency page, the auto-derived OG description ends at the first sentence break:

That is 207 characters. It reads naturally as a stand-alone preview when the page is shared. If the meta description is written so that the first sentence carries the page’s full pitch, the OG/Twitter description writes itself. If the meta description front-loads the brand or the format, the social share loses the hook.

Schema markup

The element that tells engines what kind of page they are reading before they read the first paragraph of body content. The schema decision differs across the hub and the per-question page in the hybrid architecture, and the brief generates the correct one for the page type in scope.

For the per-question page, which is the page type the rest of this guide is built around, the schema is Article. Not FAQPage. The reason is mechanical: FAQPage schema tells the engine to expect a list of multiple question/answer pairs on the page and to treat each pair as an independently extractable unit. A per-question page contains one question and one fully developed answer. Claiming FAQPage on a single-question page mis-signals the page’s structure; the engine looks for a Q&A list, does not find one, and discounts the page. Article schema, with the question as the headline and the body structured as a single argument, is the honest match.

For the hub page, the FAQ index that the rest of this guide treats as the navigation layer, the schema is two-part. FAQPage schema lists the inline-answered short questions (the ones that did not warrant their own page) as Q&A pairs. Article schema covers the hub page as a whole, naming the publisher, the dateModified, and the speakable selectors that mark the navigable sections. Two schemas, two jobs: FAQPage describes the inline-answered questions, Article describes the hub as a content asset in its own right.

A common mistake worth flagging. Sites that place FAQPage schema on every page containing a question heading, including per-question pages that contain only one Q&A pair, mis-signal the page’s shape to the engine. The schema is technically valid but tells the engine to expect a Q&A list that does not exist. The per-question page is not a FAQ in the schema sense. It is an article that happens to answer a question. The Article schema reflects that accurately. The broader schema strategy is covered in the schema as AI context layer technique.

The FAQ format is powerful but it has boundaries. Not every content type works as a question-and-answer pair. Forcing long-form content into FAQ format weakens both the FAQ page and the content itself.

Trust stories need narrative arc and emotional depth. A customer journey compressed into a 200-word FAQ answer loses everything that makes it work. Keep these as dedicated pages. The trust story playbook covers the format.

Market reality reports are category-level research publications. They establish authority through breadth and original analysis. An FAQ answer that summarises a market report is a teaser, not a citation source. The market reality report playbook covers the quarterly publication format.

Decision frameworks (scoring rubrics, decision trees, evaluation checklists) need interactive or structured formats that do not fit inside Q&A pairs. These work as standalone tools. The decision framework playbook covers the format.

Criteria flip content requires sustained argument building: reframing which evaluation criteria matter and why. This needs the depth and pacing of a long-form article, not a Q&A answer. The criteria flip playbook covers the approach.

The FAQ page is a hub for answering direct questions with evidence. It is not a container for everything your brand wants to say. The complete content type taxonomy shows which format serves each decision stage.