Which Schema.org structured data types does a website actually need?

A search engine and a language model read the same HTML but look for different things. A human is fine with a page that says "call us on 555-0100". To a machine that is just a string: it cannot tell a phone number from an order reference.

Structured data answers that question. The same content appears a second time — in a JSON-LD block where every fact has a name.

Four types are enough

Organization — who you are. Name, logo, contact details, sameAs links to your profiles. This is the one node a model uses to connect your site with whatever it already knows about you from elsewhere.

WebSite — the site as a whole. Name and language. Short, but without it Organization hangs without context.

BreadcrumbList — the path to the page. The one type Google shows in results almost every time: instead of a long URL the listing reads "Home › Services › Audit".

A page type — Article for writing, Product for goods, Service for services, FAQPage for questions. This says what to look for on the page at all.

That is it. Event, Recipe and JobPosting matter when you actually have an event, a recipe or a vacancy — not because they exist in the catalogue.

The mistake almost everyone makes

Schema with no visible equivalent on the page is a lie told to a machine. FAQPage with questions nobody can see. AggregateRating with a score nobody gave. A Product price that differs from the one on screen.

Google penalises this separately, and that is not theory — it is written plainly in their structured data guidelines. But the more serious consequence is different: a model that catches one mismatch stops trusting the rest of your markup.

One rule: content first, markup second.

@id — a reference, not a copy

If an article and the site share an author, there is no need to describe them twice. One node gets an @id, the other points at it:

{ "@type": "Article", "author": { "@id": "https://example.com/#org" } }

This is how Yoast, RankMath and every serious generator writes it. Two copies drift apart sooner or later, and then the machine sees two different authors for one text.

There is a practical consequence for auditing tools: checking whether an author is declared means following the reference, not looking for a full node in place. Our own audit once failed to do that and told eight perfectly correct articles their author was missing.

What this gives you for GEO

Classic SEO gets rich results out of schema — stars, prices, breadcrumbs. That is visible, but it is not the biggest gain.

A language model gets something else: certainty. When it has to name who provides a service in a given city, it chooses between pages where the fact has to be inferred and a page where it is declared. Declaration wins, because it needs no interpretation.

That is the same logic that makes llms.txt worth having at all: less work for the machine reading your page.

How to check

Google's Rich Results Test shows whether the markup is valid and which features it unlocks. The Schema.org validator shows whether the syntax is correct at all. Both are free and both take a minute.

The free scan checks something broader: whether schema exists, whether it matches the visible text and whether @id references lead anywhere.

Related articles

The same topic from another angle — each answers its own question:

• What AEO is and how to land in the answer
• What llms.txt is and whether you need it
• How AI decides what to cite

How this feeds into the score is described under what we check.

Sources

What this text is based on — primary sources, not retellings:

• Google Search Central — structured data guidelines
• Google Search Central — structured data gallery
• Schema.org — full type documentation