Fixing the Schema Errors Google Search Console Flags

You open Search Console, or you get the email, and there it is: "Search Console has identified that your site is affected by 1 new Breadcrumbs issue." A number in red. A chart with a line that just jumped. Maybe a few hundred URLs listed under an error you have never seen before on a site you have not touched in weeks.

The instinct is to treat this like the Rich Results Test: paste a URL, read the error, fix that page, move on. That instinct is why people spend an afternoon fixing one page and come back a month later to find the same count sitting there, unchanged.

Search Console's structured data reports are a different kind of tool, and once you understand what kind, the errors get a lot less mysterious. This guide covers what these reports actually measure, how to work the fix process so it clears, why the count sometimes climbs on its own, and the errors Search Console will never show you no matter how carefully you read it.

Search Console is a monitor, not a tester

The Rich Results Test checks one page, right now, on demand. You give it a URL or a block of code, it reads the page, it tells you what it found. It is a spot check.

Search Console's structured data reports are the opposite. They are a running record of what Google found the last time it crawled each page of your site, where "crawled" means Google's automated visitor fetched the page and read it. Nothing in these reports is live. Every error you see was recorded at some point in the past, on a crawl you did not trigger, and it stays on the report until Google crawls that page again and sees something different.

That single fact explains most of the confusion these reports cause:

• You fixed a page and the error is still there. Google has not recrawled it yet. The report is showing you the old crawl.
• An error appeared on pages you did not change. Google recrawled pages it had not visited in a while, or a template that was always slightly broken finally got crawled on enough pages to cross the reporting threshold.
• The count is a sample, not a full count. The report shows "a sample of detected items," in Google's words, not every affected URL on your site. The real number can be higher.

So the report is a lagging picture assembled from crawls, not a verdict on your site as it stands this second. Work with it on those terms and it behaves predictably. Fight it like a live tester and it will feel broken.

Where these errors actually live

There is no single "structured data" screen. The errors are split across a few places, and knowing which report you are looking at matters.

The rich result reports (grouped under "Enhancements" in the sidebar) are one report per rich result type: Breadcrumbs, Products, Review snippets, Videos, and whichever others apply to your site. Each one appears only under two conditions, both of which Google spells out: Google finds valid markup for that type on your property, and that type is one Google actually produces a rich result for. If you added Service schema and no Service report showed up, that is not a bug. Service has no Google rich result, so there is no report to generate. The same is now true for FAQ and HowTo, whose reports were removed when Google retired those rich results.

The Unparsable structured data report is separate, and it catches a different class of problem: markup with a serious syntax error that stopped Google from even working out what type it was meant to be. A missing bracket, a stray comma, an unescaped quote inside a text value. Because Google never identified a type, these errors cannot go in a type-specific report, so they land here instead. Named errors in this report include "Invalid JSON document," "Parsing error: Missing ',' or '}'," "Duplicate unique property," and "Invalid top level element."

Manual Actions and Security Issues are their own sections again, and they matter here for one reason covered later: a structured data policy violation shows up there, not in any rich result report.

If your count jumped, check which of these reports it jumped in. A new Unparsable error means something is generating broken markup right now. A new Breadcrumbs error means a specific, named property is missing or wrong on a real page type.

How to read a single issue

Open a rich result report and you get a chart, then tables of issues split into two groups: "Why items are invalid" (the errors, which block the rich result) and "Improve item appearance" (the warnings, which do not). Fix every error. Weigh each warning against whether the missing property would genuinely change what a searcher sees. For what a specific error message means, property by property, our guide to common schema markup errors is the reference. This post is about the reporting workflow around them.

The part of this screen that is easy to misread is the count. One issue in these tables is not one broken page. It is one problem, listed once, with a number next to it for how many URLs it affects. "Missing field 'name'" affecting 340 URLs is a single row, and it almost always means one template or one generator is wrong, not that 340 pages each picked up the same typo by hand.

Click into an issue and you get an Examples table: a sample of the affected URLs, capped at 1,000 rows, each with a link to inspect it. Use these to confirm the pattern, then fix the thing that generated them. If the first five examples are all product pages missing the same field, the fix lives wherever product schema is built, and patching it once clears the whole group on the next crawl. Working through the Examples list URL by URL fixes the sample and leaves the source broken for every page you publish next. If you would rather catch this class of error before a page ships at all, our guide to validating structured data in CI/CD covers asserting on required properties as part of a build.

Confirm the fix on one page before you validate

Once you have changed the generator, do not immediately hit the validate button. Check one real page first.

In Search Console, open the URL Inspection tool, enter one of the affected URLs, and run Test Live URL. This fetches the page as it exists right now, not the stored crawl, and shows you the structured data Google reads from the current version. If your fix worked, the error is gone in that live test. If it is still there, your change did not take, and starting a site-wide validation now just wastes two weeks confirming a fix that is not really in place.

Only when the live test on a sample page comes back clean should you move to the next step.

The Validate Fix cycle, state by state

On the issue details page there is a Validate Fix button. Clicking it tells Google: I believe this is fixed, please recrawl the affected URLs and check. Then you wait. Google itself sets the honest expectation, saying validation can "take two weeks or more", depending on how often it crawls the pages involved. Low-traffic pages get crawled less often, so a fix on an obscure section of the site can take longer than that.

During and after that window, the validation moves through a set of states. Google's help documentation names them:

• Not started. You have not requested validation for these items yet.
• Started. You clicked the button. Google has queued the affected URLs for a recheck and has no results yet.
• Looking good. Google has rechecked some of the URLs and the ones checked so far are fixed. Not finished, but trending the right way.
• Passed. Every known instance of the issue has been rechecked and resolved. This is the one you are aiming for. When an issue passes fully, it closes.
• Failed. Google rechecked at least one URL and the problem is still there. The validation stops. You fix whatever is still wrong and start it again.
• N/A. Google noticed the issue was resolved on its own, through normal crawling, before you ever asked it to validate. Nothing more to do.

A few things worth knowing about how this behaves. Google validates a sample first, and only proceeds to the wider set if the sample passes, so an early "Looking good" is encouraging but not the finish line. If validation fails, you do not lose your progress on the URLs that did pass: you restart validation and Google rechecks the failed and still-pending ones plus any new instances it has found since. And the whole cycle is asynchronous. You can close the tab. Search Console emails you when the state changes.

"The error count went up and I did not touch anything"

This is the most unsettling thing these reports do, and it is almost always one of four ordinary causes.

Google crawled more of your site. The report is a sample built from crawls. If a template was always missing a field, but only 12 pages built from it had been crawled recently, the issue might have been small enough to sit unnoticed. Google crawls 400 more of those pages, the count jumps, and it looks like something broke. Nothing broke. The reporting just caught up with reality.

You published new pages from a flawed template. Ten new posts from a template that omits author is ten new invalid items, arriving exactly as designed by the bug you have not fixed yet.

Content that comes and goes. Event pages for events that have passed, products that sold out, seasonal listings. When the visible content changes but the schema does not keep up, pages that were fine slide into "invalid" or into a content mismatch, and they do it in waves that line up with your publishing calendar, not with any change you made to code.

Google tightened a spec. Google changes what a rich result type requires from time to time, and does not always announce it loudly. A property that was recommended becomes required, and overnight a slice of your pages that were valid yesterday are flagged today. When a jump has no explanation on your side, this is worth checking against Google's current documentation for that type.

The 90-day window

Issues in these reports are not permanent records. Once an issue has been fully resolved, Search Console keeps it visible for a while so you can see the history, then closes it. If the same error crops up again after that, Google treats it as a new issue rather than reopening the old one.

Practically, this means two things. A recurring error will show up as a fresh issue with a fresh "first detected" date each time it comes back, so if you are seeing the same error name appear, disappear, and reappear every few weeks, that is a sign the underlying generator was never actually fixed, only patched. And clearing an issue is not a one-time event you can forget. It is a state you have to keep the site in.

The blind spots: what these reports do not check

A rich result report checks one thing: is the markup well-formed and complete for its type. Several real problems sit outside that check, so a spotless report is not the same as a healthy site. Each of these has its own diagnosis, covered elsewhere:

• Markup that no longer matches the visible page (a rating count or price the schema kept after the page moved on) is a policy issue. It surfaces in the separate Manual Actions report, often only after a human review, and it is the usual reason star ratings vanish. See the star ratings guide.
• Valid markup that still produces no rich result. Google's structured data guidelines say eligibility is not a guarantee. When the report is clean but nothing shows in search, why schema does not show walks through the diagnostic order.
• Schema that only exists after JavaScript runs. If a script adds your markup in the browser rather than the server sending it in the HTML, the report may show the type as detected on some crawls and gone on others. The headless WordPress guide covers the server-side fix.
• A type with no rich result, or a retired one. No report will ever appear for it. That is the answer, not a bug. The markup can still help AI systems read the page.

Common mistakes with the reports themselves

Validating before confirming. Clicking Validate Fix without running Test Live URL on a sample page first buys you a two-week wait to learn your fix did not land.

Reading the count as exact. It is a sample built from crawls. Treat it as the rough shape of a problem, not a precise defect tally, and do not panic when it wobbles.

Expecting the report to update the day you deploy. It updates as Google recrawls, which for most of a site is not today.

Ignoring which report the error is in. An Unparsable error means broken syntax being generated right now. A missing-field error in a type report means a specific property gap. Different reports, different fixes.

Treating a clean report as proof. It confirms the markup is valid. It says nothing about whether your numbers match the page or whether Google will show a result.

Why the same error keeps coming back

If an error clears and returns every few weeks, the report is telling you the fix was a patch, not a repair. The pattern underneath is almost always drift: a template that ships without a required field, a price that changes on the page while the schema stays frozen, new pages inheriting an old bug. As long as the markup is maintained as a separate thing from the page, by hand or by a rigid template, those errors regenerate faster than you can validate them away.

AI Schema Gen builds schema from your live page content rather than a static block, so the fields reflect what is actually on the page and stay in step as it changes, and it validates the markup before publish, so missing-field and malformed-value errors are caught before a crawl ever sees them and before Search Console has anything to flag. It does not override Google's own display decisions, and a page blocked from crawling stays blocked. What it removes is the biggest single source of recurring Search Console errors: markup that was right once and quietly stopped being right.

Tired of clearing the same Search Console errors every few weeks? AI Schema Gen generates structured data from your live page content and validates it before it publishes, so the errors above never reach a crawl. Start free at aischemagen.com.