Schema markup validation: which test to use and what the errors mean

Which test answers which question?

Schema markup validation means running the structured data on a page through a test and reading what comes back. Structured data is where your site states its name, address, phone and prices in a form machines can read without guessing, so a broken block can mean those statements never arrive. Our guide to schema markup covers what to add. This one starts once the code exists.

There are two tests, and they answer different questions. Passing both means the code can be read. It does not mean Google will show a rich result, that an AI assistant will name you, or that the facts are right. Search Console adds a third view: what Google found after crawling.

Schema.org’s announcement of May 21, 2021 says its validator “does not try to check your content against the information needs of specific services, tools or products.” If you searched for a Google schema checker, the Rich Results Test is the one you want. The older Structured Data Testing Tool is gone: Google’s post of December 15, 2020 said it “will no longer check for Google Search rich result types”, and an update of August 9, 2021 says the old address now redirects to a landing page.

Which schema markup checker fits which type?

• Organization and LocalBusiness: run both. The Rich Results Test lists both types, but Search Console’s list of reports, read November 4, 2026, names neither, so neither has a report of its own to warn you later.
• Product, Event and other listed types: start with the Rich Results Test, which checks for the properties Google requires, then watch the matching report.
• FAQPage, Service and other unlisted types: use the validator. FAQ is not on the Rich Results Test’s list; our guide to FAQ schema covers why.
• Looking for a JSON-LD validator or tester? The Schema Markup Validator reads JSON-LD, for schema.org only: its documentation says “it will not fetch or interpret other @context URLs”. Our guide to JSON-LD covers the format.

How do you run each test, step by step?

In the Schema Markup Validator

• Open validator.schema.org. For a live page, use the “Fetch URL” tab. For a draft, use “Code snippet” and paste the block or the whole page source. Choose “Run test”.
• Read the results panel: each type it found, with its errors and warnings. Open a type to see every property as the tool understood it.
• Read the type names, not only the counts. A block with no @context line got 0 errors and 0 warnings when we ran it on November 4, 2026. The only clue was the type, shown as a web address instead of “Bakery”.

In the Rich Results Test

• Open search.google.com/test/rich-results. Enter the full URL, or switch to Code and paste. The default is smartphone.
• Read the status line. Google’s help page lists “N valid item(s) detected”, “N valid item(s) with warnings detected”, “N invalid item(s) detected”, “No items detected” and “URL cannot be crawled”, among others.
• Open each item. Clicking an issue takes you to its place in the code.

A URL test needs a public page, so paste the code for a page behind a password. A page closed to Google by robots.txt or noindex cannot be tested by URL. And remove comments from JSON-LD: Google says its test ignores them, but “that behavior is not supported by the JSON-LD standard”. The validator passed a block with a comment too when we ran it.

How do you check schema markup that JavaScript adds?

Both tests run JavaScript on a URL. Google’s guide on generated markup says Search “can understand and process structured data that’s available in the DOM when it renders the page”, and schema.org’s documentation says its validator can “Extract structured data injected by Javascript, e.g. by widgets”.

So a pass on a URL does not show the markup is in the HTML your server sends, and that matters for AI: Vercel’s own analysis with MERJ, published December 17, 2024, found that “none of the major AI crawlers currently render JavaScript”, with exceptions including Gemini, which uses Googlebot’s infrastructure.

Google names Google Tag Manager as a common way to add markup like this. To find out which kind you have:

• Open the page, choose View Page Source (not Inspect, which shows the page after scripts ran), and search for “application/ld+json”. That is the raw test: what you find is what a bot reading raw HTML gets.
• Paste each block you find into the validator’s “Code snippet” tab, to test that code on its own.
• Run the live URL in either tool. That is the rendered test. In Google’s test use the URL, not pasted code, because Google says “there are JavaScript limitations when using the code input”.

Shops have one more reason to move it: Google warns that “dynamically-generated markup can make Shopping crawls less frequent and less reliable”.

What is the difference between an error and a warning?

Google’s test says “invalid” and “valid with warnings”. Search Console says critical and non-critical. The validator says error and warning.

An error takes the item out. Search Console’s help page says “An invalid item has at least one critical issue preventing it from appearing as a rich result.” Google’s general guidelines add that “Items that are missing required properties are not eligible for rich results.” Fix these first.

A warning leaves the item in. The same help page says “A valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result.”

The validator’s warnings need a closer look. On November 4, 2026 the same sentence came back at two levels: a misspelled property (“telephonee”) was an error, and a real property on the wrong type (“price” directly on Product) was a warning. That warning looks minor, yet the price is in the wrong place.

So when can a warning wait? This is our suggestion, not Google’s rule:

• It can wait if Google asks for a recommended property you do not have yet, such as reviews on a new product. Never invent a value to clear it: Google says “reviews or ratings not by actual users may result in manual action”.
• Add it at your next edit if you have the fact, such as a phone number or a product image.
• Do not wait if the validator says a property “is not recognized” or the @context is unknown. What you wrote is not being read as you meant it.

Expect the count to rise before it falls. Google warns that “after you fix a parsing error, you might trigger additional warnings or errors that were hidden because the item could not be parsed at all.”

What do the common messages mean, and how do you fix them?

We ran real blocks through validator.schema.org on November 4, 2026 to get the first group. The second comes from Google’s help pages, and Google says of its own list: “This list is not comprehensive.”

The syntax messages are the most serious. In each of our runs the validator found 0 objects: the whole block was lost, not one line. If you cannot find the fault, Google’s advice is “starting from an empty object, then add back content from your broken code piece by piece”.

Why does a clean result not mean a rich result or an AI mention?

Google promises no display. Its general guidelines, last updated July 10, 2026, say: “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test.”

Features end. Google’s changelog entry of May 8, 2026 says the FAQ rich result “will no longer appear in Google Search starting May 7, 2026”. Valid FAQPage markup still passed the validator in our run, because the validator checks vocabulary, not Google’s features. Before you spend time on a type, check Google’s changelog and its search gallery.

Neither test looks at AI answers. Google’s page on AI features says “There’s also no special schema.org structured data that you need to add.” We found nothing from the makers of ChatGPT, Gemini, Claude or Perplexity that ties a validator result to being named.

What will no validator ever catch?

Google says its quality guidelines “are not easily testable using an automated tool”, and that breaking one “can prevent syntactically correct structured data from being displayed as a rich result in Google Search, or possibly cause it to be marked as spam.” In our view this is where owners lose the most, because no schema markup testing tool says a word.

We tested that. On November 4, 2026 we ran this invented block, on a page whose only visible text was the letter x. The validator returned 0 errors and 0 warnings.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "Totally Wrong Name LLC",
  "telephone": "+1-555-010-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Old Closed Rd",
    "addressLocality": "Nowhere",
    "addressRegion": "OR",
    "postalCode": "97201",
    "addressCountry": "US"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "5",
    "reviewCount": "99999"
  },
  "priceRange": "$"
}
</script>

Only a person can do this part. Open the validator’s list of properties next to the live page, and ask of each line:

• Is it on the page? Google says “Don’t mark up content that is not visible to readers of the page.”
• Is it true today? Google says “Provide up-to-date information.” An old address, a former phone number and a stale price are all valid code.
• Is it the name your site uses? Compare the spelling with your footer, page titles and Business Profile. A plugin and a theme can each print a block, so check every block you find.
• Are the ratings real? Google says “Don’t mark up irrelevant or misleading content, such as fake reviews”.
• Do the links work, and are they yours? Open each profile in “sameAs”, the logo and every image.

Google says a structured data manual action “means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search”. The other cost cannot be measured: a wrong fact in your markup is a wrong statement in your own words, for anything that reads it. Our suggestion is to give this reading to whoever knows the business best, not to whoever wrote the code.

When should you test again?

Google’s introduction to structured data says to use the status reports after deployment “to monitor the validity of your pages, which might break after deployment due to templating or serving issues.” Those reports show “a sample of detected items” and cover only some types. So these occasions are our suggestion, not Google’s rule:

• After a theme, plugin or page builder change. Count the blocks in the page source before and after.
• After a template edit. Test one page of each template: home, service, product, post. Google says the most common cause of one error on many pages is “an underlying template error”.
• After adding a tag manager or a widget. Run the raw test again.
• After a fact changes. A move, a new phone number or new hours: reread the block, because no test will flag it.

What the MWY checker reads, and why it is not a validator

MWY’s AI visibility checker is not a validator, and it replaces neither test. It asks a narrower question: can a bot that reads raw HTML, with no JavaScript, find out who you are? It reads the JSON-LD blocks in the raw HTML of your home page and up to seven inner pages, skipping anything your robots.txt closes to MWYGeoCheck.

• Business details. It looks for an Organization or LocalBusiness block, or a specific kind such as Bakery, and checks that it has a name, contact details (an address, phone, email or contact point) and a logo or image. All three is a pass, some is a partial, no block is a fail.
• The name. It compares the name in the block with the og:site_name tag, your page titles and the application-name tag. This item is marked as a signal.
• Profiles. It checks that the block has a “sameAs” line and that your pages link to a profile. It does not compare the two.
• Questions and answers. This is the one place it compares markup with the text of the page: FAQPage questions it cannot find in the text count only as a sign.

It checks that fields are filled, not that they are right. It does not test properties against the schema.org vocabulary, does not report either tool’s messages, does not read business details from Microdata or RDFa, does not predict rich results, and cannot tell whether a phone number is yours.

The results can differ. A block added by JavaScript can pass the Rich Results Test and still read as missing in MWY: that is the gap between raw and rendered. A block that does not parse as JSON, including one with a comment the validator let through, is skipped, as if it were not there.

The free check gives you the score, the group scores and the 5 items that matter most. All 24 items are part of Pro, which opens soon. A pass on any of them does not promise that an assistant will name you. For the code, use the two tests above. For the facts, use a person.