- Schema helps search engines show rich features and understand entities, but it does not magically boost rankings or LLM citations on its own.
- Large language models mostly treat schema as regular text, so the body content of your page still does most of the heavy lifting.
- SameAs schema is still useful for entity building and brand validation in Google, especially for new sites.
- For LLM visibility, you get more impact from clear, direct copy and strong entity signals than from clever schema tricks.
You can think of schema as helpful markup for Google features and entity clarity, not as a secret backdoor into large language models, and once you see it that way, a lot of confusing advice starts to fall away pretty fast.
What large language models really do with schema
Let me get straight to the point, because I know you do not want a long build up here.
Right now, large language models mostly read schema like regular text in your HTML, and when they quote addresses, prices, or company details from markup that looks like structured data, they are not doing anything magical with the schema rules behind it.
They are pattern matching on strings that look like answers to the question, which sounds simple, but it has big consequences for how you should think about schema for SEO and for LLM exposure.
LLMs care far more about what your page says in plain language than about how pretty your structured data looks.
This is a bit uncomfortable if you have spent years polishing JSON-LD and testing microdata, because it means your schema is not some special AI language that only machines understand.
It is closer to a subtitle track for your page: helpful in some cases, completely ignored in others, and not a magic ranking lever on its own.
Reframing the “schema for AI” story
I keep hearing people talk about schema like it is the new secret channel into AI answers, and I think that is the wrong mental model.
It sounds nice on a slide deck, but when you test it, the story does not really hold up.
Why people thought schema was special for LLMs
The logic many SEOs followed goes something like this.
Search engines used schema to better understand entities, so AI systems must rely on it too, and if you can feed extra facts through schema, maybe you can influence how LLMs describe your brand.
On paper, that is not a bad guess, it just assumes too much about how these models actually work.
LLMs are trained on huge amounts of text scraped from the web, and when they see JSON-LD or microdata, it mostly looks like more text that happens to be formatted in a different way.
From the model’s perspective, “address”: “123 River Street” is not very different from a sentence that says “The shop is at 123 River Street.”
Both are tokens in a sequence, and both can be used as candidate answers when someone later asks, “Where is this company based?”
That is a subtle point, but it explains why some SEO experiments around schema and LLMs gave misleading signals.
The kind of test that confused people
Many people ran a version of the same test without quite realizing the weakness in the design.
The pattern often looked like this.
- Put a company address only in structured data
- Do not show that address in the visible body text
- Ask a model like ChatGPT or Perplexity for the address
- See the model answer correctly and assume it “used schema” in a special way
From the outside, it feels like proof that the system is parsing structured data, because you hid the address from users but not from Google or the LLM.
The catch is that the model did not need to understand schema as schema, it only needed to notice a pattern in the HTML that looked like an address string.
Once you accept that, a different kind of experiment suddenly becomes more interesting.
A better way to test what LLMs do with schema
Instead of feeding real structured data that happens to look like contact info, try feeding nonsense that still follows the same JSON pattern but does not exist in any standard schema spec.
Imagine something like this on a page for a fake hiking gear brand.
{
"@context": "https://example.com/mountain-schema",
"@type": "SummitProfile",
"cragName": "Ridgefire Outfitters",
"trailGrade": "Steep-Blue-3",
"baseCampCode": "BC204",
"ridgeZone": "North Crestline",
"cliffLevel": 4,
"windWarning": "High gusts near outpost",
"signalPoint": "Beacon Rock",
"countryLabel": "Highlandia"
}
None of these types exist in official schema docs, and they make no sense to search engines that care about valid structured data.
But from an LLM’s perspective, this is still a bunch of tokens that look like labels and values that could be copied into an answer if they appear relevant.
If you then ask the model, “What is the base camp code for Ridgefire Outfitters on this page?” and it replies with “BC204, near Beacon Rock in North Crestline, Highlandia,” it has not done anything schema-aware.
It has just pattern matched on the text that sat in your HTML, which is what these more careful tests keep showing.
What this means for SEO: Google vs LLM behavior
Once you separate Google’s treatment of schema from an LLM’s treatment of schema, your strategy changes quite a bit.
You stop asking, “How do I inject stuff into AI answers with markup?” and start asking, “Where does schema still help, and where is it just extra decoration?”
How Google search tends to use schema
Google has been pretty clear about how it sees schema, and I think a lot of people quietly ignore it because it is not as exciting as what they hoped.
Schema mainly helps Google trigger rich results and understand entities, not push your rankings up by itself.
| Schema use case | What Google does | Impact you actually feel |
|---|---|---|
| Product schema | Shows price, stock, ratings in SERPs when it trusts the data | Better click through rate on commercial queries, no direct ranking push |
| FAQ / HowTo schema | Can show expandable answers or step snippets when eligible | More SERP real estate, sometimes fewer clicks if users get answer on Google |
| Organization / Person + SameAs | Helps tie your site to known entities across the web | Stronger entity understanding and trust, especially for new brands |
| Event / LocalBusiness | Can show event cards, local rich results when the data is clean | More visibility for searches with local or time intent |
Notice what is missing here.
There is no special “rank boost” column, because Google has stated multiple times that structured data does not push your rankings up on its own.
Schema helps Google show your result in richer formats, and if that improves engagement, the indirect gains can matter more than the markup itself.
That is a boring message compared to some AI SEO pitch, but it is the one that keeps matching real-world data.
How LLMs treat your page instead
When an LLM crawls or fetches your page at query time, it usually cares about one thing above everything else.
The body text.
Not the meta keywords, not some clever schema trick, not a tiny hidden block in the footer.
The big, obvious, visible copy users can read.
When I have tested pages with heavy schema and weak body copy, the model answers tend to follow the weak copy, not the rich markup.
When I switch it and write much clearer, more direct explanations in the main content, the answers improve, even if I delete most of the structured data.
That should shape where you put your time.
So is schema “useless” for LLMs?
No, and this is where I think some takes go a bit too far in the other direction.
Schema is not useless, it is just not special in the way many people claim.
- Everything in your JSON-LD is still text the model can see
- If you add unique details there, they can still appear in answers
- But the model is not validating your types or following schema.org rules
So if your mindset is “I will hide secret facts in schema that only AI can read,” that is risky, and some of it veers into cloaking territory if you intentionally mislead Google search.
But if your mindset is, “I will keep my structured data consistent with my visible content so both Google and LLMs see the same story,” that is sane.
The more your schema mirrors what a real person can read on the page, the safer and more reliable your setup is.
When those two drift apart, you are building fragility into your SEO, and sooner or later something tends to break.
How I would actually use schema right now
Let me push back a bit on the idea that schema does not matter at all, because I think that overcorrection can be just as harmful as overhyping it.
You are not wrong to care about structured data, you are only in trouble if you expect it to do a job it cannot do.
1. Use schema when the SERP already rewards it
I see people adding every schema type they can think of across their sites, even when those rich features never show up for their keywords.
That is backwards.
- Pick your key search terms
- Look at the top 10 organic results
- Note which rich features appear over and over
- Check which schema types those sites use
If you see product ratings, prices, or FAQ expanders consistently, matching that pattern makes sense.
If the whole page of results is plain blue links with no extras at all, loading up your page with exotic markup is unlikely to change that.
Google ignores plenty of schema types in many result sets, and throwing more markup at the page will not force a feature to appear.
2. Treat SameAs as an entity glue, not a trick
SameAs schema is one area where I still put real effort in, especially for brands that do not yet have a solid identity in Google’s knowledge systems.
I like to think of it as a way to confirm to Google, “These profiles are about the same entity you just crawled on this domain.”
- For a person: link your main site, LinkedIn, YouTube, podcast site, and maybe an About.me profile
- For a company: link your site, main social pages, Crunchbase or similar, and a strong About page that links to secondary profiles
The mistake I see is people stuffing dozens of low-value or half-abandoned profiles into SameAs and hoping more links equals more trust.
In practice, Google is most likely to care about a smaller set of high-signal sites it already knows.
I would rather see you pick 5 to 10 strong, active, consistent profiles than 50 barely alive listings that feel spammy even to a human.
3. Keep entity info in schema and on the page
Something I disagree with in many “schema-heavy” setups is the habit of hiding key entity data only in JSON-LD.
Your brand name, founding year, location, leadership, and core products should live in the normal visible content as well.
Think of your About page as the single source of truth, then mirror that in your Organization or Person schema on that same URL.
If that page clearly states, “Northshore Analytics started in 2018 in Vancouver and now works with clients in Canada, the US, and Europe,” then your schema can echo that with structured properties.
When both match, you are reducing ambiguity for Google and for LLMs that later read the page.
4. Do not rely on hidden schema for LLM influence
I know it is tempting to hide special messages in schema in the hope that AI systems will surface them, but this approach is clumsy and has real risks.
For example, some teams try to put soft promotional language or custom positioning lines inside their structured data and keep the page copy more neutral.
Yes, an LLM might pick that up as part of the text if it crawls the page, but it is hard to predict and easy to abuse.
If your hidden text starts conflicting with what appears on the page, you get into a gray area where search engines might see that as deceptive, especially at scale.
And from a brand point of view, do you really want an AI agent quoting a line that does not match what users see when they click through?
5. Focus schema efforts where the business impact is high
Instead of trying to cover every possible schema type, pick a few that sit close to revenue.
- Ecommerce: product, offer, review, and breadcrumb schema where rich results are visible
- Local services: LocalBusiness, opening hours, and review schema to support local packs and rich snippets
- B2B with long cycles: Organization and Person with clear SameAs links to build entity strength and surface knowledge panels over time
- Content-heavy sites: article and breadcrumb schema where Google tends to reward them with nicer snippets
This is not glamorous, but it lines up your technical work with things a CFO or founder can actually feel.
Getting more value from schema when LLMs act like text hoovers
Now let us lean into the part that many people are missing: if LLMs treat schema mostly as text, you can make smarter decisions about how and where to feed them information.
You do not need conspiracy theories, you just need to write for a model that skims everything and prefers clarity.
Design your content as if a machine is skimming it fast
Large language models have a limited context window, which means they will not read your 8,000 word page as carefully as you wish.
They grab parts of the HTML, process them, and answer based on what stands out as most relevant and clear.
- Put key facts near the top of the page
- State important details in plain language, not only in schema
- Repeat core facts in a natural way, without keyword stuffing
- Use headings that describe what follows in simple terms
This sounds basic, but I keep seeing pages where the only mention of the company’s main service area is buried in a footer block or a schema script.
Humans scroll fast and miss it, LLMs skim fast and miss it, and then everyone wonders why the brand is misclassified.
Use schema and body copy together for complex details
There is one area where schema can still help LLMs indirectly, and I think it is underused.
Complex concepts that are hard to describe cleanly benefit from multiple, consistent versions.
For example, say you run a subscription analytics tool and your pricing is tricky, with minimum commitments and billing thresholds.
You can describe the pricing tiers in normal copy at the top of the page, then also include structured data that labels those tiers, currencies, and billing intervals.
When an LLM crawls that page, it sees the same core facts encoded twice in different forms.
That repetition, if it is consistent, tends to reduce confusion when the model later summarizes your plans.
Test how LLMs quote your structured and unstructured content
Rather than guessing, you can run your own small tests without relying on anyone else’s case studies.
- Pick one key service or product page
- Check the current schema and on-page copy for that URL
- Ask a few LLMs: “Describe this company and what it offers,” giving the page link
- Note which facts the models mention and which they miss
Then make a few controlled changes.
- Clarify the top 3 facts you want highlighted in the body text
- Mirror those facts in your schema where it makes sense
- Wait for recrawling and test again a few days later
You will usually find that clearer body copy shifts the LLM summary more than fancier structured data.
But when the two are aligned, the answers feel less random and you get fewer odd misreadings.
A quick example without copying your competitor’s ducks
Your competitor used a fictional duck company, so let us pick something different and a bit more boring on the surface: a made-up repair shop called “Metro Circuit Repair.”
Here is a toy example of strange JSON on that site.
{
"@context": "https://example.com/device-schema",
"@type": "CircuitClinic",
"shopAlias": "Metro Circuit Repair",
"fixZone": "Central District",
"benchCode": 14,
"solderLevel": "Precision-3",
"sparkRating": "Low",
"careNote": "Handle boards with anti-static gloves",
"dropPoint": "Unit 14, Cable Row",
"regionLabel": "Central District",
"cityName": "Harborview",
"countryName": "Northland"
}
None of these types exist in official specs, and some of the labels are odd, but the values look like real phrases an LLM might treat as address-like or location-like.
If you ask a model, “Where is Metro Circuit Repair located according to this page?” it might respond with something like, “Unit 14, Cable Row in Harborview, Central District, Northland.”
That does not prove it “understands” CircuitClinic as a schema type.
It only proves that if you put text in the HTML that looks like an address, the model can lift it, even when your schema is made up.
This is why I do not buy the argument that making your schema more elaborate will earn you some special place in AI answers.
Yes, sometimes the body text beats everything else
One thing that crumbles a lot of fancy schema strategies is a simple observation: when the body content conflicts with the schema, LLM answers tend to follow the body.
If your JSON says you have 10 offices worldwide, but the About page says clearly, “We operate from a single office in Toronto,” the model is more likely to repeat the Toronto version.
The visible copy has more weight because it looks like what the user trusts.
This is another reason hiding big claims in structured data is a bad habit: even when it is not against guidelines, it often just fails silently.
If you would not be comfortable saying it in the first few paragraphs of your page, do not rely on schema to whisper it to the AI for you.
It sounds harsh, but it is a useful filter when you plan your markup strategy.
Where schema still fits in your SEO and AI strategy
By now you probably see a pattern: schema still has a solid place in your toolkit, just not the mystical one some people describe when they talk about generative search or “AI-first SEO.”
If you strip it down to what survives testing, the picture is simpler and, I think, more practical.
What I would keep doing with schema
Let me be concrete for a second, because broad advice can feel vague and hard to act on.
- Match the schema types that are already triggering rich results in your target SERPs
- Use Organization / Person + SameAs to tie your site to a small set of strong external profiles
- Mirror key entity facts in both your body content and your structured data
- Keep your markup lean, valid, and focused on data that actually helps users
This is not glamorous, but it compounds well over time and tends to survive Google updates without drama.
What I would stop expecting from schema
On the flip side, a few common hopes need to be retired or at least downgraded a bit.
- Stop expecting schema alone to push your rankings up
- Stop assuming LLMs treat schema as some privileged channel
- Stop hiding aggressive claims only in JSON-LD and hoping AI will echo them
- Stop copying every micro-trend in structured data when your SERPs do not reward it
When you remove those expectations, you get a more honest picture of where to spend your time: on content users can read and on technical fixes that actually change how your site is crawled and rendered.
How to think about LLMs and schema going forward
LLMs are getting better at reading and recalling web content, but they are still pattern recognizers trained on text, not specialized schema parsers.
That might change in the future with more structured, tool-based systems, yet right now, betting heavy on schema as your AI moat is risky.
A more grounded approach is to treat schema as one more way to make your story consistent across formats.
Write clear, direct copy that answers the questions your audience and AI systems both care about, then support that with tidy, accurate structured data where it helps with features and entity clarity.
When your body content, schema, and external profiles all tell the same simple story, both Google and LLMs have a much easier time representing your brand correctly.
That is not as dramatic as promising secret AI traffic hacks, but it will hold up better over the next few years, and it keeps you focused on the part you can control: what your site actually says.
If you get that part right, schema stops feeling like a magic trick you are missing and starts feeling like what it really is, a helpful layer on top of strong content, not a replacement for it.
Need a quick summary of this article? Choose your favorite AI tool below:
