Structured Data with Syntax Errors Detected: How to Fix It

What a structured data syntax error means

Structured data is extra information you add to a page so search engines and AI systems can read facts about it without guessing: that a page is a product with a price, an article with an author, or a business with an address. Most sites write it as JSON-LD, a block of JSON inside a <script type="application/ld+json"> tag.

JSON is strict. One misplaced character makes the whole block unreadable, and a parser that cannot read a block does not try to rescue the parts that look fine. That is why a syntax error is more serious than other structured data problems:

The Unparsable structured data report groups errors by the parser's message. You will see wording such as Parsing error: Missing ',' or '}', Bad escape sequence in string or Missing ',' or ']' in array declaration. Each points at a specific kind of mistake, and the example URLs show you where to look.

The mistakes that cause it

JavaScript allows trailing commas, single quotes and comments, so code copied from a script often looks right and still fails. JSON-LD must be pure JSON.

A less obvious cause is duplicate generators. A theme and an SEO plugin can both print schema, and if one of them prints a half-finished block, that block is the one in the report. Two copies of the same type also make results harder to read; see plugin schema conflicts.

How to find the broken block

Take an example URL from the report and run it through the Rich Results Test. It reports the syntax error and highlights the line in the code view. Then look at the page yourself, because pages often carry several blocks and you need to know which one is broken.

In Chrome, open DevTools, go to the Console and paste this. It tries to parse every JSON-LD block on the page and reports which ones fail:

document.querySelectorAll('script[type="application/ld+json"]').forEach((s, i) => {
  try { JSON.parse(s.textContent); console.log(i, 'OK'); }
  catch (e) { console.log(i, 'BROKEN:', e.message); console.log(s.textContent); }
});

The error message gives a position, such as Unexpected token } in JSON at position 214. Count to that character, or paste the block into a JSON validator, and the mistake is usually just before it.

From a terminal, you can pull the blocks out of the HTML the server sends and test each one:

curl -sS https://example.com/product/shears/ | python3 -c '
import sys, re, json
html = sys.stdin.read()
for i, b in enumerate(re.findall(r"<script[^>]*application/ld\+json[^>]*>(.*?)</script>", html, re.S)):
    try: json.loads(b); print(i, "OK")
    except json.JSONDecodeError as e: print(i, "BROKEN line", e.lineno, "col", e.colno, e.msg)
'

Compare the server HTML with what DevTools shows. If the block is fine in the server HTML but broken in the browser, a script is changing it after load. If it is broken in both, the problem is in the template or the content.

The schema debugger and the JSON checker do the same job and point at the line and character of the first error.

Fix the template, not just the page

When a CMS fills JSON-LD from page fields, the content itself can break the markup. A product called 12" Brass Hinge, a description with a line break, or a name with a backslash will produce invalid JSON if the template pastes the text straight in. The fix is to build the data as an object and let a JSON encoder write it, so escaping is done for you.

PHP and WordPress

<?php
$data = [
  '@context' => 'https://schema.org',
  '@type'    => 'Product',
  'name'     => $product_name,
  'sku'      => $sku,
  'offers'   => [
    '@type' => 'Offer',
    'price' => $price,
    'priceCurrency' => 'GBP',
  ],
];
?>
<script type="application/ld+json">
<?php echo wp_json_encode( $data, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_HEX_TAG ); ?>
</script>

Outside WordPress, use json_encode with the same flags. JSON_HEX_TAG turns < and > into escape codes, so a value containing </script> cannot end the tag early.

Shopify Liquid

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | json }}
}
</script>

The json filter adds the surrounding quotes and escapes the content, so do not wrap it in quotes yourself.

Next.js and React

const data = { '@context': 'https://schema.org', '@type': 'Product', name: product.name };

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: JSON.stringify(data).replace(/</g, '\\u003c') }}
/>

Replacing < with its escape code does the same job as JSON_HEX_TAG. See JSON-LD in Next.js for where to place the block.

Platform notes

• WordPress. Most broken blocks come from custom code in the theme, a page builder's custom HTML widget, or two plugins printing schema. Pasting JSON-LD into the block editor's paragraph blocks can convert straight quotes to curly ones; use a Custom HTML block or a plugin field. See JSON-LD in WordPress.
• Shopify. Themes print product schema in a snippet. Apps can add their own, and an app removed without cleaning up can leave a half-written block. Search the theme code for application/ld+json. See JSON-LD in Shopify.
• Tag managers. JSON-LD injected through a tag manager is added by JavaScript after load. It can work, but Google must render the page to see it, and a variable that returns nothing can leave an empty value with a trailing comma.
• Static and hand-coded sites. Edit JSON-LD in a code editor that highlights JSON errors, never in a word processor or rich text editor.

A worked example

A hardware shop sees 140 product URLs in the Unparsable structured data report with Parsing error: Missing ',' or '}'. Running the console script on one of them shows block 1 broken. The relevant part reads:

"name": "12" Brass Hinge",

The inch mark ends the string after 12, and the parser then finds Brass where it expects a comma. Escaping it as "12\" Brass Hinge" fixes this page. Sorting the report shows every failing product has an inch mark or a quote in its name, so the template is the real problem. It was building the block with string joining; changing it to build an array and output it with wp_json_encode fixes all 140 at once. The Rich Results Test then reads a valid Product item, and the owner validates the fix in Search Console.

The fix, step by step

Edge cases worth knowing

• Microdata and RDFa errors. Unparsable structured data can also come from microdata or RDFa, such as an itemprop outside any itemscope. These are HTML structure problems rather than JSON ones; fix the nesting in the template.
• Valid JSON, wrong values. A block can parse and still be wrong, for example a price written as "£12.99" instead of "12.99". That shows as an invalid value rather than a syntax error; see schema errors.
• HTML entities in JSON. Some CMSs turn & into & inside script tags. It does not break the JSON, but the value then reads literally as &.
• Minifiers and optimisation plugins. A plugin that combines or minifies inline scripts can damage JSON-LD. Exclude application/ld+json blocks from inline script processing.
• Do not delete everything. Removing all schema hides the error but throws away the valid parts that describe the page. Fix the broken block instead.

Keeping your structured data valid

Syntax errors come back when content changes or code changes, so check both.

• Never build JSON-LD by joining strings. Build an object or array and let a JSON encoder write it.
• Keep one generator per schema type: either the theme, a plugin or your own code, not several.
• After a theme, plugin or app update, test one page of each template in the Rich Results Test.
• Add a check to your build or deployment that parses every JSON-LD block on a few sample pages and fails if any are invalid.
• Check the Unparsable structured data report in Search Console monthly; new entries usually follow a change you can name.

Our schema drift monitor watches your pages for markup that changes or breaks between checks.