Invalid JSON-LD (parse error)

Every <script type="application/ld+json"> block on the page is parsed as JSON. If any one of them fails, the finding is raised. It is the most straightforward check in the set: either it is valid JSON or it is not.

What the check does not do:

• It does not judge the contents. A block that is valid JSON but makes no sense (missing @type, invented properties, describing something other than the page) passes without comment.
• It does not validate against schema.org. A typo in a property name (autor instead of author) is valid JSON, so the check stays quiet even though nobody will read that field.
• It will not tell you which block is broken when there are several, only that at least one is.
• Unlike the other SCH-* checks, it runs on pages with an error status too. Broken schema is broken regardless of the status code.

The finding is page-level; severity is critical, the highest of all four schema checks. The reason is in the next section.

We have to be precise right away, because this looks like a contradiction: a critical severity alongside the “effect not demonstrated” class.

The class refers to what this product measures: visibility in AI answers. And there, exactly what applies to SCH-01 applies here: no documented effect of structured data on citations, measurements within noise, and information placed only in schema used by no platform tested. So invalid schema deprives you of no documented benefit, because nobody has documented one.

The critical severity is here for a different and solid reason: invalid JSON-LD does not work at all. It is not a degradation, it is a zero. The parser discards the whole block, not just the faulty property. If your product page carries one block with price, availability and rating, and it is missing a comma, you do not lose the rating. You lose the block.

And that is precisely when a finding is worth having: it is work you have already done that is being thrown away. Fixing it costs nothing extra, unlike schema you have yet to write. Hence critical: not because of the size of the impact, but because of the ratio between what it costs and what it returns.

Where the documented benefit does lie: with Google, in classic search. It uses structured data to qualify pages for rich results, and a broken block means you do not qualify. That is tangible; it is just not about AI.

Find the broken block by viewing the page source and pasting its contents into any JSON validator. The fault will be in one of five places, in this order of frequency:

1. An unescaped quotation mark in the text. The single most common cause. A quote inside a value must be \".
2. A trailing comma before a closing bracket. JSON, unlike JavaScript, does not allow it.
3. An unreplaced template placeholder. {{ product_name }} or an empty value where the data never got filled in.
4. A line break inside a string. A multi-line description must be written as \n, not as an actual newline.
5. Double-encoded HTML entities. The templating system ran the JSON through HTML escaping and turned " into ".

The first two look like this in code:

// Wrong: the quote in the text ended the string, plus a trailing comma
{
  "@type": "Product",
  "name": "Headphones "Pro" edition",
  "description": "Wireless headphones",
}

// Right
{
  "@type": "Product",
  "name": "Headphones \"Pro\" edition",
  "description": "Wireless headphones"
}

The real fix, though, is not repairing that one block. Almost always the cause is that the JSON-LD is assembled as text in a template: string concatenation, variables dropped into a prepared shape. Then a single product with a quotation mark in its name breaks the whole site.

The reliable fix is to build an object and let the language serialise it, rather than writing JSON by hand:

// Wrong: JSON produced as text
const ld = '{"@type":"Product","name":"' + product.name + '"}';

// Right: an object, serialised by JSON.stringify
const ld = JSON.stringify({ "@type": "Product", name: product.name });

Two things to finish with:

• Check more than one page. If the cause is in a template, it will only show on pages whose data contains the problem character, and that may be five products out of a thousand.
• Do not fix it by deleting the block. The finding goes away and so does the work you put into the schema. The repair is one character.