Writing schema markup and validating schema markup are two different skills. I have seen sites with technically correct JSON-LD that fails to generate rich results because of a property mismatch, a wrong URL, or a content discrepancy between the markup and the visible page. Validation is not a QA formality — it is the step that converts markup from code in a script tag into an actual SERP feature.

The Three-Layer Validation Stack

Solid schema validation uses three tools that catch different categories of errors:

  1. Schema.org Validator — validates against the schema.org specification; catches type errors, unknown properties, and malformed entity structures
  2. Google Rich Results Test — validates against Google’s specific implementation requirements; shows which rich result types the page qualifies for and provides a visual preview
  3. Google Search Console — validates at scale across the entire site; shows indexing status, errors over time, and regressions after site updates

Each tool catches things the others miss. Schema.org validation can pass while Google validation fails — Google requires fields beyond the bare schema.org minimum. Google Rich Results Test can pass while Search Console shows errors — because Search Console catches issues visible only at crawl time or across many pages. Use all three, in order.

Step 1: Schema.org Validator

Go to validator.schema.org. You can paste raw JSON-LD or enter a live page URL. The validator parses the markup against schema.org type definitions and flags:

  • Unknown properties — properties that do not exist on the declared type
  • Type mismatches — passing a text string where a URL or an entity is expected
  • Missing required properties for a given type
  • Incorrect value formats — date strings not in ISO 8601, unitCode values that are not valid UNECE codes, etc.
  • Structural issues with nested entities or @graph references

Run this first, before Google’s tool. Fix schema.org-level errors before moving to Google-specific validation. A schema.org error that you discover only in the Rich Results Test has already passed through the first filter it should have caught. The same three-layer process applies to specialized types like dataset markup for research and data pages.

Step 2: Google Rich Results Test

Go to search.google.com/test/rich-results. Enter the live page URL — preferred over pasting raw code because the tool renders the page as Googlebot sees it, catching issues that only appear in the rendered DOM (JavaScript-generated markup, conditionally loaded elements, CMS-rendered content). The tool shows:

  • Which rich result types the page qualifies for, listed by name
  • A visual preview of how the rich result may appear in the SERP
  • Errors that block eligibility — missing required fields, invalid property values, content mismatches
  • Warnings for recommended but not required fields
  • The full list of detected items and their parsed property values — useful for confirming that markup you added is being read correctly

Pay close attention to warnings. A warning on image for a NewsArticle means the image is present but undersized — it will not disqualify the page from article rich results, but it will prevent Top Stories carousel eligibility. Warnings often have larger practical impact than their classification suggests.

Step 3: Google Search Console Enhancements Report

Google Search Console under Enhancements shows a card for each rich result type detected across the site. Click into any card to see: valid item counts (with and without warnings), invalid item counts, specific error types grouped by frequency, affected page URLs for each error type, and a trend over time. The trend view is particularly useful — a spike in errors after a deployment is an unambiguous signal to investigate the template.

The Enhancements report is the only place to see markup issues at scale. A single template error affecting 500 product pages shows up here as a single, high-frequency error type. Fix the template, validate the fix with the Rich Results Test, then request reindexing of a representative sample URL. Once Search Console acknowledges the fix on the sample, it will process the rest of the affected URLs through regular crawl cycles.

Common Errors and What They Actually Mean

  • ‘Missing field: image’ — no image property in the markup, or the URL points to a file that returns a 404; verify the image URL is accessible to Googlebot (see image schema markup for the full ImageObject spec)
  • ‘Missing field: author’ — the author is a plain text string instead of a Person entity; wrap it in the correct entity structure
  • ‘Either reviewCount or ratingCount should be specified’ — aggregateRating is present without a count property; add one
  • Price mismatch — the price in markup does not match the visible price on the page; update the markup to reflect the actual displayed price (common on restaurant and menu pages where pricing changes frequently)
  • ‘Field datePublished format is not valid’ — the date is not in ISO 8601 format; locale-format dates like MM/DD/YYYY fail this check
  • ‘The value provided for author is invalid’ — usually a missing @type on the Person entity, or an empty name property
  • ‘A value for the logo field is required’ — on NewsArticle publisher entities; the logo must be an ImageObject with a valid URL, not a text string

Validating a Connected @graph

For pages using the @graph pattern with multiple connected entities — covered in nested schema and @graph — validate each entity type separately in addition to the full block. The Rich Results Test shows detected items by type; click into each one and confirm the properties are populated correctly. A broken @id cross-reference will not throw a hard error in most validators, but the related entity will show as an unresolved string reference rather than a connected node. That is the check to make explicitly.

Validation After Deployment Changes

Schema markup needs re-validation after any of these events: theme or template update, CMS plugin update that touches schema generation, URL structure change, domain migration, A/B testing that alters page structure, or any change to the header or footer where sitewide JSON-LD lives. The easiest way to catch post-deployment regressions is a recurring Search Console check — the Enhancements report updates as Googlebot recrawls pages after deployment.

Building a Validation Habit

For sites with active publishing and regular updates, validation should be a named step in the deployment process, not an afterthought. A pre-launch checklist that includes ‘schema validated on five representative page types’ prevents the class of problems that take months to discover through Search Console. The five representative types for most content sites: homepage, inner service or category page, content article, author or person page, and contact page.

If you are preparing for a site migration and need to validate schema continuity across the transition, the process is the same — just applied to the staging environment before launch and to production immediately after. See schema markup migration for the migration-specific workflow. For a one-time comprehensive audit of your current markup status — including the three-layer validation pass — my schema markup consulting engagements start with exactly that.