Does ChatGPT read schema

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.