Unparsable structured data: locating the character that breaks your JSON-LD

"Unparsable structured data" means a block of markup on the page is syntactically broken, so badly that Google cannot work out what type it is. One stray comma or unescaped quotation mark is enough. Open the report's example, find the reported position in the JSON, fix that character and revalidate.

The report sits under Enhancements in Search Console and appears only when Google has found such blocks. Because the type is unknown, these errors cannot be shown in the Product, Breadcrumb or other type-specific reports. A broken block is simply ignored: no rich result, no penalty.

What it looks like

Before

html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "24" monitor stand",
  "sku": "MS-24",
}
</script>

After

html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "24\" monitor stand",
  "sku": "MS-24"
}
</script>

Read the error name

Search Console groups unparsable items by parser message. The common ones translate as follows:

  • Parsing error: Missing ',' or '}'. Two properties with no comma between them, or a string that ended early because of an unescaped " inside it.
  • Parsing error: Missing '}' or object member name. Usually a trailing comma after the last property, so the parser expected another name and found }.
  • Parsing error: Missing ',' or ']' in array declaration. The same mistakes inside a [ ] list.
  • Bad escape sequence in string. A backslash followed by a character JSON does not recognise, such as \' or a Windows path like C:\files.
  • Invalid top level element. The script contains something that is not a JSON object or array: HTML, a JavaScript variable assignment, or an empty tag.

Click an example URL in the report. The side panel shows the block with the problem highlighted.

Reproduce it outside Search Console

Copy the contents of the <script type="application/ld+json"> element from view source, not from the browser's element inspector, which shows a cleaned-up version. Paste it into our JSON-LD validator. It reports the syntax error with its position, and once the JSON parses, lists missing required properties for the type.

From a terminal, Python's parser gives a line and column:

code
python3 -c "import json,sys; json.load(sys.stdin)" < block.json

The mistakes, in order of frequency

  1. Unescaped double quotes inside a value. Product names with inch marks, quoted titles, testimonials. Every " inside a string must be written \".
  2. Trailing commas. Valid in JavaScript, invalid in JSON. They appear when the last item of a list is deleted or when a template loop adds a comma after every item.
  3. Typographic quotes. “name” instead of "name". Curly quotes are not string delimiters.
  4. Raw line breaks in a string. A description copied with its paragraph breaks. Replace them with \n or a space.
  5. HTML inside the script. <p> and <br /> tags wrapped around or inserted between lines.
  6. Comments. // and /* */ are not allowed in JSON.
  7. Single-quoted strings and unquoted property names.

How WordPress introduces them

The editor reformats pasted JSON. Pasting a JSON-LD script into a paragraph or the Classic editor's visual tab runs it through the same typography filters as prose: straight quotes become curly, and line breaks become <p> and <br /> tags. Put hand-written markup in a Custom HTML block, where WordPress leaves it alone.

Templates build JSON by joining strings. Theme code like '"name": "' . get_the_title() . '",' breaks the moment a title contains a quote. Build a PHP array and print it with wp_json_encode(), which escapes every value:

php
$data = array(
    '@context' => 'https://schema.org',
    '@type'    => 'Article',
    'headline' => get_the_title(),
);
echo '<script type="application/ld+json">' . wp_json_encode( $data ) . '</script>';

Optimisation plugins rewrite the script. HTML minifiers and "combine inline scripts" features occasionally mangle JSON-LD or wrap it in a loader. Exclude application/ld+json scripts from minification and deferral.

Tag manager templates with unfilled variables. A variable that resolves to nothing leaves "price": , behind.

Markup generated by a schema plugin from structured fields does not have these problems, since it is encoded programmatically. Hydrogen SEO outputs its schema this way, server-rendered in the page head; the schema markup overview describes what it prints. When a site with such a plugin still shows unparsable items, look for a second, hand-pasted block on the affected URLs.

Fix it, then decide whether the block should exist

Correct the syntax and retest until the validator reports valid JSON. Then ask whether the block is still needed. Old hand-pasted markup often duplicates what a plugin now outputs, and two descriptions of the same thing can disagree. If the plugin covers it, delete the manual block. If you need a new block, our schema markup generator and FAQ schema generator produce escaped JSON-LD ready to paste.

Confirm in Google's tools

Run the URL through the Rich Results Test. A block that parses now appears under its type, where any missing-property issues become visible for the first time; fix those next. In Search Console, open the Unparsable structured data report, choose the error and click Validate fix. The free SEO audit also parses every JSON-LD block on the page you test and reports blocks that are invalid or lack @context and @type; that check is explained under invalid structured data.

Common questions

Does unparsable structured data hurt rankings?

No. The broken block is ignored. The loss is whatever rich result or understanding the markup would have provided.

Why does the report show fewer items than I expect?

It lists sample URLs Google has crawled recently. Templates that are broken everywhere may show only a subset; fix the template and all instances clear.

My JSON looks fine in the browser inspector. Why is it flagged?

The inspector shows the parsed document. Check the raw source, where curly quotes and stray tags are visible.

Can microdata be unparsable too?

Yes. The report also covers microdata and RDFa with broken nesting, though JSON-LD syntax errors are by far the most common cause.