Structured data definition

Structured data is markup added to a web page that tells machines what the page's content means, using a shared vocabulary like schema.org so a recipe's ingredients, cook time, and calories are separate labeled facts rather than prose a parser has to guess at. Because that markup has to agree with the page, its values need a source. In Sanity, content is stored as typed fields, and a GROQ projection renames and nests them into a schema.org-shaped object at query time.

What does structured data look like on a page?

Structured data usually appears as a block of JSON inside a `<script type="application/ld+json">` tag in the page's HTML, invisible to human readers and read by machines. Google's own example uses a recipe: the script declares `"@context": "https://schema.org/"` and `"@type": "Recipe"`, then lists properties such as the ingredients, the cook time, and the nutrition information as named fields.

The vocabulary and the format are two separate choices. The vocabulary is almost always schema.org, a collaborative community project founded by Google, Microsoft, Yahoo, and Yandex that maintains a shared hierarchy of types and properties (more than 800 types as of schema.org version 30.1, dated September 2026). The format, meaning how that vocabulary is written into the page, is one of three serializations: JSON-LD, Microdata, or RDFa. JSON-LD became a W3C Recommendation on 16 July 2020 and is the format Google uses in its own documentation examples.

One nuance most explanations skip: Google notes that while most search-relevant structured data uses the schema.org standard, Google Search Central, not schema.org documentation, is the source of truth for how Google Search behaves, and not every schema.org property is required or used by Google.

What is the difference between structured data and structured content?

Structured data and structured content sit at opposite ends of the same pipeline. Structured data is markup added to an already rendered page to describe what that page is about. Structured content is how the content is stored and modeled at the source, before anything is rendered: discrete typed fields instead of one page-shaped blob of HTML.

You can have either without the other, which is why the two get confused. A site whose article body is a single pasted HTML string, with an SEO plugin emitting `Article` markup over the top, has structured data sitting on top of unstructured content. A carefully modeled content repository that renders plain semantic HTML has structured content and no structured data at all.

They compose well, though, and that is the practical reason to care about the distinction. When a publish date, an author reference, a price, and a cook time already exist as separate typed fields at the source, the markup for them can be generated from those fields. When they only exist as bolded phrases inside one rich-text field, someone has to retype them into the markup, and the two copies drift apart the first time an editor corrects the page without remembering to correct the script tag.

For the same reason, structured data is not a content model. A content model is the blueprint of which content types exist and what fields each one carries. Structured data is an output description. A team can hold a rigorous content model and emit no structured data whatsoever.

Is structured data the same thing as schema markup?

Schema markup is one implementation of structured data, not a synonym for it. Structured data is the general concept: any standardized, machine-readable description of what a page's content means. Schema markup is that concept carried out with a specific vocabulary, schema.org, serialized as JSON-LD, Microdata, or RDFa.

Nearly all structured data in a search context is schema markup, which is why the terms are used interchangeably in practice. The concept is broader than the vocabulary, and keeping them separate makes a third term easier to place: schema.org is neither the concept nor the format. It is the vocabulary, the agreed list of types like `Product`, `Recipe`, and `Organization` and the properties each type can carry.

Structured data is also distinct from metadata. Metadata describes an item from the outside: a title tag, an Open Graph tag, a taxonomy label. Structured data describes the entities and relationships inside the item using a typed vocabulary, so a recipe carries `recipeIngredient`, `cookTime`, and `nutrition` as separately addressable properties rather than one opaque description string.

Why does structured data matter for search and AI?

Structured data matters because it removes guesswork for machine consumers of a page. Without it, a search engine or an assistant has to infer from layout and wording that "25 min" is a cook time and not a delivery estimate. With it, the page states the fact in a typed property that needs no interpretation, which is what makes pages eligible for rich results in search. Google maintains the current list of supported features in its Search Gallery.

Google publishes customer results on its structured data introduction, and they are worth reading as vendor-reported case studies rather than an independent benchmark: Rotten Tomatoes added structured data to 100,000 unique pages and saw a 25% higher click-through rate on those pages than on pages without it, and Nestlé measured an 82% higher click-through rate for pages appearing as rich results. Google attaches no dates to these figures.

There are rules. Google's general guidelines require that structured data describe content actually visible to users. Marking up information that is not on the page, or creating blank pages to hold markup, is a policy violation rather than a shortcut.

This is the layer where content infrastructure shows up. Sanity is a Content Operating System for the AI era, providing the structured foundation, automation layer, and agentic context companies need to power every content experience. Semantic clarity at the source is what makes semantic clarity at the output cheap: typed fields can be projected into whatever shape a consumer expects, whether that is a schema.org object for a crawler or a clean record for an agent.

How is structured data generated from a content repository?

Structured data is generated from a content repository by reading the same fields the page renders and reshaping them into the vocabulary the consumer expects, so there is one source of truth and one set of facts. The alternative, keeping the markup as a second hand-written copy, is where drift comes from.

In Sanity, the source side is a schema declared in code and stored in the Content Lake, describing which document types exist and what fields each carries. The available schema types are the primitives that make a page's facts individually addressable: String, Number, Boolean, Date, Datetime, Text, URL, Email, Slug, Geopoint, Image, File, Reference, Array, Object, Block, and Span, among others.

The output side is a GROQ projection, which reshapes a document into an arbitrary object at query time. Per the GROQ specification, a projection can rename a key with a quoted name, as in `{"key": value}`, compute a value from an expression, as in `{"name": firstName + " " + lastName}`, spread another object in with `...`, and nest projections inside projections, as in `*[_type == "book"]{title, "authors": authors[]{...}}`. Those three capabilities, renaming, computing, and nesting, are exactly what turning a document into a schema.org-shaped object requires.

To be precise about the boundary: Sanity does not ship a schema.org or JSON-LD generator as a product feature. What it provides is typed source fields and a query language that can project them into the shape your frontend serializes into the page.

Last updated: September 23, 2026