Get AI to Quote Your Answers: FAQPage Structured Data in Practice, With the Mistakes We Made

One-line conclusion: FAQPage structured data stopped being about "growing that collapsible Q&A box in Google" a long time ago—it's about getting machines to read your questions and answers accurately. And the most common, hardest-to-spot failure is that your schema only exists in the page after JavaScript runs. Non-JS AI crawlers fetch the raw HTML, and in the source they see, your schema simply isn't there.

This isn't about theory; it's about what you can fix tonight: one copy-pasteable correct FAQPage pattern, four mistakes that really do make AI read not a single word, and a live 23-entry FAQPage on our own site as a control group. The first mistake is one we hit ourselves during a site-wide structured-data audit—and only cured by adding a CI guard—so it goes first.

1. The one-line answer: FAQPage is now about being understood by machines

First, a fact many people miss: since August 2023, Google has restricted the FAQ rich result (that blue collapsible Q&A block in search results) to authoritative sites such as government and health authorities. Most sites that add FAQPage no longer see that collapsible box. But that doesn't mean the schema is useless—only the visual presentation was retired; the machine-readable Q&A structure is still used by indexing and AI engines.

In other words, the motivation for FAQPage changed. People used to do it to take up more space in search results (that collapsible box is eye-catching); now you do it so Google indexing, the knowledge graph, and systems like ChatGPT, Perplexity, and Google AI Overviews—which "generate an answer and attach sources"—can precisely match "this question, this page, this answer"^[2]. It's scaffolding for machine comprehension, not visual decoration. Grasp that shift and the four mistakes below make sense.

2. The minimal correct FAQPage JSON-LD

The FAQPage structure itself is simple: one FAQPage, with a list of Question under mainEntity, each Question having a name (the question) and one acceptedAnswer (the answer). This is the minimal skeleton defined by the official docs^[1]:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long until my refund is credited?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Once approved, 3 to 5 business days back to the original payment method."
      }
    }
  ]
}
</script>

The skeleton is easy; the hard parts are "how you write the content" and "where you put it." All four fatal mistakes below are not syntax errors—their JSON parses fine and validators show green—yet the result is that AI can't read it, or reads it and won't cite it.

3. Fatal mistake 1: schema injected only by JS

This is a pit we fell into ourselves. During a site-wide structured-data audit we found a batch of pages where "schema looked present in the browser but was empty when a plain-text tool fetched the raw HTML"—because that schema was injected at run time by a shared front-end script. Fine for JS-capable environments; for crawlers that read only the source (e.g. GPTBot, ClaudeBot, PerplexityBot), effectively nonexistent.

Our cure was to add an automated build-time check: scan every public page, and if a high-value page that "should have schema" is missing the required structured data in its raw HTML, block that code change from shipping. That way the regression "schema decays into JS-only injection" is caught before deployment—it can't quietly make our pages unreadable to AI.

You don't necessarily need a whole CI pipeline, but you must remember the test action: look at the source, not just the browser. The browser runs the JS for you and gives you a "post-processing" illusion; crawlers don't.

4. Fatal mistake 2: questions aren't the sentences users ask

5. Fatal mistake 3: answers aren't self-contained and can't be quoted whole

This ties into how AI actually reads pages. A 2025 controlled experiment across ChatGPT, Claude, Perplexity, and Gemini found that when these systems fetch a page directly, they often ignore JSON-LD and read only the visible HTML text^[4]. That gives us two very practical conclusions: first, do the schema (it feeds indexing and the knowledge graph, the indirect path); second, the visible Q&A text matters just as much—and arguably more for "being read directly by AI". So self-contained answers aren't just for pretty schema; that visible text is exactly what AI will quote.

6. Fatal mistake 4: schema doesn't match visible content

7. Real example: our own faq.html, 23 entries

Instead of abstract principles, here's a real one you can open and inspect. Our faq.html has 23 visible Q&As mapping to 23 Question entries of FAQPage structured data in the raw HTML—not one more, not one fewer, with visible text and schema matching word for word.

It happens to demonstrate all four mistakes in reverse:

• The schema is in the raw HTML (not JS-injected)—you can run curl against truelink-group.com/faq.html, or view-source, and find that FAQPage JSON-LD directly in the plain text.
• The questions are sentences a real person asks—things like "How long does verification take?" and "Is my data safe?", not keywords.
• The answers are self-contained—each starts with the conclusion and reads fine quoted alone.
• 23 visible Q&As = 23 schema entries—no stuffing, no hidden questions; visible and structured are strictly consistent.

You don't have to take my word for it—open the source and count. That's our consistent stance on "verifiable trust": if we say it, you should be able to check it on the spot.

8. Wrap-up: a three-step verification checklist

Do all three and you've paved two roads at once: the schema takes the indirect path of "feeding Google indexing and the knowledge graph," and the visible Q&A takes the direct path of "being quoted by AI." When both are open, your answer actually has a chance of showing up in the reply someone gets when they ask an AI.