Common Structured Data Errors (and How to Fix Them)

TL;DR — A structured data error means the schema markup on your page has a problem. Either it’s written wrong and the search engine can’t read it at all, or it reads fine but is missing something Google needs to show the fancy result (star ratings, product prices, breadcrumbs). Fixing errors wins back that fancy result — it does not move you up in the rankings, because structured data isn’t a ranking factor.

What a structured data error is

Structured data (also called schema markup) is extra code you add to a page that tells search engines what your content means — “this is the price,” “this is the author,” “this is the rating.” When that code has a problem, you get a structured data error, and the reward it was supposed to earn — a richer, more eye-catching search listing called a rich result — doesn’t show up.

Errors come in two flavors:

• The code is broken. A typo like an extra comma or an unclosed quote can make the whole block unreadable. The search engine can’t even tell what you were trying to describe.
• The code reads fine but is incomplete or wrong. You left out something Google requires (like a product image), or you put text where Google expected a number, or you marked up something that isn’t actually visible on the page.

Errors vs. warnings — do I have to fix this today?

This distinction saves a lot of panic:

• An error means a required piece is missing or broken. The rich result can’t show at all until you fix it.
• A warning means a recommended (but optional) piece is missing. The rich result can still show — it’s just a little less complete.

So an error is “fix this to get the feature,” and a warning is “you could make this better.” Not everything Google flags is urgent.

Where you’ll see these errors

Three places, and people mix them up constantly:

• The Rich Results Test — you paste in one URL or a code snippet, and Google tells you what rich results it found and any errors. It also previews how the result might look.
• Search Console’s Rich result report — an ongoing, site-wide view that watches for errors across your pages over time.
• The Schema Markup Validator — run by schema.org (not Google). It checks whether your code is written correctly, for any type of schema, whether Google uses it for a rich result or not.

The thing most people get wrong

Fixing structured data errors won’t make you rank higher. Structured data isn’t a ranking factor. The reason to fix errors is to win back the appearance — the stars, the price, the breadcrumbs — which can get you more clicks. That’s a real benefit, but it’s not the same as ranking.

One more: only mark up things that are actually on the page. Describing content a visitor can’t see breaks Google’s rules and can earn you a penalty — more serious than just quietly losing the rich result. (More on that, plus the two-tool trap and the “why does my markup validate but still not show?” mystery, in the Advanced tab.)

Want the full taxonomy of error types, the malformed-JSON gotchas, the deprecated FAQ situation, and how to debug each one? Switch to the Advanced tab.

TL;DR — Structured data errors split into parsing errors (malformed JSON-LD — trailing commas, unescaped quotes, missing colons or braces — that break the markup so badly Google can’t determine the type; these land in the Unparsable structured data report) and eligibility errors (the markup parses but fails a rich-result rule: missing required property, wrong value type, or markup describing content not visible on the page). Errors can block; warnings are non-critical — a missing required property can kill feature eligibility, while a missing recommended one generally preserves eligibility but may limit available information. Content mismatch is the one class with teeth — a policy violation that can trigger a manual action, not silent ineligibility. A separate failure mode isn’t an error at all: a deprecated/unsupported type (FAQ, gone by May 2026) is valid markup that earns no visual. Debug with three different tools — Rich Results Test (Google eligibility + preview), Schema Markup Validator (schema.org syntax, any type), and Search Console’s Rich result report (site-wide, sampled). Structured data isn’t a ranking factor, so a fix wins back a SERP visual, not a ranking.

Errors vs. warnings — what actually blocks a rich result

Before the taxonomy, get this distinction straight, because most guides use “error” as a catch-all and it causes needless panic.

• An error means a required property is missing or invalid, or the markup is unparsable. The item can’t be a rich result until you fix it.
• A warning means a recommended (not required) property is missing. The rich result can still show — just less completely.

Google’s own guidance leans toward accuracy over padding: “it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” In other words, don’t chase every warning by stuffing in half-accurate data — that can create worse problems than the warning it solves.

Worth knowing: even Google’s own reporting isn’t infallible here. In October 2022 Search Console had a bug where some issues were mislabeled as errors when they were actually warnings; Google’s fix moved them “from the critical error table to the warning table,” and clarified it was “strictly a reporting issue and did not affect whether or not a rich result could be displayed” (Search Engine Land, Oct 2022). The lesson: when in doubt, cross-check a flagged item against the Rich Results Test rather than trusting one report blindly.

Malformed JSON-LD — the “unparsable” errors

This is the most fundamental error class: the markup is broken badly enough that Google can’t even determine the intended type. Google files these in a separate Unparsable structured data report rather than a per-type report, because there’s no type to attribute the item to. Google’s own description: an item lands here because of a “serious syntax error” and “the intended type of structured data (Job, Event, and so on) could not be determined because of the parsing error.”

The usual culprits:

• Trailing commas. A comma after the last property in an object or array is valid in JavaScript but invalid in JSON. This is the single most common way hand-written or template-concatenated JSON-LD breaks.
• Unescaped quotes. A double quote inside a string value that isn’t escaped (\") terminates the string early. Google’s documented error for this is “Bad escape sequence in string.” Product names, review text, and descriptions with inch marks or quoted phrases are the classic offenders.
• Missing colons or braces. Google documents these verbatim as “Parsing error: Missing ’:’” and “Parsing error: Missing ’,’ or ’}’” — usually a copy-paste or string-concatenation accident.
• Wrong value type inside otherwise-valid JSON. Google’s “Incorrect value type” — e.g., a numeric field wrapped in quotes when a number was expected. (This shades into the eligibility errors below; when it’s bad enough to break parsing, it lands here.)

How to debug: strip to an empty object, rebuild piece by piece

Google’s own debugging tip for unparsable markup is refreshingly low-tech: “If you are having problems finding the error, try starting from an empty object, then add back content from your broken code piece by piece.” Paste the stripped-down object into the Rich Results Test, confirm it parses, then add properties back until it breaks — the last thing you added is your culprit.

One caution straight from Google: fixing a parsing error “might trigger additional warnings or errors that were hidden because the item could not be parsed at all.” One fix can unmask the next layer, so re-test after every change.

Missing required fields and wrong value types

Once the JSON parses, the next error class is about the contents: is every required property present, and is every value the right type?

Required vs. recommended (again, but at the property level)

Every Google-supported type has required properties (leave one out and you lose eligibility — that’s an error) and recommended ones (leave one out and you get a warning, but the rich result can still show). Search Console’s guidance is to open the report, “click an issue to see affected pages,” and use the “Why items are invalid” table to prioritize — errors first, then warnings.

Type mismatches — string where a number, URL, or date is expected

The classic eligibility bug: the value is there, but it’s the wrong type. A price field containing a date. A rating provided as "five stars" instead of a number. A URL field containing plain text. Google flags this as an invalid/unexpected value type.

Bing is worth a note here because, per its own structured data help documentation, it behaves differently: rather than erroring loudly, Bing’s crawlers are documented to ignore an annotation whose value type is wrong (a price field holding a date, an Event with no date, a Person with no name) rather than surface a red error. So don’t assume “no Bing error” means “correct” — Bing’s public documentation is thinner and less granular than Google’s (it doesn’t publish a per-type required-vs-recommended breakdown or a report as detailed as the Rich result report), and its tolerance for mismatched types is a silent-drop, not a loud-fail. Lean on Google’s Rich Results Test for the detailed error taxonomy.

Duplicate @id values and entity confusion

A subtler one that CMS plugins cause constantly: reusing the same @id for two different entities, or letting a plugin emit a fresh, colliding @id on every page instead of a stable one. This is not a parsing failure — the JSON itself is well-formed, so it doesn’t land in the Unparsable structured data report. @id is how JSON-LD nodes reference each other inside a @graph, so a collision is an entity-identity problem: it creates ambiguity about which node a reference actually points to. This gets worse on sites where multiple sources (the theme and a schema plugin) both auto-generate Organization, WebSite, and WebPage nodes.

The fix is a stable, unique @id per real-world entity — a URL-fragment identifier like https://example.com/#organization, reused consistently across the site, not regenerated per page. This is the mirror image of the canonicalization problem, where one stable identifier per real thing is likewise the whole game.

Nested-property errors (a missing name inside author)

Some required properties live inside other objects — author.name, aggregateRating.ratingValue. A missing one used to produce a vague error like Missing field "name" that could point anywhere on the page. In March 2022 Google added nested context so the same error now reads Missing field "name" (in "author") — a small change that makes these far easier to locate. (Anyone with an open “validate fix” request at the time had to re-trigger it, since the old issue IDs were retired.) If you see a nested-property error, read the parenthetical — it tells you exactly which object is short a field.

Content mismatch — the policy-violation error class

This is the one error class that deserves its own section, because the consequence is categorically worse than “no rich result.” Everything above is a technical problem. Content mismatch is a policy problem.

Google’s General Structured Data Guidelines are explicit on two points:

• “Don’t mark up content that is not visible to readers of the page.”
• “Your structured data must be a true representation of the page content.”

Marking up a 4.8-star rating that appears nowhere on the page, describing content that’s hidden or served only to crawlers, or labeling something as one thing when it’s really another — Google’s own examples include a sports live-streaming site labeling broadcasts as local events, and a woodworking site labeling instructions as recipes — all violate this.

Consequences: manual actions vs. silent ineligibility

A technical error costs you the rich result silently. A content-mismatch policy violation can cost you more: “If your page contains a structured data issue, it can result in a manual action. A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.” Manual actions show up in the Manual Actions report in Search Console — a place you never want to see a structured-data entry.

A common quieter version of this: templated, non-unique schema. John Mueller’s long-standing guidance is that “the structured data on a website, or on a page, should be specific to that particular page” (via Search Engine Journal). A site-wide Organization block copy-pasted with the same review count onto every page reads as a representation problem, not just a sloppy one.

Why validation isn’t enough. This is the answer to “my markup validates clean — why no rich result?” Validators check syntax and Google’s technical eligibility rules. They do not check Google’s content-quality and spam-policy layer. A syntactically perfect, policy-violating implementation can still be denied a rich result or hit with a manual action. Passing the Rich Results Test is necessary but not sufficient.

Using a deprecated or unsupported type

Here’s a failure mode that isn’t technically an “error” at all — and it trips people up because nothing turns red. Your markup is perfectly valid, it parses, it passes the schema.org validator, and yet no rich result will ever show, because Google turned the feature off.

Case study: FAQ rich results (deprecated 2026)

The timely example. Google added a deprecation notice to the FAQ rich result documentation, stating the feature “will no longer appear in Google Search starting May 7, 2026,” then in mid-2026 removed the FAQ documentation, Rich Results Test support, and Search Console reporting because “the FAQ rich result feature is no longer shown in Google Search results.”

The nuance that matters: FAQPage is still a valid schema.org type, and Google still parses it. The type isn’t “wrong.” It simply no longer earns the visual treatment. So the correct reaction to “is my FAQ schema now an error?” is no — leaving the markup in place doesn’t hurt anything; it just no longer buys you a SERP enhancement. Don’t panic-strip valid markup because the visual went away.

Other retired types

FAQ isn’t alone. Google has repeatedly retired rich-result types when analysis showed they weren’t widely used or didn’t add user value: HowTo rich results were removed from desktop back in 2023; a June 2025 batch retired seven more niche types (including Claim Review, Estimated Salary, Learning Video, Special Announcement, and Vehicle Listing); and Practice Problems structured data was deprecated starting January 2026. In each case the schema.org type usually remains valid — it just stops rendering.

How to tell if a type is still “live”

Check Google’s Search Gallery — the canonical list of types that currently earn rich results. If a type isn’t in the gallery, valid markup for it won’t produce a visual, no matter how clean it is. Re-check the gallery periodically; Google revises it often.

How to actually debug — three different tools

The single most common meta-mistake is conflating the tools. There are three, and they answer different questions.

Rich Results Test — Google eligibility + SERP preview

The Rich Results Test takes a single URL or a code snippet and checks the subset of markup Google uses for rich results, then previews how the result might appear. Google frames it as “an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” Use it during development and to spot-check a fix. It does not validate schema types Google doesn’t use for rich results.

Schema Markup Validator — schema.org syntax, any type

The Schema Markup Validator is run by schema.org, not Google. It checks general syntax and vocabulary compliance for any schema.org type — including ones Google doesn’t turn into rich results (e.g., Action schema). Passing it means your markup is well-formed schema.org; it does not mean you’re eligible for a Google rich result. This is the tool for “is my JSON-LD structurally correct?” independent of any search engine.

The two-tool trap: these are genuinely different tools, and passing one does not mean passing the other. The split has confusing history — Google tried to fully deprecate its old “Structured Data Testing Tool” in July 2020, reversed course after backlash that December, then refocused it into today’s schema.org-run validator by mid-2021. Plenty of old blog posts still point people at the dead tool name. For 2026: Rich Results Test for Google eligibility, Schema Markup Validator for schema.org syntax.

Search Console’s Rich result report — site-wide, sampled, over time

The Rich result report (the older nav and a lot of practitioners still call this the “Enhancements” reports) is the only one that’s ongoing and site-wide rather than a single-URL spot check. Google: “a valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result. An invalid item has at least one critical issue preventing it from appearing as a rich result.” Two limitations to keep in mind: per-type reports only appear once Google finds valid markup of that type, and “the reports aren’t a comprehensive list of all detected items. They show a sample of detected items to help assess the quality of your structured data.” It’s a monitoring surface, not an exhaustive audit.

A pass answers only that tool’s own layer. Rich Results Test, Schema Markup Validator, and the Rich result report each check a different question, so a clean result in one tells you nothing about the other two — a pass in the Schema Markup Validator doesn’t mean Google’s Rich Results Test would pass, and neither proves what the Rich result report will show once Google actually crawls the deployed page.

Validating a fix (and why it takes a while)

Once you’ve fixed an issue, Google’s documented workflow is: fix on-site, confirm the page is crawlable (not blocked by robots.txt or noindex), spot-check with URL Inspection, then “click Validate fix on the issue’s details page to start Google’s validation process.” Set expectations on timing — Google says validation “can take two weeks or more, depending on crawl frequency.” It’s not instant; Google has to re-crawl the affected pages.

The one framing that keeps you sane

Fixing structured data errors is about rich-result eligibility, not rankings. As John Mueller put it (reported by Search Engine Roundtable, April 2025), “structured data won’t make your site rank better” — it’s for displaying the search features in Google’s gallery. So the payoff of a clean fix is a SERP visual (stars, breadcrumbs, price) and the click-through it can earn — never a ranking bump. Keep that straight and you’ll prioritize the right errors: the ones blocking a visual you actually want, not every warning in the report.

Where this sits

This is a deep-dive sibling under the Structured Data for SEO hub — the same sub-cluster as the schema-markup, JSON-LD, and rich-results deep dives. The error taxonomy here is the troubleshooting counterpart to those: they cover what to build, this covers what breaks and how to see it. For the broader picture of on-page signals it lives alongside — meta tags, header tags, image SEO — see the on-page SEO cluster.

AI summary

A condensed take on the Advanced version:

• Two error classes. Parsing errors — malformed JSON-LD (trailing commas, unescaped quotes, missing colons/braces) that break the markup so badly Google can’t determine the type; these go to the Unparsable structured data report. Eligibility errors — the markup parses fine but fails a rich-result rule: missing required property, wrong value type, a colliding/duplicate @id (entity-identity confusion, not a parse failure), or markup describing content not visible on the page.
• Errors block, warnings degrade. A missing required property (or unparsable JSON) kills rich-result eligibility. A missing recommended property is only a warning — the result usually still shows, less richly. Google: accurate-but-fewer beats padded-but-sloppy.
• Content mismatch is the class with teeth. Marking up invisible content or data that isn’t “a true representation of the page content” is a policy violation that can trigger a manual action — worse than silent ineligibility. This is why clean-validating markup can still fail: validators don’t check the content/spam policy layer.
• Deprecated types aren’t errors. FAQ (gone by May 2026), HowTo (desktop 2023), and the June 2025 batch are valid markup that no longer earns a visual. Don’t panic-strip FAQPage — it still parses, it just has no SERP payoff. Check the Search Gallery for what’s still live.
• Three different tools. Rich Results Test — Google eligibility + SERP preview, single URL/snippet. Schema Markup Validator (schema.org) — syntax/vocabulary for any type, not Google-specific. Rich result report (Search Console) — site-wide, sampled, over time. Passing one ≠ passing another.
• Debug tip (from Google): strip to an empty object, re-add code piece by piece; a fix can unmask hidden errors, so re-test each time.
• Validating a fix takes “two weeks or more, depending on crawl frequency.”
• Not a ranking factor. Fixing errors wins back a SERP visual, not a ranking (Mueller, 2025).

Official documentation

Primary-source documentation from Google and schema.org.

Google — policies and how markup works

• General Structured Data Guidelines — the content-mismatch and hidden-content rules, and the manual-action consequence.
• Intro to How Structured Data Markup Works — the Rich Results Test recommendation and the “fewer but complete” required-vs-recommended guidance.
• Structured Data Markup that Google Search Supports (Search Gallery) — the canonical list of types that currently earn rich results (check before assuming a type is still live).

Google — the reports and the debugging workflow

• Rich result report overview — the site-wide, sampled, per-type Search Console report; valid-vs-invalid definitions and the “sample, not comprehensive” caveat.
• Unparsable structured data report — where malformed JSON-LD lands; the documented error strings and the strip-to-empty-object debugging tip.
• Fix structured data issues in Search Console — the fix → confirm crawlable → URL Inspection → Validate fix workflow, and the “two weeks or more” timing.

Google — the tool

• Rich Results Test — single-URL/snippet checker with SERP preview (Google-eligibility only).

schema.org

• Schema Markup Validator — schema.org’s own syntax/vocabulary validator for any type (distinct from Google’s Rich Results Test).
• schema.org — the vocabulary itself.

Quotes from the source

On-the-record statements from Google, plus relayed statements from Google reps. Each link is a deep link that jumps to the quoted passage where the page exposes it.

Google — content-mismatch policy (the accuracy spine)

• “Don’t mark up content that is not visible to readers of the page.” — Google Search Central docs. Jump to quote
• “Your structured data must be a true representation of the page content.” Jump to quote

Google — required vs. recommended properties

• “it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” Jump to quote
• “The Rich Results Test is an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” Jump to quote

Google — the Rich result report (Search Console)

• “A valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result. An invalid item has at least one critical issue preventing it from appearing as a rich result.” Jump to quote
• “The reports aren’t a comprehensive list of all detected items. They show a sample of detected items to help assess the quality of your structured data.” Jump to quote

Google — unparsable markup and debugging

• The intended type “could not be determined because of the parsing error.” Jump to quote
• “If you are having problems finding the error, try starting from an empty object, then add back content from your broken code piece by piece.” Jump to quote

Google — validating a fix

• Validation “can take two weeks or more, depending on crawl frequency.” Jump to quote

John Mueller, Google — structured data is not a ranking factor

• “Structured data won’t make your site rank better.” Read the coverage

John Mueller, Google — schema should be page-specific

• “The structured data on a website, or on a page, should be specific to that particular page.” Read the coverage

Search Console reporting bug (Oct 2022) — errors mislabeled as errors

• “This is strictly a reporting issue and did not affect whether or not a rich result could be displayed in Google Search results.” Read the coverage

Which tool (and what does the result mean)?

Start from the question you’re actually asking — the tools answer different ones.

“Is my JSON-LD even written correctly?” → Schema Markup Validator (validator.schema.org). It checks schema.org syntax and vocabulary for any type. Passing = well-formed schema.org. It does not tell you about Google rich-result eligibility.

“Will this page be eligible for a Google rich result, and how might it look?” → Rich Results Test (search.google.com/test/rich-results). Single URL or snippet, Google-eligible types only, with a SERP preview.

• If the type you care about isn’t recognized at all → check the Search Gallery; the type may be deprecated (FAQ, HowTo-on-desktop) — valid markup, no visual.

“Which pages across my whole site have issues, over time?” → Search Console → Rich result report (site-wide, sampled). Remember it’s a sample, not a comprehensive list, and per-type reports only appear once Google finds valid markup of that type.

What does the error actually mean?

Item is in the Unparsable structured data report → Malformed JSON — trailing comma, unescaped quote, missing colon/brace. Strip to an empty object and re-add code piece by piece. Google couldn’t even determine the type.

“Missing field …” (an error) → A required property is absent. Rich result blocked until fixed. Read any parenthetical (… (in "author")) — it names the nested object that’s short a field.

”… should be … / recommended” (a warning) → A recommended property is missing. The rich result still shows, just less completely. Fix only if the missing field is worth it — don’t pad with inaccurate data.

“Incorrect value type” / “invalid value” → Right property, wrong type — a string where a number/URL/date belongs. Correct the type.

Validates clean, but no rich result appears → Either the type is deprecated (check the gallery) or you’re hitting a content/policy issue validators don’t catch (invisible content, not a “true representation”). Worst case, check the Manual Actions report.

Entry in the Manual Actions report → A content-mismatch policy violation. This is the serious one: fix the markup-to-page mismatch, then request reconsideration. It costs rich-result eligibility, not rankings.

Structured data error triage — checklist

A pass to find, prioritize, and fix schema errors correctly:

• Separated errors from warnings — errors (required missing / unparsable) block the rich result; warnings (recommended missing) don’t. Fix errors first.
• Checked the Unparsable structured data report — anything there is malformed JSON (trailing comma, unescaped quote, missing colon/brace).
• Debugged unparsable items by stripping to an empty object and re-adding properties until it breaks; re-tested after each change (a fix can unmask hidden errors).
• Confirmed every required property is present for each type (per the Search Gallery), then recommended ones — accuracy over padding.
• Value types are correct — numbers where numbers belong, URLs where URLs belong, dates as dates; no strings standing in for them.
• Read nested-property errors’ parentheticals — Missing field "name" (in "author") tells you exactly which object is short a field.
• @id values are stable and unique per real entity — no duplicate/colliding @id, no per-page regeneration (watch for theme + plugin both emitting nodes).
• Everything marked up is visible on the page and is a true representation of it — no invisible content, no fake/aggregate ratings that appear nowhere.
• No reliance on a deprecated type — FAQ (gone May 2026), HowTo desktop (2023), the June 2025 batch. Valid markup, but zero SERP payoff.
• Ran the right tool for the question — Schema Markup Validator (syntax), Rich Results Test (Google eligibility + preview), Rich result report (site-wide monitoring).
• Checked the Manual Actions report — a structured-data entry there means a content-mismatch policy violation, not a technical error.
• After fixing, confirmed crawlable (not robots-blocked / noindex), spot-checked with URL Inspection, then clicked Validate fix — and set expectations: it can take two weeks or more.

Structured data errors — cheat sheet

The three tools (don’t conflate them)

Passing one does not mean passing another.

Error vs. warning

Error classes and the fix

Fast facts

• Not a ranking factor — a fix wins back a SERP visual, not a ranking (Mueller).
• Content mismatch can trigger a manual action — the one class with teeth.
• FAQ rich result: gone by May 7, 2026; FAQPage type still valid, just no visual.
• Validating a fix: “two weeks or more, depending on crawl frequency.”
• Rich result report is a sample, not a comprehensive list of every item.

What not to do

The recurring mistakes that turn a fixable schema issue into a bigger one:

• Treating every warning like an error. A missing recommended property is a warning — the rich result still shows. Chasing warnings by stuffing in half-true data is worse than leaving them; Google explicitly prefers fewer, accurate properties over more, sloppy ones.
• Trusting one report blindly. Search Console has mislabeled warnings as errors before (Oct 2022). Cross-check a flagged item against the Rich Results Test rather than reacting to a single report.
• Marking up content that isn’t visible. The one class with real teeth — it’s a policy violation that can trigger a manual action, not just a silent loss of the rich result. If a rating, price, or fact isn’t on the page, don’t put it in the schema.
• Copy-pasting identical schema across every page. Templated, non-unique markup (same review count sitewide) reads as a representation problem. Schema should be specific to the page it’s on.
• Regenerating @id per page, or reusing one @id for two entities. Both break entity references inside a @graph. Use one stable, unique @id per real-world entity — and watch for a theme and a plugin both emitting Organization/WebSite nodes.
• Panic-stripping valid-but-deprecated markup. FAQ schema stopped earning a visual in 2026, but FAQPage is still valid and Google still parses it. Removing it gains you nothing and risks breaking other markup around it.
• Assuming “validates clean” = “rich result guaranteed.” Validators don’t check Google’s content-quality and spam-policy layer. A syntactically perfect, policy-violating page can still be denied.
• Pointing people at the old “Structured Data Testing Tool.” It was refocused into the schema.org Schema Markup Validator by 2021. For 2026: Rich Results Test (Google eligibility) and Schema Markup Validator (schema.org syntax).
• Expecting an instant fix. After “Validate fix,” Google re-crawls on its own schedule — “two weeks or more, depending on crawl frequency.” Don’t re-file the same issue in a panic.

Resources worth your time

My related writing

• Structured Data: What It Is and How to Use It — my Ahrefs guide to schema types, implementation methods, validation tools, and the sameAs risk — the build-side counterpart to this troubleshooting piece.
• Google Uses ~40 Canonicalization Signals — my canonicalization guide; the stable-identifier-per-real-thing logic behind fixing duplicate @id errors mirrors canonical selection.
• The Beginner’s Guide to Technical SEO — where structured data (and its errors) fit into the broader technical picture.

Official

• Google’s General Structured Data Guidelines — the content-mismatch/hidden-content policy and the manual-action consequence.
• Google’s Unparsable structured data report — the malformed-JSON error strings and the strip-to-empty-object debugging tip.
• Google’s Fix structured data issues in Search Console — the fix → Validate fix workflow and the “two weeks or more” timing.
• Google’s Rich result report overview — valid/invalid definitions and the “sample, not comprehensive” caveat.
• Google’s Search Gallery — the current list of types that earn rich results (check before assuming a type is live).
• Rich Results Test (Google) and Schema Markup Validator (schema.org) — the two single-URL tools, for two different questions.

From around the industry

• Google: Structured Data Does Not Make Your Site Rank Better (Search Engine Roundtable, April 2025) — Mueller’s “won’t make your site rank better,” the framing that reorients why you fix errors at all.
• Google’s John Mueller: Structured Data Should Be Unique to Each Page (Search Engine Journal) — the source for the templated-schema mistake.
• Google Search Console Mislabeled Structured Data Errors As Errors (Search Engine Land, Oct 2022) — the reporting-bug incident behind “don’t trust one report blindly.”
• Google Search Console Structured Data Error Reporting Gains More Contextual Information (Search Engine Land, March 2022) — the nested-property context change (… (in "author")).
• Google Drops FAQ Rich Results From Search (Search Engine Journal) — coverage of the FAQ removal and what stays valid.
• r/TechSEO — the community for schema-error and rich-result debugging.

Broken vs. fixed JSON-LD

Four of the error classes this article covers, each shown as a minimal broken snippet next to the fixed version. These are simplified examples — real JSON-LD usually has more properties around the broken one.

Trailing comma

// Broken — trailing comma after "price" breaks JSON parsing entirely
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.99",
  }
}

// Fixed — comma removed after the last property
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.99"
  }
}

What’s wrong: a comma after the last property in an object is valid in JavaScript but invalid in JSON — this lands the item in the Unparsable structured data report because Google can’t determine the type at all.

Unescaped quote

// Broken — the inch mark inside "description" terminates the string early
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Monitor Stand",
  "description": "Fits a 27" display comfortably"
}

// Fixed — the inner quote is escaped
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Monitor Stand",
  "description": "Fits a 27\" display comfortably"
}

What’s wrong: an unescaped " inside a string value ends the string at that point, breaking everything after it. Google’s documented error string for this is “Bad escape sequence in string.”

Wrong value type

// Broken — ratingValue is a string, not a number
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "five stars",
    "reviewCount": "42"
  }
}

// Fixed — ratingValue is a number; reviewCount is a number too
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 42
  }
}

What’s wrong: the JSON is syntactically valid, so this passes basic parsing — but Google flags it as “Incorrect value type” because ratingValue needs a number, not a text string like "five stars".

Duplicate @id

// Broken — the theme AND a plugin each emit their own "#organization" @id
// with different data, colliding inside the site's @graph
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co" },
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company Inc." }
  ]
}

// Fixed — one stable, unique @id per real-world entity
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company Inc." }
  ]
}

What’s wrong: reusing the same @id for two different representations of the same entity creates ambiguity about which one a reference points to — pick one stable identifier, reused consistently, never regenerated per page.

Prompts for debugging structured data errors

Paste-and-run prompts for the two things this article’s error list is actually useful for: finding a parsing error in broken JSON-LD, and checking a block against the required-vs-recommended distinction.

Find the parsing error in broken JSON-LD

Paste in: the raw JSON-LD block that’s failing (copy it straight from view-source or the Rich Results Test’s code view).

Here is a JSON-LD structured data block that Google's Rich Results Test is
flagging as unparsable. Find the syntax error (trailing comma, unescaped
quote, or missing colon or brace) and tell me the exact line and character
that's wrong. Then give me the corrected JSON. Don't change any property
values, only fix the syntax.

[paste the broken JSON-LD block here]

What to expect back: the specific syntax problem named (not just “there’s an error somewhere”), plus a corrected block you can diff against the original to confirm nothing else changed. Re-run the fixed block through the Rich Results Test yourself — a fix can unmask a second, previously-hidden error, so don’t treat one AI pass as the final word.

Check required vs. recommended properties for a type

Paste in: the JSON-LD block plus the schema.org type name you’re targeting (e.g. Product, Recipe, Event).

This is a JSON-LD block using schema.org type [TYPE]. Based on Google's
required and recommended properties for this type in its Search Gallery
documentation, tell me: (1) which required properties are missing —
these block the rich result entirely, (2) which recommended properties
are missing — these only produce warnings, and (3) whether any present
value looks like the wrong type (text where a number, URL, or date is
expected).

[paste the JSON-LD block here]

What to expect back: a split list — required gaps first, since those are what block eligibility — not a flat list treating every missing field as equally urgent. Verify the type-specific requirements against Google’s own Search Gallery page before acting, since AI-model knowledge of Google’s exact required-property lists can be stale.

Proving a schema fix actually took effect

The article’s own “Validate fix” workflow — fix on-site, confirm crawlable, spot-check, click Validate fix, wait — turned into pass/fail checks.

Rich Results Test shows the type with zero errors

Test to run: Paste the live page URL (or the fixed JSON-LD snippet) into the Rich Results Test. Expected result: The target type (e.g. Product, Recipe) is detected with 0 errors — warnings for recommended properties are acceptable. Failure interpretation: If the type still shows the same error, the fix either didn’t deploy to the live page or didn’t address the actual property the error named — re-read the parenthetical on any nested-property error. Monitoring window: Immediate — this test reads the current live markup, not a cached or crawled version. Rollback trigger: If the previously-passing type now shows a new error it didn’t have before, the fix likely broke something else in the same @graph — revert and re-apply more narrowly.

Page is confirmed crawlable before requesting revalidation

Test to run: URL Inspection tool in Search Console on the fixed page. Expected result: “URL is on Google” (or “URL is available to Google”) with no robots.txt block and no noindex directive. Failure interpretation: If the page is blocked or noindexed, Google won’t re-crawl it regardless of how clean the schema is — clicking “Validate fix” on a blocked page is a wasted cycle. Monitoring window: Immediate — URL Inspection reads the current crawl and index status. Rollback trigger: Not applicable here — this is a precondition check, not a change to roll back.

Search Console’s Validate fix process resolves the issue

Test to run: In Search Console’s affected issue, click Validate fix after confirming the two tests above pass. Expected result: The issue’s status moves from “Failed”/“Not started” to “Started,” then eventually to “Passed,” and the affected-page count for that issue drops. Failure interpretation: A status of “Failed” after validation means Google re-crawled and still found the problem — go back to the Rich Results Test on the live URL to see what’s still wrong before re-requesting. Monitoring window: Per Google’s own guidance, “can take two weeks or more, depending on crawl frequency” — don’t re-file the same issue before that window has passed. Rollback trigger: If the issue count is climbing instead of falling after the monitoring window, the fix likely wasn’t applied site-wide (e.g., only one template updated, not all pages using that type) — audit for other pages still emitting the broken markup.

The standing KPI: the Rich result report over time

Fixing one page’s schema is a one-off task. Watching whether structured data stays healthy site-wide is an ongoing measurement, and Search Console’s Rich result report is the tool built for exactly that.

Valid items (per type)

Metric: The count of valid items Search Console reports for each rich-result type your site uses (e.g., Product, Recipe, Article). What it tells you: How many sampled items of that type currently pass Google’s eligibility rules — the number that’s actually eligible to show a rich result. How to pull it: Search Console → Rich result report, filtered to the specific type; the valid-items count and trend line are on the report’s overview. Benchmark / realistic range: There’s no universal healthy percentage — what counts as “good” depends on how many pages on your site should carry that type at all. Set your own baseline the first time you check: note the current valid-item count, then watch for movement from that number rather than comparing to an industry figure. Cadence: Monthly, or right after any template/schema-plugin change — since Google’s reports are sampled, don’t over-read week-to-week noise.

Invalid items (per type)

Metric: The count of invalid items — items with at least one critical issue blocking rich-result eligibility. What it tells you: Where new or unresolved errors are accumulating, broken out by the specific issue type (missing field, unparsable, etc.) so you can prioritize which issue affects the most pages. How to pull it: Same Rich result report, the invalid-items table; click an issue to see the list of affected pages. Benchmark / realistic range: Never invented — this number should trend toward zero for issues you’ve fixed, but the starting count is whatever your site currently has. Use your first read as the baseline and track the delta after each fix cycle, not against a general target. Cadence: Monthly at minimum; check within a day or two of any bulk content or template change, since a broken template can spike invalid items across every page using it.

Unparsable structured data count

Metric: The item count in the separate Unparsable structured data report (malformed JSON-LD that broke parsing entirely). What it tells you: Whether a code-level bug (a template that concatenates strings without escaping quotes, for instance) is actively producing broken markup, as opposed to a content-level eligibility gap. How to pull it: Search Console → Unparsable structured data report. Benchmark / realistic range: The honest target is zero, since unparsable markup is a pure syntax bug, not a judgment call about which properties to include — but there’s no defensible “acceptable rate” above zero to compare against; the value in tracking this metric is watching it return to zero after a fix, not a benchmark number. Cadence: Check after every deploy that touches schema-generating code or a schema plugin update; otherwise monthly alongside the other two reports.

Test yourself: Structured Data Errors

Five quick questions on the errors that block rich results — and how to fix them. Pick an answer for each, then check.

Structured Data Errors

Structured data errors are problems in a page's schema.org markup that either break parsing entirely (malformed JSON-LD — trailing commas, unescaped quotes, a missing colon or brace) or parse fine but fail a search engine's eligibility rules for a rich result: missing required properties, wrong value types, a colliding/duplicate @id, or markup describing content that isn't visible on the page. Google surfaces them in the Rich Results Test and Search Console's Rich result report; schema.org's Schema Markup Validator checks general syntax/vocabulary. Fixing them restores rich-result eligibility — structured data isn't a ranking factor.

Related: Structured Data, Canonicalization

Structured Data Errors

Structured data errors are problems in a page’s schema.org markup (usually JSON-LD) that fall into two broad classes:

• Parsing errors — the markup is malformed and can’t be read at all. Trailing commas, unescaped quotes, or a missing colon or brace break the JSON so badly that Google can’t even determine the intended type. These land in Search Console’s separate “Unparsable structured data” report rather than a per-type report.
• Eligibility errors — the markup parses fine but fails a search engine’s rules for a specific rich result: a missing required property, a wrong value type (a string where a number, URL, or date is expected), a colliding/duplicate @id (the JSON is well-formed — it’s an entity-identity ambiguity, not a parsing failure), or structured data that describes content not visible on the page (a policy violation that can trigger a manual action).

There’s also a quieter failure mode that isn’t technically an “error”: using a deprecated or unsupported type — valid schema.org markup that simply no longer earns a rich result because the search engine turned that feature off (the FAQ rich result, removed by May 2026, is the timely example).

Google surfaces these problems through the Rich Results Test (single-URL or code-snippet spot check, Google-eligibility + SERP preview) and the Rich result report in Search Console (site-wide, per-type, sampled monitoring over time). Schema.org’s own Schema Markup Validator checks general syntax and vocabulary compliance for any type, independent of any one search engine — passing one does not mean passing the other.

Fixing errors restores eligibility for the associated rich result (review stars, breadcrumbs, product pricing, and so on). Because structured data itself is not a ranking factor, the payoff of a fix is regaining a SERP visual, not recovering rankings.

Related: Structured Data, Canonicalization

Changelog