Rich result reports

See which rich result entities Google found on your site

See which rich results Google found on your site, and any problems that Google had parsing them.

Rich result reports for your site are listed under Enhancements in the menu pane. There is a separate report for each rich result type.

You will see a rich result report for a given type only if:

Google finds rich results of that type in your property, and
The type is a supported rich result type listed below.

If you have implemented a supported type and you don't see the report in your property, see Missing rich results.

OPEN SEARCH CONSOLE

Monitoring Rich Results in Search Console - Google Search Console Training

Supported rich result reports

Search Console provides reports for the following rich result types, in addition to the Unparseable structured data report:

About the data

The numbers in the report count items not pages. One page can host multiple structured data items.

The report covers only a sample of your indexed pages, though this sample size can change occasionally.

Structured data on non-indexed pages (including alternate or duplicate pages) isn't shown, and won't make it into the Google Index.

General usage guide

Each report shows rich result items, not pages (one page can host one or more structured data items of the same or different types).

What to look for:

Ideally your Invalid error count should be 0. An error prevents an item from being used on Google. If you find errors, handle them as described in the Troubleshooting section below.
If you find warnings (the item count in the Improve item appearance table is greater than 0), these do not disqualify your rich results from being shown in Google Search with special features, but they can provide a somewhat reduced experience for your users. Debug warnings as described in the Troubleshooting section below.
Investigate any unexpected spikes or dips on this count, as described in the Troubleshooting section below.

Prioritize and fix rich result issues:

On the summary page of a rich result report, filter out the warnings and valid items and focus on the errors first.
Fix errors according to the number of affected items:
1. If there is a spike in the error chart, look for a corresponding spike in an issue row in the table.
2. Fix the issue on your site, test your fix, and ensure that your fixes are live on the web. See Inspecting errors to learn about the different tools to view and troubleshoot your structured data items.
3. Return to the issue details page and click the Validate Fix button to begin the validation process. This process can take several days, and you will receive email notifications of the progress.
4. If all instances of that issue are found to be fixed (that is, the fix is validated), the count of items affected by that issue will become 0 and the issue status will be updated.
Continue fixing errors.
When all errors have been fixed, remove the filter for warnings, and consider fixing the warnings. Most warnings are about missing optional properties in your structured data. Having more information in rich result can be more useful to your site visitors.

More tasks

Debug a specific rich result

You can use several different tools to inspect and fix a structured data error:

In the error details page:
1. Click a URL in the table to see the structured data code.
2. Click the inspect icon next to the URL in the table to run the URL Inspection tool, which offers error details, indexed and live test results, and a screenshot.
Use the Rich Results Test tool to test your page, or to iteratively test, modify, and retest your code directly in the browser. Either submit the URL of the page to test, or copy and paste code into the tool. This is the best tool for debugging and fixing structured data code.
Use the URL Inspection tool to inspect an arbitrary URL on your site. This tool also evaluates all structured data on the page, both in the indexed and live version of the page. The URL Inspection tool is best for seeing whether Google has found and indexed a rich result, and whether Google can access the page containing the rich result (a requirement for indexing the rich result).

Troubleshoot error spikes

The most common reason for a spike in errors is an error introduced to a template used by many pages on your site.

Determine if a spike caused was by a group of items moving from one severity to another:

If you see a spike, look for a corresponding drop in another state (warning or valid).
If you find a corresponding drop, confirm that the spike and drop are the same URLs.
If the items moved from one state to another, determine what caused it by drilling in to the error spike.

Troubleshoot the specific issue by drilling down into an example item and inspecting the errors as described previously.

Troubleshoot missing rich results / drop in total rich results

Here are some reasons why a rich result might not appear in the report:

Not all rich result types are currently supported in this report. See the list of supported rich result types.
Only rich results from indexed pages can be shown. Not all the pages on your site might be crawled for various reasons; for very large sites, you might see a significant difference between the number of pages with structured data on your site, and the number of rich results in this report. If you see a sharp drop in the number of rich results on your site, see if you can find a corresponding dip in indexed pages.
Google hasn't crawled a given page yet. It can take some time for Google to crawl new or updated pages. You can ask Google to recrawl your URLs. Indexing requests are not immediate; it can take up to a week to fulfill an index request.
Google can't access the page. Use the URL Inspection tool to see whether Google can access the page.
The structured data might be so invalid that Google doesn't recognize it as a rich result. Use the Rich Results Test Tool to check your page (check the URL of the live page rather than pasting your structured data code). If structured data is found but it could not be parsed at all, it should appear in the Unparsable structured data report.
Your rich result might not be supported for your location yet. Check the documentation to see if your rich result type is supported for your location.
Chart totals might omit some pages. This report covers only a sample of your pages, though this sample size can change occasionally.

To troubleshoot why a rich result isn't included in a report:

Use the URL Inspection tool to see if the page is indexed, and whether the rich result was found and is valid. Chances are, if the rich result isn't shown in the rich results page, either the containing page isn't indexed or there is a critical issue in the rich result. The URL Inspection tool will reveal both of those conditions.
If the problem is that the page isn't indexed, fix the page and test it using the URL Inspection tool's live test. Once the problem is fixed, request reindexing, and wait to see if this solves the problem.
If the problem is bad rich result code, use the Rich Results test on your code snippet to test and fix your code. Then update the code on your page and, if desired, request reindexing.

List of common structured data errors

Here is a list of the most common errors shown in this report:

Error	Description
Invalid URL in property "property name"	Invalid URL in the specified property.
Missing property "property name"	Missing required property.
Invalid calorie format in property "property name"	Invalid value for `calories` property.
Date/time not in ISO 8601 format in property "property name"	Invalid date value for the specified property. Date should be in ISO 8601 format.
Missing value in property "property name"	Empty value for the specified property.
Invalid value in property "property name"	Invalid value for the specified property.
Invalid string length in property "property name"	String value too long or too short for the specified property.
Invalid object type for property "property name"	Wrong structured data object type for the specified property.
Invalid value type for property "property name"	Wrong value type for the specified property.
Unrecognized property "property name"	You defined an unknown property in your structured data.
Duplicate property "property name"	Duplicate property definitions in the same object.
*Either "property 1"* or "property 2" should be specified**	You must specify only one of these two properties.
*Either "property 1", "property 2", or "property 3"* should be specified**	You must specify only one of these three properties.
No global identifier provided (e.g., gtin, mpn, isbn)	You must provide at least one of the following global identifier properties to uniquely identify your product: `gtin8`, `gtin13`, `gtin14`, `mpn`, or `isbn`
*Value in property "property name"* must be positive**	The indicated property value must be a positive number.
Invalid integer in property "property"	Invalid integer value for the specified property.
Invalid price format in property "property"	Invalid price format for the specified property.
Invalid product availability value in property "property name"	Invalid value for product availability.
You rated a review, rather than an item	You rated a review in an aggregated rating, rather than the item itself.
Couldn't determine the rating scale	You provided a rating scale that we could not understand.
Rating is missing required best and/or worst values	Missing the best and/or worst values for a rating.
Rating value is out of range	The rating value provided is out of range.
Review has multiple aggregate ratings	The Review has multiple aggregate ratings; you can provide only one.
Multiple reviews without aggregateRating object	You provided multiple reviews without an aggregate rating.
Number out of range for property "property name"	Numeric property is out of the allowed (or defined) range.
Syntax error in Sitelinks Searchbox	Generic syntax error in a Sitelinks Searchbox definition.
Custom query parameter not defined in target URL	(Sitelinks Searchbox) Issue string for undefined query value in sitelinks url template.
Mismatched query parameter name in target URL	(Sitelinks Searchbox) The query variable name used in `target` is different from the variable name used in `query-input`. For example, you might have done something like this: "target": "https://query.example.com/search?q={search_term_string}", "query-input": "required name=my_query" The name used in 'q' and 'query-input' should be the same: "target": "https://query.example.com/search?q={search_term_string}", "query-input": "required name=search_term_string"
Target URL domain is outside the website URL domain	(Sitelinks Searchbox) The URLs in `target` and `url` must have the same root domain. Here are examples of matching and non-matching URLs: http://www.example.com and http://example.com -- Match http://m.example.com and http://query.example.com - Match http://www.example.com and http://example.fr.co -- No match http://www.example.com and http://exaample.com -- No match
Invalid target URL	(Sitelinks Searchbox) Invalid URL in the `target` property.
Non-HTTP target URL	(Sitelinks Searchbox) Invalid URL in the `target` property: must be either http or https.
Error in Sitelinks Searchbox definition	(Sitelinks Searchbox) Error in Sitelinks Searchbox definition.
Invalid enum value in property "property name"	Property value does not match any of the allowed enumerated values.
Unknown error	An error occurred that doesn't fall into any of the other categories listed here.
Invalid or unsupported @context value	The value specified for the `@context` attribute in JSON-LD markup is misspelled, unsupported, or does not apply to that element. The only values currently supported by Google are: http://schema.org http://schema.googleapis.com http://gs1.org/voc https and trailing / mark variations of the previous values Google does not support custom remotely declared JSON-LD contexts, for example: `http://example.com/schemas/custom_schema`

Useful troubleshooting resources:

Elements of the report

The report consists of a summary page and a details page:

The summary page shows a chart of invalid and valid items found on your site over time, and a table grouped by status + description. The page has tables of critical issues and non-critical issues found in your items, and a link to a list of all valid items.
Click a row in the summary page table to see details about items in that category.

Report summary page

The top level of the report shows structured data items and issues of the specified type found on your site.

The graph labels each rich result instance according to the most severe issue affecting it: so an item with both an error and a warning is assigned the status "Error". An instance is counted only once in the graph.

The tables:

Why items are invalid: Shows critical issues affecting items on your site. These issues prevent your structured data from being used by Google. An item can be affected by one or more critical and non-critical issues.
Improve item appearance: Shows non-critical issues affecting structured data on your site.

Valid items are listed when you click View data about valid items below the chart on the summary page.

To see all issues affecting a single structured data item, see Inspecting errors.

Low rich results totals

The total number of items shown in the report graph might be lower than the actual known number of items on your site, for various reasons. Therefore, the total of Valid + Invalid items might be lower than the number of items actually known to Google.

If you want to know for sure whether items on a specific page have been found (and indexed), inspect the page to see if it is indexed and the rich result items are listed in the Enhancements section.

Why do issue totals exceed the valid + invalid totals

The total value per issue in the table can exceed the valid + invalid totals in the graph. Two examples why this can happen:

A single item with 3 different warnings will appear 3 times in the table (total = 3), but count as only 1 item (total = 1) in the warning tab total.
An item with both an error and a warning (two table rows) will count only as 1 error item in the error tab total. (An item is counted as the most severe status it contains.)

Issue details page

Select an issue row in the summary page table to open a page showing details for the selected issue. An issue can affect rich results on different pages, multiple rich results on a single page, or a single rich result multiple times.

The issue details page contains the following information:

Issue title and help link: A short description of the issue and a Learn more link for documentation about this rich result type. To see the an example of the problem, click an instance in the Examples table to see the error highlighted in the code.
State: Validation state of this issue, if validation was started.
First detected: The date when this issue was first detected on your site. Note: If all issues of this type are resolved, but a new instance of this issue appears within 90 days, the date will be original first detected date, not the date of the new instance.
Examples: A list of rich results affected by this issue. Note that it's possible that the examples list might omit rows for various reasons, such as issue instances that happened after the last crawl of your site, or instances that affect more than 1,000 items (the table is limited to 1,000 rows).
Item name: The name value in the item's structured data.
Last crawled: The last time the page containing this issue was crawled.

To see more information about an issue on a specific page, select the issue in the examples table.

Click the inspect icon next to the URL in the table to run the URL Inspection tool, which offers error details, indexed and live test results, and a screenshot.

Sharing the report

You can share issue details in the coverage or enhancement reports by clicking the Share button on the page. This link grants access only to the current issue details page, plus any validation history pages for this issue, to anyone with the link. It does not grant access to other pages for your resource, or enable the shared user to perform any actions on your property or account. You can revoke the link at any time by disabling sharing for this page.

Exporting report data

Many reports provide an export button to export the report data. Both chart and table data are exported. Values shown as either ~ or - in the report (not available/not a number) will be zeros in the downloaded data.

Validate your fixes

After you fix all instances of a specific issue on your site, you can ask Google to confirm your fixes. If all known instances are fixed, the issue count goes to zero in the issues table and drops to the bottom of the table.

Why validate

Telling Google that you have fixed all issues in a specific issue status or category has the following benefits:

You'll get an email when Google has confirmed your fix on all URLs, or conversely, if Google has found remaining instances of that issue.
You can track Google's progress in confirming your fixes, and see a log of all pages queued for checking, and the fix status of each URL.

It might not always make sense to fix and validate a specific issue on your website: for example, URLs blocked by robots.txt are probably intentionally blocked. Use your judgment when deciding whether to address a given issue.

You can also fix issues without validating; Google updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation.

Pro tip: Validate your fixes by sitemap

To speed up a fix request, create and submit a sitemap containing only your most important pages, then filter the report by that sitemap before requesting a fix validation. A validation request against a subset of your affected URLs can complete faster than a request that includes all affected URLs on your site.

Start validation

To tell Search Console that you fixed an issue:

Fix all instances of the issue on your site. If you missed a fix, validation will stop when Google finds a single remaining instance of that issue.
Open the issue details page of the issue that you fixed. Click the issue in the issues list in your report.
- ⚠️ If you are filtered to a specific sitemap in your report, the validation will apply only to items in the sitemap at the time you requested validation. This might be what you want, or it might not. Just be aware of it.
Click Validate fix. Do not click Validate fix again until validation has succeeded or failed. More details about how Google checks your fixes.
You can monitor the validation progress. Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient. You will receive a notification when validation succeeds or fails.
If validation fails, you can see which URL caused the validation to fail by clicking See details in the issue details page. Fix this page, confirm your fix on all URLs in Pending state, and restart validation.

When is an issue considered "fixed" for a URL or item?

An issue is marked as fixed for a URL or item when either of the following conditions are met:

When the URL is crawled and the issue is no longer found on the page. For an AMP tag error, this can mean that you either fixed the tag or that the tag has been removed (if the tag is not required). During a validation attempt, it will be labeled Passed.
If the page is not available to Google for any reason (page removed, marked noindex, requires authentication, and so on), the issue will be considered as fixed for that URL. During a validation attempt, it is categorized in the Other validation state.

Issue lifetime

An issue's lifetime extends from the first time any instance of that issue was detected on your site until 90 days after the last instance was marked as gone from your site. If ninety days pass without any recurrences, the issue is removed from the issues table.

An issue's First detected date is the first time the issue was detected during the issue's lifetime, and does not change. Therefore:

If all instances of an issue are fixed, but a new instance of the issue occurs 15 days later, the issue is marked as open, and first detected date remains the original date.
If the same issue occurs 91 days after the last instance was fixed, the previous issue was closed, and so this is recorded as a new issue, with the first detected date set to the new detection date.

Validation flow

Here is an overview of the validation process after you click Validate Fix for an issue. This process can take several days or even longer, and you will receive progress notifications by email.

When you click Validate Fix, Search Console immediately checks a few pages.
- If the current instance exists in any of these pages, validation ends, and the validation state remains unchanged.
- If the sample pages do not have the current error, validation continues with state Started. If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.
Search Console works through the list of known URLs affected by this issue. Only URLs with known instances of this issue are queued for recrawling, not the whole site. Search Console keeps a record of all URLs checked in the validation history, which can be reached from the issue details page.
When a URL is checked:
1. If the issue is not found, the instance validation state changes to Passing. If this is the first instance checked after validation has started, the issue validation state changes to Looking good.
2. If the URL is no longer reachable, the instance validation state changes to Other (which is not an error state).
3. If the instance is still present, issue state changes to Failed and validation ends. If this is a new page discovered by normal crawling, it is considered another instance of this existing issue.
When queued URLs have been checked for this issue and found to be fixed of this issue, the issue state changes to Passed. However, even when all instances have been fixed, the severity label of the issue doesn't change (Error or Warning), only the number of affected items (0).

Even if you never click Start validation Google can detect fixed instances of an issue. If Google detects that all instances of an issue have been fixed during its regular crawl, it will change the issue count to 0 on the report.

Revalidation

⚠️ Wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

To restart a failed validation:

Navigate into the validation log for the failed validation: Open to the issue details page of the issue that failed validation and click See details.
Click Start new validation.
Validation will restart for all URLs marked Pending or Failed, plus any new instances of this issue discovered through normal crawling since the last validation attempt. URLs marked Passed or Other are not rechecked.
Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.

See validation progress

To see the progress of a current validation request, or the history of the last request if a validation is not in progress:

Open the issue details page for the issue. Click the issue row in the main report page to open the issue details page.
- The validation request status is shown both in the issue details page and also in the Validation row of the Details table.
Click See details to open the validation details page for that request.
- The instance status for each URL included in the request is shown in the table.
- The instance status applies to the specific issue that you are examining. You can have one issue labeled Passed on a page, but other issues labeled Failed, Pending, or Other on the same page.
- In the AMP report and Page Indexing report, entries in the validation history page are grouped by URL.
- In the Rich Result reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).

Validation request status

The following validation states apply to validation for a given issue:

Not started: One or more instances of this issue have never been in a validation request for this issue.
Next steps:
1. Click into the issue to learn the details of the error. Inspect the individual pages to see examples of the error on the live page.
2. Click Learn more on the details page to see the details of the problem.
3. Click an example URL row in the table to get details on that specific error.
4. Fix your pages and then click Validate fix to start validation. Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.
Started: You have begun a validation attempt and no remaining instances of the issue have been found yet.
Next step: Google will send notifications as validation proceeds, telling you what to do, if necessary.
Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed.
Next step: Nothing to do, but Google will send notifications as validation proceeds, telling you what to do.
Passed: All known instances of the issue are gone (or the affected URL is no longer available). You must have clicked Validate fix to get to this state (if instances disappeared without you requesting validation, state would change to N/A).
Next step: Nothing more to do.
N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt.
Next step: Nothing more to do.
Failed: A certain threshold of pages still contain this issue, after you clicked Validate.
Next steps: Fix the issue and restart validation.

Instance validation status

After validation has been requested, every instance of the issue is assigned one of the following validation states:

Pending: Queued for validation. The last time Google looked, this issue instance existed.
Passed: [Not available in all reports] Google checked for the issue instance and it no longer exists. Can reach this state only if you explicitly clicked Validate for this issue instance.
Failed: Google checked for the issue instance and it's still there. Can reach this state only if you explicitly clicked Validate for this issue instance.
Other: [Not available in all reports] Google couldn't reach the URL hosting the instance, or (for structured data) couldn't find the item on the page any more. Considered equivalent to Passed.

Note that the same URL can have different states for different issues; For example, if a single page has both issue X and issue Y, issue X can be in validation state Passed and issue Y on the same page can be in validation state Pending.

Was this helpful?

How can we improve it?