# Does ChatGPT read schema

An honest answer to the question technical buyers ask first. Structured data is not read by the model directly, and it still matters. Here is why both are true.

Source: https://martenfield.com/guides/does-chatgpt-read-schema/
Published: 2026-07-31

---
The short answer: not the way the question usually means, and it still matters.

That sounds like a dodge. It is not, and the distinction is the whole point.

## What actually happens to your JSON-LD

When a model answers a question using live information, it does not fetch your
HTML, parse the `<script type="application/ld+json">` block, and reason over the
graph. What it receives is closer to the readable text of your page, converted
to something like markdown, with the markup stripped.

If your only statement of a fact lives in structured data and nowhere in the
visible text, treat it as invisible. This is the single most common and most
expensive misunderstanding in the category, because it produces sites where
the price, the date, or the figure exists in the JSON-LD and nowhere a reader or
a model can see it.

State facts in the text. Then also state them in the schema.

## Why it still matters

Structured data does its work one layer earlier, in the systems that decide what
gets retrieved and what your company is understood to be.

**Retrieval runs through search infrastructure.** Most grounded answers start
with a conventional search against a conventional index. Schema has always
influenced how those indexes understand and surface a page, and that influence
did not stop being relevant because the consumer of the result changed from a
person to a model.

**Entity disambiguation.** This is the part that pays off most and is discussed
least. An `Organization` node with `sameAs` links to your authoritative profiles
tells every consuming system that the company on your site, the company on the
review site, and the company in the funding database are one entity. Without it
you are three weak entities instead of one strong one, and models confidently
merge you with a similarly named company or split your track record in half.

**Freshness and authorship signals.** `datePublished`, `dateModified`, and a
real `author` node feed the systems that decide whether a page is current and
who stands behind it. Undated material gets discounted.

**Feature eligibility.** Rich results, dataset discovery, and the various
answer surfaces still gate on structured data. Those surfaces are themselves
sources that models retrieve.

## The test that settles it for your own site

Stop reading vendor claims and look at what a crawler receives.

Fetch your own page with JavaScript disabled and strip the markup. Whatever
remains is approximately what a model gets. Ask three questions of it:

1. Is the main content there at all, or did it arrive by client-side rendering?
2. Are the specific facts you want quoted present in that text?
3. Are the dates visible in it, or only in the schema?

Most sites fail at least one. Sites built on modern JavaScript frameworks
without static rendering routinely fail the first, which makes the other two
irrelevant.

We serve a plain markdown version of every page on this site next to the HTML,
linked from the head, precisely so this is checkable rather than arguable.

## What to implement, in order

**Organization, site-wide, with sameAs.** Point at every authoritative profile
you control: the funding database entry, the review site profile, the trade
association listing. This is the highest-value item and it is usually missing.

**Article on anything editorial,** with `datePublished`, `dateModified`, and an
`author` that resolves to a real person or organisation node rather than a
string.

**Dataset on any published data,** with `license` and `distribution` actually
filled in. An empty Dataset node is a claim without a payload.

**FAQPage only on genuine question and answer content.** Marking up sales copy
as questions is the kind of thing that eventually gets penalised and never
helped much anyway.

**BreadcrumbList throughout,** because structure is cheap to express and is used
more than people expect.

Then validate it. Not "it looked right in the editor": run the output through a
structured data validator and confirm every `@id` reference resolves to a node
that exists. A graph with dangling references describes nothing.

## The honest limits

Nobody outside the labs knows exactly how much weight any of this carries, and
the answer differs per engine and changes without a changelog. Anyone giving you
a percentage is inventing it.

What is defensible: structured data is cheap, it is standard, it does real work
in the retrieval layer, and it costs you nothing but discipline. The failure
mode is not that schema does not work. It is believing schema is a substitute
for stating the facts in text a model can actually read.

Do both. Then check what the crawler receives, because that is the only part of
this you can verify yourself.

## Questions

### So should we implement schema or not?

Yes, but for the right reason. Implement it because it makes you eligible for search features, because it disambiguates your entity in the knowledge graphs that sit behind retrieval, and because it forces you to state facts explicitly. Do not implement it expecting a model to parse your JSON-LD out of the page and quote it.

### Which schema types matter most?

Organization with sameAs links pointing at your authoritative profiles, so your entity resolves to one thing rather than three. Article with datePublished, dateModified, and a real author on anything editorial. Dataset with license and distribution filled in on any published data. FAQPage on genuine question and answer blocks. BreadcrumbList for structure.

### Does schema help if my content is thin?

No. Structured data describes content, it does not substitute for it. Marking up a thin page correctly produces a well-described thin page, and retrieval will still prefer the source with the actual numbers in it.