Broken JSON-LD is invisible JSON-LD, and nothing tells you

Hand-written JSON-LD rarely breaks, because you look at it. Generated JSON-LD breaks constantly, and almost always in one of these ways.

• A trailing comma. Legal in a JavaScript object literal, illegal in JSON, and the mental model everyone brings to writing braces is the JavaScript one. A conditional block that emits a property with a comma and then emits nothing after it produces this every time.
• An unescaped double quote from a value. The most common cause by a wide margin, and the one that arrives from content rather than code. A product called 13" frame, a headline with a quoted phrase in it, an author who signs with a nickname in quotes. Each one closes the JSON string early and everything after it is garbage.
• HTML entities where JSON wants characters. A field arrives as Costs & savings and the block now contains a literal entity, not an ampersand. Where this turns fatal is when the escaping hits a structural character and the quotes around a value become ", at which point there are no string delimiters left.
• A </script> sequence inside a value. Valid JSON, lethal HTML. The parser ends the element at the first </script it sees, wherever that is, so the remainder of your JSON becomes text in the page and the block is truncated mid-object. A tutorial about script tags breaks its own markup by describing it.
• JSON assembled by concatenation. Building the block by adding strings together means every comma, brace and quote is your responsibility on every code path. Any value that turns out to be null, undefined or a number formatted for display puts an unquoted token into the output.
• The element rewritten in transit. Minifiers, optimisation plugins and tag managers all touch script tags. One that reorders, inlines or re-emits your block can lose or alter the type attribute, and the exact attribute value is what makes anything look inside. Test the deployed page, not the local one.

Three of those, in one real block that shipped:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Why we left the "enterprise" plan",
  "description": "Costs &amp; what we cut",
  "author": { "@type": "Person", "name": "R. Iyer" },
  "datePublished": "2026-02-11",
}
</script>

The quotes around enterprise came from a CMS title field. The & came from a template that HTML-escapes every interpolation. The comma after the date came from a conditional image property that was not emitted because the post had no image. Any one of them alone discards the whole block.

The reason this is not a single-page question in practice: a parse failure triggered by a content value affects every page whose data contains that value, and no page that does not. One product with an inch mark in its name breaks one product page out of four hundred, and checking your own homepage will never find it.

Severity here is not about the value of the markup. It is about the gap between what you believe you shipped and what is actually being read. Every other Critical failure on the catalogue is visible to somebody: a broken link 404s, a redirect chain shows up in a waterfall, a noindex tag is right there in the source. This one reports success at every layer a person would think to look at, so the belief persists for as long as nobody specifically tests it. Teams have carried this for years.

The second half of the argument is blast radius, and it is the reason this outranks simply having no markup. JSON-LD comes out of a template, so the fault is never one page. It is every page of that type. And because the trigger is usually a data value rather than a code change, it appears months after the deploy that was tested, the first time an editor types a quotation mark into a title field. Nothing in your pipeline runs at that moment. The scale is defined on the audit page, and this sits at the top of it because the cost is not the missing markup, it is the confidence that the markup is fine.

Do not test this by eye and do not test one page. Fetch the HTML, extract every ld+json element and attempt to parse each one. Anything that throws is a block you do not have. Thirty lines of Node, no dependencies, and it exits non-zero so it can sit in CI.

const url = process.argv[2]
const html = await fetch(url).then((r) => r.text())

const blocks = [
  ...html.matchAll(
    /<script[^>]+application\/ld\+json[^>]*>([\s\S]*?)<\/script>/g,
  ),
]

if (!blocks.length) {
  console.error(`${url}: no JSON-LD found`)
  process.exit(1)
}

blocks.forEach(([, body], i) => {
  try {
    const parsed = JSON.parse(body)
    const type = parsed['@type'] ?? parsed['@graph']?.map((n) => n['@type'])
    console.log(`block ${i + 1}: parses, @type ${JSON.stringify(type)}`)
  } catch (err) {
    console.error(`block ${i + 1}: ${err.message}`)
    process.exitCode = 1
  }
})

Run it against the deployed URL rather than a local build, so anything your host or your optimisation layer does to the markup is included in the test. Then point it at the pages most likely to break: the longest product name you sell, the post with a quoted phrase in its title, anything with an apostrophe or a measurement in it. Those are the rows that fail, and they are never the homepage.

For a one-off check by hand, validator.schema.org reports a parse error with a position and does not filter by feature support. Once it parses, you have cleared this rung and moved on to the next one, where a block that parses and still earns nothing is a different problem with an identical appearance.