Google Rich Results Test: Validate Your Schema Markup Instantly

Structured data is one of those things that's easy to get subtly wrong and hard to debug without the right tool in front of you. I've been using Google Rich Results Test as my go-to for JSON schema validation — specifically for checking whether the schema.org JSON-LD blocks I drop into pages are actually valid and eligible for rich results in Google Search. It's a hosted tool from Google, not open-source, but it's free, requires no account, and gives you the most authoritative read on structured data you can get short of waiting for Google to crawl your page.

What Google Rich Results Test Actually Does

The tool accepts either a live URL or a raw HTML snippet, parses every structured data block it finds, and tells you two things: whether the markup is technically valid JSON-LD, and whether it qualifies for specific Google rich result types — things like FAQ dropdowns, article cards, breadcrumbs, product snippets, review stars, and so on. That second layer is what makes it genuinely useful beyond a generic JSON linter. You're not just checking syntax; you're checking whether Google will actually do something with your schema.

The results screen breaks down every detected schema type, flags errors (which block rich results) separately from warnings (which are advisory), and shows you a rendered preview of what the rich result would look like in search — before a single Googlebot crawl has happened.

How I Use It for JSON-LD Validation

My most common workflow is the HTML snippet path rather than the URL path. When I'm building out structured data for a page — especially TechArticle, SoftwareApplication, or BreadcrumbList blocks — I paste the raw JSON-LD directly into the code input rather than deploying and testing against a live URL. That gives me an instant feedback loop without touching a server:

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "Google Rich Results Test: Validate Your Schema Markup", "author": { "@type": "Person", "name": "Dev Ervin A." }, "datePublished": "2025-01-01", "about": { "@type": "SoftwareApplication", "name": "Google Rich Results Test", "url": "https://search.google.com/test/rich-results" } } </script>

Paste that block into the tool's HTML input, hit Test Code, and within a few seconds you get a full breakdown. If a required property is missing or a type is mismatched, it surfaces immediately with a specific error message — not a generic "invalid JSON" response, but a structured-data-aware error like "Missing field 'author'" or "Invalid value for property 'datePublished'."

The Workflow That Actually Saves Time

Here's the exact pattern I follow when adding or updating schema on any page:

1. Draft the JSON-LD in a scratch file or directly in the CMS template.
2. Paste the full HTML block (including the <script type="application/ld+json"> wrapper) into the Rich Results Test code input.
3. Read the detected items list. If the tool finds fewer schema types than I expect, something is structurally wrong — a missing closing brace, a misplaced comma, a nested object that didn't parse.
4. Fix errors first, then warnings. Errors are blockers; warnings are advisory. I don't ship with open errors, ever.
5. Check the rich result preview to confirm the visual output matches intent — especially for Article and Product types where the preview shows exactly what a search result card would look like.
6. Deploy, then run the URL test against the live page to confirm the rendered HTML still contains the schema after any CMS or framework processing.

That final URL test matters more than it sounds. Frameworks and CMS platforms — Drupal included — sometimes strip, escape, or double-encode JSON-LD blocks during render. Testing the raw snippet and the live URL are two different checks, and you need both.

What It's Particularly Good At

• Catching type mismatches fast. If you use "datePublished": "January 2025" instead of an ISO 8601 date string, the tool flags it immediately. That's the kind of subtle error that passes a JSON syntax check but fails schema validation.
• Nested object validation. Complex schemas with nested @type declarations — an Article with an author of type Person with a sameAs pointing to a URL — get fully parsed and each level is validated independently.
• Multiple schema blocks on one page. If your page has both a BreadcrumbList and a TechArticle block, the tool finds and validates both in a single pass. You see all detected items in one results screen.
• Rich result eligibility, not just syntax. A JSON-LD block can be perfectly valid syntax and still not qualify for a rich result because a required property for that specific type is missing. This tool tells you both things separately.

Rough Edges and Limitations

For all its usefulness, there are real constraints worth knowing:

• Not open-source, not an API. This is a Google-hosted web tool with no public API. You can't script it, integrate it into a CI pipeline, or run it locally. For automated schema validation in a build process, you'd need a separate tool like the schema-dts TypeScript library or a custom JSON Schema validator.
• Only covers Google's rich result types. The tool validates schema against Google's specific implementation of schema.org, not the full schema.org specification. A property that's valid per schema.org might not appear in the Rich Results Test results if Google doesn't use it for any of its rich result types.
• No bulk testing. You test one URL or one snippet at a time. If you're auditing schema across fifty pages, this is slow manual work. Google Search Console's Enhancements reports are a better tool for site-wide audits.
• Preview accuracy isn't guaranteed. The rich result preview is illustrative, not a pixel-perfect promise of what will appear in search results. Google's actual rendering depends on additional signals beyond schema validity — content quality, page authority, and crawl frequency all factor in.
• Rendering can lag on JavaScript-heavy pages. For pages where JSON-LD is injected by client-side JavaScript, the URL test may not execute the JavaScript fully. Server-side rendered or static schema is always more reliable for this tool.

The Bottom Line on JSON Schema Validation

Google Rich Results Test isn't glamorous, but it's the most authoritative JSON schema validation tool available for web developers working with structured data. The fact that it comes directly from Google — the entity whose crawlers will eventually consume your schema — means its opinion on validity is the only one that practically matters for SEO purposes. I use it at every stage of schema work: drafting, deploying, and auditing. It's one of those tools that earns a permanent browser bookmark not because it's clever, but because it's exactly right for the job every single time you need it.

WHY I'D USE IT (valid HTML, 2 short paragraphs — my personal use case):

On this Drupal site, every post emits schema.org structured data as a TechArticle about a SoftwareApplication — and getting that right matters for rich search results. I use Google Rich Results Test every time I update the schema template or add a new field to the structured data output. Pasting the raw JSON-LD snippet into the tool before touching a live URL is the fastest way I know to catch a missing required property or a malformed nested object before it goes anywhere near Googlebot.

I also use it as a gut-check whenever I'm unsure whether a schema.org property I want to use is actually recognized by Google's rich results pipeline. The tool either surfaces it in the detected items panel or it doesn't — which is a faster and more reliable answer than reading through documentation. For structured data work, it's permanently open in a tab alongside my CMS.