Machine-readable content definition

Machine-readable content is content a program can parse reliably because its meaning is carried by explicit structure rather than by visual layout or prose convention. A heading looks like a heading to a person; to software it is just text unless something labels it. In Sanity, content is modeled as typed fields in a schema and queried directly with GROQ, so an agent asks for the field it needs and gets a predictable value back instead of scraping it out of HTML.

What makes content machine-readable?

Content is machine-readable when a program can locate a specific piece of meaning in it without guessing. Three properties do most of the work.

The first is explicit structure. The parts of the content are separated into named fields (title, summary, price, effective date) rather than blended into one block of formatted text. The second is typed values. A date is stored as a date, a number as a number, and a reference to another item as a reference, so software knows what it can do with the value before it reads it. The third is stable identity. Every item and every field has a name that does not change when the design changes, so code written against it last year still works today.

A PDF price list fails all three. A JSON object with a `price` field of type number, attached to a product with a permanent ID, passes all three. The content in both cases is the same information; only one of them is machine-readable.

What is the difference between machine-readable and human-readable content?

Human-readable content conveys meaning through appearance and language, while machine-readable content conveys meaning through labels and structure. The distinction is not about format quality. A beautifully typeset page and a messy one are equally opaque to software if neither says which part is the author name.

People infer structure from visual cues. Bold text near the top is probably a title. A number after a currency symbol is probably a price. Two columns of dates and events are probably a timeline. Software cannot make those inferences reliably, because the same visual pattern means different things on different pages.

Machine-readable content removes the inference step. Instead of a large bold string that a parser has to classify, there is a field literally called `title`. Instead of a paragraph that happens to describe shipping policy, there is a `shippingPolicy` field. The content can still render beautifully for people. Readability for humans and readability for machines are not a trade-off; they are two outputs of the same well-labeled source.

Is machine-readable content the same as structured data?

Machine-readable content and structured data overlap, but they sit at different points in the pipeline. Structured data usually means markup added to a rendered web page, most commonly Schema.org vocabulary expressed as JSON-LD in the page HTML, so that search engines and other consumers can identify what the page is about. It describes a page after that page has been built.

Machine-readable content is broader and earlier. It describes the content itself in the repository where it is authored and stored, before any page exists. One machine-readable source record can produce a web page, a mobile app screen, an API response, an email, and the JSON-LD markup on that web page.

The practical consequence: if your only machine-readable representation is the markup on the rendered page, then every consumer has to fetch and parse a page to get at the data, and anything you did not render is invisible. If the source content is machine-readable, the markup becomes one more output rather than the only copy.

Why does machine-readable content matter for AI agents?

Machine-readable content matters for AI agents because it removes the guessing step that makes agent behavior unpredictable. An agent that scrapes a rendered page has to identify the relevant text, decide what it means, and hope the layout has not changed since the last run. An agent that reads typed fields gets a value it can trust and a name that tells it what the value is.

This affects retrieval quality directly. When content is chunked for a retrieval-augmented generation system (the pattern where a model is given relevant source passages to ground its answer), structured source content lets you chunk along meaningful boundaries and attach real metadata (product, version, effective date, locale) to every chunk. Unstructured source content forces you to chunk by character count and hope the split lands somewhere sensible.

It also affects what an agent is allowed to change. Writing back to a labeled field is a checkable operation: you can validate the type, enforce required values, and review the change. Writing back to a blob of prose is not.

How do you make content machine-readable?

Making content machine-readable is a modeling exercise, not a formatting one. A workable sequence:

First, list the questions software will ask of the content. "What does this cost?", "Which regions is it available in?", "When does this policy take effect?" Every question that matters becomes a candidate field.

Second, give each answer its own field with a real type, rather than leaving it inside a paragraph. Dates as dates, numbers as numbers, options as a fixed list of allowed values.

Third, replace repeated text with references. If three hundred articles name the same author, store one author record and point to it, so a change happens once and every consumer sees it.

Fourth, keep rich text structured rather than storing it as an HTML string. A structured rich text format keeps headings, links, and embedded items as addressable objects, which means a program can pull just the headings or just the linked products.

Fifth, validate at the source. Constraints enforced where content is authored are the only ones every downstream consumer inherits.

Sixth, expose it over a query interface, so a consumer can request exactly the fields it needs rather than downloading a page and discarding most of it.

Last updated: September 23, 2026