Rich Results Test Errors: Fix the Most Common Problems and Warnings

Crawvix Editorial Team · Published October 29, 2026 · Last updated October 29, 2026 · 9 min read

You paste your page into Google's Rich Results Test and get a red list of rich results test errors. Some read like plain English, such as "Missing field 'name'". Others are harder to decode, like "Invalid object type for field" or "Invalid or unsupported @context value". Each message points to a specific property in your structured data, and nearly all of them have a short fix.

This guide is for site owners, developers and SEOs who maintain JSON-LD and need to turn a failing test into a clean one. You will learn the difference between errors and warnings, how to find the exact line behind a message, and what to change for the messages you are most likely to meet. It will not turn invalid markup into a rich result: a clean test means a page is eligible, and Google decides what it displays.

Google says the list of messages it documents is not comprehensive, so treat this guide as a map of the common ones, and read the issue details in the tool for anything else.

Before you begin

You need the page URL or the JSON-LD block, and the tool open in a browser tab: the Rich Results Test at search.google.com/test/rich-results. If you only have a snippet, use the code option, so you can re-run it as you edit. Keep the documentation for the feature you are marking up (product, organization, article and so on) open next to it, because the required properties come from that feature's page rather than from schema.org.

Work on a copy of the markup. Change one thing at a time and re-run the test, so you know which edit fixed which message. Typical time is 15 to 45 minutes per template.

Errors, warnings and critical issues

The words matter, because they tell you what to fix first.

  • In the Rich Results Test, invalid items are shown as errors. Items that are valid but incomplete are shown as warnings.
  • In Search Console, Google uses the words critical and non-critical. Critical issues prevent the structured data from being used and make items invalid. Non-critical issues are listed under "Improve item appearance". The Search Console help text does not use the labels "errors" and "warnings" in that report.
  • A page with warnings only can still be eligible. A page with an error in the required properties is not.

Fix errors first, then decide on warnings. A warning usually means a recommended property is missing. Add it only if it is true for your page.

Step-by-step instructions

Step 1: Find the exact message and location

Run the test and expand the failing item. Each issue names the property involved. Click the issue description to open the code explorer in the rendered source at that location. This is the quickest way to see which block, and which part of it, is at fault. If a page has several items, work through them one by one, because one item can have several issues.

If you see "Syntax errors in items of unknown type", the parser failed before it could tell what type of item you meant. The usual causes are a missing colon, a missing comma or brace, an invalid escape sequence or invalid Unicode. Fix the JSON first (see the next section), then retest.

What success looks like: you can name the property and the block behind each message.

Step 2: Fix syntax errors first

Nothing else can be judged until the block parses. Paste it into a code editor that checks JSON. Look for trailing commas, unquoted keys, curly quotes, an unclosed bracket and unescaped quotation marks inside text. Remove any comments: the Rich Results Test ignores them, but the JSON-LD standard does not allow them, so they may cause errors in other readers.

What success looks like: the item is detected with a type, so the message changes from a syntax error to specific property messages, or disappears.

Step 3: Work through the property messages

These are the messages Google documents, grouped by what to do. Use the wording in the tool to match them.

Missing or empty properties

  • Missing field 'property name': add the property. The message also applies if the property is present but its value is an empty string.
  • Either 'property 1' or 'property 2' should be specified (and the three-property version): include only one of the listed properties, as the message says.
  • No global identifier provided (for example gtin, mpn, isbn): for a product, provide at least one of gtin8, gtin13, gtin14, mpn or isbn.

Wrong type or shape

  • Invalid object type for field 'property name': use the object type the documentation expects for that property. For example, a property that expects a PostalAddress object will not accept a plain string.
  • Invalid value type for field 'property name': use the data type the documentation expects (text, number, URL and so on).
  • Type object must be nested inside a type object: correct the nesting so the child sits inside its parent, such as an offer inside a product.
  • Unrecognized field 'property name': check the property name for typos, and confirm it exists for that type.
  • Duplicate field 'property name': give the object only one value for that property.
  • Identical property values given, but unique values are required: remove the repeated values.

Wrong value format

  • Invalid URL in field 'property name': replace the value with a valid, absolute URL.
  • Invalid price format in field 'property': use a valid price format, or give price and currency as separate values. Use a period as the decimal separator.
  • Invalid ISO 4217 currency code: use a valid three-letter code such as USD.
  • Invalid integer, Invalid floating point number, Number out of range, Value must be positive: supply a valid number within the stated range.
  • Invalid enum value in property 'property name': use one of the allowed values shown in the issue details, such as an availability value written as InStock or https://schema.org/InStock.
  • Invalid string length in field 'property name': keep the text within the minimum and maximum length given in the details.

Dates and times

  • Date/time not in ISO 8601 format: format it as ISO 8601, for example 2026-10-29T09:00:00+00:00.
  • Datetime property is missing a timezone: add a timezone to the string.
  • Invalid datetime value: give a complete date and time, usually by adding the missing time.

Ratings and reviews

  • Rating is missing required best and/or worst values: add them when your scale is not the default 1 to 5.
  • Rating value is out of range: keep the value between worstRating and bestRating.
  • Couldn't determine the rating scale: use a scale Google supports.
  • Multiple reviews without aggregateRating object: Google says to make sure each aggregate rating includes a review, so check that your reviews and aggregate are consistent.
  • Review has multiple aggregate ratings: keep only one aggregate rating per review.
  • You rated a review, rather than an item: attach the aggregate rating to the item, not to the review.
  • Item does not support review: use reviews only on item types Google supports for review markup. Self-serving reviews on your own organization or local business are not eligible for stars either.

Context and vocabulary

  • Invalid or unsupported @context value: use a supported context. Google lists http://schema.org, http://schema.googleapis.com and http://gs1.org/voc, including their https and trailing-slash forms. Custom, remotely declared contexts are not supported.
  • Data-vocabulary.org schema deprecated: migrate the markup to schema.org vocabulary. Markup in the old data-vocabulary.org vocabulary is no longer eligible for rich results.

What success looks like: each message you fixed disappears on the next run, and no new ones appear.

Step 4: Decide what to do about warnings

Warnings tell you which recommended properties are missing. Read the property, ask whether you have the true value, and add it if you do. Do not add a property just to clear a warning, and never invent data. Google's guidance prefers fewer, accurate recommended properties over many incomplete or wrong ones.

You may also see warnings about resources that could not load, such as images, CSS and scripts. Causes include timeouts, 404 errors, login requirements and robots.txt rules aimed at Google-InspectionTool. Unblock important resources on your own site. If results change from run to run, the cause may be resources loading inconsistently.

What success looks like: remaining warnings are ones you have read and accepted.

Step 5: Retest the live URL and watch Search Console

Deploy, then test the live URL, not just the snippet. Then check the relevant report in Search Console after Google recrawls, which can take several days. In Search Console, a resolved issue that comes back within 90 days keeps its original first-detected date. The report table is capped at 1,000 rows, so large sites should fix the template and check a few examples rather than hunt for each URL. For the wider routine, see Test and Debug JSON-LD Structured Data.

What success looks like: the live URL shows no errors, and the Search Console report moves items from invalid to valid after recrawl.

When the test is clean but nothing shows

A clean test does not ensure a rich result. Google's guidelines say the markup must also follow its content and spam policies, must describe content visible on the page, and may not be shown even when valid. Check that the page is indexable, that the information in the markup is on the page, and that the feature is one Google currently shows for your type of content. If the same content is reachable at several URLs, Google's general guidance is to put the same markup on every duplicate, and Fix Duplicate URLs and Incorrect Canonical Tags explains how to reduce those duplicates in the first place.

Final verification checklist

  • The block parses and the item type is detected.
  • No errors remain for the live URL.
  • Every warning has been read, and each one is fixed or consciously accepted.
  • Required properties for the feature are present and not empty.
  • Currency codes, URLs, dates and numbers use valid formats.
  • The @context is a supported value.
  • Ratings and reviews are real, visible, and attached to the right item.
  • The page is crawlable and indexable.
  • Search Console shows the item as valid after recrawl.

Common mistakes to avoid

  • Fixing warnings before errors. Errors block eligibility. Start there.
  • Adding fake values to clear a warning. Only add true, visible information.
  • Putting the rating on the review. Attach aggregate ratings to the item.
  • A string where an object is needed. Check the expected type, for example PostalAddress for an address.
  • Spaces and symbols in prices. Use plain numbers like 24.99, with the currency in its own field.
  • A custom @context. Use one of the supported values.
  • Retesting only the snippet. The live page can differ from your snippet.
  • Expecting same-day results. Search Console reports update after recrawling.

Frequently asked questions

What is the difference between an error and a warning?

An error means the item is invalid. A warning means it is valid but missing recommended data.

Why does the Rich Results Test pass but Search Console shows invalid items?

The report reflects what Google crawled earlier. Fix the page, then wait for a recrawl. The live test shows the current state.

Do I have to fix every warning?

No. Fix errors. For warnings, add properties you can support truthfully.

What does "Missing field" mean when the field exists?

Google says the message also applies when the value is an empty string. Fill the field or remove it.

Can structured data errors hurt my rankings?

Google's guidelines say a structured data manual action makes the page ineligible as a rich result, and that it does not affect how the page ranks in web search. Errors simply stop the markup from being used.

Official references


Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.