How to Write FAQs That Get Cited by AI Search

Search "how to write FAQs AI will cite" and you'll find the same five articles saying the same thing: keep every answer to 40 to 60 words, lead with the answer, add FAQPage schema, don't hide answers in accordions. A couple of them attach a precise-sounding number to it, like "28% higher citation rates" or "up to 400% more visibility," with no study or source behind either figure.

None of those numbers trace back to anything OpenAI, Google, Anthropic, or Perplexity has published. No answer engine has released an official rule about answer length, and no one outside those companies can tell you a real citation percentage. So this post skips the length rule and the invented stats entirely, and looks at something none of those five articles actually explain: how a machine finds your FAQ content in the first place, and exactly why an accordion defeats that.

We build a schema tool that reads pages for a living, so we had the code on hand to check this properly instead of guessing. What follows is built from our own FAQ detector, the part of our WordPress plugin that scans a page and decides whether it contains question-and-answer content worth marking up. Its logic turns out to answer the "how do I get found" question far more precisely than the writing-advice articles do.

Two different problems, and most advice only covers one

"Will AI quote my FAQ" is really two separate questions, and almost every guide on this topic answers only the second one.

Can a machine find your FAQ content at all? This is a structural question. Before anything reads your answer and judges whether it's well written, something has to recognize "this block of text is a question, and this block right after it is the answer." That recognition step can fail completely, for reasons that have nothing to do with how good your writing is.

Is the content itself worth citing once it's found? This is a writing question. Is the answer clear, accurate, and self-contained? Does it actually resolve what was asked?

The five-article echo chamber jumps straight to the second question. Write cleaner answers, format them a certain way, add schema. All reasonable advice, but it assumes the first question is already solved. It isn't, for a large share of FAQ sections, and no one in that space is explaining why.

How a machine actually finds your FAQ content

Here's the mechanism, straight from our detector's logic.

The first pass scans a page's headings, <h2> through <h6>, looking for one signal: a literal question mark. Not a keyword. Not "how" or "what" or "why" at the start of the heading. Just the character "?" somewhere in the heading text.

That's a deliberate, tested choice, not a shortcut. Keyword-based heuristics ("does this heading start with a question word") sound smarter, but they produce constant false positives on completely ordinary section headings. "How We Work." "What to Look for Instead." "Why Choose Us." None of those are questions, even though every one of them starts with a question word. A detector built on keywords would misread a huge share of normal marketing headings as FAQ content. Requiring an actual question mark is cruder but far more reliable: "What to Look for Instead" gets skipped, "What Should You Look for Instead?" gets caught.

Once a heading passes that test, the detector needs an answer to go with it. It grabs the text between that heading and the next one, strips out the HTML tags, and treats what's left as the answer. That window is capped at 2,000 characters, and the cap exists for a specific, ordinary failure case: a question heading sitting near the bottom of a long page, with a sidebar, a related-posts block, or a footer coming right after it in the raw HTML. Without a cap, "answer" text would bleed into unrelated content that happens to follow it in the markup. The cap trims that risk without cutting off a genuinely long answer.

That's the entire mechanism for plain, heading-based FAQ content: a real question mark in a real heading tag, followed by text before the next heading. Simple, and it's exactly why it misses so much.

Why accordions and toggle widgets break this, and the nuance most posts skip

The advice "don't hide your FAQ in an accordion" shows up everywhere, usually with no explanation of what's actually happening underneath. The real mechanics are more specific than "AI can't click things," and understanding them changes what you should actually check.

Start with the one that's least broken: a plain HTML details element and <summary> tag, or the version WordPress's block editor produces (its native collapsible block renders down to the same <details> tag). The question and answer text are both sitting in the raw HTML the moment the page loads, visually collapsed but textually present. A crawler reading raw HTML, the way most retrieval crawlers do, can see every word of it. What breaks is a heading-based detector specifically: it's scanning for <h2> through <h6> tags, and a <summary> tag isn't one, so a detector built the way described above walks straight past it, not because the words are hidden, but because they're wearing the wrong tag.

A definition list, <dl> with <dt> and <dd> pairs, has the identical problem for the identical reason. The question and answer are both real text in the raw HTML. They just aren't inside a heading, so a heading-only scan skips them completely.

Elementor's accordion and toggle widgets are the genuinely different case. That content doesn't live in a heading tag, and it doesn't live in a plain HTML element either. It's stored as structured data in a WordPress option called _elementor_data, essentially a JSON description of the widget's tabs, where each tab has a tab_title (the question) and tab_content (the answer) as raw string fields. A detector that only reads rendered heading tags will never find this content at all, because it was never in a heading to begin with, it's in the page builder's own settings. Finding it means reading that JSON structure directly, which is exactly why our plugin needs a dedicated method just for Elementor, separate from the one for plain headings and separate again from the one for <details> tags.

So the honest version of "don't hide your FAQ in an accordion" isn't one rule, it's three different failure modes:

A native <details> block or a definition list hides your Q&A from anything that only looks for headings, even though the text is sitting in the page in plain sight for anything smart enough to look elsewhere.

A page builder's accordion or toggle widget can hide your Q&A from almost everything, because the question and answer were never expressed as ordinary page content at all, they're settings inside a specific plugin's data format.

A plain heading with a real question mark, followed by ordinary paragraph text, is the one format that every method here, ours included, reliably catches without any special-case code.

A five-minute self-check you can run yourself

You don't need our tool to check this. You need your browser and two minutes per page.

Open the page and view the source, not the rendered page, the actual HTML your server sent. In Chrome or Firefox this is Ctrl+U (or right-click, "View Page Source"). This is close to what a retrieval crawler actually receives.

Search the source for one of your FAQ questions. Use Ctrl+F on the source view and paste in a distinctive phrase from the question. If it isn't found at all, that content isn't reaching a crawler in any form, full stop, regardless of what format it's in.

Check what tag it's sitting inside. If your question text is found, look at what surrounds it. Is it between <h2>, <h3>, or similar tags, with a literal question mark in there? That's the format every detection method handles cleanly. Is it inside a <details> or <dl> tag? The text is present, but you're now relying on whatever reads that specific structure, some tools will catch it and some won't. Do you find the question text only inside a large blob of escaped JSON, something that looks like \"tab_title\":\"Do you ship internationally?\"? That's the page-builder case. The words exist on the page for a visitor, but nothing reading plain HTML tags will ever associate that text with a question-and-answer pair.

Confirm the answer is there too, not just the question. Repeat the search for a phrase from the answer itself. A surprisingly common failure is a question that's fully present in a heading, with an answer that only populates after a script runs, an FAQ section built with a JavaScript accordion library rather than a native block or plugin widget. The question passes every check above and the answer is invisible.

If a question and its answer both show up as plain text near a real heading tag, you're in the format that's the safest bet across the board. If either one only appears buried in a JSON blob or is missing from the source entirely, that's a page worth fixing before anything about your writing style matters.

Being detectable is necessary, not sufficient

Getting the structure right doesn't guarantee anything about what happens next, and it's worth being direct about that rather than letting the mechanics above imply a promise they can't back up.

No answer engine publishes a citation formula. Nobody outside OpenAI, Google, Anthropic, or Perplexity can tell you the actual weight a well-structured FAQ section carries in their retrieval process, and anyone quoting you a specific percentage lift is quoting a number they made up or copied from someone who did. What the mechanism above gets you is a genuine floor: your content is at least eligible to be read and understood as a question-and-answer pair, instead of being invisible to that interpretation entirely. Whether it then gets chosen, over everything else answering the same question, still comes down to the ordinary things that make any content worth citing, covered in more depth in our AEO checklist: is the answer accurate, is it specific, does it actually resolve what was asked, and does your site say something here that a dozen other pages don't already say. Structure clears the door. It doesn't walk you through it.

That also means writing quality still matters, just not through an invented word-count rule. A self-contained answer, one that makes sense read on its own without needing the rest of the page for context, is a real and sensible target, because that's literally the shape a system needs to lift a clean answer out of your content. That's a description of good writing, not a formula, and there's no magic number of words attached to it.

Common mistakes

Assuming a collapsed section is invisible. A native <details> block or a definition list isn't hidden from a crawler reading raw HTML, it's hidden from a detector that only looks at headings. Those are different problems with different fixes.

Phrasing every heading as a statement instead of a question. "Shipping and Returns" as a heading, with the actual question buried in the first sentence underneath it, won't register with any heading-based detection method. If the question is real, put it in the heading, with a literal question mark.

Cramming multiple questions under one heading. The text-capture window between headings has a limit for a reason. A heading followed by three loosely related questions and a wall of text makes it much harder for anything, human or machine, to tell where one answer ends and the next begins.

Building your FAQ purely inside a page builder's accordion widget with no plain-text fallback anywhere on the page. This is the one genuine blind spot. If the only place a question and its answer exist is inside a widget's JSON settings, you're relying entirely on whatever specific method a given tool built for that exact widget, and that coverage varies a lot between tools.

Treating structure as the whole job. A perfectly detectable, perfectly formatted FAQ section with vague, generic answers still isn't worth citing. Structure gets you found. It doesn't make a thin answer good.

Repeating an invented rule because five other sites repeat it. If a number can't be traced to a source, treat it as marketing, not fact, ours included.

How to check and fix your FAQ content

Run the five-minute self-check above on your three or four highest-traffic FAQ pages first. Not your whole site at once, the pages that matter most. A structured data crawl is the faster route once you're ready to check every page at once instead of one at a time.

For any question missing from the raw source entirely, find out why. Common culprits: the FAQ section is injected by client-side JavaScript after the page loads, or it lives behind a "load more" interaction that never fires for a crawler.

For any question sitting inside a page-builder widget's JSON data, decide whether that's acceptable for that page or worth changing. It isn't a broken page, it's a page whose FAQ content depends on whatever tool is reading it having built specific support for that widget.

For any heading phrased as a statement, rewrite it as the actual question a visitor has, with a real question mark. This is a small, mechanical edit and it's the single highest-leverage fix on this list.

Re-run the check after any fix, on the same page, the same way. The source view either shows your question and answer as plain text near a real heading now, or it doesn't.

AI Schema Gen reads your page content directly and generates the correct FAQPage or QAPage markup automatically, once your questions and answers are actually there to find. Start free or see the schema types directory.