Schema Markup for AI Search

The argument for bothering

An AI system reading your pricing page has to work out what your product costs. In prose, that inference can go wrong in ordinary ways: it picks up an annual figure and reports it as monthly, or it reads a struck-through comparison price, or it finds a legacy plan mentioned in a footnote.

In an Offer object, the price is a number in a field named price, with a currency and a validity date. There is nothing to infer.

That is the whole case for schema in AEO. It is not a ranking lever. It is ambiguity removal — and since a large share of AEO damage comes from models stating wrong facts about you, removing ambiguity is more valuable than it sounds.

The six types that matter

Organization

The foundation. It establishes who you are as an entity and connects your brand name to your domain and your other profiles. Publish it once, sitewide.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "AEO Landscape",
  "url": "https://aeolandscape.com",
  "description": "Independent guides, research and tool comparisons for Answer Engine Optimization.",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://github.com/example"
  ]
}

The sameAs array does real work: it links the entity across sources so a model can consolidate what it knows about you rather than treating three mentions as three organisations.

Article

For every editorial page. The properties that matter most for AEO are the ones engines use to judge freshness and provenance: datePublished, dateModified, and a named author.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup for AI Search",
  "datePublished": "2026-04-16",
  "dateModified": "2026-06-08",
  "author": { "@type": "Person", "name": "Editorial Team" },
  "publisher": { "@type": "Organization", "name": "AEO Landscape" }
}

For anything with a temporal dimension — comparisons, pricing, "best tools in 2026" — an accurate dateModified is among the most valuable properties you can publish, because fresh-preferring engines use it to break ties.

One discipline: only update dateModified when you have genuinely changed the content. Bumping it on cosmetic edits is a short-lived trick that degrades your own signal.

FAQPage

The highest-leverage type for AEO, because its structure matches how retrieval works. Each entry is a self-contained question-and-answer pair — exactly the unit a re-ranker scores.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Does schema markup improve AI citations?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "There is no public confirmation that engines use schema as a citation ranking input. It removes ambiguity about facts, which reduces incorrect statements about you."
    }
  }]
}

Mark up questions that appear visibly on the page, and keep the answer text substantively identical to what a reader sees.

Product and Offer

Essential if you sell something, because pricing is among the facts models most often get wrong about vendors.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Pro",
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "USD",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock"
  }
}

Include priceValidUntil. It tells a system when to stop trusting the figure, which is better than having a stale price quoted indefinitely.

Do not mark up aggregateRating unless you display genuine, verifiable reviews. Fabricated ratings are both a policy violation and the kind of claim that gets checked.

BreadcrumbList

Cheap, and it communicates where a page sits in your hierarchy. This helps a system understand that a comparison page belongs to a comparisons section rather than being an isolated document, which supports topical-authority inference.

HowTo

For genuine procedures with discrete steps. Steps chunk cleanly and map well onto "how do I" queries. Only use it for actual sequences, not for listicles wearing a procedure costume.

Implementation notes

Use JSON-LD in a single block. One <script type="application/ld+json"> per page, generated from your CMS data rather than hand-maintained. Hand-written schema drifts out of sync with content within a quarter; generated schema cannot.

Generate from the same source as the visible content. This is the structural way to guarantee consistency. If your page renders a price from a field and your schema reads the same field, they cannot disagree. This site does exactly that — every page's JSON-LD is built from the CMS entry that renders the page.

Validate. Use Google's Rich Results Test and the Schema.org validator. Malformed JSON-LD is ignored entirely, and silent failure is the normal outcome, so untested markup is often doing nothing at all.

Do not over-nest. Deeply nested graphs are hard to maintain and no more useful than a few clean, correct top-level objects.

What schema will not do

It will not make an unretrievable page citable. It will not compensate for thin content. It will not override the consensus of other sources about your product.

And it will not, on the available evidence, directly raise your citation rate. The mechanism is narrower and still worthwhile: models make fewer wrong statements about you, and wrong statements are what cost deals.

If you have limited engineering time, the order is: fix crawler access first, restructure your key pages second, add schema third. Schema is the cheapest of the three and the least impactful on its own.

Further reading

Technical AEO for AI Crawlers covers the access work that has to come first. Structuring Content So AI Can Quote It covers the editorial half of making facts extractable.