JSON-LD

The practical advantages are maintainability and auditability: one block states the page's claims, it can be generated from the same data that renders the page (so the two never drift apart), and validators can check it directly.

The older alternatives explain why this matters. Microdata and RDFa express the same vocabulary by decorating visible HTML with attributes, which means every redesign risks stripping the markup and every template change risks breaking it silently. JSON-LD sits in one script tag, survives visual redesigns untouched, and can be diffed like any other data.

A few implementation details cause most real-world failures. Multiple JSON-LD blocks on one page are permitted, and linking them by @id rather than repeating the business details is what turns several disconnected claims into one coherent statement about an entity. Values must match what a visitor can see — markup asserting a rating no one can find on the page is a policy violation, not a shortcut. And JSON-LD injected by client-side JavaScript is read inconsistently, so server-rendering it is the reliable choice.

The discipline that prevents drift is generating the markup from the same source as the visible content rather than maintaining it as a parallel document. Hand-written schema starts accurate and rots: a price changes in the copy, the JSON keeps the old one, and now the page makes two contradictory claims to a machine that reads both.

Every substantive page on this site carries JSON-LD generated from the same source as its visible content — the research pages, for instance, emit Dataset objects whose numbers are asserted by the test suite to match the page. That is the pattern worth copying: markup as a projection of real data, never a separate thing to keep honest by hand. See structured data for what the markup is worth and what it is not.