In one paragraph
Invalid JSON-LD syntax means at least one recognised structured-data block could not be parsed as JSON. Fix the malformed block at its source, then validate its vocabulary, required properties, and factual accuracy separately. A syntactically valid object is not automatically useful JSON-LD or eligible for a Google rich result, and an accurate markup implementation still does not guarantee enhanced display.
Why it matters
JSON-LD can describe entities and relationships in machine-readable form. Its JSON syntax must first be readable before a consumer can interpret the intended structured data. A trailing comma or broken string can therefore remove useful information while leaving the visible page unchanged.
The next layer is meaning. A parser can accept an object that lacks an appropriate type, has incorrect property values, or describes facts not shown on the page. Search-feature eligibility adds another layer of required fields and policies. Keep these checks distinct rather than calling every parseable object valid for Google.
One malformed block does not necessarily invalidate independent well-formed blocks. Diagnose the specific generator and block rather than deleting all structured data from a page to silence the error.
How WebAuditOS evaluates this finding
The supplied rule reads recognised application/ld+json script blocks from eligible server-returned HTML and parses each as JSON. All parsed blocks pass; one or more parse failures fail at medium severity. No recognised block is not graded.
It does not validate schema.org semantics, Google-required properties, current feature eligibility, or factual accuracy. It does not read microdata or RDFa. Runtime-injected JSON-LD is outside this source-only check, although Google can process dynamically inserted structured data. A pass is therefore JSON syntax validation within the observed scope, not a rich-result certification.
How to fix it
- Copy the exact failing block from the deployed source, keeping its boundaries clear. If several generators exist, identify the theme, plugin, CMS field, or code path responsible for each. Avoid sharing private data in public validators.
- Parse the JSON with a strict validator and inspect the error location. Common causes include trailing commas, single-quoted properties, comments, unescaped double quotes, literal line breaks inside strings, and two objects pasted together without an array.
- Check HTML boundaries as well as JSON text. A value containing a script-closing sequence can terminate an unsafe embedded block before the intended JSON ends. HTML entity escaping is not a general substitute for correct JSON serialization in a script's raw-text context.
- Build a data object and use the platform's appropriate serializer rather than concatenating user or CMS values into JSON strings. Use a safe embedding strategy that prevents a literal less-than character in untrusted values from creating an unintended script end tag. Follow the framework's documented output handling and test edge cases.
- A simple illustrative static block is:
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"WebSite","name":"Example","url":"https://example.com/"}
</script>Replace it with data appropriate to the real page. This example demonstrates readable syntax, not eligibility for every rich-result feature or a substitute for the missing entity you intended to describe.
- Validate meaning separately in Schema Markup Validator and the Google Rich Results Test where applicable. Check current feature documentation, complete required fields, and agreement with visible content. Do not invent ratings, prices, authors, or credentials to make a test pass.
- Test names and descriptions containing quotes, newlines, Unicode, and HTML-like text. Also test missing data and more than one block. Keep generated values tied to the same source data used for the visible page.
- Deploy, inspect the final source and relevant rendered output, then rescan. Monitor supported enhancement reports where available, recognising that valid data can still be ignored for display.
What the fix can break
A syntax repair can make stale or misleading information readable for the first time. Review factual values before assuming the change only affects punctuation.
Two independent plugins can emit conflicting descriptions of the same entity. Correct syntax does not resolve that duplication; assign ownership and keep identifiers coherent.
Unsafe serialization can become a security problem as well as a parse problem. Test the HTML embedding boundary, not just an isolated JSON string in a development console.
Questions
Does a passing JSON parse guarantee a rich result?
No. Meaning, required properties, content policies, feature support, and Google's display decisions are separate.
Can Google read JSON-LD added with JavaScript?
Yes, when rendering and insertion work. The documented source-only scanner may not see the same block.
Does one broken block destroy every other block?
Not necessarily. Independent valid blocks can remain readable. Fix the specific failure without deleting unrelated useful data.
Which related checks help?
Review structured-data presence, organisation markup, and the indexing checklist.