Schema markup for AI search
Schema matters more in AI search, not less — it tells engines what your content means with machine precision. This module covers JSON-LD fundamentals, the high-value types, entity grounding with @id and sameAs that feeds GEO authority, the markdown-vs-schema debate and the llms.txt hybrid, and the validation discipline that keeps it all working.
What you will learn
Why schema matters more in AI search
Schema markup — structured data in JSON-LD — matters more in AI search, not less. It tells an engine, with machine precision, what your content means: this is an organization, this is the author, this is a question and its answer, this is a product and its price. That clarity reduces the chance a model misreads or skips you, and it’s how generative engines build the trusted entity picture they synthesize answers from. JSON-LD has effectively graduated from ‘markup’ to ‘data’ engines rely on.
The myth to kill: ‘models read everything, so schema is dead.’ The opposite is true for grounding. Reading text and knowing what it means are different problems, and structured data solves the second one cheaply and unambiguously. The engines that write today’s answers lean on entity and schema signals to decide who to trust — so schema moved from a rich-results nice-to-have to part of how you become legible to the machine.
The mistake is re-declaring a slightly different Organization on every template — one page says ‘RGM’, another ‘Real Growth Matters LLC’, a third has no sameAs. To a model, that’s three fuzzy half-entities, none fully trusted.
I define the Organization and Person once, give each a stable @id (e.g. /#org, /#person) with complete sameAs links, and then every page’s schema references those @ids instead of re-describing them. One canonical entity, reinforced site-wide.
Now every page is a vote for the same entity, and the model’s confidence in who you are compounds instead of fragmenting.
Schema fundamentals: JSON-LD
Use JSON-LD — a script block of structured data in the page head — as your schema format; it’s Google’s recommended approach and the cleanest for engines to parse. The vocabulary is schema.org: a shared dictionary of types (Organization, Article, FAQPage, Product…) and properties. You don’t need every type — you need the few that describe your entity and your content, implemented correctly and kept consistent with what’s visible on the page.
Claim: JSON-LD is Google’s recommended structured-data format, placed in a script tag rather than wrapped around HTML — the easiest form for search and AI engines to parse reliably. Source: Google — Structured data introduction. Context: Prefer JSON-LD over microdata/RDFa; keep the marked-up facts consistent with the visible page, or engines discount it.
Schema isn’t dead in the AI era — it’s how you tell a machine what your content means, not just what it says. Meaning is exactly what a model needs to trust and cite you.
The types AI systems use most
Prioritize a short list. Organization and Person establish your entity and authorship (the trust foundation). Article/BlogPosting mark your content and its author/date. FAQPage and HowTo map directly onto answer-engine formats. Product (with offers, reviews) powers commerce answers. BreadcrumbList communicates site structure. Implement these well rather than chasing exotic types — coverage of the basics, done correctly, beats breadth done sloppily.
Entity grounding: Organization & Person
Entity schema is the most strategically important and most neglected. Organization (name, logo, URL, sameAs to your verified profiles, knowsAbout for your topics) and Person (your authors, with credentials and sameAs to their real profiles) tell the engine who you are, what you’re expert in, and that you’re corroborated elsewhere. This is the schema layer that feeds GEO authority — a model is far likelier to cite an entity it can clearly identify and verify.
The power move is consistency with the wider web. sameAs links from your Organization/Person schema to your real LinkedIn, Wikipedia/Wikidata, Crunchbase, and authoritative profiles let the engine connect your on-site claims to its existing knowledge of you. That’s how you graduate from ‘a website making claims’ to ‘a known entity’ — and known entities get synthesized into answers.
Content types: Article, FAQ, HowTo, Product
Content schema maps your pages onto the shapes engines answer in. Article/BlogPosting attaches author, date, and headline (freshness + authorship signals). FAQPage labels genuine Q&A — among the most citable patterns (build it with our FAQ Schema Generator). HowTo structures step-by-step guides. Product with offers and reviews powers shopping answers. Match the type to the page’s real content, and keep the markup synced with what users actually see.
- Is FAQ schema still worth adding?
- Yes, when it marks up real, visible Q&A. It forces self-contained answers and labels them for engines — one of the most reliably citable patterns. Avoid fabricated or hidden FAQs, which violate guidelines and get discounted.
- Do I need HowTo schema?
- Use it for genuine step-by-step content. It structures steps an engine can reproduce. Like all schema, it must reflect visible on-page steps; note Google has changed how HowTo rich results appear, but the structured data still aids machine understanding.
- What about Product schema for non-ecommerce?
- Use it where you genuinely have products/offers. For services, lean on Organization, Article, and FAQPage. Don’t force Product schema onto pages that aren’t products.
Markdown vs schema: llms.txt and the hybrid
There’s a live debate — structured data (JSON-LD) versus clean markdown (the llms.txt standard and markdown page versions). They solve different problems and you want both. JSON-LD = meaning: precise entity and content grounding a model can trust. Markdown/llms.txt = access: token-efficient navigation and substance an AI crawler can ingest cheaply. The research is explicit that JSON-LD gives superior factual grounding while llms.txt offers higher token efficiency — a hybrid wins.
Claim: Comparative LLM-optimization analysis finds JSON-LD provides superior factual grounding and entity recognition, while llms.txt offers higher token efficiency and better navigation for AI crawlers — a hybrid approach is recommended. Source: LLM-optimization analysis of llms.txt vs JSON-LD. Context: Don’t choose: ship JSON-LD for meaning, an llms.txt for navigation, and clean rendered HTML/markdown for retrievable substance.
Practically, the full AI-readability stack is three layers: JSON-LD schema so engines understand what your content means; an llms.txt (build one with our llms.txt Generator) so they can navigate to your priority pages efficiently; and clean, server-rendered HTML or markdown so the substance is actually retrievable. Each closes a different failure mode — misunderstanding you, not finding your best pages, or choking on un-rendered content.
AI crawlers pay a token tax to wade through your nav, scripts, and markup to reach the actual content. The lighter and cleaner the version they can fetch, the more of your substance fits in the model’s context — and the more accurately it represents you.
So for priority pages I serve a markdown twin (content-negotiated, or a sibling .md) alongside the HTML: same substance, none of the chrome. The HTML serves humans; the markdown serves machines the unadulterated content.
It’s the same instinct as llms.txt, applied page-by-page — give the model the cleanest possible read of exactly what you want quoted.
Most Organization schema lists the basics — name, logo, URL — and stops. But there’s a property that directly tells engines what you’re an authority on: knowsAbout, a list of your core topics and entities.
I populate knowsAbout with the specific subjects the brand should own, using canonical entity names (ideally linked to Wikidata/schema.org entities). It’s a machine-readable claim of expertise that reinforces every topical signal elsewhere on the site.
You can literally hand the engine a structured list of what you’re the authority on — few brands do.
Validation: schema the parser accepts
Schema that doesn’t validate is invisible — a single malformed bracket can void the whole block. Always validate with Google’s Rich Results Test and the Schema.org validator before shipping, and confirm the marked-up facts match what’s visible on the page. Generate it correctly (our generators emit valid, escaped JSON-LD), validate it, and keep it in sync as the page changes — stale schema that contradicts the page is worse than none.
The discipline that prevents most schema bugs: treat structured data as code, not copy. It has syntax, it can break silently, and it needs the same validate-before-ship rigor as any deploy. Build it from a generator or template, run it through the validators, and re-check after content edits — because schema drifting out of sync with the visible page is the most common way good markup quietly stops helping.
Where schema goes wrong
Schema fails predictably: declaring inconsistent entities across pages, marking up content that isn’t visible (or is fabricated), shipping invalid JSON-LD that silently voids, chasing exotic types while neglecting Organization/Person, and treating schema as a substitute for the markdown/retrieval layer rather than a complement. Each undercuts the grounding schema exists to provide.
Different Organization/Person details per template create fuzzy half-entities a model can’t fully trust.
Schema for content not visible on the page violates guidelines and gets discounted.
A malformed block voids silently — the engine sees no structured data at all.
Chasing rare types while skipping Organization/Person misses the trust foundation.
Schema grounds meaning but doesn’t make un-rendered content retrievable.
Your schema checklist
Schema is a checkable layer. Tick what is genuinely true of your site today.
Prove it. Earn your passcode.
Ten questions, CASE method (Context · Analysis · Strategy · Execution). Pass at 90% to unlock this module’s completion passcode — retake as many times as you like.