Schema, LLMs and the Low Bar for “Evidence” in GEO

I built a fake company with nonsense schema. The LLMs returned the address anyway. That is not the win the GEO industry thinks it is.

TL;DR

I ran a small experiment to try and get some insight into whether Large Language Models actually parse schema markup or are just nodding politely in its direction. I put a fake company address (inside beautifully invalid JSON-LD, on a page about ducks) into the head of an HTML document, mentioned no address anywhere in the visible text, and then asked various LLMs where the company was based. They happily told me, several of them citing the “structured data” they had so studiously consulted.

The experiment was then picked up by Search Engine Roundtable, at which point British sarcasm met the LinkedIn carousel, the two annihilated each other in a small puff of smoke, and a chunk of the GEO community came away convinced I had just proved that LLMs are lovingly parsing schema exactly as Schema.org intended.

The guilty LinkedIn post that was patient zero of schema confusion

I had arguably proved the opposite. The schema was deliberately broken. The LLMs returned the data anyway, because as far as they were concerned, the JSON-LD was simply more text on the page, lightly garnished with curly braces. That distinction is the whole point, because a growing cohort of “GEO experts” are pointing at “the LLM returned information that was only in the schema” as cast-iron proof that LLMs are using schema as designed. They are doing nothing of the sort. They are reading the HTML and shrugging at the structure.

I am not professing schema is worthless. I think you should still use it. But the way it is currently being sold to clients (as a magical injection of LLM citations) is propped up on a remarkably thin pile of evidence, and I want to walk through why.

A quick refresher on what schema is actually for

Schema, or Schema.org structured data, is a collaborative vocabulary built by Google, Microsoft, Yahoo and Yandex to let webmasters embed machine-readable information on their pages. The clue is in the name. It is a schema. A shared, agreed structure that lets a machine know that “Mark Williams-Cook” is a Person, that he works at an Organization called “Candour”, and that the string “01603 957068” sitting in his profile is a telephoneNumber and not, for instance, my weight in grams.

Google’s official documentation puts it about as plainly as Google ever puts anything: “Structured data is a standardized format for providing information about a page and classifying the page content.” Google also says it uses structured data “to understand the content of the page, as well as to gather information about the web and the world in general, such as information about the people, books, or companies that are included in the markup.”

The whole point of schema is to remove ambiguity. Natural language is messy. “Apple” is a fruit, a company, a record label and probably the surname of someone’s gerbil. If you tell a search engine in plain English that you sell Apple, it has to guess. If you tell it in schema that you sell an Organization called “Apple Inc.” with sameAs linking to Apple’s Wikipedia page, that ambiguity collapses to nothing. That is the job. Disambiguation. Explicit clues. Machine-resolvable identity. It is, basically, a polite contract between you and a machine saying “let’s both agree what this word means, just this once”.

Where does the ambiguity actually get resolved? In Google’s case, into the Knowledge Graph, the giant entity-and-relationships database that powers knowledge panels, “people also ask”, entity carousels and a hundred other surfaces. Schema is one of the inputs. It is not the only input, and it has never been the only input. But it is a clean, explicit, low-noise one, which is why search engines like it.

Right. That is what schema does for search engines. Now to LLMs, which are a different animal in nearly every way that matters.

Where, exactly, would an LLM even use schema?

There are two camps in the LLM/schema debate, and most arguments collapse into one of them.

Camp 1: Schema is hoovered up during the training of the model and ends up “baked in” somehow.

Camp 2: Schema is read at the moment the LLM live-fetches a page (during retrieval at query time, or via crawls that feed retrieval).

Let’s take them in turn, with appropriate scepticism.

Camp 1: schema gets into training data

I have written about this before, and it was covered by Search Engine Roundtable last year. The short version is that this is the most popular theory and also the one with the weakest mechanical case behind it. There are two problems, and neither of them is small.

Problem 1: schema is almost certainly stripped before training

If you have not gone down the rabbit hole of how base LLMs are actually made, Andrej Karpathy’s three and a half hour deep dive on LLM pre-training is the canonical reference, and yes, three and a half hours is the deal.

Pre-training pipelines do a lot of unglamorous cleaning work before a single GPU sees the data: URL filtering, language filtering, deduplication, removal of personally identifiable information, and crucially, stripping out HTML and boilerplate. The goal is not to preserve the page. The goal is to extract clean prose that helps the model build a useful probability distribution over language. The more noise (markup, navigation, footers, scripts, JSON-LD, your cookie consent banner) you leave in, the worse the resulting model. So they don’t.

The widely used FineWeb dataset (15 trillion tokens, derived from 96 Common Crawl snapshots) is refreshingly explicit. Their pipeline extracts text from the WARC files using trafilatura, a library specifically chosen because it produces “the main page text” with “less boilerplate and menu text” than the alternatives. The data card states: “We then extracted the main page text from the HTML of each webpage, filtered each sample and deduplicated each individual CommonCrawl dump/crawl.” JSON-LD lives in a `<script>` tag. Trafilatura is, by design, deeply uninterested in `<script>` tags. The unavoidable inference is that JSON-LD does not make it into the training corpus at all. It is binned with the analytics snippets, where it has been keeping good company.

You might reasonably ask: then how can ChatGPT write schema markup for me when I ask it? Because there are millions of examples of schema in visible prose across the web. Tutorials. Documentation. Forum posts. GitHub repos and Stack Overflow answers. Code blocks in blog posts. The model learns what schema looks like the same way it learns what a Python function looks like, by reading endless explanations of it, written by humans, in paragraphs. The schema on your actual product page, sitting silently in the head of the document doing its proper job, gets thrown straight out.

Problem 2: even if it survived, it would not work the way you think

Let’s be generous and stipulate that some non-trivial amount of raw schema does sneak into a model’s training data. We do not actually have full transparency from frontier labs about what they ingest, and the courts have not exactly been kind on this point. Meta’s training pipeline is currently being picked apart for allegedly using LibGen, a pirate library of around 7.5 million copyrighted books. If the frontier labs are happy to swallow other people’s novels whole, they are probably not above swallowing the odd <script type=”application/ld+json”> along the way.

Even if this was the case and our precious JSON-LD schema made it into the training data, it would not be unscathed.

Here’s the catch: The model does not memorise pages. It does not have a little filing cabinet labelled “Candour Agency Ltd” with the address tucked inside. What actually happens is this:

1. All the text in the training corpus gets chopped into tokens (chunks of characters, often parts of words).

2. The model is shown billions of small windows of tokens and asked to predict the next one.

3. Each time it gets it wrong, billions of tiny numerical weights inside the network are nudged so it would do slightly better next time.

4. After enough nudging, those weights collectively encode a (lossy, blurry, statistical) impression of which tokens tend to follow which other tokens, in what contexts.

That is what is stored. Weights. Not facts. Not addresses. Not your postalCode. A glorified probability distribution that has read a great deal and remembers, with the same fidelity as someone trying to recall the lyrics to a song they last heard in 2011, which words usually follow which other words.

Your beautiful schema, being Dahmerfied.

This is where schema specifically falls apart. The whole point of schema was to take a string like “77 The Muddy Bank” and tag it explicitly as a streetAddress belonging to a PostalAddress belonging to your Organization, so a machine cannot mistake it for anything else. When that JSON-LD is tokenised, the structure dissolves. The string “@type”: “Organization” becomes a sequence of tokens including @, type, :, Organization, completely indistinguishable, to the model, from the same word soup appearing in any blog post about schema. The disambiguation, which was the entire reason for using schema in the first place, is the very first thing thrown out by the very first stage of training. Marvellous.

Worse still, an LLM only “recalls” a fact if it has seen it many, many times. A single mention of your address on a single product page is a vanishingly small drop in a fifteen-trillion-token bucket. Even if it survived ingestion, you would also need the model to encounter your streetAddress enough times that those particular weights actually settle into a useful pattern. For >99.99% of businesses, that does not happen. The fact is not stored. It will not be recalled. You are paying a consultant to whisper your postcode into a hurricane.

So if you are buying the “schema gets baked into the model” theory, you are buying improbabilities in a trench coat: that it survives pre-training cleaning, that it survives tokenisation with its structure intact, and that it gets repeated often enough across the web for the model to actually “learn” it. None of the three is obviously true.

Camp 2: schema gets read at query time

I’ve experienced that it is rare for any LLM/schema proponents to want to discuss training data involvement once it has been gently set on fire. The argument tends to move quickly onto the possibility that schema is not in the model itself, but is read at the moment a user asks a question, when the LLM fetches the page in real time. Let’s examine the three flavours of this argument in increasing order of confidence and distressing level of inaccuracy.

Flavour 1: "Schema feeds the knowledge graph"

Google’s Knowledge Graph is a vast, curated, slow-moving database of entities and relationships. It is fed by structured data, Wikipedia, Wikidata, freebase legacy data, and a hundred other signals. It is built and updated by Google’s pipelines on Google’s schedule. It is not assembled on the fly when someone types a question, no matter how briskly they type.

The notion that an LLM “builds a knowledge graph in real time when pages are fetched” sounds a lot less reasonable when you say it out loud into the mirror. Knowledge graphs are constructed entities. They have IDs. They have relationship cardinality rules. They have to be reconciled against existing entries so you do not end up with three drifting “Apple Inc.” nodes filing different tax returns. None of that happens between a user pressing enter and the answer appearing on screen. It cannot. There is not enough time, and there is no infrastructure exposed in the chatbot product to do it.

So if an entity-resolution pipeline exists at any of the frontier labs, it is being built upstream, on a similar cadence to Google’s, and not during your conversation. Which is fine, but it does not match the breathless claim that “your schema feeds the LLM’s brain”. Conceptually, the strongest version is closer to “your schema may eventually feed a curated database that the LLM might one day consult”. Which is a much weaker claim, and one for which there is, at present, no public evidence whatsoever.

Flavour 2: "Microsoft confirmed schema feeds Copilot"

Misquoted to an industrial scale, Search Engine Land’s write-up ran under the headline “Microsoft Bing/Copilot use schema for its LLMs”, in which Fabrice Canel of Microsoft was reported to have “confirmed” that schema markup helps Microsoft’s LLMs. Cue half of LinkedIn pasting the headline as proof, often without troubling the body copy.

If you read the actual quote, it is about IndexNow:

“Gen AIs value fresh content in particular, partly as a reference check of their LLM training data. Use the API at indexnow.org to push that information as it’s published or updated.”
~ Fabrice Canel

It is “your page changed, here is its new state, please come look”. Fabrice was making a point about freshness (telling search engines when your content has changed so they can update their understanding) and not a point about JSON-LD being deferentially parsed by GPT-flavoured systems. Conflating the two is a textbook example of the industry’s favourite parlour trick: take a careful claim about one thing, sand the edges off it, and resell it as a bold claim about something else entirely.

Flavour 3: "LLMs return information that was only in the schema, therefore they use schema"

This is the one that prompted the experiment. It is also the single most-cited piece of “evidence” in GEO LinkedIn posts, and the most easily falsified once you spend half an afternoon thinking about it.

I built a deliberately silly test page about a fictional duck t-shirt company called DUCK YEA at i83.uk/duckyea.html. The visible content of the page mentions no address. Tucked into the head of the HTML, inside a <script type=”application/ld+json”> tag, sat the following:

{
“@context”: “http://api.the-great-pond.net/schema”,
“@type”: “MallardEnterprise”,
“flockName”: “DUCK YEA T-SHIRTS”,
“waddleStyle”: “Aggressive”,
“nestingGrounds”: {
“@type”: “LilyPadAddress”,
“reedNumber”: “77”,
“puddle”: “The Muddy Bank”,
“region”: “South Pondshire”,
“featherCode”: “DK99 YEA”,
“country”: “United Queendom”
},
“migrationPattern”: “Non-Migratory”,
“quackVolume”: “Loud”
}

A few things to notice. The @context is a made-up URL that does not resolve to anything (the great pond, sadly, has no API). The @type is not a valid Schema.org type. Not a single one of the properties (flockName, waddleStyle, nestingGrounds, reedNumber, puddle, featherCode, quackVolume) exists in the Schema.org vocabulary. The JSON is syntactically valid JSON, but as far as Schema.org is concerned this is unmitigated nonsense, the digital equivalent of someone speaking French very loudly while only knowing the words for “cheese” and “weasel”. A well-behaved schema-aware parser should look at this, sigh, and ignore it.

I then asked ChatGPT and Perplexity, “what is the address of this company?”, pointing at the URL.

Both happily returned: Reed Number 77, The Muddy Bank, South Pondshire, DK99 YEA, United Queendom.

Perplexity even helpfully volunteered that it had found the answer “in the page’s embedded structured data”, with the satisfied air of a student who had clearly read the prescribed material. Neither of them flinched at the fact that none of the schema was real, because (and this is the entire point of the exercise) they were not parsing it as schema. They were doing what LLMs always do: reading the visible-ish text of the page, picking out the bit that looked like an address, and presenting it. The JSON-LD wrapper was, to the model, just slightly weirdly-punctuated prose. If I had wrapped the address in <marquee> tags and surrounded it with ducks emoji, it would have made precisely no difference.

If LLMs were genuinely parsing JSON-LD with any reverence for the Schema.org vocabulary, my made-up types and properties would have been rejected, or at the very least flagged. They were not. The information was just lifted straight out of the HTML, dusted off, and served up with confidence. Quack. 🦆

In the interest of not committing the exact sin I am accusing the GEO crowd of: the duck experiment proves that LLMs returned content from a JSON-LD block with a made-up @context, a made-up @type, and no real Schema.org properties. What it does not, on its own, prove is that LLMs ignore schema entirely. A system that consulted schema and fell back to text extraction would produce the same answer here.

If you run the same query today, you get a slightly different result:

LLMs now get the answer ‘correct’, without ever knowing it was wrong

The model now (correctly) flags that this is a test page made by some SEO bloke, charmingly demonstrating the AI Convergence Problem doing its thing in real time: enough people have written about the experiment that “DUCK YEA is a joke page by Mark Williams-Cook” is now getting pulled during RAG, and the consensus answer has overwritten what would otherwise be a clean test. The address is still being read from the HTML, schema validity be damned. The model has just learnt to caveat it. Which is, in a small and slightly bleak way, progress.

Conjecture: could LLMs be using schema, somehow, somewhere?

The honest answer is that we do not know what is happening upstream at OpenAI, Anthropic, Google DeepMind, xAI and the rest, because they are not telling. Google itself is a sprawl of separate systems (the index, re-rankers, glue, the knowledge graph, AI Overviews, AI Mode) which all work together to produce what looks, from the outside, like a single coherent answer, and on a good day actually is one. There is no reason in principle why an LLM provider could not run an entity-extraction pipeline against the web, build its own entity store, and consult it at answer-generation time. That is conceptually adjacent to how retrieval-augmented generation (RAG) works, and it is the kind of thing you would absolutely build if you were OpenAI and you wanted to stop your model confidently inventing the wrong CEO.

If they are doing that, schema is an excellent and obvious input. It is explicit, structured, low-noise, and already widely deployed. It would be daft for them not to use it.

But here is the big “but”. We have no published evidence, no leaked papers, no public confirmation, and no behavioural test result that any frontier LLM is actually doing this yet. Reasoning forward from “they probably should” to “therefore schema is worth £20k of consultancy this quarter” is exactly the kind of fact-light, vibe-heavy thinking that the discourse needs less of. Make the case, by all means. But label it conjecture, not evidence. Use a different font.

Google still hasn’t solved this problem reliably

There is also a slightly awkward elephant standing quietly in the corner of the room. If anyone on earth were going to crack the “feed an entity-resolved knowledge graph into an LLM’s answer pipeline” problem first, it would surely be Google. They have over a decade head start on entity extraction approach. They have the Knowledge Graph. They have Google Business Profile, which is a user-edited, structured, ostensibly authoritative database of business information. They own the model (Gemini). They own the surface (AI Overviews). They own the search index that wraps around it. Every page on the planet eventually walks past one of their crawlers. If joining structured business data to LLM output is supposed to be the obvious next step in the human story, Google has every conceivable advantage in being the one to demonstrate it.

And yet:

Google contradicting itself in spectacular fashion

That is a single Google search result page. On the left, Google’s AI Overview confidently asserts that Perrys Dover Mazda is “not closed”, lists the address, and helpfully provides opening hours, presumably so you can pop down and have a look at the cars that are no longer there. On the right, on the same page, the Google Business Profile knowledge panel for the exact same business is labelled “Permanently closed” in a large, unambiguous red banner. Google Business Profile data is structured. It is user-edited. It is the closest thing Google has to a verifiable, authoritative source on whether a business is, in fact, open. And the AI Overview, generated on the same SERP, by the same company, in the same session, is not consulting it. They are two organs of the same body that have not been on speaking terms for some time.

If the company with the longest possible head start, the most structured data, the most obvious commercial incentive, and full vertical integration over every part of the stack cannot reliably wire its own business-hours database into its own AI answers, the idea that OpenAI or Anthropic have quietly built a richer entity pipeline that does defer to your Organization schema is, let us say, optimistic.

So... should you still use schema?

Yes. Just for the right reasons and the right price.

Schema is, in the grand scheme, still a stopgap. It exists because the technology cannot yet reliably read human language without ambiguity, and structured data is how we paper over the gap while the engineers work out how to read English properly. Gary Illyes from Google, speaking at an SEOFOMO meetup in 2025, pointed out (paraphrasing) that it would be lovely if Google did not have to rely on schema at all, because in an ideal world the systems would simply understand the page. Schema buys you a bit of certainty in the meantime, which is worth something even if it is not worth the consultancy invoice you may have been quoted.

The recent Ahrefs study, which tracked 1,885 cited pages that newly added JSON-LD and matched them against 4,000 controls, found that schema had essentially no effect on AI citations across ChatGPT, AI Mode and AI Overviews. That sounds damning, and a number of LinkedIn carousels are already enjoying themselves accordingly. But as Gianluca Fiorelli pointed out in his excellent critique, the study tested pages that were already being cited heavily by AI (every page in the dataset had 100+ AI Overview citations before treatment). That is the worst possible population to test schema on, because these are already strong, well-understood entities. Schema’s job is to disambiguate. If the system can already resolve who you are with high confidence, adding Organization schema is solving a problem the page does not have. You don’t introduce yourself by name to your own mother.

The interesting case, and the one nobody has properly tested, is the new and challenger brands, where the entity footprint across the web is thin and the system cannot yet confidently say “this company is the company you mean”. For those, schema is infrastructure. It is how you become a resolvable node in the graph in the first place. It does not buy you a citation today. It earns you the right to be one of the candidates tomorrow, which, in a world where being a candidate is suddenly the only game in town, is no small thing.

Takeaways

A few practical thoughts, dressed down for tactical use:

• Still use schema. The implementation cost is low, the downside is essentially nil, and the upside is cumulative. If schema does end up being meaningfully ingested at any stage of the LLM stack (and it might), the work is already done and you can be smug about it. Free smugness is the best kind.

• Stop selling schema as a magic LLM citation lever. The current public evidence for LLMs using schema “as intended” at query time is, frankly, weak. Anyone telling a client otherwise should be politely asked to show their working, in front of other people, with a whiteboard.

• Be ruthless about the bar of evidence. “An LLM returned a fact that appears in the schema” is not evidence the schema was used. The same fact almost always appears in the HTML, the metadata, the page title, the social card, or somewhere a token predictor would gleefully pick it up. The duck experiment matters precisely because the schema was invalid and the LLMs returned the answer anyway. If your “proof” survives that test, talk to me. If it doesn’t, please stop putting it on slides.

• Focus schema investment where disambiguation actually matters. New brands. Brands with name collisions. Organisations without a knowledge panel. Personal entities that overlap with other people who share their name and have been more famous for longer. That is where the asymmetric upside lives.

• Treat “GEO best practice” the way you would treat any other new SEO orthodoxy. Sceptically, with experiments, and with a willingness to revise the position when the evidence changes. The car-wash-grade reasoning on LLMs, where the popular answer just gets repeated until it sounds true, is alive and thriving in our industry too.

Schema is a useful, low-cost, long-lived bet. It is also not the thing that is going to single-handedly drag your brand into ChatGPT’s answer set. Use it. Just do not oversell it. And for the love of god, before you build a deck around “LLMs returned the content from schema, therefore they use schema”, run the experiment with a deliberately nonsense schema first. You may be surprised what the duck tells you.

Further reading and references

• Schwartz, B. “ChatGPT & Perplexity Treat Structured Data As Text On A Page”, Search Engine Roundtable, Feb 2026.

• Schwartz, B. “Structured Data Does Not Help With Visibility In AI Search”, Search Engine Roundtable, Sep 2025.

• Williams-Cook, M. “The AI Convergence Problem”, 2026.

• Schema.org, “About”.

• Google Search Central, “Introduction to structured data markup in Google Search”.

• Google, “Knowledge Graph Search API”.

• Karpathy, A. “Deep Dive into LLMs like ChatGPT”, YouTube, 2025.

• Penedo, G. et al., “The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale”, 2024.

• Authors Guild, “Meta’s Massive AI Training Book Heist: What Authors Need to Know”, 2025.

• Schwartz, B. “Microsoft Bing/Copilot use schema for its LLMs”, Search Engine Land, Mar 2025.

• IndexNow, indexnow.org.

• Linehan, L. & Guan, X. “We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.”, Ahrefs Blog, May 2026.

• Fiorelli, G. “The Ahrefs Schema study is right. And it’s testing the wrong thing”, iloveseo.net, May 2026.

• SEOFOMO, “What’s new in SEO + AI Search? Read SEOFOMO June 15, 2025”.