Schema markup that AI models actually read

What schema markup does for AI citations

Schema markup is structured data that tells a machine what a page is about instead of making it guess. For AI answer engines it does two jobs: it disambiguates your entity so ChatGPT, Claude, Gemini, Perplexity, and Grok know which company or product you are, and it hands them clean, quotable facts they can lift into an answer. It is not a ranking lever you flip on. It is a comprehension aid that only pays off when the underlying content is already worth citing.

The honest framing: schema does not manufacture a citation. It removes the reasons a model would skip you or attribute your fact to a competitor. When two pages say the same thing and one has clean Organization and sameAs markup, the model can be more confident about who said it. That confidence is the whole game.

The types that carry weight

A handful of schema.org types do most of the work for AI visibility because they map to the things models need: who you are, what you sell, what you claim, and how to get from a question to an answer.

• Organization (or LocalBusiness): the entity anchor. Set name, url, logo, description, and sameAs. Every other block on your site hangs off this. If a model cannot resolve your entity, nothing else you mark up lands cleanly.
• Article (or BlogPosting, NewsArticle): identifies authored content, its headline, author, and date. Useful for guides and posts you want quoted, and the author field feeds author-entity signals models increasingly weigh.
• FAQPage: pairs a question with a self-contained answer. This is the highest-leverage type for AEO because it mirrors exactly how answer engines extract. One caveat below on Google eligibility that does not change its AI value.
• HowTo: encodes an ordered sequence of steps. When someone asks an engine how to do a thing, structured steps are far easier to lift than steps buried in prose.
• Product: with a complete offers block (price, currency, availability) plus honest aggregateRating and review. Structured purchase signals beat marketing copy every time a model weighs what to say about a product.
• BreadcrumbList: shows where a page sits in your site hierarchy. Low direct citation value, but it reinforces topical structure and costs almost nothing to ship.

sameAs and entity linking: the part people skip

sameAs is the single most underused field in AEO. It is an array of URLs pointing at other authoritative profiles that describe the same entity: your Wikipedia or Wikidata page, Crunchbase, LinkedIn company page, GitHub org, official social accounts. It tells a model "the entity on this page is the same entity described over there," which lets it connect your on-site claims to the broader web graph it already trusts.

Point sameAs at sources with independent authority, not just your own social feeds. A Wikidata entry or a Crunchbase profile carries weight because a model has seen it corroborated elsewhere. If your brand has no third-party presence to link to, that is the gap to fix first. Schema cannot link to authority that does not exist. Build the Wikidata entry, claim the Crunchbase profile, then point sameAs at them.

Keep the entity consistent everywhere. Same legal name, same URL, same logo across Organization markup, your footer, and every external profile. Models resolve entities by matching signals across sources. Contradictions (one name here, a d/b/a there) make you harder to attribute, and hard-to-attribute means uncited.

What models largely ignore

Not all markup earns its keep for AEO. Some is fine for traditional search but does little for citations, and some actively backfires when done wrong.

• WebSite and SearchAction (sitelinks search box): a Google SERP feature, near-zero AEO value. Ship it if you want the search box, but do not expect it to move citations.
• Custom or invented @type values: anything not in the schema.org vocabulary is silently dropped. Stick to published types.
• Deeply nested @graph constructions with broken @id references: one dangling @id can invalidate the relationships in the whole block. Complexity is not a virtue here.
• Puffery-filled Article or Product markup: a model will parse a headline of "The #1 Best Revolutionary Platform" and gain nothing citable from it. Markup is only as good as the facts it wraps.
• Marking up content that is not on the page: describing FAQs or steps in JSON-LD that a human cannot see is a guidelines violation and a trust risk. The structured data must match the visible content.
• Review and aggregateRating you cannot substantiate: fabricated ratings are a claims-integrity problem before they are a schema problem. If the reviews are not real, leave the field out.

JSON-LD vs microdata: use JSON-LD

There are two ways to add schema to a page. Microdata (and RDFa) interleave attributes directly into your HTML tags, so the markup is tangled into the markup that renders. JSON-LD is a self-contained block, usually a script tag in the head, that sits apart from the visible DOM.

Use JSON-LD. It is the format Google recommends, it is the easiest to generate programmatically, and it is the easiest to validate because it lives in one place instead of being scattered across a template. Microdata breaks the moment someone restructures the HTML around it, and that someone is usually a developer who has no idea the schema is load-bearing. The one real advantage of JSON-LD (decoupling from the DOM) is also its one real risk: because it is separate, nothing forces it to stay in sync with the page. That is what validation is for.

Common mistakes that quietly kill your markup

Most broken schema does not throw an error anyone notices. It parses, looks fine in the page source, and contributes nothing because of a defect the author never checks for.

• One syntax error in a JSON-LD block invalidates the entire block, not just the bad line. A trailing comma can take down your whole Organization entity.
• Copy-pasting a template and leaving placeholder values ("Your Company Name", example.com URLs) live in production. It happens more than anyone admits.
• Schema that describes content the page no longer shows, because the copy was updated and the JSON-LD was not. This is the top drift failure mode.
• Multiple conflicting Organization blocks across pages with different names or logos, so the model cannot settle on one entity.
• Relative URLs or missing @id anchors, so cross-references between blocks do not resolve.
• Assuming FAQPage still shows Google rich results. Google restricted FAQ rich results to authoritative government and health sites in 2023, so the SERP snippet is mostly gone. The markup still carries clear question-answer semantics that AI engines read, so keep it for AEO even though the blue-link payoff shrank.

The validation checklist

Treat schema as code: put it in version control, and check it every deploy. Run this sequence before you trust any page's markup.

1. Paste the URL into the Schema.org Validator (validator.schema.org) to catch type and syntax errors first.
2. Run it through Google's Rich Results Test to catch rendering issues and see what Google can actually extract.
3. View source on the live, rendered page and confirm the JSON-LD is present after your framework hydrates, not just in the local template. Client-rendered schema that never ships is a common miss.
4. Diff the markup against the visible content field by field. Every marked-up fact should appear on the page a human sees.
5. Verify sameAs URLs resolve to live, correct profiles for the same entity, and that the entity name and logo match everywhere.
6. Run an AEO spot-check: ask the engines a question your page should answer and see whether they cite you and attribute the fact correctly. That is the only test that measures the outcome you actually care about.
7. Add a schema lint step to CI so a future "tidy-up" commit cannot silently break @id references without failing the build.

How to measure whether it worked

Validators tell you the markup is well-formed. They do not tell you it earned a citation. Those are different questions, and only the second one matters for AI visibility.

The real test is behavioral: after you ship or fix schema, does the model cite you more often, place you more prominently, and attribute your facts correctly? Pondral's rubric scores exactly those dimensions, Presence, Prominence, Context, Citation Link, and Competitive Presence, across ChatGPT, Claude, Gemini, Perplexity, and Grok. Clean entity markup mostly moves Presence and Citation Link: the model finds you and gets the attribution right. Baseline before you change anything, ship the fix, then re-measure. If citations do not move, the problem is the content, not the schema.