Industry gospel says that schema helps optimize for AI Search, but does it?
We had an eye-opening experience helping a client who had JavaScript rendered content. ChatGPT wasn’t “seeing” their events, and therefore, had incomplete and incorrect data when asked. The event data lived in a table that was rendered via JavaScript on pageload. However, AI bots don’t render JavaScript, therefore the content was invisible to them.
The client had the idea to add the event data as JSON schema. My response to their idea was a supportive, “great, yes, that’s a smart workaround. AI likes structured data so that should ensure they see your event information.”
After the schema was added, we ran some tests with Claude and it was insistent the schema wasn’t there. After more and more attempts, it finally launched Claude in Chrome and confirmed the schema was present. A relief, but it exposed a feature of how their native web fetch works:
- When ChatGPT, Claude, and Gemini fetch a page, they strip all scripts, including JSON-LD
This finding had us wondering, under what conditions, if any, does an LLM interact with JSON schema on your webpage. To answer this question, we designed a research study to determine what factors lead to different models – Claude, ChatGPT, and Gemini – retrieve schema when they fetch a page.
Here’s the chain of events that kicked off our skepticism of schema and its role in AI search
Below is a step by step account of a deep rabbit hole I went down, which was kicked off by this client’s JS-rendered content.
- First, I looked at the page in the browser by disabling JavaScript. Nothing. Empty. The events table didn’t exist, which also confirmed it was rendered with client-side javascript.
- Next, I asked Claude, “Hey, fetch this page and tell me if you can see the events table.” At first, it said yes, but it was using Firecrawl to fetch the page, not its default fetch tool. Once it used its default browser fetch, it confirmed what I found first, no events.
- I wrote to the client and reported our findings that those events are likely invisible to most LLMs during a standard fetch request.
- Their plan was to add Event schema via JSON-LD to the page, and I thought this was a good idea. Everyone knows that schema is good for AI optimization. LLMs may not be able to see the events table, but they’d see the Events schema and get the information that way. Solid plan.
- After they added the Events schema, we checked the page again with Claude. Claude kept telling me it didn’t see the schema. I was perplexed and skeptical. See Claude’s response after multiple asks to check for it.
I checked, and I'm not finding it. Two separate cache-busted scrapes of the fully JS-rendered HTML (5-second render wait, maxAge: 0), then searched the raw source for every form structured data can take:
application/ld+json — 0 matches
schema.org — 0 matches
@context / @type / @graph — 0 matches
itemprop / itemscope / typeof= (microdata, RDFa) — 0 matchesWhat’s funny is Claude thinks it should be able to see the schema, too. It later asked me, “Did they deploy it on a different page?” and “Is it configured but not deployed?”
After insisting the Events schema was present, it launched the Claude Chrome extension and confirmed it did indeed exist. But that’s a problem, right? If Claude can only see JSON-LD schema using Chrome as an Agent (or now in its built-in browser), then what are we optimizing for?
At this point, I’m feeling untethered. My gears are turning, wheels spinning. If LLMs can’t see schema when they fetch a page, then what use does it have for AI optimization purposes? During training runs, our understanding is that scripts are dropped and the content is extracted and tokenized, meaning, JSON-LD wouldn’t impact training either. At least not directly.
As my mind is spinning, I remember the client saying the Events schema was “injected” onto the page. Could it be that the method of schema insertion matters? Could Claude and other LLMs see it if we made the JSON-LD more accessible? SEJ has a published article on this topic, but at this point, I trust nothing so our next step was to design an experiment to see under what conditions (if any) LLMs parse JSON schema.
The experiment we created to test whether AI can see schema
Our idea was to build a static HTML webpage that deployed structured data multiple ways to see which methods resulted in the AI tools being able to “see” it on page fetch. We worked with Claude to help build out a quick web page and design the experiment parameters.
Within the webpage we hid 14 different markers (we’re calling them “canaries”) in the HTML to see under what conditions the schema survived page fetch by Claude, ChatGPT, and Gemini. A few of the markers were negative or positive controls to make sure the test page was sound but it was designed to test two different things:
- Location on the page: does location on the page matter when it comes to extraction, e.g. header, body, footer?
- Container: does it matter whether it’s a <script>, <div> or other container?
Research findings
Below are the findings of our experiment. The results are conclusive, your schema isn’t being seen by AI models.
| What we hid on the page | ChatGPT | Gemini | Claude |
|---|---|---|---|
| JSON-LD schema (5 blocks in 5 different spots) | 0 of 5 | 0 of 5 | 0 of 5 |
| The same JSON in a hidden <div> instead of a <script> tag | ✓ | ✓ | ✓ |
| Meta description | ✗ | ✗ | ✓ |
| Accessibility label (aria-label) | ✗ | ✓ | ✗ |
| Normal visible text (positive control) | ✓ | ✓ | ✓ |
Tested August 6, 2026. Full results for all 14 canaries and 5 tools are in the appendix.
- ChatGPT, Gemini and Claude found 0 of 15 JSON-LD blocks. Add two common scraping tools, Firecrawl and Chrome’s reader, and it’s 0 of 25 for tools extracting JSON-LD blocks. NOTE: Firecrawl was able to see the events on the rendered page, not in JSON schema.
- Location doesn’t matter. Header, footer, body. None of our experiment’s JSON-LD survived the fetch.
- The containing element is the reason why it doesn’t survive the fetch. JSON-LD sits in a <script>, which gets discarded by each model during fetch.
- Whether accessibility attributes survive fetch is model dependent. Only Gemini fetched the content we hid inside an ‘aria-label’.
The final finding about Gemini is an unexpected finding from our study. Google’s developer docs say AI agents use the accessibility tree to make sense of a page, mostly to find things like buttons and form fields. So we were curious whether any of the AI tools would pick up text we tucked into an aria-label. Only Gemini did. It’s only one result, so I wouldn’t build a strategy around it. But it does look like Gemini’s browsing tool holds on to some accessibility data the others toss out.
Even more interesting was Gemini’s response to our prompt about its ability to extract any JSON.
“This tool strips <script> tags, including Schema/JSON-LD, during content extraction, which is why other potential matches in the raw source code may not be visible here… The live browsing tool I have available returns a sanitized, body-only DOM representation of the webpage and strips out the <head> section and all <meta> tags before I receive the data.”
That is a major AI model describing its extraction layer is designed to discard JSON-LD.
Skip down to the full experiment details →
Do AI models see my structured data on training runs?
Our experiment showed that AI bots don’t see your schema on fetch. But what about during training, is the schema included then? Unfortunately, this is very unlikely. Anthropic and ChatGPT use ClaudeBot and GPTBot to crawl, and extract text at a massive scale. They don’t publish their training pipeline, but most standard LLM training pipelines (Fineweb by Hugging Face, Trafilatura) strip <nav>, <form>, <script>, <style>, and <footer> tags. This means at the two most crucial moments – training runs and live fetch by an agent – AI likely isn’t seeing your schema.
If LLMs can’t fetch JSON schema, what good is it?
The conventional wisdom in the AiSEO community is that JSON-based schema structured data is critical for AI search optimization. There are articles abound claiming that structured data is essential for AI optimization:
- Schema Markup for AI Search: Complete Guide – SEOptimer, Nov 2025
- Schema Markup for AI Citations: The Technical Implementation Guide – Averi.ai , Dec 2025
- How Can Schema Markup Specifically Enhance LLM Visibility – Walker Sands, Nov 2025
- How to Use Schema Markup for AI to Improve Search Visibility – TMV, May 2026
However, when you dig into the details, you start to notice more correlation than causation, or the finding is conflated to fit the claim, or there is no cited source anchoring their claim at all (ahem… Walker Sands). Averi.ai claims in their post above, “GPT-5’s accuracy improves from 16% to 54% when content relies on structured data…” but when you look at the source, the “structured data” in question is about answering natural-language questions over an enterprise SQL database. It’s not about AI search, and they also cited the wrong GPT model, which was GPT-4 in the study.
What about those quotes from Google and Microsoft search execs?
There are a couple oft-cited quotes from Google and Microsoft Search executives who commented on structured data and AI, but when you review, neither are a slam dunk.
On Google Search Central Live, Ryan Levering from Google shared, “A lot of our systems run much better with structured data,” he noted, adding that “it’s computationally cheaper than extracting it.” Which could be another instance of “structured data” getting conflated with JSON-LD schema.
The day before, Fabrice Canel, Principal Product Manager of Bing, stated at SMX Munich that, they use schema “as a reference check of their LLM training data” which David Mihm posted about on LinkedIn claiming that, “Fabrice Canel confirms that schema markup helps Microsoft’s LLMs understand your content.” But that’s not what he said, and he was actually promoting IndexNow as a means to keep your site fresh in Bing, which ChatGPT uses for search grounding.
If schema doesn’t optimize for AI search, why do other studies find a correlation?
We think studies that show a correlation between websites that implement schema and AI citations rates surfaces for two reasons:
- Most websites that deploy structured data are also focused on improving their SEO. And while not identical, AI search optimization has a lot of overlap with SEO best practices.
- Structured data must represent content that’s on a page. That means you need to have really well structured page content and website IA to have a robust structured data strategy. In this scenario, these sites have robust content, which is likely why they have higher citation rates.
Focus on content instead
Google said in their Generative AI fundamentals guide that people are “overfocusing on structured data.” We always tell clients, content is always the biggest lever to pull for website optimization. Your website content is your training data. What products or services you choose to highlight is what AI will know about your brand.
And back to what kicked off this experiment, do not use JavaScript-rendered content. Any content rendered via JavaScript will be invisible to AI tools.
We included the full experiment details below if you’d like to dig in further.
Appendix: Read the full experiment
We ran this test on August 6, 2026. I designed it with Claude, and Claude helped build the page and run the fetches. The results below come from a mockup of a healthcare page. We’ve since put up a public copy with the same 14 canaries, where the page text explains the test itself. You can see that version here.
The question
When an AI tool reads a web page, does the schema on that page reach the AI?
We also wanted to know why it gets lost, if it does. There were two ideas to rule in or out:
- Location. Maybe it matters where the schema sits on the page: the top, the bottom, or buried deep in the code.
- Hidden vs. script. Maybe AI tools skip anything a visitor can’t see. Or maybe they skip the <script> tag that JSON-LD lives in.
The second question is the tricky one. On a real website, JSON-LD is always hidden and always inside a <script> tag. You can’t tell which one is causing the problem. So we had to pull them apart.
How we built the test page
One page, not fourteen
The simple approach would be to build a separate page for each test. But then each page gets fetched at a different time, and that adds noise. Caches change. Tools change.
So we put all fourteen tests on one page. Each one hides a unique code word, from PILOTTEST01 to PILOTTEST14. We call these code words canaries. When an AI tool reads the page, we check which canaries show up in what it got back. If PILOTTEST07 shows up, test 07 survived. If it doesn’t, that test got thrown out.
A real-looking page
We didn’t use a bare-bones page. Some tools decide what counts as the “main content” by looking at how much text is on the page. A nearly empty page can confuse them.
Instead, we used a mockup of a healthcare website. It has about 2,000 words of real text: a header, seven content sections, an eight-question FAQ, and a footer. The page is plain HTML. Nothing loads with JavaScript after the page opens. What the server sends is exactly what’s on the page.
The 14 canaries
| # | What we hid | Why |
|---|---|---|
| 01 | Meta description tag | Does the page summary in the <head> get through? |
| 02 | JSON-LD in the <head>, clean and valid | The textbook way to add schema |
| 03 | JSON-LD in the <head>, wrapped in CDATA | How our client did it. This wrapping technically breaks the JSON. |
| 04 | Plain JSON in a <script> tag (not labeled as schema) | Is it schema being thrown out, or any script? |
| 05 | An HTML comment | Negative control. This should never show up. |
| 06 | JSON-LD at the top of the <body> | Location test |
| 07 | The same JSON, in a hidden <div> | The key test. Hidden like schema, but not in a script tag. |
| 08 | The same JSON, in a <template> tag | Another hidden container |
| 09 | JSON-LD buried deep inside tables and divs | Copies our client’s page structure |
| 10 | Microdata (an older schema format) | Does a different schema format do better? |
| 11 | RDFa (another schema format) | Same question |
| 12 | An accessibility label (aria-label) only | Do the labels used by screen readers get through? |
| 13 | Normal, visible text in a paragraph | Positive control. This should always show up. |
| 14 | JSON-LD at the very end of the <body> | Location test |
Two groups do most of the work:
- Canaries 02, 06, 09, and 14 test location. Same schema, four different spots on the page.
- Canaries 06, 07, and 08 test the container. The exact same JSON, all hidden from visitors. The only difference is what tag holds it: a <script>, a hidden <div>, or a <template>.
Here’s the exact code for each canary:
<!-- 01 meta tag in head -->
<meta name="description" content="…PILOTTEST01">
<!-- 02 JSON-LD in head, clean and valid -->
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"MedicalWebPage","description":"PILOTTEST02"}
</script>
<!-- 03 JSON-LD in head, CDATA-wrapped (invalid strict JSON) -->
<script type="application/ld+json">/*<
