A JSON block can parse correctly and still describe the wrong thing or miss required properties. Separate three questions: is the JSON valid, does the markup accurately represent the page, and is it eligible for the search presentation you want? No single syntax check answers all three.
Inspect the markup that is actually returned
Run the structured-data checker on the exact public page. It identifies JSON-LD blocks, attempts to parse them, and lists top-level schema types and property names. If nothing is found, check whether the site uses microdata, RDFa or JavaScript to add markup later. Those formats are outside this tool's fetched JSON-LD scope. Absence in this result is not proof that the rendered page has no structured data.
Fix syntax before reviewing properties
An extra comma, an unescaped quote or malformed output from a template can make the JSON unreadable. Fix the generating component rather than editing only one response. If user-entered content is inserted into JSON, ensure the template serializes it correctly instead of building fragile strings. Retest a page with simple text and another with punctuation or special characters so the fix covers the actual content range.
Check whether the type fits the page
A type should reflect the content a visitor sees. An article, product and organization describe different entities and require different supporting facts. Do not label an ordinary marketing page with a more attractive type just because you want a rich result. Review whether each entity is visible, accurate and current. Multiple entities can be appropriate, but copied template nodes may refer to the wrong page or an obsolete business detail.
Validate meaning separately
After the JSON parses, use Schema.org's validator to inspect the vocabulary and relationships. Then use Google's Rich Results Test for a supported search feature. A type being valid Schema.org markup does not mean Google supports a special result for it. Keep those validation outcomes separate in your release notes. The NewSiteCheck syntax pass is intentionally narrow so it does not imply a semantic or eligibility guarantee.
Avoid unsupported claims in the data
Do not invent reviews, ratings, prices or availability to fill a field. Where offers or event details change, connect the markup to the same source that populates the visible page. If an offer disappears, update or remove its markup as part of the same workflow. A structured representation that disagrees with the page can create confusion even when every property is syntactically correct.
Retest templates and monitor changes
Check at least one page for each template that emits JSON-LD. A global component may make the same mistake across hundreds of pages, while a single unusual value can break only one response. Save the initial syntax inventory and the semantic validation result. After a template change, compare the emitted types and property names as well as the pass count. A deleted block may remove useful information without creating a JSON syntax error.
A practical action checklist
- Inspect fetched JSON-LD blocks and types.
- Fix malformed JSON at the generating template.
- Confirm that entities match visible content.
- Run semantic and rich result validation separately.
- Retest representative pages after template changes.
NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.