Schema Markup for AI Search: What Still Earns a Citation

Two things are true at once about structured data right now, and most advice picks one and ignores the other.

The first is that Google has been steadily removing rich results. FAQ and HowTo snippets were cut back to almost nothing. If you added schema purely to get stars and dropdowns in the results, a lot of that return has quietly disappeared.

The second is that structured data has become more useful, not less, because a different set of consumers arrived. AI systems reading your page to answer a question benefit enormously from being told plainly what the page is about, rather than having to infer it.

So the question is no longer “which schema gets me a rich result”. It is which schema still does work.

What Schema Was Always Actually For

Structured data does not make a page rank. It never did, and anyone selling it as a ranking factor is selling something else.

What it does is remove ambiguity. Your page says “$49 per month”. A machine reading that has to guess: is that your price, a competitor’s price, an example, a discount that expired? Schema states it unambiguously, in a field designed for exactly that, with no inference required.

That mattered moderately when the consumer was a search index. It matters considerably more when the consumer is a system deciding whether to quote you as the source of a fact.

The Types Still Worth Implementing

Ruthlessly short list. Everything else is optional.

Notice what is missing. FAQPage is now largely cosmetic for most sites in terms of visible results, though it remains harmless and reasonably well suited to being parsed as question-and-answer pairs. HowTo lost its display treatment. Neither is worth building a content strategy around any more.

The Entity Part Is the Part That Matters

If you implement exactly one thing from this article, implement a properly connected entity graph for your organisation or yourself.

The common failure is a hollow Person or Organization node containing a name and a logo and nothing else. That tells a machine you exist. It does not tell it who you are, what you do, or why you would know anything.

A useful entity node carries:

• sameAs pointing at profiles that independently confirm the same identity
• knowsAbout listing genuine subject areas, not a keyword dump
• jobTitle and worksFor resolving to a real described organisation
• The same entity referenced consistently as author across the site, by @id, not repeated inline

That last detail is the one most implementations get wrong. Define the entity once with an @id, then reference that @id everywhere else. Copy-pasting a full author block into every article creates dozens of nodes that a parser has to work out are the same person, and sometimes it does not.

Getting the Types Right

Schema errors are usually type errors, not missing fields. A field expecting a structured object gets handed a plain string and the whole node gets rejected.

The frequent offenders:

• image as a URL string rather than an ImageObject
• address as one line of text rather than a PostalAddress
• addressLocality and addressRegion swapped, which validates cleanly and is simply wrong
• author as a name string rather than a reference to a Person node

A validator will pass some of these happily. Validation confirms your syntax, not your accuracy. Read the output as data and ask whether it is actually true about your business.

And the failure mode nobody warns about: choosing a type that fits the vocabulary but not the page. A type can be technically valid and still be rejected because your page does not resemble what that type describes. When that happens, the fix is removing the type, not adding fields to it.

Schema Is Not a Substitute for the Page

Structured data describes content. It does not replace it.

If a fact appears only in your JSON-LD and nowhere in the visible page, you have a mismatch, and Google’s guidelines are explicit that markup should reflect what users actually see. Systems that summarise pages read the rendered content first and use the markup to confirm and disambiguate it.

Practically: put the price on the page and in the markup. Put the answer in a clear paragraph and mark it up. Markup is corroboration, not a back channel.

This is where structured data connects to answer engine optimization: the markup helps, but only when the page genuinely contains a clean, extractable answer in the first place.

A Sensible Implementation Order

1. One properly built Organization or Person entity, with a stable @id, referenced sitewide
2. BreadcrumbList across the site, cheap and structural
3. Article with the author pointing at that entity by @id
4. Product, LocalBusiness or whatever matches your actual business model
5. Everything else, only if you can name the specific benefit

Most sites get real value from the first three and then stop. That is a perfectly good place to stop. Adding eleven schema types to a page does not make it eleven times clearer, it usually makes the graph harder to parse and more likely to contain a contradiction.

The Short Version

Schema markup for AI search is worth doing for exactly one reason: it removes ambiguity about who you are and what you claim. Build the entity properly, keep the types honest, make sure everything in the markup is also visible on the page, and ignore anything added purely in hope of a rich result that Google has already stopped showing.

Written by Shahzaib Ul Hassan, senior AI SEO consultant and founder of ShazzSEO. Ranking sites since 2009. 500+ websites optimized, 3,000+ students trained.