Schema.org for AI

1. What “Schema.org for AI” is

This entry is not a mirror of the Schema.org documentation. It is the AI-citation-relevant subset: the handful of types and properties that change how an AI engine resolves your entity and parses your page — and nothing more.

Definition (GEO Wiki working definition): Schema.org for AI is the subset of structured-data vocabulary whose presence changes how an AI engine disambiguates the entity behind a page and parses the page reliably — distinct from whether any passage on it is liftable.

2. Markup ≠ citation — why schema is infrastructure, not a signal

The load-bearing honesty, and this entry’s counterpart to E-E-A-T §1’s “not a score”: structured data is not a ranking factor and not a citation lever. Google states it plainly — “using structured data enables a feature to be present, it does not guarantee that it will be present”, and a structured-data manual action “doesn’t affect how the page ranks” (see General Structured Data Guidelines). Google’s 2025 AI-search guidance repeats it: markup “makes pages eligible for certain search features and rich results”, not ranking (Succeeding in AI search).

What markup actually buys is exactly three things, all upstream of selection:

Where it acts is the whole point. Schema operates at the pre-retrieval parse and entity layer — never at the grounding/selection gate that Citability and E-E-A-T govern in Answer Loop §3:

  page ──► [ PARSE + ENTITY LAYER ]      ◄── schema acts here
              │  facts parsed cleanly
              │  entity resolved (sameAs → KG)
              ▼
  retrieval ──► candidate passages
              ▼
  [ GROUNDING / SELECTION GATE ]         ◄── schema does NOT act here
   citability (shape) · E-E-A-T (trust)      Citability & E-E-A-T own this
              ▼
  grounded answer ──► (maybe) citation

The orthogonality line, stated as the reciprocal of Citability §2’s: marking up an FAQ does not make its answers citable. Passage shape is citability’s, decided in the visible content. Markup only declares structure a parser could already extract.

3. The AI-relevant type subset — the load-bearing table

The canonical table the rest of the site quotes — the E-E-A-T §4-of-this-entry. Each type is read for what it asserts to an engine and which proxy it feeds, not for spec completeness.

The single highest-leverage rows are Organization and Person, because they carry the property that actually feeds the layer AI consumes — covered next. FAQPage/HowTo are deliberately last: they describe shape a parser already sees and carry the §6 caveat.

4. The AI-relevant property subset — sameAs is the workhorse

Companion table, same reading. Properties, not types, are where the entity leverage concentrates.

sameAs is the entity-resolution join key — the single property worth getting right before any other. It is the explicit edge from your markup to the knowledge graph the model already trusts. A minimal, illustrative block:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/example-co"
  ]
}

This is one illustrative block, not a template. Syntax — JSON-LD vs Microdata vs RDFa, where it goes, escaping — is JSON-LD’s. Full per-type templates and validation are the Schema Implementation playbook’s. Which markup feeds the entity layer and why is below; the resolution mechanism is treated in Entity Recognition and Knowledge Graph Presence.

5. How AI engines actually consume schema — the honest mechanism, per surface

The honesty section, mirror of E-E-A-T §5. The core: engines do not “read your schema and rank you.” How — and whether — markup is consumed at answer time splits hard by surface, and the evidence now exists to say so rather than hedge.

The negative result is well-supported, not speculative. A controlled December 2025 test placed a price only inside JSON-LD across five systems; none of the live-fetch chatbots extracted it (searchVIU). An independent observation found ChatGPT and Perplexity will surface values even from invalid, fabricated schema — they are reading the markup as text on the page, not as a parsed structure (Search Engine Roundtable, observation).

The seam, restated: the entity benefit still reaches these models — but through the model prior and the knowledge graph, not by parsing your JSON-LD during the fetch. Why each markup is an entity proxy is this entry’s; how the identity resolves across platforms is Entity Recognition’s and Knowledge Graph Presence’s.

6. What the evidence says — and what it does not

The bounded-reading section, same honesty discipline as E-E-A-T §6.

The FAQ/HowTo deprecation is the cleanest cautionary datum: a surface that schema “earned” was withdrawn by the vendor in one announcement. Markup is not a durable benefit you own.

One boundary on the GEO literature, stated explicitly: Aggarwal et al. measured content substance and structure rewrites — cite sources, add statistics, quotations — and did not test schema markup as a variable (KDD ‘24, arXiv:2311.09735; paper summary). The headline GEO numbers therefore do not transfer to “add schema.” Borrowing them here would be the exact over-claim §7 warns against.

The position, the reciprocal of E-E-A-T §6’s “earned, not annotated”: schema is declared, not rewarded. It lets engines trust what is already on the page; it cannot create what is not.

7. Anti-patterns — schema spam and why it backfires

Mirror of E-E-A-T §7. Each pattern looks like the signal it imitates and fails on a trust or anti-abuse filter.

The load-bearing line: invalid or content-mismatched schema is worse than none. It trips AI anti-abuse the way fabricated authority trips trust filters — the over-claim pattern that AI Content Detection covers. Google’s standing position is that there are no special markup tricks; markup must mirror content that is already visible.

8. Schema across SEO and GEO — invariant baseline vs what changes

Mirror of E-E-A-T §8; this restates SEO vs GEO’s shared-baseline contract rather than re-deriving it.

Invariant: valid markup that matches content is a shared SEO+GEO baseline — on the “never drop” list. It costs little, it cannot be the differentiator, and removing it degrades both blue links and machine parseability.

What changes is the consumer: from a rich-result renderer to an entity/parse layer feeding the model’s prior.

Two routed lines, not expanded: the trust-readability of non-text assets — ImageObject/VideoObject provenance — is Multimodal Signals’; and the format choice underneath all of this is JSON-LD’s.

9. Why this matters for GEO + how to act

Schema is infrastructure that feeds the entity layer — not a lever on the grounding choke point Answer Loop §3 calls highest-leverage. Get it correct and out of the way; spend the real effort on citability and trust. This entry is the concept; the doing is the playbook.

For the term itself and its neighbors, see the GEO glossary.

References

Official (Google):

• Google Search Central — General Structured Data Guidelines · Introduction to structured data markup
• Google Search Central — Changes to HowTo and FAQ rich results (2023-08-08)
• Google Search Central — AI features and your website · Top ways to ensure your content performs well in Google’s AI experiences (2025-05-21)
• Google Search Central — Speakable structured data (beta)

Vocabulary:

• Schema.org — Organization, Person, sameAs, FAQPage, HowTo, Article, speakable

Independent / industry:

• searchVIU — Schema Markup and AI in 2025: What ChatGPT, Claude, Perplexity & Gemini Really See (2025-12-02)
• Search Engine Land — How schema markup fits into AI search — without the hype (2026-03-25)
• Search Engine Roundtable — ChatGPT & Perplexity Treat Structured Data As Text On A Page [observation] (2026-02-03)

Academic (boundary reference — schema not a tested variable):

• Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K. & Deshpande, A. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · paper summary