A JSON-LD block on the page does not parse
Updated
What this check looks for
A JSON-LD block on the page is not valid JSON, so search engines discard it entirely: the markup is present and is doing nothing for the page.
In a report, this finding reads as follows, with each ‹…› filled in from what that scan observed:
‹count› of the page's JSON-LD blocks are not valid JSON, so they are discarded entirely. The markup is present and is doing nothing.
Why it matters
A block that does not parse is skipped in full — not partially read. Whatever the markup was meant to make the page eligible for, it does not.
When the check passes, your report says: “Every JSON-LD block on the page parses”.
What it costs your score
When this check fails it removes 8 points from your SEO score, before the status, confidence and repeat multipliers are applied. SEO carries a weight of 5 in the overall score.
It shares the seo.structured-data family ceiling of 10 points: however many findings that family produces, together they cannot remove more than that from SEO. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 8 points
- Family cap
- seo.structured-data · 10
- Category
- SEO
- Module
- Seo audit
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Fix the JSON so the block parses, and generate it with an encoder rather than a template.
A block that does not parse is discarded whole, so the markup currently achieves nothing.
Copy the block into Google's Rich Results Test or any JSON validator to see the exact position of the error.
Look for a trailing comma, a comment, single quotes, or an unescaped quote inside a string — these are almost always it.
Build the object in code and serialise it, rather than interpolating values into a JSON-shaped string in a template.
Ensure the serialiser escapes
<so a value containing</script>cannot close the element early.
How to confirm it worked
curl -sS ‹url› | sed -n '/application\/ld+json/,/<\/script>/p' — paste into a JSON validator
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
The parse failed with: ‹error›.
‹excerpt›
JSON-LD must be valid JSON inside a <script type="application/ld+json"> element. The failures that occur in practice are: a trailing comma after the last property, which JavaScript accepts and JSON does not; an unescaped quote or newline inside a string, usually from interpolating a page title or description straight into the template; a JavaScript comment; and single quotes instead of double.
The interpolation case is the one worth fixing structurally. Build the object and serialise it with a JSON encoder rather than assembling the string in a template — JSON.stringify escapes what needs escaping, and a title with an apostrophe stops being a deployment risk.
One further trap: if the content is inserted into the page as text, </script> appearing inside a string will end the element early. Encoders that escape < avoid it.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.