ClickflowClickflow

Unparsable Structured Data in Google Search Console: What It Means and What to Fix First

What "Unparsable structured data" means in Search Console

The Unparsable structured data report lists structured data Google found on your site that it could not parse because of a serious syntax error. According to Google's help page for the report, the error is bad enough that Google can't even tell which type you intended (Article, Product, Event, and so on). The JSON-LD or Microdata never got as far as being checked field by field.

That makes it different from the type-specific rich result reports under Enhancements (Breadcrumbs, Product snippets, Review snippets, and so on). Those reports cover markup Google parsed successfully, then found a missing or wrongly typed field in. The unparsable report catches problems one step earlier, where the syntax is too broken to read at all.

One more distinction. This report is about the markup on the page, not the page's indexing status. A page can be indexed and earning impressions while carrying a broken JSON-LD block. What you lose is the structured data in that block and any rich result it was meant to earn. Indexing problems show up separately in the Page indexing report.

Below: how to confirm the error, trace it to the template producing it, fix it with a serializer instead of string-building, and validate the repair.

Why every item in this report is a critical error

Google's help page is explicit: every item in this report is a critical error, and there are no warnings or valid items. Each row means a markup block Google could not use at all.

The report only appears in a property if Google actually found unparsable structured data on the site. If you can't find it in your Search Console, you don't have this problem.

Confirm the error before you fix anything

Resist the urge to start editing templates the moment you spot the report. Confirm what you're dealing with first, because misdiagnosing a template-level issue as a page-level one (or vice versa) wastes time.

Inspect a single affected URL

Open the error row in Search Console and pick one affected URL. Run two checks on it.

First, open the URL Inspection tool and click "Test live URL." That tells you whether the current version of the page still has the problem or whether the report is showing an older crawl.

Second, paste the same URL into the Rich Results Test. It reports the parse error and points you to where in the markup it happens.

Then view the page source yourself. Search for <script type="application/ld+json"> and read the raw JSON-LD. You'll often spot the problem faster in source than in any tool output.

Check whether the error is template-wide

Look at the list of affected URLs.

Are they all blog posts? All product pages? All FAQ pages?

If dozens or hundreds of URLs share the same error type and the same page template, you are almost certainly looking at one template bug. Google's help page says the most common cause of a single error affecting many pages is an underlying template error. Confirm that before you touch code, so one template change clears the batch instead of a page-by-page cleanup.

Fix order: start with the cheapest check

Once you know whether the problem is page-level or template-level, work through these causes in order. The first two are the cheapest to check and usually take minutes to fix.

Unescaped characters injected from CMS fields

Check this first.

Your CMS template probably injects changing content (page titles, FAQ answers, product descriptions) directly into a JSON-LD string. When that content contains a double quote, a backslash, or a line break, it breaks the JSON.

Here's what a broken escape looks like versus the fix.

Broken:

{
  "@type": "Product",
  "name": "The 8" Chef's Knife"
}

Fixed:

{
  "@type": "Product",
  "name": "The 8\" Chef's Knife"
}

The unescaped double quote after the 8 ends the string early, so the parser hits text where it expected a comma or closing brace and reports an error such as "Missing ',' or '}'". Backslashes and raw line breaks pasted into a CMS field cause the related "Bad escape sequence in string" and "Invalid JSON document" errors. Every page whose title contains one of those characters breaks the same way.

One template fix, hundreds of errors resolved.

Trailing commas and missing braces

Hand-edited JSON-LD templates love to accumulate trailing commas. You remove a property and leave the comma on the line above. Or you add a property and forget the comma before it.

These show up as errors such as "Missing ',' or '}'", "Missing '}' or object member name", or "Missing ',' or ']' in array declaration". If the Rich Results Test points to a specific spot, count braces and commas backward from there.

The error is usually one or two lines above where the parser choked.

Overlapping scripts or minification damage

Two plugins each writing their own <script type="application/ld+json"> block is fine on its own. The risk is an optimization or caching plugin that rewrites inline scripts, treating JSON-LD as if it were JavaScript to combine, defer, or minify. That can strip quotes, merge blocks, or cut one off partway.

Turn the optimization off temporarily and retest the page. If the error disappears, exclude JSON-LD script blocks from that plugin.

Wrong value types

Google's help page describes "Incorrect value type" as a field holding the wrong kind of value, for example a string where a number or an array was expected. Check the structured data documentation for that type to see what each field requires.

Watch for templates with conditional logic that sometimes outputs an array and sometimes a single bare value for the same field.

JavaScript-injected markup that renders incomplete

If your structured data is injected with client-side JavaScript, anything that interrupts the script can leave the JSON-LD incomplete: a script error, a race condition, or a consent tool that blocks the script from running.

Google does read structured data generated with JavaScript, and its guide to generating structured data with JavaScript covers Google Tag Manager and custom scripts. It also warns that dynamically generated Product markup can make Shopping crawls less frequent and less reliable.

The Rich Results Test renders the page, so use it to check whether the injected markup actually completes. If it doesn't, generate the JSON-LD on the server instead.

Common causes of unparsable structured data mapped to the template-level fix for each

Fix at the template

If you traced the error to a blog post template and 300 posts are affected, fix the template once. You don't edit 300 posts.

The strongest move is to stop building JSON-LD by concatenating strings. Use a proper serializer instead.

  • PHP: Build an associative array, then output it with json_encode(). It handles escaping automatically.
  • JavaScript (Node/SSR): Build an object, then output it with JSON.stringify().
  • WordPress/Shopify: If you're using a plugin, make sure it's actively maintained. If you're using a custom Liquid or PHP template, run dynamic values through the platform's JSON filter (| json in Liquid).

String concatenation is how unescaped quotes and missing commas happen in the first place. A serializer eliminates the entire category of error.

If you can't spot the problem, use the approach Google suggests on its help page: start from an empty object, then add your fields back piece by piece until the error returns.

Verify the fix (and expect new errors to surface)

After deploying your fix, confirm it worked before asking Search Console to revalidate.

Run the fixed URL through the Rich Results Test or the Schema Markup Validator and confirm it returns parsed structured data items with no syntax errors. The Rich Results Test shows which rich result types Google detects. The Schema Markup Validator checks broader schema.org compliance.

Use both if you want to be thorough.

Once the tools confirm the fix, go back to the Unparsable structured data report and click Validate Fix on the error. Google rechecks the affected pages as it recrawls them, so the count can take a while to drop. Don't panic if it doesn't move the same day.

Validation flow: deploy the fix, retest, click Validate Fix, Google recrawls, then check the reports

Hidden errors will surface after parsing succeeds

Here's the part most guides skip.

Google's help page warns that fixing a parsing error can trigger new warnings or errors that were hidden because the item couldn't be parsed at all. A Product block that was unparsable might now parse and turn out to be missing a field that its rich result type needs. Those errors appear in the matching Enhancements report.

That means your fix worked. The markup went from unreadable to readable but incomplete. Handle the new type-specific errors in their own reports. If a validation run comes back failed, the workflow in Validation failed in Google Search Console applies here too: fix, retest, revalidate.

What not to do

Some fixes create worse problems than the original error. Avoid these.

Don't delete all structured data to clear the report. If your pages benefit from structured data (and most do), removing it trades a fixable syntax error for permanently lost rich result eligibility. Fix the syntax. Only remove markup you never needed in the first place.

Don't mass-click "Request Indexing" for markup fixes. Request Indexing is for getting new or updated content crawled. Structured data fixes go through the Validate Fix workflow, which handles recrawling automatically.

It doesn't speed anything up here and it uses up your request quota.

Don't add markup for content that isn't on the page. Google's structured data guidelines say markup should describe content that is visible to users on the page. Adding hidden markup to make up for a broken block can get the page excluded from rich results.

If you are chasing a traffic change, keep this report in proportion. Broken markup costs you rich result eligibility, not the page's place in the index. If impressions are up and clicks are down, work through how to diagnose impressions up, clicks down and check Search Appearance before blaming the markup. For a page that is indexed but shows little content, see page indexed without content.

Frequently asked questions

Does unparsable structured data hurt my rankings or indexing?

Not directly. The error is about the markup, not the page. Google can't use the broken block, so the page loses any rich result that markup was meant to earn, but the page itself can still be crawled and indexed. Indexing problems are reported separately in the Page indexing report.

Why does the report list pages I never added structured data to?

Themes, SEO plugins, review widgets, and ecommerce apps often add JSON-LD or Microdata automatically. View the page source, find each structured data block, and work out which theme, plugin, or app wrote the broken one.

Should I use the Rich Results Test or the Schema Markup Validator?

Use the Rich Results Test to see what Google can read and which rich result types it detects. Use the Schema Markup Validator to check markup against schema.org in general, including types Google doesn't show as rich results. For this report, the Rich Results Test is the one that matters.

Can multiple structured data formats on the same page cause parsing issues?

Mixing formats isn't an error by itself, but JSON-LD and Microdata generated by different systems can conflict or duplicate each other. Standardize on one approach per template (usually JSON-LD) and make sure every generator produces valid output on its own.

Keep the markup readable

Unparsable structured data usually comes from one template building JSON by hand. Fix the template, serialize instead of concatenating, and validate once. ClickFlow connects to Search Console and helps you keep track of indexing issues and content performance, so you spend less time in diagnostic mode and more on the pages that drive traffic.