How to Triage Structured Data Issues in Search Console

No. A change in a Google Search Console structured-data report is a diagnostic signal, not automatic proof that your markup disappeared, a page dropped from Google’s index, or search performance declined. First identify the report and issue, classify it as critical or non-critical, then inspect representative URLs with URL Inspection and the Rich Results Test.

This workflow is for developers, SEOs, and small-business site operators who need to decide whether to edit a template, investigate access and indexing, or allow time for crawling and report sampling. The most important rule is to avoid broad markup changes until URL-level evidence identifies the cause.

Why a Search Console count can mislead you

Google’s Rich result report overview explains that these reports count structured-data items, not pages. One page can contain more than one item, and one item can have more than one issue. The report also presents a sample of detected items rather than a complete inventory of every URL and instance on a site.

That means a lower Product-item count is not, by itself, evidence that every product template is broken. The issue-details table is also not a complete affected-URL list. Examples can be omitted when instances appeared after the last crawl or when a report contains more than 1,000 affected items.

Use the count as a reason to investigate. Do not use it as the diagnosis.

Understand the issue classification first

Search Console groups report items into broad valid and invalid categories. According to Google’s updated issue categorization guidance, an invalid item has a report-specific critical issue. A valid rich-result item has no critical issues and can be eligible to appear as a rich result. A valid item may still have non-critical issues listed as appearance improvements.

That distinction determines the priority:

Search Console state	What it means for triage	Initial action
Invalid or critical issue	A required condition for that report’s rich result is not met.	Inspect and repair the affected markup, page content, or access condition promptly.
Valid with non-critical issue	The item can remain eligible, but Google has identified an appearance improvement.	Confirm that the property and visible content are accurate, then schedule cleanup based on its value.
Lower valid-item count with clean URL tests	The movement could relate to sampling, crawl timing, indexing, parsing, or access.	Compare representative URLs and monitor rather than changing the whole template immediately.

Do not treat every warning as harmless. A non-critical issue is different from an invalid item, but it still deserves review if it describes inaccurate content, an incomplete implementation, or a property your business depends on.

Step 1: Open the exact report and record the change

Open the specific report rather than relying on an email summary or a chart alone. Product snippets and merchant listings reports are generally found under Shopping; other supported rich-result reports are generally found under Enhancements. The exact labels and navigation can vary by report type, property, and future Search Console interface changes.

Record:

Report name and structured-data type, such as Product, Product snippet, or Merchant listing.
Issue name and whether Search Console classifies it as critical or non-critical.
Date or date range of the change.
Current valid and invalid item counts.
Several example URLs from the issue details, while treating those examples as a sample rather than a complete list.

Also note whether the movement is a count change, a new issue, or a validation-state change. Those are different signals and should not be treated as interchangeable.

Step 2: Choose representative URLs

Pick more than one URL. Include at least one reported example and one known-good comparison URL with the same content type. For a larger site, vary the template or deployment group if possible: for example, compare a recently published product, an older product, and a product from a different category.

Look for a pattern:

If several affected URLs from the same template lack the same item, a shared template or deployment change becomes more plausible.
If only one URL is affected, inspect that page’s content, directives, response, and data before changing a shared component.
If affected and known-good URLs produce the same clean test results, crawl timing or report sampling remains possible.

This comparison is a recommendation for efficient diagnosis, not a claim that Search Console’s examples identify every affected URL.

Step 3: Compare indexed and live states in URL Inspection

Run each selected URL through Search Console’s URL Inspection tool. Record the indexed result and then use the live test where appropriate. Compare:

Whether the URL is on Google and whether the indexed result reports a structured-data issue.
The last crawl date and any difference between the indexed version and the current live page.
Google-selected and user-declared canonical signals.
Indexing directives, including noindex conditions.
Any structured-data finding attached to the URL.

Google’s categorization guidance distinguishes a URL that is on Google from a URL that is on Google but has a structured-data issue. Therefore, do not automatically describe a structured-data failure as an indexing failure. A page can remain indexed while its intended rich-result eligibility is impaired.

If the indexed version is old but the live page contains corrected markup, the report may not yet reflect the current deployment. That does not establish a universal recrawl time. Record the crawl date and use it as part of the explanation for the next verification point.

Step 4: Test the rendered page

Run the affected URL and the known-good URL through Google’s Rich Results Test. Record:

Detected rich-result types.
Critical errors and non-critical suggestions.
Crawl permission and page-fetch status.
Rendered structured data, not only the source code you expected to deploy.

The test supports JSON-LD, RDFa, and Microdata. A clean result means Google detected eligible structured data on that tested page at test time. It does not predict a rich result for every query, guarantee a merchant listing or product snippet, or establish that every URL using the same template is clean.

Inspect the rendered output for missing, empty, duplicated, or unparsable properties. Then compare the selected type and properties with the actual visible page. Schema.org’s vocabulary reference is useful for checking whether a type and property describe the content accurately, but Schema.org vocabulary alone does not prove that Google supports a particular rich-result appearance.

Step 5: Check access, indexing, and content conditions

Before editing markup, check the conditions Google identifies in its guidance for missing or declining structured-data items. Google’s structured-data troubleshooting documentation lists possible causes including sampled reporting, unparsable markup, pages not indexed, crawl delays, login or access restrictions, robots.txt restrictions, and noindex directives.

For each representative URL, verify:

The server response can be fetched without authentication or an IP restriction that blocks Google’s test.
robots.txt is not preventing the relevant page or required resource from being crawled.
The response and rendered page do not contain an unintended noindex directive.
The intended structured data is present in the rendered output and can be parsed.
The canonical and indexability signals point to the URL you are evaluating, where appropriate.
The visible product, service, or business information supports the selected type and properties.
The page is not simply waiting for Google to recrawl a recent change.

Check both the raw response and the browser-rendered page when the site relies on JavaScript, a tag manager, a plugin, or a server-side deployment step. A template can contain the right source fragment while the final rendered page omits it, or it can render data that does not match the page’s visible content.

Hypothetical example: WooCommerce Product items decline

Scenario: A WooCommerce site reports fewer valid Product items after a theme deployment. The owner is concerned that product visibility failed across the catalog.

Start with one product URL listed in the report and one product URL that remains valid. Do not assume the issue-details examples represent the entire catalog.

In the Product-related Search Console report, record the issue classification, count movement, and crawl dates.
Use URL Inspection on both products. Confirm whether each URL is on Google, review the indexed structured-data result, compare canonical signals, and note whether the indexed page predates the theme deployment.
Run both URLs through the Rich Results Test. Check whether Product is detected, whether critical errors appear, and whether the rendered output contains the expected product information.
Compare the deployed WooCommerce template, plugin output, and rendered HTML for differences. Look specifically for a missing Product object, malformed JSON-LD, empty price or availability values, or data emitted only for some product types.
Check robots.txt, noindex, authentication, response status, and the visible product content before editing the shared template.

If the affected product consistently lacks Product markup or produces a critical error while the known-good product passes, repair the relevant template or data-generation condition and test several product types before considering the work complete. If both pages are indexed and both live tests detect clean Product markup, the count change does not identify a template defect. In that case, document the crawl dates and investigate recrawl or reporting-sample timing rather than making a speculative sitewide change.

Use this decision aid

Fix now: a critical issue prevents the intended rich result, or the rendered page has missing or unparseable markup.
Schedule cleanup: the item remains valid and the issue is identified as a non-critical appearance improvement, provided the markup accurately represents the page.
Investigate timing or sampling: representative URLs are indexed, accessible, and clean in live testing, while the report count has moved without a reproducible URL-level defect.
Investigate indexing or access: URL Inspection shows the page is not indexed, the live test cannot fetch it, or robots.txt, authentication, noindex, or canonical conditions explain why Google cannot use the page as expected.

After a repair, use Search Console’s available validation or recrawl workflow where appropriate, but do not promise an immediate crawl or immediate report update. The supplied Google guidance does not establish a universal timing threshold.

Verification checklist

Keep a short record for each investigation:

Report name and structured-data type.
Issue classification: critical, invalid, valid, or non-critical.
Affected example URL and known-good comparison URL.
Indexed verdict, last crawl date, canonical signals, and live-test result.
Rich Results Test detected type, critical errors, suggestions, crawl permission, and fetch status.
Rendered markup result and whether the visible content supports the chosen type and properties.
robots.txt, noindex, authentication, response-access, and deployment findings.
Action taken and the next verification point.

That record lets you explain whether the evidence supports a markup repair, a targeted cleanup task, an indexing or access fix, or continued monitoring. It also prevents a sampled report count from becoming an unsupported claim about the whole site.

When a structured-data count changes in your account, which comparison has been most useful: indexed versus live URL Inspection, rendered markup testing, or comparing an affected template with a known-good URL?

Sources

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.