en
/login
Koval SEO

A JSON-LD block fails the syntax check

In the reportInvalid JSON-LD structured data

structured_data_invalid_json · Issue

Short answer

This appears when our parser rejects a JSON-LD block in a page's HTML, for example because of a trailing comma or a comment. Search engines may ignore structured data that does not parse. Fix the syntax; a JSON validator shows the exact spot.

Severity: Low. Fix it when you next work on the page. It is Medium when the broken block holds a type the check counts for rich results, such as Product or BreadcrumbList, that no valid block on the page repeats, and our check sees no noindex that applies to Google and no canonical pointing elsewhere.

Why it matters

Google uses structured data to understand a page, recommends JSON-LD, and needs the required properties for a page to be eligible for enhanced display. A block that cannot be parsed provides none of that.

What to do

  1. Look at the finding: it shows parser details for up to five broken blocks that it reports, with the parser's message, the line and column and the types it could detect, and counts any other reportable ones.
  2. Fix the syntax at that spot, usually in the plugin, theme or template that writes the block; common causes are trailing commas, single quotes and comments.
  3. Run a new audit once the change is live, or test the page in Google's Rich Results Test.

What we read

We read every <script type="application/ld+json"> in the page's HTML, head or body, without running JavaScript, and parse it as JSON after removing HTML comment and CDATA wrappers, allowing one trailing semicolon. Trailing commas, single quotes, comments, NaN and two objects in a row all fail; a missing @context or an unknown type does not, because only syntax is checked.

A broken block is not reported when it has at least one detected type and all detected types are in this check's exclusion list, such as FAQPage or HowTo. Empty blocks and blocks over 100,000 characters are not parsed. Pages marked noindex are checked too, and kept at Low.

Example & evidence

Illustrative example — one JSON-LD block, not a live audit.

https://bakery.example/cakes/lemon-cake/ is indexable and names itself as canonical. Its head contains:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Lemon cake",
  "offers": {
    "@type": "Offer",
    "price": "24.00",
    "priceCurrency": "EUR",
  }
}
</script>

The comma after "EUR" makes the block invalid, so the page is reported: JSON-LD for Product cannot be parsed. The block holds Product and the page is indexable, so the finding is Medium.

A possible correction: delete that comma; the block then parses.

Confirm & check again

Check for yourself: copy the block into a JSON validator, or test the page in Google's Rich Results Test, which reports parsing errors.

Check again: Full audit — run a new audit of the site. The finding closes when the page is read again as a complete HTML page and no reportable block fails to parse. A block that grows past 100,000 characters, or a page that is only a frame for scripts, cannot be confirmed. A new full audit can also close it when complete evidence shows the address answering directly with 200 and a file that is not HTML, or starting with a permanent redirect whose whole chain stays within your site, provided the check gives a usable result.

Limits & sources

Only syntax is checked, not schema.org types, required properties or rich-result eligibility. Google can read JSON-LD that scripts add to a page, while this check reads the HTML as served, and microdata and RDFa are not parsed.

Confidence: High because the parser checks the block as captured, after removing supported wrappers and allowing one trailing semicolon, and records its error.

Sources

Editorial review: 29 September 2026