Structured data that earns its place
Structured data is worth implementing when it describes something the page genuinely shows and a consuming system genuinely uses. Generate it from the same data that renders the page, keep it to types the content supports, and treat any mismatch between markup and visible content as a defect.
Part ofTechnical SEO Engineering
Structured data has an unusual failure mode: it is invisible to the people who own the page, so it drifts from reality without anybody noticing. A price changes in the database and the JSON-LD keeps the old one. A review block is removed from the design and the aggregateRating stays behind. Both are worse than having no markup at all, because both describe a page that no longer exists.
Rule one: generate it, never hand-write it
The single most effective structural decision is to derive JSON-LD from the same objects that render the page. If the heading, the description and the markup all read from one content record, they cannot disagree. Hand-maintained script blocks in page templates always eventually disagree.
A test that asserts the markup's description equals the rendered description costs three lines and catches the entire class of drift permanently.
What is actually worth implementing
For most business sites the useful set is small. The types below do work: they either produce a documented search feature or they establish machine-readable facts that ranking and generative systems both consume.
Connect the nodes with stable identifiers
Isolated snippets describe fragments. Linking them with stable @id values describes a graph, which is what lets a consuming system understand that the organisation publishing this article is the same organisation providing that service.
Use a fragment identifier on a canonical URL, keep it stable forever, and reference it from everywhere. Regenerating identifiers on each deploy defeats the purpose.
sameAs is how you disambiguate an entity
Company names are rarely unique. sameAs links to authoritative profiles are the cheapest available signal that the organisation on this page is the one on those profiles. Only include properties you actually control and keep current — a link to an abandoned profile with a contradictory description is worse than omitting it, because it gives a generative system two conflicting sources to reconcile.
Validation in the pipeline, not in a browser tab
- Assert in unit tests that generated markup carries the required properties for each type you emit.
- Assert that the description and name in markup equal the strings the page renders.
- Check the Rich Results Test and Schema Markup Validator before launch and after any content-model change.
- Watch the Enhancements reports in Search Console for errors that appear only at scale.
- Re-check whenever the content model changes, because that is when drift is introduced.
What changes when the consumer is a language model
Structured data was designed for search features, and it is now also parsed by systems generating prose. That shifts the emphasis in two ways. First, factual properties matter more than feature-triggering ones: name, description, areaServed, sameAs, dates and authorship are the fields that shape how an assistant describes you. Second, consistency across pages matters more than completeness on any single page — a generative system reconciling three different descriptions of your company will produce a fourth.
It does not, however, change the fundamental rule. Markup asserts facts about the page. If the assertion and the page disagree, you have published something untrue in a format designed to be trusted. That is the one outcome worth engineering against.
Questions
Does structured data improve rankings?
Not directly, and Google has said as much. It makes eligibility for specific search features possible and makes page facts machine-readable, which matters increasingly for answer and generative surfaces. Treat it as a comprehension and eligibility mechanism rather than a ranking lever.
Should structured data include content the page does not display?
No. Markup is meant to describe visible content, and mismatches are a documented cause of manual action. It is also simply misleading. If information is worth asserting to a machine, display it to the reader.
JSON-LD, Microdata or RDFa?
JSON-LD. Google recommends it, it keeps markup separate from presentational HTML, and it can be generated from the same data objects that render the page — which is what prevents drift.