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, and it can only describe content that is already on the page.

The honest framing: schema does not manufacture a citation. What it does is state who you are and what the page claims in a form a machine can parse, so there is less for a model to guess about who said what. We have not measured how much that changes citations.

The types that carry weight

A handful of schema.org types are worth the effort because they map to the things a model has to work out: 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, everything else you mark up is harder to attribute.
• Article (or BlogPosting, NewsArticle): identifies authored content, its headline, author, and date. Useful for guides and posts you want quoted, and the author field names who wrote it.
• FAQPage: pairs a question with a self-contained answer. Its question-and-answer shape matches the shape of a question put to an answer engine. One caveat below on Google eligibility, which does not change that structure.
• HowTo: encodes an ordered sequence of steps. When someone asks an engine how to do a thing, structured steps are easier to lift than steps buried in prose.
• Product: with a complete offers block (price, currency, availability) plus honest aggregateRating and review. Structured purchase facts are more specific than marketing copy.
• BreadcrumbList: shows where a page sits in your site hierarchy. It says little on its own, but it reinforces topical structure and costs almost nothing to ship.

sameAs and entity linking: the part people skip

sameAs is an often-skipped 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 is maintained outside your own site, which is the point. 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.

Markup with little AEO purpose

Not all markup earns its keep for AEO. Some serves traditional search features rather than answer engines, and some causes problems when done wrong.

• WebSite and SearchAction (sitelinks search box): built for a Google SERP feature, not for answer engines. Ship it if you want the search box.
• Custom or invented @type values: anything not in the schema.org vocabulary is not recognized by schema.org parsers. 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.
• Schema that describes content the page no longer shows, because the copy was updated and the JSON-LD was not. This is a common drift failure.
• 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 any parser can 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. Baseline before you change anything, ship the fix, then re-measure. AI answers vary between runs, so on Pondral's dashboard treat changes under 15 points as directional. If nothing moves, look at the content before the schema.