How does Stan Consulting use this in practice?

Stan Consulting reads this against the account, the site, and the numbers in The SC Method, then names the three things to fix first. Written diagnostic in 72 hours. Principal-led. Scoped after intake.

Marketing Atlas · Reference · AI Search

Schema for AI.

Updated May 2026 · Reference route · written diagnostic

The schema.org JSON-LD markup decisions that improve AI search engine understanding of a page's entity, content, and authority. The same schema as SEO, applied with different priorities.

Concept · reference page Revised 2026-05-15 Author Stan Tscherenkow

Diagnostic bridge

Business implication.

Reference use: AI search, answer engines, or citation surfaces do not understand or recommend the business cleanly. Qualified buyers may compare options without seeing enough trust, proof, or entity clarity. Keep this as an authority reference, then use the route table to decide the next check.

Concept signal	Business problem	Next checks	Next route
Symptom match	AI search, answer engines, or citation surfaces do not understand or recommend the business cleanly.	Compare the concept to the visible business symptom before changing the channel, page, or budget.	Read the problem
Proof need	The idea needs evidence before it becomes a work order.	Review the closest proof file for the same failure pattern.	Review proof
Execution lane	The failing layer appears specific enough to scope work.	Use the service route only when the constraint is named.	See service
Unknown layer	The account, site, offer, tracking, or follow-up path may still be the leak.	Get the written diagnostic before another rebuild, retainer, or budget increase.	Get diagnosis

The numbers underneath

What this concept moves in the AI search.

•Same JSON-LD · different priorities

•Article, Person, Organization, BreadcrumbList, speakable

•@id cross-references · entity disambiguation

The shift this concept produces

Before and after the operator applies the discipline named here. Source: SC install benchmarks across categories, 2024-2025.

Before applying this concept

22% baseline

After applying this concept

78% lift

Section 01 · Quick definition

Definition.

In one read

Schema for AI is the application of schema.org JSON-LD markup with priorities tuned for AI search retrieval. The vocabulary is the same vocabulary SEO has used for a decade. The priorities are different: Article with author, Organization with @id and sameAs, Person with stable bio URL, DefinedTerm over generic Thing, and SpeakableSpecification on definitional content.

The structural read

The goal is not a rich result in Google. The goal is a confident citation in an AI answer. The same JSON-LD block can be SEO-correct and AI-inert if the priorities are wrong.

Section 02 · Why it matters

Why it matters.

Origin.

Schema is the structural layer an AI retrieval agent uses to answer the question, what is this page, and can I cite it. A page with strong schema for AI gives the agent a clean answer in milliseconds: this is an Article, written by this Person, published by this Organization, about this DefinedTerm, with these speakable selectors. A page with weak or generic schema makes the agent infer everything from raw HTML, which is slower and less confident. The lower the agent's confidence, the lower the citation probability.

Mechanic.

The metric matters because most operator sites finished schema work before AI search retrieval mattered. The Article tag is there. The Organization tag is there. The pieces that disambiguate entity, anchor authorship, and surface speakable content are usually missing. The fix is not new schema. The fix is reordering priorities and filling gaps.

The load-bearing point

The practical stake is that schema for AI is the technical work with the best dollar-for-dollar return on AI citation rate. The site already has the markup framework. The question is whether it carries the signals the retrieval layer actually needs.

Section 03 · How it runs

How AI retrieval reads schema.

An AI retrieval agent fetching a page parses the JSON-LD blocks in the head and body, builds an entity graph from the @type, @id, and sameAs values, and uses that graph to answer two questions about the page: which entity is this about, and how authoritative is this source. Strong schema produces clean answers to both. Weak schema forces the agent to fall back on raw text and document structure.

Step one · entity graph assembly

The agent reads every @type and @id in the JSON-LD. Organization @id, Person @id, Article @id, and any cross-referenced entities form a small graph. Pages with a complete graph (Organization with founder Person, Article with author Person, both Persons resolving to bio pages) score higher than pages with isolated nodes.

Step two · specificity check

The agent prefers specific @type values over generic ones. DefinedTerm is more useful than Thing. SoftwareApplication is more useful than CreativeWork. ProfessionalService is more useful than LocalBusiness alone. The more specific the type, the more the agent learns from the markup without having to re-derive it from the page text.

Step three · speakable surface

The agent looks for SpeakableSpecification cssSelector values that mark which page elements are definitional. Pages that mark their H1 and definition card as speakable tell the agent what to quote when the answer needs a one-line description. Pages that omit speakable force the agent to choose what to quote, and the choice is often suboptimal.

Step four · cross-reference verification

The agent checks sameAs links from Organization and Person schema. Cross-references to Wikidata, LinkedIn, Crunchbase, Bloomberg, and other authoritative directories increase confidence. A Person @id with three sameAs links resolves more confidently than one with none. The verification compounds across the graph: a confident Person makes the Article more citable.

The shift this concept names

Schema for AI is the application of schema.org JSON-LD markup with priorities tuned for AI search retrieval.

Before applying this concept

“Our schema validates, so it's done.”

After applying this concept

Section 04 · Common misunderstandings

What people get wrong.

Misunderstanding 01

“Our schema validates, so it's done.”

Validation confirms the markup is parseable. It does not confirm the markup carries the signals AI retrieval needs. A page with valid Article, BreadcrumbList, and FAQ schema and no Person @id, no Organization sameAs, and no SpeakableSpecification validates cleanly and produces nothing useful for citation. Validation is the floor. Priority is the work.

Misunderstanding 02

“FAQ schema is the most important markup.”

FAQ schema was the highest-priority markup for SEO rich results in 2019. For AI search retrieval in 2026, Article with author and Organization with @id outrank it. FAQ markup still helps for specific question-answer surfaces, but the citation work has moved upstream. Operators still prioritizing FAQ over entity schema are working against the wrong scoring function.

Misunderstanding 03

“More schema is better schema.”

The opposite. AI retrieval prefers a focused, internally-consistent graph over a sprawling one. A page with five overlapping schema types and conflicting @id values scores lower than a page with three clean types and consistent @id. The work is to remove redundancy and tighten cross-references, not to add types.

Misunderstanding 04

“Speakable schema is for voice search and we don't care about Alexa.”

SpeakableSpecification was originally aimed at voice surfaces, but AI search engines now use the cssSelector values to choose what to quote in answer cards. A page that marks its H1 and definition body as speakable gives the model an explicit cue. The voice-surface origin is irrelevant; the AI-citation use is real.

Misunderstanding 05

“Generic schema types like Thing or CreativeWork are safe defaults.”

Safe in that they validate. Useless in that they communicate nothing the retrieval layer can use. AI retrieval prefers DefinedTerm to Thing, ProfessionalService to LocalBusiness, SoftwareApplication to CreativeWork. The specific types tell the model what kind of answer this page can support. The generic types tell it nothing.

Section 05 · Diagnostic questions

Questions a Stan Consulting diagnostic asks.

Does every key page carry Article, Person (author), and Organization (publisher) schema with @id values that resolve to a single canonical fragment URL across the site?

Do Organization and Person schema include sameAs cross-references to Wikidata, LinkedIn, Crunchbase, and other authoritative directories?

Are specific @type values used (DefinedTerm, ProfessionalService, SoftwareApplication) instead of generic ones (Thing, CreativeWork, LocalBusiness)?

Does definitional content carry SpeakableSpecification with cssSelector values that point at the H1 and the canonical definition body?

Does the @graph structure include all relevant entities in one block per page, or are there scattered separate JSON-LD blocks that fail to cross-reference?

Is BreadcrumbList present and accurate, with itemListElement positions that match the live navigation hierarchy?

Are Article entries published with datePublished and dateModified, and do those dates reflect actual editorial activity rather than automated stamps?

Stan's take . four chunks

Most pre-2024 schema implementations were technically correct and AI-inert. The markup signaled what to crawl, not what to trust.

I have audited sites with valid Article, BreadcrumbList, FAQ, and Review schema across every page and zero Person @id, zero Organization sameAs, zero SpeakableSpecification. Validation passed.

Citation never moved. The fix is not more markup.

The fix is the thirty minutes spent adding @id cross-references to the existing Person and Organization blocks and the additional ten minutes adding sameAs to Wikidata. That hour shifts the page from technically present to citably present, which is the difference the retrieval layer actually scores on.

Stan Tscherenkow · Principal · Stan Consulting LLC

Section 06 · Adjacent concepts

Related Atlas entries.

Section 07 · Sources

Sources.

Schema.org · Full schema vocabulary

The complete schema.org type hierarchy, including DefinedTerm, SpeakableSpecification, ProfessionalService, and the Person and Organization types used for AI citation work.

Google Search Central · Structured data introduction

Google's reference on structured data, including how AI features in Search use schema and which markup signals affect appearance in AI Overviews.

Google Search Central · SpeakableSpecification

Google's reference on speakable schema, the cssSelector convention, and how the markup is read for voice and AI surfaces.

Search Engine Land · Structured data library

Practitioner reference covering structured-data implementation patterns, common mistakes, and the priority shifts that came with AI search retrieval.

Search Engine Journal · Structured data for AI search

Practitioner reference on the schema priorities that affect AI citation rate, including author and entity markup that matter more than rich-result-era priorities.

Continue in the Atlas

Up to hubMarketing Atlas SiblingAI Search Optimization SiblingAI Citation Siblingllms.txt SiblingEntity Clarity Adjacent clusterGA4 Attribution Adjacent clusterUTM Loss Commercial bridgeConversion Second Opinion