Schema & AI Search: Use It—But Stop Selling It As “LLM Evidence”
Schema still matters in 2026—but not because it “feeds the LLM.” Here’s what the evidence actually supports, what breaks in common GEO/AEO advice, and what SMEs and agencies should do now to win AI citations without magical thinking.
Schema is having a moment again—this time because of AI Search, “GEO,” and the race to become the cited source inside chat-based answers.
But here’s the uncomfortable truth: a lot of what’s being sold as “evidence” that Schema markup makes LLMs cite you is not evidence at all. It’s wishful interpretation of outputs, mixed with a shallow understanding of what Structured data is designed to do, and how modern AI answer systems are actually assembled.
This article is my attempt—speaking as Marius Dosinescu at AYSA.ai—to reset the conversation. Yes: you should still implement schema. No: you should not buy the idea that schema is a magical injection that LLMs faithfully parse and reward with citations.
Instead, you should treat schema as one part of a broader system for Search visibility in 2026: Entity clarity, corroboration across sources, structured Crawling/Indexing, retrieval-friendly pages, and a workflow that turns strategy into production changes you can actually ship.
Primary research lead & credit: This editorial is informed by Mark Williams-Cook’s analysis and experiment, originally published at Search Engine Journal. I’m not repeating the article—I’m building on the core question it raises: what does the evidence really support?
Concise summary
- Schema is for disambiguation and machine-readable meaning—primarily for search engines and knowledge systems, not necessarily for LLMs “as designed.”
- “The LLM returned info that only appears in JSON-LD” is not proof that the model parsed schema; it could simply be reading that block of text like any other text on the page.
- The highest-value reason to keep schema is still classic SEO: eligibility for rich results, clearer entity associations, fewer misunderstandings, and better data quality across search surfaces.
- AI visibility requires more than markup: corroborated facts across the web, clean site architecture, strong on-page evidence, and content that retrieval systems can quote and cite.
- Execution is the bottleneck. AEO/GEO strategies die in Jira. You need monitoring, change preparation, human approval, and reliable deployment—which is exactly where AYSA fits.
Table of contents
- What changed: From “SEO signals” to “AI answers”
- The schema vs. LLM confusion: what people claim, what the evidence supports
- What schema is actually for (and what it is not)
- Where would an LLM even use schema?
- Why “schema gets baked into training data” is a weak assumption
- Why “schema is read at query time” is often overstated
- Where schema actually helps in 2026 (even if LLMs don’t ‘respect’ it)
- What to do instead of schema theater: build citation-worthy evidence
- An SME scenario: a multi-location clinic trying to win AI answers
- What agencies should rethink in GEO/AEO proposals
- What to monitor now: the visibility signals that matter
- How AYSA helps: monitor, prepare, approve, execute (without GEO theater)
- What to do next: a practical action list
- Sources and further reading
What changed: From “SEO signals” to “AI answers”
In the classic SEO era, most business owners had a reasonably simple model of the world:
- You publish pages.
- Google crawls them.
- You rank for keywords.
- You get clicks.
That model wasn’t complete, but it was close enough to be useful.
AI search changed the user interface and the attention economy. People now ask questions and expect synthesized answers. Those answers may cite sources, may provide local recommendations, may list products, or may provide step-by-step instructions—without the user clicking through in the way we’re used to.
In that environment, businesses are asking a new set of questions:
- How do we become the source an AI answer cites?
- How do we reduce wrong answers about our business?
- How do we ensure the model describes our product accurately?
- How do we show up when someone asks “best option near me” without a traditional SERP click?
That’s where GEO/AEO entered the chat. It’s a real need, and there are real tactics. But the vacuum created by uncertainty also created a market for comforting stories—and schema became one of those stories: “Add JSON-LD, and the LLM will understand and cite you.”
It sounds plausible. It’s easy to sell. And it’s often packaged as “evidence-based,” because someone ran a quick test and got a chatbot to repeat a value that appeared inside a schema block.
Which brings us to the problem: repeating something is not the same as understanding it the way schema intends.
The Schema vs. LLM Confusion: What People Claim, What the Evidence Supports
The current “schema for AI” conversation often makes a quiet, unproven leap:
If the AI answer included a fact that was only present inside JSON-LD, then the AI must be parsing schema.
Mark Williams-Cook’s piece (linked above) is valuable because it stresses-test this idea with an intentionally broken structured data block—nonsense types, nonsense properties, and a fake context—and observes that LLMs still happily returned an “address” and even claimed to have used “structured data.”
That observation matters even if you disagree with the conclusions, because it forces you to confront a simpler possibility:
- The LLM is not “using schema.”
- It is reading a chunk of text that happens to be formatted like JSON.
- It is extracting something that looks like an address.
- And it is explaining its own output using the most plausible-sounding narrative: “I found it in structured data.”
This is not a knock on LLMs; it’s a known property of generative systems. They generate fluent explanations whether or not those explanations represent an internal, verifiable chain of processing.
For business owners, the takeaway is straightforward: don’t treat a chatbot’s explanation of how it found something as technical proof. Treat it as a clue, and then go validate with system-level understanding and repeatable tests.
What schema is actually for (and what it is not)
Schema (Schema.org structured data) exists to reduce ambiguity. It’s a shared vocabulary that lets machines interpret meaning more reliably than plain text alone.
Search engines have said this plainly for years. Google’s documentation describes structured data as “a standardized format for providing information about a page and classifying the page content.” (If you want the canonical definition, start at Google Search documentation for structured data; the SEJ article quotes Google’s language.)
That framing matters because it keeps you grounded in what schema is designed for:
- Confirming “this string is a product name” vs. “this string is a category label.”
- Helping connect a page to an entity (organization, person, location, product).
- Powering specific SERP features (rich results) where Google explicitly supports certain schema types and properties.
- Providing structured hints that can feed knowledge systems over time.
Schema is not a magic spell that forces an AI assistant to cite your brand. It is not a direct “ranking factor for chatbots.” And it is not a substitute for visible, corroborated on-page evidence.
Here’s the practical way to think about it:
- Schema is a label.
- Your content is the proof.
- Your reputation and corroboration are the reinforcement.
If your page has no real-world proof of a claim, schema doesn’t make the claim true. It just makes it easier for machines to read—assuming they are reading it as schema in the first place.
Where would an LLM even use schema?
To evaluate whether schema helps AI answers, you have to ask a more basic question first: where, in the pipeline, would structured data be consumed?
There are two common theories, echoed in the SEJ analysis:
- Training-time ingestion: schema is included in the data used to train the base model, so it’s “baked in.”
- Query-time retrieval: schema is used when the system fetches pages (live or near-live) to answer a question, so it affects what gets retrieved or how it’s interpreted.
Both are plausible at a conceptual level. Both are frequently asserted as fact in marketing. And both require more precision than most GEO pitches provide.
Let’s break them down in a business-friendly way.
Why “schema gets baked into training data” is a weak assumption
The “training data” argument says: if your schema is on the web, the model learns it when it trains, and then it will later “know” your facts.
This argument runs into two practical obstacles (also discussed in the SEJ piece):
1) Training pipelines usually strip boilerplate and HTML
Most large-scale pretraining pipelines are designed to extract main content and remove noise: navigation, footers, scripts, and various markup. JSON-LD schema often lives inside a <script type="application/ld+json"> block—exactly the kind of thing extraction pipelines tend to ignore.
The SEJ article cites the public description of the FineWeb dataset, which explains it extracts “main page text” using tools intended to minimize boilerplate. That’s an example of a modern, open dataset where the pipeline choices are explicit. It’s not definitive proof of what every frontier model does—but it’s a strong signal that “your JSON-LD is guaranteed to be included” is an unsafe assumption.
Business implication: even if you add schema everywhere, it may never touch the training corpus that shaped the model.
2) Even if it’s included, it doesn’t preserve “schema meaning”
LLMs learn statistical patterns over tokens. They don’t store a structured database of your business facts simply because those facts appear once on one page.
Schema’s value comes from its structure: streetAddress belongs to a PostalAddress that belongs to an Organization. But training-time tokenization flattens that into text tokens. The crisp semantics schema was designed to provide are not guaranteed to survive as “meaning” inside the model.
Business implication: even if your schema appears in training data, it’s not a reliable path to “the model will remember our phone number.”
So why can an LLM write schema markup when asked?
Because the web contains countless human-written tutorials, documentation pages, GitHub repos, and Q&A posts that describe schema in plain text and code blocks. The model can learn the pattern of schema syntax without learning your specific facts from your site’s head tags.
That distinction matters. Knowing how to format JSON-LD is not the same as trusting JSON-LD as a privileged source of truth.
Why “schema is read at query time” is often overstated
The second big theory says: even if schema isn’t “baked into the model,” AI answer systems can fetch pages and read schema at the moment a user asks a question.
There are a few versions of this claim, ranging from plausible to sloppy.
Version A: “Schema feeds the Knowledge Graph, and the AI reads the Knowledge Graph”
It’s broadly true that structured data can help search engines understand entities and relationships. It’s also true that knowledge systems can be used to power answer experiences.
But a common exaggeration is that knowledge graphs are built “live” during a user’s chat query, as if the system can resolve entities, reconcile conflicts, and create durable identifiers in milliseconds.
In reality, knowledge systems are typically curated and updated on a pipeline schedule. That doesn’t mean schema is useless. It means the promise “add schema today, get AI citations tomorrow” is not grounded in how these systems tend to work.
Version B: “Microsoft confirmed schema feeds Copilot”
The SEJ article highlights how easily the industry misquotes careful statements into stronger claims. One example raised is how conversations about Bing/Copilot, schema, and freshness can get conflated—especially when people cite headlines rather than primary quotes.
Without a primary technical spec that says “Copilot parses Schema.org JSON-LD as a privileged source at query time,” you should treat this as a hypothesis—not a guarantee.
Version C: “The AI returned info that was only in schema, so it must be parsing schema”
This is the weakest form, because it confuses format with privilege.
If an AI system fetches HTML and converts it to text for retrieval/summarization, the JSON-LD block might appear as plain text in that extraction step. If so, the model can “see” the information, even if it does not validate it against Schema.org, even if it does not understand the context, and even if the markup is invalid.
Business implication: you can get the model to repeat your JSON-LD without proving it’s treated as structured data.
Where schema actually helps in 2026 (even if LLMs don’t ‘respect’ it)
After all that skepticism, let’s be clear: schema still belongs in your stack.
Just for different reasons than the typical GEO pitch deck.
1) Rich results and enhanced search appearances
Google continues to support specific structured data types for specific enhancements (product snippets, breadcrumbs, organization details, FAQs in some contexts, etc.). The exact set of supported features changes, but the principle remains: structured data is a way to qualify for features where Google explicitly asks for it.
If you’re an ecommerce site, correct product schema and merchant-relevant markup is still one of the cleanest ways to reduce ambiguity around price, availability, variants, and reviews.
2) Entity consistency across your site
Even if a chatbot doesn’t “parse schema,” search engines and other systems do parse structured signals. Schema helps you consistently declare:
- who you are (Organization),
- what you sell (Product/Service),
- where you operate (LocalBusiness/PostalAddress),
- and which profiles corroborate identity (sameAs).
This matters because AI answers often lean on retrieved sources that themselves are search-driven. If your underlying web presence is ambiguous, you increase the probability of wrong retrieval, wrong summaries, and wrong citations.
3) Cleaner machine-readability for multiple consumers
Your website data isn’t consumed only by Googlebot. It’s consumed by:
- other crawlers,
- data aggregators,
- browser features,
- internal site search,
- and whatever retrieval systems are being built next.
Schema is a low-cost, high-discipline habit that improves the probability your information is interpreted correctly in more places over time.
4) A forcing function for internal data quality
Most SMEs don’t suffer from “lack of markup.” They suffer from:
- inconsistent addresses across pages,
- old hours,
- conflicting phone numbers,
- duplicated location pages,
- products with missing attributes,
- and vague, unprovable claims.
Implementing schema correctly forces you to standardize these facts. Even if the AI never parses it, you’ve improved your business’s informational hygiene.
What to do instead of schema theater: build citation-worthy evidence
If schema isn’t a cheat code for AI citations, what is?
In practice, AI visibility tends to follow a familiar pattern: retrieval systems select sources that look authoritative, relevant, and consistent—and then the model summarizes them.
You can’t control the model, but you can control what the web says about you and how easy it is for systems to retrieve correct, quotable passages.
1) Put the “answer” in visible content, not only in markup
If a user asks, “Do you offer emergency appointments?” don’t hide that answer in schema or a footer. Put it near the top of the relevant service page in plain language.
If a user asks, “Where are you located?” make sure the location is visible and unambiguous on:
- the location page,
- the contact page,
- the site footer (if relevant),
- and your Google Business Profile / major citations (where appropriate).
Schema can mirror the information. It should not be the only place it exists.
2) Create retrieval-friendly passages
AI answer systems often quote or paraphrase short spans of text. Make those spans easy to extract:
- Use clear headings (“Pricing,” “What’s included,” “Service areas,” “Return policy”).
- Write direct, specific sentences that stand alone.
- Use tables or bullet points where clarity matters.
- Avoid burying key facts inside accordion UI that may be poorly extracted by some systems.
3) Corroborate with external sources where it matters
If you’re in YMYL-ish categories (health, finance, safety) or regulated spaces, external corroboration matters more. So does author identity and credentials.
Schema can help connect authors and organizations, but it’s not the same as having:
- recognizable leadership bios,
- professional profiles,
- press mentions,
- industry directory listings,
- consistent reviews and citations.
4) Reduce the surface area for wrong answers
AI answers go wrong when the web is inconsistent. Common causes:
- Old PDFs outranking your current policy page
- Duplicate location pages with conflicting details
- Franchisee pages using outdated templates
- Out-of-date third-party listings
- Thin pages that don’t contain the facts users ask about
Your AI strategy should include “removing confusion,” not only “adding signals.”
5) Treat schema as part of a broader technical standard
Schema correctness still matters for the systems that do validate it. That means:
- Use valid types and properties.
- Keep it consistent with visible content.
- Don’t mark up things that are not actually on the page.
- Don’t spam it with irrelevant markup.
If you’re going to invest, invest in correctness and governance—not volume.
An SME scenario: A multi-location clinic trying to win AI answers
Let’s make this real with a scenario I see constantly.
Business: a 12-location dental group across two states.
Goal: show up when people ask AI assistants questions like “Which clinic near me offers Invisalign consults on Saturdays?” or “What’s the best emergency dentist in [city]?”
Current reality:
- Each location page has different wording and different service lists.
- Some pages show updated hours; others show last year’s hours.
- Two locations share the same phone number on the website (routing number), but Google Business Profiles show direct lines.
- Provider bios exist on a third-party scheduling tool, not on the main site.
- Schema exists, but it’s copied-and-pasted boilerplate and not aligned with on-page content.
What happens in AI answers:
- The assistant occasionally recommends the wrong location.
- It cites an aggregator listing with outdated hours.
- It answers confidently but incorrectly about Saturday availability.
The wrong “fix”: pay someone to “add more schema” and declare victory when the bot repeats an address from JSON-LD.
The real fix (what actually improves outcomes):
- Normalize location data across the site: consistent NAP, consistent hours, consistent service definitions.
- Put the facts in visible content: “Saturday Invisalign consults available at these locations” with a table.
- Create a canonical policy/service page that each location page links to (and that can be cited).
- Clean up duplicates and remove/redirect outdated pages and PDFs.
- Align schema to reality (LocalBusiness/MedicalBusiness types where appropriate; Organization; physician/dentist profiles if you maintain them; avoid overreach).
- Corroborate externally: ensure Google Business Profiles and major directories match the website; don’t let third parties become the “source of truth.”
Notice what’s missing: “schema as evidence.” Schema is there, but it’s not the centerpiece. The centerpiece is consistency + on-page proof + retrievability.
What agencies should rethink in GEO/AEO proposals
If you sell services, the schema hype cycle is tempting. It productizes well: “We’ll implement schema across 10,000 pages and you’ll appear in AI answers.”
But it’s not a responsible promise, and it sets up the wrong incentives: volume of markup instead of quality of evidence.
Here’s how I’d reset a GEO/AEO proposal in 2026.
1) Stop calling weak tests “proof”
If your evidence is “the bot repeated my JSON-LD,” that’s not evidence that schema is being parsed as structured data. It’s evidence the model saw a string and repeated it.
Better: define a test that distinguishes between:
- visible content vs. hidden markup,
- valid schema vs. invalid schema,
- corroborated facts vs. isolated facts.
Then run it repeatedly. Document failure modes. Show uncertainty honestly.
2) Replace “schema installs” with “entity clarity programs”
Schema can be one component, but the deliverable should be broader:
- Entity inventory (brand, products, locations, experts)
- Canonical pages for each entity
- Internal linking and navigation that reinforce entity relationships
- External corroboration plan (citations, profiles, references)
- Structured data that mirrors the above
3) Sell governance and deployment, not just recommendations
The modern SEO problem isn’t a lack of advice. It’s a lack of execution capacity. If your deliverable ends as a PDF, you’re not doing AEO/GEO—you’re doing theater.
Agencies that win will be the ones that can:
- monitor changes in visibility,
- identify what to fix,
- prepare changes safely,
- get approvals,
- and deploy reliably.
That’s also why “approved execution” matters. In AI-era SEO, the pace of change is higher and the blast radius is bigger.
What to monitor now: the visibility signals that matter
If the goal is AI search visibility, you need monitoring that reflects how users discover you today—not only classic rank tracking.
At minimum, SMEs and agencies should monitor:
1) Brand correctness checks
- Does the web consistently show your current name, address, phone, hours?
- Are old phone numbers still indexed?
- Are outdated policies still ranking?
2) Query-to-page coverage
- Do you have a canonical page that answers the top 20 questions customers ask?
- Are those answers visible and quotable?
3) Crawl and index health
- Are important pages being crawled and indexed?
- Are duplicates and parameters wasting crawl budget?
- Are you shipping changes that accidentally noindex key content?
4) Structured data integrity
- Is schema valid for the features you care about?
- Is it consistent with on-page content (no contradictions)?
- Is it maintained as content changes, or is it rotting?
5) Citation and mention footprint
- Where are you mentioned as a source in your niche?
- Do those mentions reflect accurate positioning and offerings?
This isn’t about chasing every new AI UI. It’s about building a stable foundation that makes you hard to misunderstand.
How AYSA helps: Monitor, Prepare, Approve, Execute (Without GEO Theater)
Here’s my blunt view: most businesses don’t lose AI visibility because they didn’t hear about GEO on LinkedIn. They lose because they can’t operationalize the work.
AYSA exists for that exact gap: we’re an execution system for SEO/AEO/GEO where the workflow is:
- Monitor your site and visibility signals
- Prepare recommended changes (technical fixes, content improvements, structured data alignment)
- Ask for approval so a human stays in control
- Execute accepted changes on the website reliably
If you want the product-level overview, start here:
And if you’re evaluating whether this is a fit operationally, pricing and packaging are here:
What this enables in the schema/AI debate is important: you can treat schema as one controlled component of a broader program. Not an isolated “install.” Not a one-time audit. A maintained system.
What AYSA does differently than “GEO advice”
- We don’t stop at recommendations. Recommendations without deployment are not strategy; they’re content marketing.
- We reduce risk with approvals. In an AI-driven rush, teams ship unsafe changes. Approval gates prevent accidental regressions.
- We focus on evidence on the page. If a claim matters to users, it should exist in visible, retrievable content—not only in JSON-LD.
- We operationalize consistency. Multi-location and large sites need repeatable templates and governance, not one-off heroics.
If you want more of our thinking (and fewer hype cycles), our editorial hub is here: AYSA Blog.
What to do next: a practical action list
If you’re an SME owner, in-house marketer, or agency lead, here’s the playbook I’d follow right now.
Step 1: Keep schema—but treat it as hygiene, not a hack
- Implement schema types that match your business model (Organization, LocalBusiness, Product, FAQ where appropriate).
- Validate it (don’t invent types or properties).
- Ensure it matches visible content.
Step 2: Put high-stakes facts in visible, quotable sections
- Address, hours, service areas, pricing ranges (if you share them), policies.
- Make them easy to find and hard to misinterpret.
Step 3: Build canonical “answer pages” for your top questions
- One strong page beats ten thin pages.
- Use clear headings and short factual statements.
Step 4: Eliminate conflicting pages and outdated documents
- Redirect or retire old PDFs and old policy pages.
- Consolidate duplicates.
Step 5: Corroborate externally (where you can)
- Keep major listings accurate (especially for local businesses).
- Ensure consistent brand identity across profiles.
Step 6: Operationalize execution
- Set up monitoring so you catch regressions fast.
- Create an approval workflow for changes.
- Deploy improvements continuously, not quarterly.
If your team can’t do this consistently, don’t blame the algorithm—fix the workflow. That’s the gap AYSA is designed to close with monitoring and approved execution: AYSA Monitoring.
Sources and further reading
- Search Engine Journal (research lead): Schema, LLMs & The Low Bar For ‘Evidence’ In GEO
- FineWeb dataset card (training pipeline context referenced in the SEJ article): FineWeb on Hugging Face
- IndexNow (mentioned in the SEJ article as part of the “freshness” conversation): IndexNow.org
- AYSA.ai: AI search visibility overview: AI Search Visibility
- AYSA.ai: Monitoring: AYSA Monitoring
- AYSA.ai: AI SEO tools: AI SEO Tools
- AYSA.ai: Pricing: AYSA Pricing
- AYSA.ai editorial hub: AYSA Blog
Final word: Don’t optimize for the story—optimize for the system
The schema debate is a great example of how the industry can get distracted by narratives that feel technical but don’t hold up under scrutiny.
Schema remains a best practice. Keep doing it. But if you want AI visibility, shift your center of gravity:
- From “signals” to evidence.
- From “markup volume” to consistency.
- From “recommendations” to deployment.
In 2026, the brands that win will be the ones that are easiest for machines to interpret and hardest for machines to misunderstand. That’s not a schema trick. That’s operational excellence—implemented page by page, approved change by approved change.
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
