Quick answer
The jsonld-valid check passes when every measured JSON-LD block can be parsed as JSON, including when no JSON-LD is present. It confirms syntax at the audit’s level; it does not prove that the schema type, properties, values, or search-feature eligibility are correct. Invalid JSON is reported separately by invalid-jsonld.
What the issue means
JSON-LD is structured data embedded in a script element:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to store winter tyres"
}
</script>
The payload must be valid JSON before a consumer can parse it. Valid JSON-LD can still describe the wrong page or omit properties required for a particular rich result.
Why it matters for SEO
Correct structured data can help search engines understand entities and may make a page eligible for supported search features when all separate requirements are met. It is not a ranking guarantee, and syntax alone does not create a rich result. Google may ignore markup that is misleading, incomplete, or not representative of visible page content.
How NOTABIS detects it
The jsonld-valid rule is a page-level passed check created when each script[type="application/ld+json"] block returns no JSON parse error. No blocks also pass because there is no invalid JSON to report. NOTABIS records detected types and selected properties when available, but it does not validate the full Schema.org vocabulary, required properties for a feature, or Google feature eligibility.
How to check it yourself
View Source and copy each JSON-LD block into a JSON parser. Check commas, quotes, escaping, arrays, and duplicate keys, then validate the intended schema type with Google’s Rich Results Test or Schema Markup Validator. Compare the structured values with the visible page and its canonical URL.
How to fix it
Generate JSON-LD from the page’s authoritative content and keep one valid block per entity or a well-formed graph. Escape values through the serializer provided by your platform instead of concatenating strings by hand. Add only properties that are true and visible, then rerun a syntax and feature-specific validation.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example trail shoe"
}
Do not add fake ratings, reviews, prices, or hidden content to satisfy a validator.
When this is intentional or does not need fixing
A page may have no structured data and still be valid for search. A site can also use Microdata or RDFa instead of JSON-LD; the JSON-LD check does not judge those formats. Keep markup only when it describes the page accurately and supports a real consumer need.
Related issues
Read invalid JSON-LD, missing canonical URLs, and social metadata. Google’s structured-data policies explain quality and eligibility requirements.
Run a NOTABIS audit
NOTABIS confirms JSON-LD parseability in the measured HTML and records the detected types so you can follow up with a feature-specific validator.