Schema markup checker: which validator to use, and how to read what it tells you

Use two checkers, because they answer two different questions. Google's Rich Results Test tells you whether a page qualifies for a rich result in Google and lists the required properties you are missing. The Schema Markup Validator at validator.schema.org tells you whether your markup is correct against the schema.org vocabulary itself, including types Google does not use for rich results. Run the Rich Results Test when you care about how the page appears in Google, run the Schema Markup Validator when you care about whether the data is right, and then watch the Enhancements reports in Search Console, because those are the only reports based on your actual live pages rather than on a single test fetch.

This page covers which checker to use for which job, how to read errors against warnings, the problems a checker reliably catches, and how to validate at scale instead of one URL at a time. Both tool links above were checked on 10 October 2026.

The four checks, and the question each one answers

Check	Question it answers	Run it
Rich Results Test	Is this page eligible for a Google rich result, and which required properties are missing?	Before release, on one URL or on a pasted code block
Schema Markup Validator	Is the markup valid schema.org, with correct types, properties and nesting?	Whenever you use a type outside Google's supported list, or when the Rich Results Test says nothing is detected
Search Console Enhancements reports	What does Google find on my live pages, across the whole site, over time?	Weekly, and after every template change. Search Console is free
Bing URL Inspection	What does Bing see on this URL, including schema issues?	Alongside the Google checks, since Bing's index feeds other assistants. See Bing Webmaster Tools and the Bing webmaster documentation

The pairing matters. A page can be perfectly valid schema.org and still show no rich result, simply because Google does not produce a rich result for that type. Equally, a page can pass the Rich Results Test and contain a property you have misspelled, because that test only reports on what it needs for the feature.

How to run each check properly

• Rich Results Test, by URL. Paste the live URL. Choose the user agent, because the mobile and desktop crawls can differ on sites that serve different markup. Read the detected items, then open each one and work through the issues list. The rendered HTML tab shows you what the crawler received, which is where you discover that your markup was injected too late.
• Rich Results Test, by code. Paste the JSON-LD block itself. This is the right mode for a page that is not published yet, for a staging site behind a login, and for checking a block you have just written before it goes anywhere near a template.
• Schema Markup Validator. Paste a URL or the code. It reports the full structure it parsed, so use it to confirm nesting: that the address really is inside the organisation, that the offer really is inside the product, and that your identifiers tie entities together as you intended.
• Search Console. Open the Enhancements section and read the valid, warning and error counts per type, then use the example URL lists. This is the report that catches the problem affecting four thousand pages rather than the one you happened to test.

Errors, warnings, and what each one is worth

• An error means the feature is off. A missing required property stops eligibility for that rich result. Fix every error, and fix it in the template rather than on the page.
• A warning means a recommended property is absent. The page can still qualify, and adding the recommended property usually makes the result richer or more accurate. Work through warnings in order of how many pages they affect.
• Nothing detected is the most useful message of all. It almost always means one of four things: the markup is not in the response the crawler received, the JSON has a syntax error, the script tag is missing its application/ld+json type, or the page you tested is not the page you edited.
• Valid and still no rich result in search means eligibility rather than entitlement. Google decides per query whether to show the feature, and the structured data gallery in Google's introduction to structured data, checked on 10 October 2026, is the list of types that can produce one at all.

The seven problems a checker reliably catches

Problem	How it shows up	Fix
Invalid JSON	Nothing detected, or a parse error	A trailing comma or a smart quote from a word processor. Generate the block from data instead of typing it
Markup and page disagree	Warning or manual spotting: price in markup differs from the price shown	Populate both from the same field. Every value in the markup should be visible somewhere on the page
Missing required property	Error naming the property	Add it in the template, then revalidate one example of each page type
Wrong type for the page	Valid markup, no eligibility	Product on product pages, Article on editorial, LocalBusiness on location pages. One type per page type
Two blocks contradicting each other	Multiple detected items of the same type	One block per entity per page, with a stable identifier
Markup injected by JavaScript too late	Nothing detected by URL, detected when the code is pasted	Render it server side or at build time so it is in the first response
Review markup on the wrong page	Error or ineligibility on self serving reviews	Read the eligibility rule first, which our review schema guide sets out

A block to test with

Paste this into either checker, replace the values, and you have a working baseline to compare your own output against.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Example Supplies",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "sameAs": ["https://www.linkedin.com/company/example"],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+44 20 7000 0000",
    "contactType": "customer support",
    "areaServed": "GB"
  }
}
</script>

Checking at scale, not one URL at a time

• Crawl your own site and extract the markup. Any crawler that can report structured data per URL turns a one page check into a site wide inventory. Export it and sort by page type.
• Validate at build time. If your markup is generated from data, add a test that parses every generated block and fails the build on invalid JSON or a missing required property. This stops the problem reaching production at all.
• Keep one example URL per template on a watch list. Ten URLs revalidated monthly covers a site of any size, because the markup lives in the template.
• Diff after every release. Compare the extracted markup before and after a deploy. Most structured data regressions arrive with an unrelated template change.

The monthly routine

• Open Search Console Enhancements and clear anything counted as an error.
• Revalidate one URL per template in the Rich Results Test.
• Run the Schema Markup Validator on the home page and the main money page, to confirm identifiers still tie your entities together.
• Spot check that a price, a stock status and an opening time in the markup match what the page shows today.
• Inspect one URL in Bing Webmaster Tools, since a second engine's view catches different problems.

This page covers validating and monitoring structured data. For what structured data is and the types worth adding first, see what schema markup changes. For copyable blocks by type, see LocalBusiness and Organization. On WordPress, see schema plugins for WordPress.

What gets asked about schema markup checker

What happened to the Structured Data Testing Tool?

Google retired it and split the job in two. Eligibility checking moved to the Rich Results Test, and vocabulary checking moved to the Schema Markup Validator at validator.schema.org, which schema.org hosts. Both were checked on 10 October 2026.

Which checker should I use first?

The Rich Results Test, because it tells you whether the page can produce the result you want. Move to the Schema Markup Validator when the Rich Results Test detects nothing, or when you are using a type outside Google's supported list.

Can I check markup before the page is live?

Yes. Both tools accept a pasted code block, which is the right way to validate a new template or a staging page behind a login.

My markup is valid but I see no rich result. What next?

Confirm the type can produce a rich result at all, confirm the page is indexed, then check Search Console for the type to see whether Google has processed the live page. Google decides per query whether to display the feature, so a valid page is eligible rather than entitled, and the gain in clarity for every system reading the page holds either way.

How often should I validate?

One URL per template monthly, plus a full check after any template or plugin change. Markup breaks during releases far more often than it breaks on its own.

Valid markup, and then what an assistant makes of the page

A validator confirms that your markup parses and that eligible rich results can show. It says nothing of how an assistant, reading the same page, will describe the business.

Both checks are worth having, and they answer different questions. After the validator is green, ask an assistant about the entity the markup describes. AI Knows Us does that across several assistants and shows which names and facts come back, so you can set them beside the schema you wrote.