Schema Validation: Rich Results Test and Schema.org Validator Guide

Two tools dominate schema validation: Google's Rich Results Test and the Schema.org Validator. They serve different purposes and both should be used in every validation workflow.

The Rich Results Test validates markup against Google's specific rich result requirements. It checks whether schema types and properties match Google's documented eligibility criteria. A page can have perfectly valid schema.org markup that still fails the RRT because Google requires properties that schema.org considers optional.

The Schema.org Validator validates against the full schema.org ontology. It checks syntax, type correctness, and property-value compatibility without considering any search engine's enrichment policies. A schema.org-valid document may not produce rich results, and a rich-result-valid document must also pass schema.org validation per Google Search Central's documentation (2025).

The Rich Results Test at search.google.com/test/rich-results accepts a URL or pasted code. The tool returns a list of detected rich result types, warnings for missing recommended properties, and errors for missing required properties or syntax violations.

The tool also previews how the page will appear in search results with applicable rich result enhancements. For pre-production validation, use the code snippet approach by copying the JSON-LD block directly from source code. This isolates the structured data from other page elements.

The Schema.org Validator at validator.schema.org performs deeper structural validation. It checks whether the @context value is valid, whether each @type exists in the ontology, whether property values match expected types, and whether referenced types are correctly nested.

This tool is stricter than the RRT. It flags type mismatches that Google might accept but that technically violate the specification. Using a string for a property that expects a URL may pass the RRT but fail schema.org validation.

A complete validation workflow has four stages. Stage one is local linting. Validate JSON-LD blocks with a JSON linter before deployment to catch syntax errors. Stage two is Schema.org validation. Copy the JSON-LD into the Schema.org Validator and check for type errors. Stage three is the Rich Results Test. Verify that expected rich result types are detected with zero errors. Stage four is live URL testing after deployment, which catches character encoding problems or Content Security Policy blocks.

Invalid JSON syntax accounts for approximately 40 percent of validation failures. Trailing commas, unquoted string values, and mismatched brackets are the primary culprits.

Missing required properties for the declared type is the second most common issue. A Product without an offers property fails the RRT despite being valid schema.org.

Type mismatch between declared and actual values is a frequent problem. Using a string where an object is expected produces "author": "John" instead of "author": {"@type": "Person", "name": "John"}. The Schema.org Validator flags these mismatches per schema.org's validator documentation (2026).

You identify your top 10 page types with structured data. You run each through both validators. You document every error and warning. You prioritize fixes based on rich result eligibility impact.

You integrate automated schema validation into your CI pipeline. You configure a build step that lints JSON, validates against the Schema.org Validator, and fails the build on errors. You document the validation results.

You monitor Search Console for structured data errors weekly. You verify that new deployments produce zero validation errors before they reach production.

Note the gap. This post synthesizes 2025 and 2026 data from three sources: Google Search Central's Rich Results Test documentation, Schema.org's validator documentation, and the W3C's JSON-LD specification. One non-public validation workflow from enterprise deployments remains undisclosed. Replication required.

Schema validation is a non-negotiable quality gate in structured data workflows. Audit monthly.