Does schema markup help with AI search?

Less than the people selling it claim, and more than the sceptics do. It will not make an engine cite you — but markup that asserts content the page does not display is worse than no markup at all, and that is a defect we shipped on our own site and had to build a checker to stop.

What structured data actually does

Schema.org markup is a machine-readable restatement of what is already on the page. It removes ambiguity: which number is the price, which string is the author, which block is a question and which is its answer. That is genuinely useful to any system parsing your page at speed, and it is the whole of the benefit.

What it does not do is create authority. No vendor can point at evidence that adding FAQPage markup caused an answer engine to cite a page. We cannot either, and we publish structured data on every page of this site. Anyone telling you otherwise is describing a hope.

The asymmetry is the point. Correct markup is a small, unproven upside. Incorrect markup is a measurable downside: it makes you ineligible for rich results, and on a page whose claim is that it is accurate, it is a falsehood a machine can detect. The downside is the reason to care.

Which types earn their place

Type	Use it when	Do not use it when
`Organization`	Once, on your homepage. Name, URL, logo, contact, same-as links.	On every page, with a different name each time.
`Article`	Any guide or explainer. Carry `datePublished` and `dateModified` honestly.	On a product or pricing page. It is not an article.
`FAQPage`	The page displays the questions and answers, visibly, in those exact words.	The answers are only “covered somewhere in the prose”. The common failure.
`HowTo`	There is a genuine ordered sequence and the steps are visible in order.	You have a list of tips. A list is not a procedure.
`Product` or `Offer`	You sell a specific thing at a specific price shown on the page.	The price is “contact us”. Do not invent one to fill the field.
`DefinedTermSet`	A glossary where each term is visibly defined.	A page that mentions the terms in passing.
`ItemList`	A ranked or enumerated list the reader can see.	An unordered pile of links you wish were a list.
`Dataset`	You publish real data people can download. Rare, and strong when true.	You have a chart.

Notice that every “do not” is the same mistake in a different costume: asserting something the page does not show.

The defect we shipped

When we built the first batch of these guides, our structured data asserted 51 of 60 questions and answers that no page displayed. The answers were paraphrased somewhere in the prose; the questions themselves were invisible. Our pricing page was marketing the question “Why is the price range for AEO so wide?” to machines while its visible headings read “The four price bands”.

We fixed it the right way round — by rendering the questions rather than deleting the markup — and every page that carries an FAQPage block now ends with a visible accordion built from that block. Then the review found a second, subtler version of the same bug.

Four pages had a visible FAQ section, so the obvious rule — “never add FAQ markup to a page with no FAQ section” — was satisfied. But the JSON-LD used straight apostrophes where the rendered HTML had curly ones. The markup still asserted strings the page never displayed, by one character, and it survived two rounds of human review because it is invisible to reading.

The rule that actually holds

Every Question.name, every acceptedAnswer.text, every HowTo step name, every DefinedTerm name and every ItemList item name must appear in the page’s rendered text as an exact string. Not paraphrased, not normalised, not “substantively present”.

We enforce it with a script that strips scripts and styles, closes up inline tags the way a browser does, decodes entities, collapses whitespace — and forgives nothing else. No apostrophe folding, no Unicode normalisation. It exits non-zero on any drift and prints the character where the two diverge, because “string not found” is useless and “matches for 43 of 118 characters, then diverges” is instantly fixable.

You do not need our script. You need the rule, and something that runs it. The cheapest version is a single check in CI: for each string your JSON-LD asserts, assert that it is a substring of the page’s visible text.

How to add markup without lying

Write the visible page first. All of it — including the FAQ section, if there is going to be one.
Generate the markup from the page, not beside it. If the two are typed separately they will drift, and the drift will be invisible.
Mark up only what you can point at. If you cannot highlight the sentence on screen, do not assert it.
Validate that it parses, with a real JSON parser, in a test. A block with a trailing comma is silently ignored by every consumer.
Check exact strings on every commit. A hand-edit to one visible heading is all it takes, and nothing else will catch it.
Keep dates honest. A dateModified that updates on every deploy while the words never change is a small, checkable lie.

What we would skip

speakable — narrow, voice-assistant specific, and not worth the maintenance for most sites.
aggregateRating you do not have. Inventing a review count is the single most common piece of schema fraud, and it is trivially detected.
Marking up your entire navigation. It tells a machine nothing it could not already see.
An llms.txt file treated as markup. It is a different thing, it is a proposal rather than a standard, and we have no evidence it does anything. We publish one anyway and say so.

The honest summary

Add Organization once, Article on your guides, and FAQPage only where the page visibly shows the questions. Check the exact strings automatically. Then stop thinking about markup and go and write the page that answers the question, because that is what our citation analysis says is actually deciding it.

Common questions

Does schema markup help you get cited by AI?

There is no published evidence that it does, ours included, and we mark up every page on this site. What it reliably does is remove ambiguity about which string is the price, the date, the question or the answer. The stronger reason to care is the downside: markup that asserts content the page does not display makes the page ineligible for rich results and is a falsehood a machine can detect.

Can I add FAQ schema if the questions are not visible on the page?

No. That is the single most common structured-data defect and we shipped it ourselves on 51 of 60 questions. The markup asserts the page displays a question and answer that a reader cannot find anywhere on it. Fix it by adding the visible FAQ section, not by quietly deleting the markup, and then check the strings match exactly.

What is the exact-string rule?

Every Question name, every acceptedAnswer text, every HowTo step name, every DefinedTerm name and every ItemList item name must appear in the page's rendered text as an exact string. Not paraphrased, not normalised. We check it with no apostrophe folding and no Unicode normalisation, because the second version of our own bug was straight apostrophes in the JSON-LD against curly ones in the HTML, and it survived two human reviews.

Which schema types are worth adding for an AI answer engine?

Organization once on the homepage, Article on guides and explainers with honest dates, FAQPage only where the page visibly shows the questions, HowTo only where there is a real ordered procedure, and Product or Offer only where a real price is shown. Dataset is rare and powerful when you genuinely publish data. Everything else is usually maintenance without benefit.

Structured data for AI search

What structured data actually does

Which types earn their place

The defect we shipped

The rule that actually holds

How to add markup without lying

What we would skip

The honest summary

Common questions

See whether any of it is working