Rich-result reports: complete guide

Understand valid, invalid, and non-critical structured-data issues across supported enhancement types.

GSC UI required Intermediate

Search Console's rich-result reports show whether Google detected valid and invalid structured-data items for supported search features. They help find template errors, understand critical and non-critical issues, inspect examples, and ask Google to validate a deployed fix.

They do not show every schema.org object, every affected URL, or every rich result Google displayed. A valid item is eligible for its supported feature; it is not guaranteed to receive that appearance in Search.

This guide reflects Google's current documentation on July 18, 2026.

There is no single universal rich-result report

Search Console creates a separate report for each supported type that it finds for the property.

Most reports appear under Enhancements. The Product snippets and Merchant listings reports appear under Shopping.

Google's current supported report types are:

Report family	Current report types
Site structure and content	Breadcrumbs, Datasets, Discussion forum, Education Q&As, Events, Hotels, Image metadata, Job postings, Math solvers, Practice problems, Profile pages, Q&As, Recipes, Review snippets, Subscribed content, Vacation rentals, Videos
Shopping	Merchant listings, Product snippets

A type can be supported by the Rich Results Test without having its own property-level Search Console report. For example, the test currently supports additional types such as Article, Local business, Loyalty program, Organization, Return policy, Shipping policy, and Software app.

Do not use the Rich Results Test's feature list as a promise that a matching report will appear in the navigation.

2026 FAQ retirement

FAQ is absent from Google's current supported-report list. Google records that FAQ rich results stopped appearing in Google Search on May 7, 2026. Historical FAQ report or Performance data can still exist, but a post-May decline is not evidence that the site's markup broke.

When a report changes suddenly, check Google's data-anomalies page and the current supported-report list before changing production markup.

When a report appears

Google documents two conditions for a type-specific report to appear:

Google finds valid markup for that type in the property.
The type has a supported Search Console rich-result report.

New markup does not create a report immediately. Google must be able to access the page, crawl and render the markup, index the page, and process the structured data. Search Console's missing-data guidance states that only indexed pages appear in these reports.

A missing report therefore does not prove that the site has no structured data. It can mean:

The type has no dedicated Search Console report.
Google has not found a valid item of the supported type.
The markup is so malformed that Google cannot identify its type.
The pages are not indexed.
A login, robots.txt, noindex, or another access restriction prevents processing.
Google has not recrawled the new or changed pages yet.
The report's representative sample does not expose the expected URLs.

Check the Unparsable structured data report when serious syntax errors may prevent Google from identifying the intended type.

What the landing page shows

A rich-result report landing page normally contains:

A timeline of valid and invalid items.
A Why items are invalid table for critical issues.
An Improve item appearance table for non-critical issues.
A link to View data about valid items.

The current top-level model is Valid versus Invalid. Older documentation and screenshots may show a third “Valid with warnings” state. Search Console removed that three-way top-level categorization; non-critical issues now sit in a separate improvement table while the item remains valid.

Valid

A valid item has no detected critical issue for that rich-result type. It can be eligible for the feature.

Valid does not mean:

The rich result was shown.
The page received an impression or click.
Every recommended property is present.
Google approved every quality or content-policy requirement.
The page will keep the feature after another crawl or documentation change.

Invalid

An invalid item has at least one critical issue that prevents that item from being used for the rich-result feature. Missing a required property, using the wrong value type, or supplying an invalid value are common examples.

Invalid structured data does not normally mean the hosting page cannot be indexed as an ordinary result. It means the affected item is not eligible for that enhancement. Check Page Indexing separately when the page itself is absent from Search.

Non-critical issues

Non-critical issues identify recommended or improvable properties. The item remains valid, but supplying accurate recommended data can improve completeness or the possible presentation.

Do not add values merely to clear a warning. Every value must be accurate, current, relevant, and consistent with content visible to users. Fewer complete and truthful properties are better than a larger set of fabricated or low-quality values.

The unit is an item, not a page

This distinction explains many apparent count mismatches.

One page can contain:

Several items of the same type, such as multiple events.
Nested items, such as a recipe with a video.
Several supported types, such as breadcrumbs, product data, and review information.
One item with multiple critical and non-critical issues.

Consequently:

Ten invalid items do not necessarily mean ten pages are invalid.
Fixing one template can repair thousands of items.
Issue-row totals can exceed the valid-plus-invalid item total because one item can have multiple issues.
Removing one broken item can lower the invalid count without increasing the valid count.

Record both the number of affected items and the number and type of hosting pages before estimating impact.

Reports and example URLs are not exhaustive

Rich-result reports show representative samples for quality assessment, not a complete inventory of every detected item or URL.

An issue's example table is limited to 1,000 rows and can omit newer instances or additional examples. A report export is also limited to the rows exposed by the report; exporting does not turn it into a complete crawl.

This means:

A URL absent from the examples is not proven clean.
The sum of visible examples need not equal the issue total.
A sample-size change can create a reported drop without the same number of pages losing markup.
Monitoring only exported example URLs can miss affected templates.

Use URL Inspection for a specific indexed URL and maintain a site-side structured-data inventory or crawler when complete coverage is required.

Read an issue detail page

Select an issue row to see:

The issue name and documentation link.
Its validation state.
The first-detected date.
Representative affected items and hosting URLs.
The last crawl date for an example.
Links into URL Inspection and debugging details.

The First detected date is not necessarily the release date that caused the issue. It is when Search Console first detected the issue during its current lifetime. If the same issue recurs within 90 days, the original first-detected date remains.

Use deployment history and representative last-crawl dates before connecting an issue to a code change.

A reliable debugging workflow

1. Confirm the feature and property

Verify the exact Search Console property, report type, affected template, and intended rich-result feature. Open the feature-specific Google Search documentation; schema.org alone is not the specification for Google eligibility.

2. Prioritize critical template issues

Start with issues that:

Make valuable items invalid.
Affect many indexable pages through one template.
Appeared after a known release.
Are growing across recent crawls.
Affect required properties or page access.

Do not prioritize solely by the largest percentage. Ten broken items on a critical commercial template can matter more than thousands of intentionally retired pages.

3. Inspect representative examples

Sample different page templates, languages, product states, authors, and content conditions. Include both obvious failures and edge cases, such as missing images, out-of-stock products, expired events, or items without optional content.

The goal is to identify the generating rule, not hand-edit every example URL.

4. Compare indexed and current evidence

Use URL Inspection to review the indexed version's detected enhancements and errors. Then run Test live URL to see whether the deployed page now differs from Google's indexed evidence.

An indexed error with a clean live test usually means Google has not processed the fix yet. A live error confirms that starting validation would be premature.

5. Use the Rich Results Test during development

The Rich Results Test can test a public URL or a code sample. It uses rendered source and reports supported item types, errors, and suggestions. Use it before deployment and for rapid iteration.

It does not prove that:

The page is indexed.
The indexed version contains the same markup.
The content satisfies every quality or policy rule.
Google will select the rich result for a real search.

Use the Schema Markup Validator when the task is generic schema.org validation rather than Google rich-result eligibility.

6. Fix the source of truth

Apply the correction to the CMS, component, data feed, or template that generates the markup. Keep the structured data aligned with visible page content.

Check:

Required properties and their documented data types.
Current feature-specific rules.
Empty, placeholder, or malformed values.
Dates, time zones, currencies, prices, availability, ratings, and URLs.
Crawlable and indexable image URLs.
JavaScript rendering and blocked resources.
Whether the markup describes the page's main content truthfully.
Whether duplicate pages carry consistent structured data.

The “Fix” action belongs on the site; Search Console cannot rewrite the site's structured data.

7. Test the full template matrix

Before deployment, test more than the example that first exposed the bug. A conditional fix can solve one product state while breaking another.

At minimum, test:

A typical valid item.
Every affected edge case.
A page with multiple items.
A page with nested or multiple rich-result types.
Mobile-rendered output when markup is injected by JavaScript.

8. Deploy, verify, then validate

After deployment, confirm representative live pages are accessible and pass the intended checks. Start Validate fix only after all known instances of that issue have been corrected.

How fix validation works

Validation is issue-specific. Clicking Validate fix tells Google to check known instances of one issue; it does not validate every structured-data type or guarantee a rich result.

Google first checks a sample. If those pages pass, it continues through affected instances. Google says validation typically takes up to about two weeks but can take longer, depending partly on crawling.

The issue-level states are:

State	Meaning
Not started	No validation attempt has been started.
Started	Validation is in progress.
Looking good	Checked instances are passing so far; the run is not complete.
Passed	All known instances in scope are resolved.
Failed	At least one checked instance still has the issue.
N/A	Google detected the fix without an explicit validation attempt.

If validation fails:

Open the validation details and identify the failing URL.
Fix that case and recheck every pending or similar page condition.
Wait for the current run to finish.
Restart validation once the full scope is fixed.

Do not repeatedly click validation as a recrawl accelerator. Search Console also updates issue counts through normal crawling even if validation was never started.

Sitemap-filtered validation changes the scope

If the report is filtered to a sitemap when validation starts, the request applies only to items in that sitemap at that time. This can make a focused validation finish faster, but it is not a property-wide confirmation.

Record whether a sitemap filter was active so “Passed” is not misreported as full-site resolution.

“Fixed” does not always mean “eligible again”

Google can mark an issue fixed when it no longer finds the error, including when the page or item was removed or the page became unavailable, noindex, or authentication-protected.

After a successful validation, separately confirm that important pages remain indexed, accessible, and valid. A falling invalid count can be caused by repair or removal.

Why a valid item might never show as a rich result

Correct structured data enables eligibility; Google's systems still decide whether and how to present the result for each search.

Possible reasons include:

A standard text result is more appropriate for the search.
The page or site does not meet a feature-specific, quality, or content policy.
The markup does not represent the main visible content accurately.
Information is hidden from users, misleading, stale, or incomplete.
The page is not indexed or cannot be accessed reliably.
A structured-data manual action removed rich-result eligibility.
The feature is unavailable for that query, country, device, or current product state.

A structured-data manual action removes eligibility for rich-result presentation; Google states that it does not by itself change the page's ranking in ordinary Web Search. Check the Manual actions report separately because a syntactically valid item can still violate policy.

Relate validity to actual Search performance carefully

Some rich-result reports include an impressions overlay, but not all do. The overlay is not the same as the valid-item count.

For supported appearance types, use Performance → Search results → Search appearance to examine recorded impressions, clicks, CTR, and position. Search appearance options appear only when the property has recorded impressions for them.

Keep these questions separate:

Question	Best evidence
Did Google detect a valid structured-data item?	Rich-result report or indexed URL Inspection
Does the deployed markup pass a current test?	Rich Results Test or live URL Inspection
Was the page indexed?	URL Inspection and Page Indexing
Did Search Console record the appearance?	Performance report's Search appearance dimension
Did the enhanced presentation cause more clicks?	A controlled performance analysis; GSC alone does not prove causation

An increase in valid items can coexist with fewer impressions because demand, rankings, query mix, device mix, feature selection, or reporting changed. A Performance drop can also occur without any validity change.

Diagnose common patterns

Invalid rises while valid falls

This is consistent with previously valid items developing a critical issue. Check first-detected dates, last-crawl dates, and recent template or data-source releases.

Both valid and invalid fall

Investigate indexing loss, access restrictions, page retirement, canonical or URL changes, feature retirement, and sampling changes. Do not assume that markup was repaired.

Invalid falls but valid does not rise

The broken items might have been removed, made unavailable, excluded from indexing, or dropped from the sample. Inspect important URLs directly.

Live tests pass but the report still shows errors

Google's report reflects processed crawl evidence and can lag the deployment. Confirm the example's last crawl, test several affected templates, and allow recrawling or run validation after the site-side fix is complete.

The report exists, but a specific URL is absent

The report is sampled. Confirm the URL is indexed and use URL Inspection to see detected items for that specific indexed page.

Markup validates, but no Search appearance data exists

Validity establishes eligibility, not selection. Confirm indexing, policy compliance, feature-specific requirements, query demand, and whether the selected Performance scope has ever recorded that appearance.

Monitoring cadence

After a markup deployment

Test representative code and URLs before release.
Confirm production rendering after release.
Inspect a small set of important live URLs.
Watch valid and invalid counts as Google recrawls.
Validate a fix only after every known template case is corrected.
Review the relevant Search appearance trend separately.

Ongoing monitoring

Review rich-result reports after template, CMS, commerce-feed, or JavaScript-rendering changes and during the normal technical SEO review cycle.

Alert on:

A new critical issue.
A material rise in invalid items.
A simultaneous fall in valid items.
A report disappearing unexpectedly.
A mismatch between expected structured-data coverage and sampled evidence.

Preserve release annotations and example URLs so the team can distinguish new faults from delayed crawls and recurring issues.

Automation boundaries

Google's public Search Console API exposes Search Analytics, Sitemaps, Sites, and URL Inspection services; it does not expose a property-level rich-result-report or fix-validation endpoint.

Automation can:

Run site-side schema tests in development and continuous integration.
Crawl rendered templates and inventory structured-data types.
Query the URL Inspection API for sampled indexed URLs and read richResultsResult.
Monitor relevant Search appearance data through Search Analytics or BigQuery bulk export.

Human or UI work is still needed to:

Review the complete type-specific report and its examples.
Run the interface's live URL test.
Start and monitor Validate fix.
Judge content accuracy, policy compliance, and whether recommended properties are worthwhile.

The URL Inspection API returns indexed-version evidence only; it cannot run the live test. Treat API sampling as a supplement to the report, not a replacement.

What the reports can and cannot conclude

They can show:

Which supported item types Google sampled for the property.
Whether sampled items are valid or invalid.
Which critical and non-critical issues Google detected.
Representative affected items and hosting URLs.
Whether Google passed or failed an issue-specific validation request.

They cannot prove:

That every site URL was checked.
That valid markup appeared as a rich result.
That a rich result improved CTR or rankings.
That an absent URL has no structured data.
That a passed validation restored indexing or impressions.
That markup complies with every quality or content policy.
That every schema.org type has a Search Console report.

Review checklist

The exact report type and Search Console property are recorded.
Current Google feature documentation is used instead of an old screenshot.
Counts are described as items, not pages.
Critical and non-critical issues are separated.
Example URLs are treated as representative, not exhaustive.
Indexed evidence and live tests are compared.
The generating template or data source is fixed.
All known cases are tested before validation starts.
Sitemap-filtered validation is labeled as scoped.
Validity and actual Search appearance are reported separately.
Feature retirements and data anomalies are checked.
Important URLs remain indexed after a validation passes.