Someone told you schema markup is how you get cited by AI. A consultant, a blog post, maybe a slide in a deck you had to sit through.
Search for structured data AI citations advice and you will find a hundred posts promising the same lever. Here is the honest version: that advice is mostly wrong, and the real answer is far more useful than the myth.
This guide is the hub for schema markup for AI search. By the end you will know what schema actually is, which types earn their keep, what AI engines really do with your markup, and how to plan a rollout you can measure. Where a piece of this needs its own deep dive, I will point you to it.
No code here. Just the map. Take a breath, and let's walk it.
Does Schema Help AI Search? The Honest Answer
Schema markup will not buy you AI citations. Skipping it will still cost you.
Both are true at once. Holding both is the whole skill.
Start with the strongest evidence available. Ahrefs ran a controlled study on 1,885 pages that added JSON-LD between August 2025 and March 2026, matched against roughly 4,000 control pages that already ranked and added nothing. Every page started with real AI Overview citations, so these were not stragglers hoping for a miracle.
The result? The pages that added schema saw their AI Overview citations fall about 4.6%. Citations in Google AI Mode and ChatGPT ticked up by around two percent each, close enough to zero that you cannot call it a win.
Read that twice. Adding schema markup, by itself, did not move AI citations.
So why is this guide 4,000 words long?
Because the same dataset showed something else. Pages that AI engines cite are roughly 2.6 times more likely to carry JSON-LD than pages they ignore. The correlation is real and it is strong.
That gap between "no causal lift" and "strong correlation" is where the structured data AI citations question actually resolves. Clean schema is a symptom of a well-built page, not the cause of its success. Teams that ship valid structured data tend to be the same teams shipping clear entities, fast pages, tidy markup, and content organized so a machine can follow it. AI engines like those pages. They were going to like them anyway.
Here is the mental model to keep: schema is plumbing, not a lever.
You do not install plumbing to impress guests. You install it because the house does not work without it. Skip schema and you forfeit rich result eligibility, you weaken how engines resolve your brand as an entity, and you strip out a layer of clarity that retrieval systems lean on when they parse your page. None of those show up as a citation spike on a dashboard. All of them cost you quietly.
If that feels deflating, hold on. There is freedom in it. You can stop treating structured data as a growth hack that failed you, and start treating it as infrastructure that compounds. Infrastructure is calmer work. It also does not need to be perfect this week.
Want the full evidence review, study by study? That question gets its own piece. This one stays on strategy.
What Schema Markup Actually Is, and the Words You Need
Schema markup is a shared vocabulary that labels what is on your page so machines do not have to guess.
Three words get used interchangeably and should not be.
Structured data is the umbrella. Any standardized format that labels page content for machines counts.
Schema markup is one vocabulary inside that umbrella, maintained by the collaborative Schema.org project. It is the dominant one, and it is what Google, Bing, and most AI systems parse. When people say structured data, they almost always mean this.
Metadata is the broader HTML concept: title tags, meta descriptions, Open Graph tags. Related, but a different category.
If you have been nodding along in meetings without being sure of the difference, that is normal. Most people are fuzzy here. You are now ahead of the room.
The three formats, and why only one matters
Schema.org vocabulary can be written three ways.
- JSON-LD is a script block you drop into the page. Google recommends it. It templates cleanly, validates easily, and stays out of your visible HTML.
- Microdata weaves attributes into your visible markup. It was Google's original recommendation. It is legacy now.
- RDFa uses HTML5 extension attributes and shows up in academic and publishing contexts.
As of early 2026, JSON-LD accounts for roughly 89% of all schema implementations. Microdata sits around 8%. Everything else is a rounding error.
Use JSON-LD. That decision takes ten seconds, and you never revisit it. If you want the full format comparison and the edge cases where the others appear, we break that down separately.
The vocabulary is enormous, and you can ignore most of it
Schema.org holds roughly 823 types and 1,529 properties. Google actively supports about 35 rich result types, a strict subset.
Do the math on that and relax. The vast majority of the vocabulary exists for cross-industry data interchange, not for anything you will ever see in search or an AI answer. You are not behind for not knowing 800 types. Nobody knows 800 types.
You need maybe eight.
Rich results and AI understanding are different jobs
Rich results are the visual treatments in search: star ratings, recipe cards, breadcrumb trails, knowledge panels. Google renders them when a page qualifies.
AI understanding happens earlier and quieter. At parse time, engines extract entities, relationships, and facts from your structured data and feed them into knowledge graphs and retrieval indexes.
Schema does both jobs. The second one keeps working even when Google retires the visual treatment, which matters more than it sounds, and we will come back to it when we talk about FAQ markup.
The Schema Types That Actually Move the Needle
You need a handful of types, applied where they honestly fit. That is the entire type strategy.
Planning schema for AEO gets much easier once you accept how short the real list is. Here is how to think in tiers.
Tier 1: the foundation every site should have
These five are the ones most consistently associated with AI citation across the research. If you do nothing else this quarter, do these.
Organization is your publisher identity card. It carries your name, URL, logo, and a sameAs array pointing to authoritative profiles like Wikipedia, Wikidata, LinkedIn, or Crunchbase. That sameAs array is the single highest-leverage property in this whole guide. It is how a knowledge graph decides that your Acme Inc. is not the other four companies called Acme Inc.
WebSite is a site-level declaration on your homepage, linking back to your Organization.
Person is the author identity card on bio pages. Beyond the name and job title, it carries worksFor, sameAs, and knowsAbout, an array of expertise topics. knowsAbout is quietly powerful for signaling topical authority to AI systems.
Article (or BlogPosting, NewsArticle) marks editorial content: headline, image, publish date, author, publisher. Add dateModified and mainEntityOfPage and you have covered the important ground.
BreadcrumbList is your site hierarchy trail. It is universally supported, dead simple, and missing from a shocking number of sites.
Notice what these five have in common. None of them are about a clever tactic. They are about telling machines who you are, who wrote this, and where it sits. That is entity work, and entity work is the part AI systems genuinely traverse.
Tier 2: add these where your content matches
- FAQPage for real question-and-answer content.
- HowTo for step-by-step guides. Still an active rich result.
- Product for product pages, with
offers,aggregateRating, and identifiers likeskuorgtin. - LocalBusiness for anyone with a physical location, plus its 100-plus subtypes.
- Recipe, Event, Course, SoftwareApplication where those describe the page.
The rule for Tier 2 is discipline, not ambition. Add the type when the page genuinely presents that content. Not because the type exists.
Tier 3: the specialists
SpeakableSpecification marks the sections of a page best suited to audio playback for voice assistants. It is still in beta and limited to news publishers. JobPosting, VideoObject, Review, and a long tail of others serve narrow verticals.
Most teams can skip Tier 3 entirely and lose nothing.
The layer most sites miss: connecting the entities
Marking up an author is table stakes. Linking that author into a graph is where it gets interesting.
Point author.url at a bio page that carries Person schema. Point author.sameAs at verified profiles. Link Person to Organization through worksFor and a consistent @id. Use knowsAbout to describe expertise.
Now you have a graph, not a pile of tags. AI systems traverse graphs to work out who is credible and why. This is how structured data for LLMs starts doing real work instead of just sitting in a script block.
If you are wondering how AI engines recognize and match entities in the first place, that mechanism deserves its own read.
What AI Engines Actually Do With Your Schema
Engines use schema at parse time, not as a citation vote. And the evidence on how much they use it is genuinely mixed.
Let's be honest about that mixture rather than tidy it up.
Google AI Overviews and AI Mode treat schema as one signal among many for entity resolution and rich result eligibility. Google's ecosystem has the deepest structured data roots, so this is where markup does the most work.
Gemini leans hard on Google's entity graph. Organization, LocalBusiness, and Product schema feed the brand knowledge that Gemini draws on.
ChatGPT parses JSON-LD when crawling, and vendor reporting suggests pages carrying Organization, Product, and FAQPage schema show up more often in citations than you would expect by chance.
Perplexity uses schema to pin down canonical entities and structured facts. Article, Person, and Organization markup correlate with citation rates there.
Claude treats the web as a corpus. Structured data improves extraction accuracy, but the model does not appear to weight it heavily during retrieval.
Now the complication. One live-crawl experiment by Otterly found JSON-LD was used by Gemini and effectively ignored by six of the seven engines tested during live retrieval. That does not square neatly with the vendor reporting above, and pretending it does would be doing you a disservice.
Here is how to reconcile it. Schema's contribution mostly happens before an engine ever answers your buyer's question.
Four things are going on under the hood, and together they explain what structured data for LLMs is really doing:
Entity disambiguation. sameAs and @id let a system resolve your brand to a specific Wikidata entity instead of guessing between similarly named companies.
Fact extraction. Structured properties like founder, foundingDate, price, and availability hand engines clean, parseable facts. Clean facts are harder to hallucinate.
Knowledge graph contribution. Well-formed schema flows into Google's Knowledge Graph, Bing's entity graph, and Wikidata. Those graphs get re-cited by AI systems for months afterward. This is the compounding part, and it is invisible on any weekly report.
Rich result triggers. Star ratings, breadcrumbs, and product carousels still shape click-through and perceived authority.
So when someone asks whether a given engine "reads your schema," the question is slightly wrong. The better question is whether your schema has already shaped what the engine knows about you. Usually, by answer time, that work is long done.
llms.txt: Worth Knowing, Not Worth Betting On
llms.txt is a proposed Markdown file at your domain root that gives LLMs a curated map of your content. Jeremy Howard of Answer.AI proposed it in September 2024.
Think of it as a table of contents written for a machine: a short site description, then sections of linked pages with one-line summaries. An optional llms-full.txt goes further and serves full markdown for every page.
Adoption tells the real story. Somewhere around 1,000 domains have published one by mid-2026, growing roughly 10% quarter over quarter from a very small base. It clusters among AI-native startups, developer tools, and documentation-heavy sites. Mainstream publishers have not moved.
Google has not endorsed it. No major AI vendor has confirmed they parse it.
So here is the call. If your site is documentation-heavy or AI-tool-adjacent, publish one. It is an afternoon of work and the downside is zero. If it is not, skip it without guilt and come back when the picture changes.
Schema and llms.txt are complements, not rivals. Schema describes page-level semantics for retrieval. llms.txt describes site-wide content for context. Neither substitutes for the other, and neither substitutes for content worth citing.
How to Roll Out Schema Across Your Whole Site
Schema at scale is a template problem, not a page problem. Get that one sentence right and the rest is logistics.
Four phases. You can run them over a quarter, not a weekend.
Phase 1: audit what you already have
Crawl every URL with something that extracts JSON-LD blocks. Classify each block by type. Run them through the Rich Results Test and the Schema Markup Validator.
Build a boring spreadsheet: URL, schema type, validation status, rich result eligibility. Boring is the point.
You will almost certainly find some mix of these:
- Pages with no schema where a Tier 1 type obviously applies
- Stale Article markup with a
datePublishedand nodateModified - Two plugins fighting, one page emitting both Article and Product
- Schema values that do not match what a human sees on the page
- Missing required properties, or image URLs quietly returning 404
If your audit comes back ugly, good. That is a list of fixes, not a verdict on you. Most sites that have been alive for five years look exactly like this.
Phase 2: fix it at the template
Never hand-code schema page by page. It will drift within a month and you will be the only person who knows why.
Schema generation belongs in the CMS template. WordPress teams have Rank Math, Yoast, and All in One SEO. Shopify has built-in Product schema you customize at the theme level. Webflow has structured data fields in CMS templates. Headless setups inject schema at build time or server-side.
One template change fixes 400 pages. That is the whole reason this phase exists.
If you do not have a developer standing by, that is a solvable problem, and there is a platform-by-platform walkthrough for exactly that situation.
Phase 3: design your entity graph
This is the phase most teams skip, and it is the one that matters most for AI.
Give every entity a canonical @id URL: your organization, each author, each product, each location. Then use those same @id values everywhere that entity is referenced. Your organization @id shows up in the publisher field of every Article, the worksFor of every Person, the brand of every Product.
Do that and you have not marked up 400 pages. You have described one company, consistently, 400 times. Those are very different things to a knowledge graph.
Phase 4: validate, then keep watching
Run every template type through the Rich Results Test before it ships. Check the Schema Markup Validator against your domain monthly. Watch Search Console's Enhancements reports for warnings. Spot-check a handful of pages per content type each quarter. Set an alert if the JSON-LD block count per page ever drops.
Schema breaks silently. A theme update, a plugin conflict, a migration, and it is gone with no error anywhere. Monitoring is not optional, it is the only way you find out.
The mistakes that actually hurt
Most schema mistakes are harmless. These are not.
- Markup that contradicts the page. Structured data claiming things a visitor cannot see violates Google's spam policies and can earn a manual action. This is the one that bites.
- Forcing a type that does not fit. Product schema on a blog post is worse than no schema.
- Conflicting plugins producing overlapping, contradictory markup.
- Missing required properties, which quietly disqualifies you from rich results.
- Broken images: 404 URLs, missing dimensions, or resolution below Google's minimum.
- Date format errors. ISO 8601 or nothing.
- Stale
sameAsURLs pointing at profiles you abandoned or never controlled. - Mixing formats across your site so parsers have to work it out.
Read that list as a pre-flight check, not an indictment. Almost everyone has committed at least three.
How to Tell If Your Schema Moved Anything
You cannot manage schema for AEO by feel. You need the citation data, and it has to be prompt-level.
Given everything above, this is the uncomfortable part. Schema is infrastructure with no direct citation lift, which means you cannot judge it by whether citations went up next Tuesday. You judge it by whether your entity is resolving correctly, your templates are valid, and your overall AI visibility is trending the right way as the whole system improves.
That still requires measurement. Four metrics carry the weight:
- Mention rate: how often AI answers name your brand.
- Citation rate: how often AI answers link to your pages as a source.
- Share of voice: your citations against your competitors' for the same questions.
- Page-level attribution: which of your pages earn citations, and which prompts drive them.
That last one is where schema work gets interesting. When you can see which pages get cited and for which prompts, you can check those pages against your schema audit and look for patterns. Are your well-marked-up pages over-represented? Are the entity-rich pages winning? That is a real feedback loop, and it beats arguing about tier lists.
Building it starts with defining the prompts your buyers actually ask, tracking mentions and citations across engines on a schedule, benchmarking against competitors, and iterating. The category of tools that do this has grown quickly, and any of them beat guessing.
This is where DeepSmith fits into the schema conversation. It tracks how AI engines answer the questions that matter in your space across ChatGPT, Perplexity, Gemini, Claude, and Google AI Mode, with per-prompt mention and citation rates and a Pages view showing which of your pages AI actually cites. It also builds schema markup, heading structure, internal linking, and metadata into the writing pipeline rather than bolting them on afterward. It cannot make an engine cite you, and nothing can. What it can do is tell you the truth about whether your work is landing.
Measure the system, not the markup. Schema is one input into a much larger picture, and the picture is the thing you are actually managing.
Where to Go From Here
Let's land this.
So, does schema help AI search? Indirectly, and that word is carrying real weight.
Schema markup for AI search is not the citation lever you were sold. It is infrastructure: necessary, quietly compounding, and costly to skip. Schema for AEO works the way good plumbing works, invisibly and only when you maintain it. The correlation between clean structured data and AI citations is real, and it points at something bigger than markup. It points at teams who build pages machines can understand, and then measure whether it worked.
So here is your smallest useful next step. Do not plan a six-month schema program. Pick your Organization schema, get the sameAs array right, and make sure your entity resolves cleanly. That is one afternoon. It is also the highest-leverage hour in this entire guide.
Then work Tier 1 across your templates. Then design the entity graph. Then measure.
You are closer than you think. Most sites already have half of this through their CMS, sitting unvalidated because nobody checked.
Go check. And when you want to see whether any of it is actually moving your AI visibility, start a free DeepSmith trial and watch the citation data instead of guessing at it.



