# What Is the Schema Markup Validator? What It Checks

> What a schema validator is, what the Schema Markup Validator checks, how it differs from Google's Rich Results Test and which errors neither one sees.

URL: https://clione.ai/glossary/schema-markup-validator/
Lang: en

A schema validator is the tool you use to check a page's [Schema.org](/glossary/schema-org/) markup, what the industry calls [_schema markup_](/glossary/schema-markup/). When someone says "run it through the validator" they usually mean the Schema Markup Validator, at validator.schema.org.[^smv] It matters because **it is the neutral tool**: it does not tell you whether Google will show your [product page](/glossary/product-page/) with [rich results](/glossary/rich-results/), like the price or the stars, but whether your markup is well written and uses a vocabulary that does not belong to Google alone. Schema.org was founded in 2011 by Microsoft, Yahoo!, Google and Yandex, with what their search engines could make use of in mind.[^schemaorg-datamodel]

## Where it comes from

Until 2020, the validator everyone used was Google's [structured data](/glossary/structured-data/) testing tool. On December 15, 2020, Google announced it was repurposing it: it would move to a new domain in service of the Schema.org community, its main purpose would be **checking the syntax and the conformance of markup with Schema.org standards**, and it would stop checking the rich result types of Google Search. For that it pointed to the [Rich Results Test](/glossary/rich-results-test/).[^sdtt-update]

On May 11, 2021, Schema.org announced the tool's new home, already under the name Schema Markup Validator, and on August 9, 2021, with the validator stabilized, Google began redirecting the old tool to a page for choosing which one to use.[^sdtt-update] Today Google sums it up this way: start with the Rich Results Test to see which Google rich results your page can generate, and use the Schema Markup Validator to **validate any type of Schema.org markup without the warnings specific to Google features**.[^google-test-sd]

## What it checks, layer by layer

Markup can fail on four different layers, and each tool reaches one of them. Separating them is the most useful way to read a validator.

**1. Syntax.** The code has to be a valid document: in [JSON-LD](/glossary/json-ld/), commas, quotes, braces and brackets in their place. It is the layer the two tools share. Google's, for example, lists errors of this kind that stop parsing before it even knows what type the item is: invalid JSON document, a missing comma or closing brace, an incorrect escape sequence, a single property defined twice.[^rrt-help]

**2. Vocabulary.** The types and properties have to exist in Schema.org and be used with reasonable values. This is the validator's own ground: Google gives it as an example of its use, for anyone who only wants to make sure they use valid Schema.org properties or to validate a type Google does not consume.[^sdtt-update] Here it helps to know something about how Schema.org is designed: **it is flexible on purpose**. Its data model accepts that text may arrive where a person or an organization is expected, that one description may combine properties from several types (something can be a book and a product at once), and it says validators may warn about what turns out ambiguous but **are not obliged to treat an unexpected structure as an error**.[^schemaorg-datamodel] That is why a validator gives so many warnings and so few errors.

**3. Google's requirements.** For a product page to qualify for [merchant listings](/glossary/merchant-listings/), Google requires a name, an image and an offer with a price greater than zero and its currency on the product.[^google-merchant-listing] Schema.org requires none of that: a product with no image is a perfectly valid product in its vocabulary. Only the Rich Results Test looks at this layer.[^google-test-sd]

**4. What no tool sees.** Google asks you not to mark up content the reader of the page cannot see, for the markup to truly represent the main content and not be misleading, and warns that **an automated tool cannot easily check these quality guidelines**.[^google-sd-policies]

## In a store

The same product, marked up four ways, in a **fictional example** store. The first version is the correct one:

```json
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "6-cup stovetop espresso maker",
  "image": "https://example-store.com/img/moka-6.jpg",
  "offers": { "@type": "Offer", "price": 39.9, "priceCurrency": "USD" }
}
```

And this is how each of the other three would fail:

| Version (fictional example) | What changes in the code                              | Layer that fails   | Who is built to see it             |
| --------------------------- | ----------------------------------------------------- | ------------------ | ---------------------------------- |
| A                           | The comma after `"name"` is missing                   | Syntax             | Both tools                         |
| B                           | The property is written `"cost"` instead of `"price"` | Vocabulary         | The schema validator               |
| C                           | There is no `"image"`                                 | Google requirement | Only the Rich Results Test         |
| D                           | The price in the markup is not the one the page shows | None of the three  | None: you have to look at the page |

Row B has a practical consequence: a vocabulary validator detects that `cost` is not a Schema.org property, but for Google that offer also has no price, so the product page stops being eligible. **One failure can show up on two layers at once**, which is why it pays to run both tools. Row D is the one that costs a store the most and the one no markup tool detects: it is the job of [publication verification](/glossary/publication-verification/).


Reading "no errors in the validator" as "eligible for Google". The validator checks Schema.org syntax and vocabulary; **Google's rich result requirements are not its job**, and Google separated them on purpose when it moved the tool.[^sdtt-update] A product page with no image passes the validator clean and is not eligible for merchant listings.[^google-merchant-listing] And the other way around: a validator warning about an unexpected value type is not always a problem, because Schema.org accepts those uses.[^schemaorg-datamodel]


## How to check it

1. **Open validator.schema.org and paste the URL of a published product page** or the block of markup you want to review.[^smv]
2. **Fix the syntax errors first**: while the document cannot be read, no other check is worth anything.[^rrt-help]
3. **Read the vocabulary warnings one by one.** A misspelled property gets fixed; text where an object was expected can stay, depending on what you need.[^schemaorg-datamodel]
4. **Run the same URL through the Rich Results Test** for Google's layer, the one with each result's required properties.[^google-test-sd]
5. **Compare two or three values in the markup by hand with what the page shows**: price, availability, name. Nobody validates that layer for you.[^google-sd-policies]

## Related concept: the Rich Results Test

The Rich Results Test is Google's tool: it checks only the types Search uses and applies Google's requirements to them, and it shows a preview of the result. A schema validator checks any Schema.org type, without Google's rules.[^google-test-sd] **They do not replace each other: they chain.** First the validator or the test for syntax, then Google's test for its layer, and last the published page for what neither of them sees. [Catalog data coverage](/glossary/catalog-data-coverage/) is the next step: not whether one product page's markup is right, but how many product pages in the catalog have the data that markup needs.

To keep going, the comparison [validating markup vs verifying publication](/comparisons/validate-vs-verify/) separates the two questions, and the [measurement and verification reading path](/learn/measurement-and-verification/) orders the rest of the terms.