Unparsable Structured Data in Search Console: Causes and Fixes

What is the unparsable structured data error and what should you do first?

Unparsable structured data means Google found a structured data block on your page but could not read it because of a serious syntax error. The error is so basic that Google cannot even tell which type the markup was meant to describe. In the Search Console interface, the report carries the name "Unparsable structured data".

Do not panic, because the cause is usually tiny, such as a single comma or quote mark. The error also does not lower your rankings directly. The real loss is that those pages can no longer qualify for rich results. Here is what to do on day one:

1. First, open the report in Search Console and click the error row to see the affected pages.
2. Then pick one sample page and paste its address into Google's Rich Results Test.
3. Next, read the error message and line reference to find the broken spot.
4. Then test two or three more pages to learn whether the problem sits on one page or in a whole template.
5. Finally, publish the fix, then start validation in Search Console.

We walk through each step below. If you need a refresher on the basics, read our guide on what schema markup is. This article only covers repairing broken markup.

How does this report differ from other structured data reports?

In rich result reports for products, recipes or events, Google recognizes the type and tells you which fields are missing. In this report, Google cannot determine the type at all. According to Google's help page, the report lists structured data that could not be parsed because of a serious syntax error.

Another difference is that the report only appears when there is a problem. Google's documentation says it shows up in your property only if unparsable data was found. So if you never see it, that is a good sign.

Also, every item in the list counts as a critical error. There are no warnings and no valid items. Google sorts the errors by severity, based on the number of affected pages and other factors. Starting at the top row is therefore usually the most efficient approach.

On the other hand, a missing required field does not belong here. You track that in the matching rich result report. This article stays at the syntax level.

Which error types can you see in the report?

Google's help page lists many different parsing errors. We do not translate interface strings for you. Instead, we give the English names in quotes, and your panel will show something similar.

• "Invalid JSON document": The block cannot be read as a whole.
• "Incorrect value type": A field received a value of an unexpected type.
• Parsing errors such as "Parsing error: Missing ':'": A required punctuation mark is absent.
• Escape sequence and Unicode problems: Special characters use the wrong encoding.
• "Duplicate unique property": The same field appears twice in one object.

This list is not complete, because the help page names more error types. The description on your row is your first clue about the error family. So note the error name, then compare it with the output of the Rich Results Test.

Which JSON-LD syntax mistakes cause the error?

JSON-LD is the format Google recommends for markup. A machine reads it, so it forgives none of the small slips that a human eye would skip. We will describe the most common syntax mistakes without showing code.

• Missing comma: Forget the separator between two fields, and the block breaks in the middle.
• Extra comma: A comma left after the last field stops many parsers.
• Missing or extra quote mark: The opening and closing quotes of a text value do not match.
• Unclosed bracket: An object or list opens but never closes.
• Unquoted field name: Field names need quotes as well.

For example, a team edits a block by hand and adds a new field, but skips the comma before it. The whole block then becomes unreadable. A single character can throw away your entire markup.

Spotting these mistakes by eye is hard. You need a parser for that, and we describe the tool in a later section.

Why do escape characters and quotes trigger this error?

Text values in a markup block sit inside double quotes. If your title or description contains a double quote, you must escape it with a special marker. Without that marker, the parser thinks the text ended early and finds the rest meaningless.

This problem shows up most often in dynamic templates. A product name or post title flows into the block automatically. If one title contains a quote, a backslash or a line break, only that page breaks. As a result, the error may appear on a handful of pages out of hundreds.

Watch for these sources:

• Smart (curly) quotes and invisible special characters pasted from a text editor.
• Line breaks inside description fields.
• File paths or product codes that contain backslashes.
• Characters with broken encoding, which the parser may report as a Unicode error.

The fix is to escape every value automatically before it enters the block. You usually correct this in one place in your template code.

Can an invalid date or number format cause this error?

Mostly no, although it can happen indirectly. A wrong date format alone does not break the JSON. For that reason, date problems normally show up as warnings or errors in the relevant rich result report. Still, a row such as "Incorrect value type" can point to a field that received the wrong kind of data.

These cases do cause real parsing errors:

• A unit or currency symbol added to a number field, which turns the value into unquoted text.
• An empty template variable that leaves a field name with no value after it.
• A number written with a decimal comma and no quotes.
• A word such as "unknown" placed where a date belongs, without quotes.

In practice, use the international ISO format for dates, write numbers with a decimal point, and move units into a separate field. In addition, add a condition in your template for every field that might be empty: if there is no value, skip the field entirely.

How do you find a broken second block on the same page?

A page can hold several markup blocks. Your theme may output one, your SEO plugin another, and a review plugin a third. If only one of them is broken, the report still raises an error even though the others are fine.

So when you test a page, do not look only at the first block. The Rich Results Test lists results item by item. There you can separate the healthy types from the block that cannot be parsed. If the tool finds no types at all, the broken block may be the only one.

Use this method to find it:

1. First, open the page source and count the markup blocks.
2. Then work out which plugin or template file produces each block.
3. Next, disable the suspect source temporarily and retest the page.
4. Finally, if the error disappears, you have found the culprit.

This approach gives the fastest result when plugins conflict.

How does a plugin conflict create unparsable structured data?

In systems such as WordPress, several plugins try to mark up the same information. One tags the page as an article, another as a product. Most of the time the problem is a duplicate declaration. Sometimes, however, a plugin damages or truncates the output of another one.

Typical scenarios look like this:

• A cache or minify plugin changes line breaks or quotes in the output.
• A security plugin strips special characters from the block and breaks its structure.
• An old theme and a new SEO plugin both write the same field.
• A translation plugin alters quote marks while it translates values.

Here is an example scenario: If the report turns red right after you install a new SEO plugin, that plugin is your first suspect. Disable it, clear the cache and test again. If your site crashes instead, you have a different problem, and our article on the WordPress critical error can help.

To resolve the conflict, let only one source produce each type. Turn the feature off in the other source.

Why do template errors affect thousands of pages?

Google's documentation says the most common reason a single error affects many pages is an underlying template error. That makes sense, because the same code runs on every page. If a comma disappears from the template, every page that uses it breaks.

The number of affected pages therefore gives you a hint. If only a few pages fail, a content-driven quote or special character is likely. If hundreds fail, inspect the template.

Follow this order when you fix a template:

1. First, identify the template the affected pages share, such as product, blog or category.
2. Then inspect that template's markup output on one sample page.
3. Next, check whether the variable values are escaped.
4. Then add conditions for the case where a value is empty.
5. Finally, test the fix on a staging copy first, then on the live site.

A template fix often rescues hundreds of pages in one go. So look for the shared cause first.

How do you diagnose a broken page step by step?

Working systematically is much faster than guessing. Google's debugging guidance for missing structured data suggests a similar order: confirm the page is indexed, then validate the data, then make sure nothing blocks access.

1. First, open the error row in Search Console and choose a sample address.
2. Then use the URL Inspection tool to confirm the page is indexed and that Google sees the current version.
3. Next, run the same address through the Rich Results Test and read the error line.
4. Then check the balance of commas, quotes and brackets in the code the test shows.
5. Next, if needed, run the page source through a JSON validator.
6. Finally, once you find the cause, apply the fix and repeat the test.

If the live test itself fails, our article on the URL Inspection "Page resources couldn't be loaded" message may help. Also, if Search Console is new to you, start with our guide to using Google Search Console.

How do you confirm the fix with the Rich Results Test?

The Rich Results Test is Google's free tool for validating markup. The help page tells you to use it to fix unparsable data and to test your repairs in small steps. You can use it in two ways: enter a live address, or paste a code snippet.

Pasting code is ideal for trying a fix before you publish it. That way you see a risky change before it reaches the live site. After publishing, always retest the live address.

During the test, watch for these points:

• Does the tool report a parsing error, or does it list the types successfully?
• Do all the types you expected appear?
• Is the tested version the same one your visitors see?

Note: A passing test does not mean a rich result will appear. Google does not guarantee that, even for correctly marked up pages.

If you build markup from scratch, our schema generator gives you a syntax-clean starting point.

How do you validate the fix in Search Console?

After you publish the repair, open the error row in Search Console and click the "Validate Fix" button. Google then rechecks the affected pages. Menu and button names can change over time, so look for a similar label in your panel.

Google's documentation describes these validation states:

• "Started": The check has begun.
• "Looking good": The pages checked so far are fixed.
• "Passed": All known instances are resolved.
• "Failed": The issue persists, and you must restart validation.

Before you start validation, make sure you fixed every affected template. If you begin with a partial fix, validation fails and the process restarts. So test a few sample pages first, then press the button.

If a page is not indexed, solve that problem first. Our article on how to find unindexed pages shows you how.

How long does validation take, and why can it fail?

Google's help page says validation typically takes about two weeks, and in some cases much longer. We cannot shorten that, so do not panic while you wait. Your crawl frequency and the number of affected pages both influence the timing.

Validation can fail for these reasons:

• You fixed only some pages, and other templates remain broken.
• A cache keeps serving the old version.
• The broken block comes from a different plugin.
• The pages are blocked from Googlebot or marked noindex.

If validation fails, reopen the new sample addresses in the error row. Usually a second source slipped past you.

On the other hand, a "Passed" result does not mean the error cannot return. The prevention section below explains how to keep it away.

Why do the numbers in the report not change right away?

Reports are not real time. The numbers update as Google recrawls and reevaluates pages. In addition, Google's documentation notes that related reports show only a sample of your pages. Fixing one page therefore does not mean it disappears from the report the next day.

The main reasons for the delay are these:

• Googlebot has not recrawled the page yet.
• Discovering new data takes time.
• The report covers only indexed pages.
• The item count shifts when the sample size changes.

To speed things up, you can request indexing for key pages through URL Inspection. Keep in mind that a daily quota applies. Our article on the Search Console quota limit explains the details.

Which cause should you check first for each symptom?

The table below summarizes the patterns we see most often in the field. Treat it as a starting guide, because every site differs.

Start with the first row, because a template problem affects the most pages and gives the fastest win.

How do you prevent this error from the start?

Prevention costs less than repair. For sites that publish new pages all the time, a few habits make a big difference.

• Use a reliable generator or plugin instead of writing markup by hand.
• Escape dynamic values before they enter the block, and skip empty values.
• After any template change, test a sample page with the Rich Results Test before release.
• Let only one source produce each markup type.
• Check the report after every plugin and theme update.

Also keep Search Console email notifications on. That way you hear about a new error row quickly.

On pages that target rich results, make sure the content matches the markup. Google asks you not to mark up content that visitors cannot see.

Does unparsable structured data hurt your rankings?

Do not expect a direct ranking drop, but the indirect loss is real. A page with a broken block cannot qualify for the related rich result feature. As a result, your click-through rate, visibility and competitive edge can shrink.

Even so, markup never guarantees that Google shows a rich result. So treat it as a way to describe your page correctly, not as a ranking trick. If your traffic dropped, first separate the cause using our Search Console traffic drop guide.

For example, if a page lost traffic, compare its search appearance before you blame the markup. In most cases, the real cause is something else.

A syntax error does not care about the markup type. FAQ, article, product or organization, a broken block is unreadable either way. Because support for some types changes over time, simplify old markup such as FAQPage schema. If you use rating markup, also read our notes on AggregateRating guidelines. A type losing support is no excuse to leave it broken.

How do you read and prioritize the unparsable structured data report?

When you open the report, check the order of the error rows first. Google sorts rows by severity, so the error with the most affected pages sits on top. Click a row to see the affected pages, the error details and links to debugging tools.

We suggest this prioritization order:

1. First, start with the row that affects the most pages, since a shared template may sit behind it.
2. Then choose two or three sample pages from different categories in each row.
3. Next, test the samples and note the error family.
4. Finally, merge rows with a shared cause into one fix task.

To show the report to a teammate or developer, use the share link. Google's documentation says the link gives read-only access to the current issue. You can also export the page list with the download button.

Keep your unparsable structured data rows in a separate task list from other technical issues. That way you can track what is fixed more easily.

How do cache and minify settings break markup?

In some setups, the page output passes through a cache, a minifier or a security layer before it reaches the visitor. These layers are normally harmless. When misconfigured, though, they can alter whitespace, line breaks or quotes inside a block.

The telltale sign is this: the page looks healthy in your admin panel but is broken on the live site. For that reason, testing a live address is more reliable than testing pasted code alone.

When you suspect this cause, do the following:

• Clear the cache and retest the page.
• Turn off minification temporarily.
• Review your firewall or content filter rules.
• Try a single page first, then roll out to the whole site.

If the error disappears, you have identified the layer responsible. Add the block to that layer's exclusion list.

How does a fix play out in an example scenario?

The following is an example scenario that we made up for illustration, not a real client. A small online store uses product markup on its product pages. One day, Search Console shows an unparsable structured data row with dozens of affected pages.

1. First, the store owner opens the row and runs three different product pages through the Rich Results Test.
2. Then the tool shows a parsing error near the product name field on all three.
3. Next, the owner notices that the product names contain an inch mark, which is the same character as a double quote.
4. Then the template writes the product name into the block without escaping it.
5. Next, a developer changes the template so it escapes the value.
6. Finally, the owner retests the live pages and then starts validation.

In this scenario, the problem appeared only on certain products, because only their names contained the special character. So the error looks random at first glance. In fact there is a rule, but you must compare affected and unaffected pages to find it.

Which checks should you run after the fix?

After you publish the fix, do not settle for a green result in the test tool. A few extra checks keep the error from returning.

1. First, retest the live addresses with the Rich Results Test.
2. Then confirm in URL Inspection that the page is indexed.
3. Next, test at least one more page from each different template.
4. Then clear the cache and check the result again.
5. Next, start validation in Search Console and watch the status.
6. Finally, after a few weeks, look at the related rich result reports for changes.

Also write the repair into a change log. Note what was broken, how you solved it and which template was affected. That note will save you time at the next plugin update.

Is a page still listed in the report really broken?

Not always. An address in the report reflects the state Google saw at its last crawl. If you repaired the page but Google has not recrawled it, the address stays on the list.

So run the live test first. If the tool returns a clean result, the page is healthy now, and all you need to do is start validation and wait. If the tool reports an error, your fix has not reached the live site yet, or another source is broken.

In addition, the report covers only indexed pages and a sample. A page you do not see in the list can still be broken. Keep that in mind to be sure your template fix reaches every page.

Which checkpoints should you add to your release process?

Seeing an error in Search Console means the problem is already live. A better approach is to catch it before release. You do not need heavy infrastructure for that. A short checklist is often enough.

• Before a template or plugin change, pick one sample page of each template type.
• After the change, test those samples with the Rich Results Test.
• Create a test page whose title contains a quote, a slash or an emoji, and test that too.
• Test a record with an empty field as well, so you catch errors caused by empty values.
• A few days after the update, open Search Console and look for new error rows.

This habit is especially valuable on busy e-commerce and content sites. Template errors spread silently across hundreds of pages, while the checklist takes only a few minutes.

When should you get professional help?

If the error sits on a single page, you can usually fix it yourself. However, expert eyes save time when hundreds of pages fail, when themes and plugins overlap, or when validation fails again and again.

At Talha Aslan and team, we run this kind of technical audit as part of our SEO consulting work. We first inspect the template output, then separate the sources one by one. We cannot promise a result, but we can show you exactly where the problem lives.

If you prefer to check things yourself, our SEO checker is handy for a first pass. And if you want to automate repetitive audits, our AI reporting automation solution can help.

For a related topic, our sibling guide on appearing in People Also Ask shows how to structure content as questions. For official sources, read Google's Unparsable structured data report help page, the guide to debugging missing structured data, and the general structured data guidelines.