How to FAQ schema.
FAQPage schema is the highest-hit-rate schema type for AI citations. It's also trivial to implement — a JSON-LD block in the page head, nothing more. Here's how to do it right.
The short answer
Adding FAQ schema means emitting one FAQPage JSON-LD node per page, containing 5–8 real buyer questions with 40–120 word declarative answers, rendered visibly in the same HTML, validated against Schema.org, then pushed for re-crawl. The markup declares question-to-answer boundaries a chunker would otherwise have to guess.
Before you start
You need exactly one technical capability: the ability to put a script tag into server-rendered HTML. That comes from a CMS schema field, a theme template, a plugin, or your framework's head API. Everything else on the prerequisite list is editorial — a page worth marking up, and a source of real questions. If your only route to the head is a page-builder widget that strips script tags, stop and solve that first, because no amount of good writing survives markup that never ships.
- Server-side head or body injection — a page builder that sanitises script tags will silently drop the whole node.
- Read access to support tickets, sales transcripts or a community your buyers actually post in.
- A page with buying intent — a pricing, comparison or integration page, not an About page.
- The ability to render the answers as visible HTML, not just as markup.
Fifteen minutes is the implementation time per page once the questions exist. The questions are the real work, and they take about an hour of ticket reading for the first page. Teams that skip that hour and write the questions from memory produce markup that validates perfectly and gets quoted by nobody, which is the most common way this guide fails. Headless setups where the head is assembled at the edge need one extra deploy to wire the field through.
Why this works
For almost every site this is no longer a rich-result play. Google restricted FAQ rich results to well-known authoritative government and health sites in August 2023, so if you are not one of those, valid markup will never render as an expandable SERP feature. That change removed the reason most people shipped FAQPage, and left the reason that actually matters intact.
What survives is extraction value. A retrieval layer has to cut your page into spans before it can quote one, and by default it infers where an answer begins and ends from headings, punctuation and token counts. FAQPage markup replaces that inference with a declaration: this string is the question, this string is the answer, they belong together. The model gets a chunk with clean boundaries and an explicit intent label, which is precisely the shape a generated answer needs.
Structured markup does not make your content better. It makes your content's boundaries unambiguous, which is a different and more reliable kind of advantage.
The steps
- 01
Pick real questions, not marketing ones
Bad: 'Why is <Product> the best?'. Good: 'Does <Product> work without code access?'. The difference is that only one of them is a question somebody types. Mine your support tickets, r/<yourvertical>, sales-call transcripts and Google's 'People also ask' box for the phrasings that recur, then keep the wording exactly as you found it — including the awkward grammar. Aim for 5–8 per page. A retriever matching a user's query against your markup is doing approximate string matching against real language, so a question rewritten into brand voice is a question that no longer matches anything.
Check
You'll know it worked when every question on your list can be traced back to a real ticket, thread or 'People also ask' result — if you cannot find the phrasing anywhere outside your own site, you wrote it, not your buyer.
- 02
Write answers in 40–120 words
Shorter than 40 words reads like a headline and gets deprioritized as a fragment. Longer than 120 words stops being quotable in one shot, and a model that cannot quote you whole will paraphrase you instead — which is harder to detect and easier to merge with a competitor's claim. Write declaratively: the answer in the first sentence, the justification in the next two. Never open with 'It depends' or with a restatement of the question. Each answer should survive being lifted out of the page with no surrounding context and still be correct.
Check
You'll know it worked when each answer's word count lands between 40 and 120 and its first sentence still makes sense with the question deleted.
- 03
Add the JSON-LD block
Paste this into the page head (or use your CMS's schema field): ``
json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "Does AIRank require code access?", "acceptedAnswer": { "@type": "Answer", "text": "No. You can verify your site with a meta tag or a DNS TXT record. Code access is only required for automatic fixes." } }] }`Repeat the Question object for each pair inside the samemainEntity` array — one FAQPage node per page, never one per question, and never a second node emitted by a plugin alongside yours. Emit it server-side; a block written by client-side JavaScript is not in the bytes a crawler receives, however good it looks in devtools. Escape quotes and newlines properly, since one malformed character invalidates the entire node rather than a single answer. Generate the markup and the visible HTML from the same source so they cannot drift apart later. Validate with the Schema.org validator.Check
You'll know it worked when validator.schema.org reports exactly one FAQPage node with the expected number of Question children and zero errors or warnings.
- 04
Render the same content visibly on the page
Google's structured-data policies require marked-up content to be visible to users on the page, and answer engines apply the same logic for a simpler reason: content that only exists in a script tag has no surrounding context to disambiguate it. Always render the FAQ as real HTML too. An accessible
<details>/<summary>block is fine — collapsed is not hidden, as long as the text is present in the initial HTML response. What is not fine is text that only appears after a fetch, or answers that differ between the markup and the page.Check
You'll know it worked when curl -s on the URL piped through grep finds each question string twice in the raw HTML — once inside the JSON-LD, once in the visible markup.
- 05
Validate and re-crawl
Run the page through Google's Rich Results Test and Bing's Markup Validator. Expect the Rich Results Test to parse your FAQPage without errors and still report that it is not eligible for a rich result — since August 2023 Google restricts FAQ rich results to well-known authoritative government and health sites, so for almost every site this markup is an LLM-extraction play rather than a SERP-appearance play. After validation, ping IndexNow or submit the URL in Search Console so the change gets ingested rather than waiting for an organic crawl.
Check
You'll know it worked when the Rich Results Test shows zero structured-data errors and Bing Webmaster Tools reports a crawl date later than your deploy — an 'ineligible for rich results' notice is expected behaviour, not a failure.
How to verify it worked
Validation is not verification. A green validator tells you the JSON parses; it says nothing about whether anything reads it. The end-to-end check is to take the marked-up questions themselves and add them to your tracked query panel as literal probes, then watch for verbatim spans of 15 or more tokens matching your answer text, or paraphrases scoring above the semantic threshold with no plausible alternative source.
Start the measurement window from the crawl date, not the deploy date — those can be a week apart, and attributing from the wrong one is how teams conclude a working change did nothing. Give it two to four weeks. Against the usual 10–15% week-over-week variance on any single query, a genuine result looks like several of your marked-up questions appearing as quoted spans across different phrasings of the same intent.
Control
Mark up two of your three pages first and leave the third for a fortnight. If all three move together, something else caused it.
Three ways this goes wrong
- The rich-result phantom. Symptom: your FAQPage validates cleanly, the Rich Results Test finds it, and no expandable FAQ ever appears under your listing in Google. Cause: none — this is expected behaviour for practically every site since August 2023, when Google narrowed FAQ rich results to well-known authoritative government and health sources. Fix: stop measuring this markup by SERP appearance. Measure it by whether answer engines quote the answer text, which is the value that was never withdrawn.
- The invisible-answer violation. Symptom: the markup is present and correct, but the page gets flagged in a structured-data report or quietly ignored. Cause: the answer text in your JSON-LD is not on the page, or does not match what is on the page — a summary in the markup and a longer version in the HTML counts as a mismatch. Fix: generate both from one source of truth so drift is structurally impossible, and treat any hand-maintained second copy as a future bug.
- The duplicate-FAQPage collision. Symptom: a validator reports two or three FAQPage nodes on one URL, and the questions rendered do not match the ones you wrote. Cause: an SEO plugin, your theme, and your hand-written block are each emitting schema, and parsers resolve the conflict arbitrarily. Fix: search the raw HTML for the count of FAQPage occurrences before you debug anything else, then disable every emitter but one. Consolidation beats reconciliation here every time.
What to expect
FAQPage schema typically lifts AI citation rate on a page by 15–40% within 30 days of Bing re-crawling. The variance is about whether you wrote the questions well — generic marketing questions produce near-zero lift, while questions phrased like real user queries produce the high-end result.
Why is my FAQPage schema valid but not showing up in Google?
Because you are almost certainly not eligible, and that is by design. In August 2023 Google restricted FAQ rich results to well-known authoritative government and health sites. Valid markup on a normal commercial site parses fine and simply never renders as a SERP feature. Nothing is broken. The markup still does its real job, which is giving answer engines a pre-cut question-and-answer chunk to quote.
Can I put FAQ schema on a page that already has Product schema?
Yes. Multiple schema types on one URL is normal and expected — a product page commonly carries Product, Review, AggregateRating and FAQPage together. The rule is one node per type per page, not one type per page. Keep them in separate script tags or in a single graph, and validate the page as a whole so you catch a conflict between two blocks that each validate alone.
Does the answer text have to match the visible text exactly?
It should. Google's structured-data policies require marked-up content to be visible on the page, and a mismatch between markup and body is the most common reason a technically valid block gets ignored. Minor formatting differences — stripped HTML tags, collapsed whitespace — are fine. A shortened summary in the markup while the page carries a longer version is not; generate both from one source.
How many questions is too many on one page?
Past eight or so you are usually building a page that answers nothing well. The limit is not technical — it is that a long FAQ tends to be a dumping ground, and the questions at the bottom get written carelessly. If you have twenty real questions, that is twenty pieces of evidence you need more pages, each with its own five to eight questions on a single intent.
Should I mark up an FAQ that lives in an accordion?
Yes, provided the text is in the initial HTML response and the accordion only collapses it visually. Collapsed is not hidden. What breaks the rule is content fetched on click or rendered by JavaScript after load, because the text is genuinely absent when a crawler reads the page. Test it with curl rather than with devtools — the rendered DOM will lie to you here.
Written by
The AIRank Editorial Team
Research & editorial, AIRank
The AIRank editorial team runs the 47-point scanner, the Observer pings, and the GEO research programme every week. Writing is reviewed by the core engineers who build the Injector, Blaster, and Surgeon agents.
Last reviewed
About the team →