JSON-LD gives a page a second way to state what it is about. Types and properties can assign explicit meanings to names, dates, prices, and relationships (Schema.org, "Getting Started"). When those fields repeat facts from the visible page, they can become stale or contradict what a reader sees.
Structured data is valuable as maintained publishing data, not as an invisible bundle of keywords. Parseable markup is an observed signal. Whether a search engine or another client trusts, supports, or uses it is a separate outcome.
The vocabulary is not the consumer
Schema.org publishes a shared vocabulary of types and properties for describing things and their relationships. Publishers can express that vocabulary through JSON-LD, Microdata, or RDFa (Schema.org, "Getting Started"). JSON-LD is therefore a serialization choice, not another name for Schema.org.
Consumers define their own support. Google Search accepts all three formats and generally recommends JSON-LD when a site's setup allows it. Google also says its own documentation, rather than the broader Schema.org vocabulary, is authoritative for Google Search behavior (Google, "Introduction to Structured Data"). A term's presence in Schema.org does not establish that every client recognizes it or does anything with it.
Valid JSON is only syntax. Markup can make a statement explicit without compelling a result, and its content can still be outdated, irrelevant, or inconsistent with the page (Google, "General Structured Data Guidelines").
Syntax is only the first review
For Google Search eligibility, structured data should describe the page where it appears and should not introduce information hidden from readers. Google's guidelines call for current, relevant markup that truthfully represents visible page content (Google, "General Structured Data Guidelines"). This is a content-maintenance requirement, not just a linter rule.
Completeness is specific to the intended use. Schema.org defines a broad vocabulary, while a consuming system may document a smaller set of required or recommended properties. For Google Search features, Google advises publishers to favor fewer complete and accurate recommended properties over a larger set of incomplete or inaccurate ones (Google, "Introduction to Structured Data"). Even correctly marked up content is not guaranteed to appear as a rich result (Google, "General Structured Data Guidelines").
Consider a product page that visibly shows one price while its Offer object contains another. A parser can report both values, but syntax alone cannot identify the authoritative one. The repair is to fix the publishing pipeline and decide which public fact is current, not to add more markup around the conflict.
How MachineRead uses the signal
MachineRead inspects application/ld+json script elements in the fetched target-page HTML. It attempts to parse top-level objects, arrays, and @graph entries, scores a limited set of common types, and checks whether selected fields are populated. When commerce scope is enabled, the check gives particular attention to Product and Offer fields and can report specific mismatches between selected structured fields and visible product content.
This is a local structural inspection. It does not execute page JavaScript, consult a live Schema.org vocabulary, or prove that the published facts are true. A parse error, a type outside the scoring rubric, or a missing expected field is a concrete finding a publisher can inspect.
What this check can and cannot establish
The check can establish whether the audited page response contains JSON-LD that its parser can read, which type it selects under its scoring rubric, and whether selected fields are populated under the chosen audit scope. It may also expose a limited visible-content conflict for supported commerce fields.
It cannot establish full Schema.org conformance, consumer-specific eligibility, markup injected only after browser rendering, the truth of a business fact, or what any search engine or other client will select and use. It does not promise a rich result, ranking, traffic, citation, or agent response.
Treat markup as maintained content
Begin with the main entity a page actually presents. Use the most specific applicable type, populate fields from the same source that renders the visible page, and remove claims the page no longer supports. When several objects belong together, nest or link them deliberately (Google, "General Structured Data Guidelines").
Use the Schema.org Markup Validator to inspect Schema.org syntax and the extracted graph; its documentation says the tool extracts JSON-LD, RDFa, and Microdata and identifies syntax mistakes (Schema.org, "Schema.org Markup Validator"). If Google Search is an intended consumer, use Google's Rich Results Test and feature-specific documentation as a separate, Google-specific review (Google, "Introduction to Structured Data"). Recheck deployed pages after template or data-feed changes.
MachineRead can flag a structural condition during a broader site audit. The validator, the consumer's documentation, and the site's source data answer different questions.
Works Cited
Google. "General Structured Data Guidelines." Google Search Central, updated 10 July 2026, https://developers.google.com/search/docs/appearance/structured-data/sd-policies. Accessed 7 Aug. 2026.
Google. "Introduction to Structured Data Markup in Google Search." Google Search Central, updated 10 Dec. 2025, https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data. Accessed 7 Aug. 2026.
Schema.org. "Getting Started with Schema.org Using Microdata." Schema.org, version 30.0, 19 Mar. 2026, https://schema.org/docs/gs.html. Accessed 7 Aug. 2026.
Schema.org. "Schema.org Markup Validator." Schema.org, version 30.0, 19 Mar. 2026, https://schema.org/docs/validator.html. Accessed 7 Aug. 2026.
See also
- Methodology reference - documents the schema_ld check group
- Launch post - explains the audit's evidence boundaries
- Related: llms.txt and canonical URL