Most people test schema markup by pasting a URL into a single tool, seeing a green checkmark, and moving on. That approach misses the majority of real issues. Google uses multiple systems to process structured data, and they do not all agree with each other. A page can validate cleanly in one tool while producing warnings in Search Console and failing to generate rich results in production. The four-step workflow below is how I approach testing on any site, and it applies regardless of what CMS or schema type you are working with.

The three tools and what each one tells you

The Rich Results Test (search.google.com/test/rich-results) is the tool to run first. It shows you which rich result types Google can detect on a page, what properties it found, and whether anything is blocking eligibility. Critically, it renders the page the way Googlebot does — meaning it executes JavaScript — so it catches schema injected by scripts that a static parser would miss. If a type does not appear here, it will not generate rich results regardless of what you see in other tools.

The Schema Markup Validator (validator.schema.org) is the tool for checking syntactic correctness and property coverage against the full schema.org vocabulary. Unlike the Rich Results Test, it is not limited to types Google uses for rich results — it will validate MedicalEntity, Certification, Dataset, and any other type. It also surfaces warnings for recommended properties that are missing, which the Rich Results Test sometimes skips. Use this when you want to know if your markup is technically correct, not just whether Google can use it for a feature.

Google Search Console (search.google.com/search-console) is the authoritative record of what Google has actually processed at scale across your site. The Enhancements reports show you errors and warnings aggregated across all indexed URLs, which is something neither of the other tools can provide. The limitation is that Search Console reflects crawl data that may be days or weeks old, and it only shows types Google tracks for rich result features.

A four-step testing workflow

Step 1: Run the Rich Results Test on the URL immediately after deploying schema. Confirm the type is detected and there are no errors. Step 2: Run the Schema Markup Validator on the same URL and check for warnings on recommended properties you may have omitted. Step 3: Use Search Console to fetch and render the URL under URL Inspection and confirm Googlebot sees the same output as the Rich Results Test. Step 4: After Google recrawls the page (typically within a week for established sites), check the relevant Enhancements report in Search Console to confirm the URL is flagged as valid rather than having errors.

<!-- Confirm your block is present before testing -->
<!-- Then paste the live URL into Rich Results Test, not raw HTML -->
<script type='application/ld+json'>
{
  '@context': 'https://schema.org',
  '@type': 'WebPage',
  'name': 'How to Test Schema Markup'
}
</script>

Testing before you publish, not just after

Most of the testing mistakes I see happen because someone waits until a page is live to run any of these tools. By the time you catch a problem in production, Google may have already crawled a broken version, and you are waiting on a recrawl before you can even confirm the fix worked. I test in two places before a page ever goes live. First, I check the rendered HTML with view-source or a browser’s developer tools to confirm the JSON-LD block is actually present in the DOM and not stripped out by a caching layer or a template conditional that only fires in certain contexts. Second, if the site has a staging environment, I run the Rich Results Test against the staging URL, keeping in mind that a robots.txt block or noindex tag on staging can make results look worse than they will be in production — so I treat a staging failure as informative, not final, unless I know the crawl block is not the cause.

The other habit worth building is testing immediately after any deploy that touches templates, not just content. Schema markup is usually generated by a template or a plugin, which means a single change to a theme file, a plugin update, or a migration can silently strip or break markup across hundreds of pages at once. Spot-checking one URL after a content edit is not the same as checking whether a template change affected the whole site. I treat template and plugin deploys as a trigger to retest a representative sample of URLs, not just the one page someone happened to be editing.

Testing schema at scale, not just one URL at a time

Everything above works well for a single page, but most sites are not built page by page — they are built from templates, and a handful of URLs is not a reliable sample once you are past a few dozen pages. When I test a site with hundreds or thousands of templated pages, I do not rely on the Rich Results Test alone, because there is no version of that tool built for bulk checking. Instead I use a crawler with custom extraction (Screaming Frog is the one I reach for most often) to pull the JSON-LD block from every URL in a sitemap, then compare the extracted @type and required properties against what the template is supposed to output. This surfaces the pages where a conditional failed, a field was empty and the property silently dropped, or a content type variant never got the markup applied to begin with.

Search Console’s Enhancements reports are the other side of scale testing. Instead of asking “does this one page validate,” the question becomes “what percentage of my indexed URLs for this type are showing valid versus with warnings versus with errors.” A site with 40 pages showing errors in the Product Enhancement report has a systemic issue, not 40 individual issues, and the fix is almost always in one template or one data source, not in 40 separate places. I use the Enhancements report to find the pattern, then use the crawler export to identify exactly which URLs and which template variant is affected, then fix the template once.

When to retest markup you already validated

Structured data is not something you test once and leave alone. It breaks silently, and nobody notices until a rich result that used to show up stops appearing weeks later. There are a few events that should trigger a retest of your full schema footprint even if nothing about the page content changed. A site redesign or CMS migration is the most common cause of schema regressions I see — markup that lived in an old template does not always get carried over to the new one, and it is easy for a redesign to focus entirely on visual layout while structured data gets forgotten. A plugin update on a WordPress site is another common trigger, particularly for SEO plugins that generate schema automatically, since an update can change default property mappings without any visible change to the page. And a content restructuring — merging categories, changing how prices or availability are stored, renaming custom fields a template pulls from — can quietly break the mapping between your content and the properties in your schema even though the template code itself never changed.

My practice is to treat any of those three events as a mandatory retest, not an optional one, and to retest a representative sample across every template type on the site, not just the pages someone happened to touch. It is a lot faster to catch a broken template on day one than to notice six months later that an entire content type quietly stopped generating rich results and to have to work backward to find out when and why.

Errors vs. warnings

In both the Rich Results Test and the Schema Markup Validator, errors indicate something that blocks eligibility or violates the specification — these need to be fixed. Warnings indicate missing recommended properties. Fixing warnings is not always required for a rich result to appear, but in practice missing recommended properties like image, author, or datePublished are often what prevent a result from surfacing even when errors are absent. Treat warnings as a priority list, not an ignore list.

Common mistakes

  • Testing only with the Schema Markup Validator, which does not reflect Google rich result eligibility requirements.
  • Testing a staging URL with a different domain or robots.txt block, which changes how Googlebot renders the page.
  • Treating a Rich Results Test pass as confirmation the markup will generate rich results in production — eligibility does not guarantee appearance.
  • Ignoring warnings and only fixing errors, when missing recommended properties like image or author are often what prevent rich results from appearing.
  • Checking Search Console once and assuming the data is current — the Enhancements reports update on a crawl cycle, not in real time.
  • Testing one URL after a template or plugin deploy and assuming the rest of the site is unaffected.

If your testing workflow is surfacing errors you cannot diagnose, or if Search Console shows a pattern of warnings across many URLs, that is a signal to look at the underlying implementation rather than fix issues one at a time. A schema audit identifies systemic issues across the full site. If you want help building a testing process or interpreting what Search Console is telling you, that is part of what I cover in schema markup consulting. For background on the tools used to generate the markup you are testing, see the schema generators guide.

Related reading on testing and monitoring schema