Structured data is a data type — a subclass of data whose defining quality is structure, and whose opposite is unstructured data. Making a page machine-readable means moving claims out of the second category and into the first. This is what that actually involves, in the order it is worth doing.
First, know what you are aiming at
Structured data uses a data model, and it is recorded as a facet of the Semantic Web — the information system credited to Tim Berners-Lee, classed as a subclass of the World Wide Web, semantic network and semantic integration, and whose parts include linked data. That lineage explains why the vocabularies feel heavier than a page author expects: they were designed so that statements could be joined across sites, not merely parsed within one.
It is also worth naming the third category the graph is careful about. Structured data is different from semi-structured data. HTML is the everyday example of the latter: it has real structure, and that structure describes presentation rather than meaning. A machine can tell an <h2> from a <p>. It cannot tell a price from a part number, because the markup never said.
Second, use the vocabulary that already exists
Schema.org is a technical standard, an ontology and an organization. It was created on 2 June 2011 by Yandex, Microsoft, Google and Yahoo, its parent organisation is the World Wide Web Consortium, it is published under Creative Commons Attribution-ShareAlike 3.0 Unported, and it has moved through versions 9.0, 10.0, 11.0, 12.0 and 13.0.
Two things follow. It is a genuinely shared vocabulary — four competing search companies agreed on it, which is the only reason a term means the same thing to more than one consumer. And it is versioned and open, so it changes; a page written against it is written against a moving standard, not a fixed one.
The practical instruction is short: do not invent your own terms for concepts Schema.org already has. A bespoke property is invisible to everything except the code you wrote for it.
Third, put the claim in the markup, not only in the prose
This is the whole job, and most of it is unglamorous.
Say what the page is about. A page that never states its own subject in a machine-readable field is asking every consumer to infer it from the text, and inference is where they disagree with each other.
Make the important facts explicit. Anything a reader would want — what a thing is, who made it, when it was published, what it costs, whether it is available — belongs in a field, not only in a sentence a parser has to interpret.
Keep the structure and the prose in agreement. Markup that contradicts the visible page is worse than no markup: it makes the page unreliable rather than merely ambiguous, and unreliability is the one property that survives into every downstream system.
Fourth, check what a non-JavaScript client sees
Fetch your own page without executing scripts and read what comes back. This is a five-second check that reliably surprises people.
If the title, the description and the structured data are assembled in the browser, then the document that arrives at a client which does not run scripts contains none of them. Some clients render. Many do not, and the ones that do not fail silently — they get a valid, well-formed, empty-of-meaning document and proceed.
The same check answers the question people usually ask second: whether the markup is correct. A block of structured data that never reaches the response cannot be correct or incorrect. It is absent.
What survives to a model, and what does not
Search engine optimization, a field of study and professional skill, names backlinks and on-page SEO among its parts. Only one of those two is on your page. When a page’s text is read by a large language model rather than ranked by an algorithm, the external half does not travel: whatever the rest of the web says about you is not in the passage that was retrieved.
So the machine-readable head has a narrower and more literal job than the ranking-era version. It is not a signal that argues for the page’s importance. It is the page stating what it is, in a form that does not require anyone to be right about your HTML.
The order that works
Serve the important claims in the initial response. Use Schema.org terms rather than your own. Keep the markup and the visible page saying the same thing. Verify by fetching, not by believing. Everything else in this area is refinement on top of those four, and skipping any of them makes the refinements meaningless.
This site runs the same check on itself; that is the point of publishing it here rather than describing it in the abstract.
Leave a Reply