Validating Structured Data with Rich Results Test
After writing JSON-LD, don't rush to launch—validate first. A missing required field, a syntax error, can completely break your structured data, and you won't see any hint in search results. Validation tools can tell you what's wrong before launch. This article clarifies how to use two core tools, how to distinguish errors from warnings, and how to troubleshoot common issues.
Why You Must Validate#
Structured data is written for machines to read, making problems hard to spot with the naked eye. Its "silent failure" characteristic is particularly dangerous:
- Syntax errors break everything: A trailing comma, an unescaped quote can make the entire JSON-LD unparseable.
- Missing required fields silently fail: The page displays normally, but that type won't get rich results—you won't receive any warning.
- Rich results have delays: Even when everything is correct, there's a delay before appearing in search results. Debugging by "watching search results" is extremely inefficient.
So the correct workflow is: validate with tools after writing → deploy after passing → monitor after launch. Validation is the fastest, most controllable step in this chain.
Two Core Tools#
| Tool | Owner | What It Checks | Use |
|---|---|---|---|
| Rich Results Test 富媒体结果测试 | Types Google supports that can produce rich results | Determine if page can get rich results | |
| Schema Markup Validator schema.org 校验器 | schema.org | Compliance with schema.org syntax (all types) | General syntax validation |
The two serve different purposes and complement each other:
- Want to know "can I get rich results" → Use Rich Results Test. It only recognizes types Google supports (like Article, FAQ, Product, Breadcrumb, etc.) and directly tells you which rich result it detected.
- Want pure syntax validation → Use Schema Markup Validator. It covers all schema.org types but doesn't determine whether Google will display them.
Two Testing Methods#
Rich Results Test supports two input methods for different stages:
| Method | What It Does | Suitable For |
|---|---|---|
| Test URL | Google actually fetches and renders the live page | Validating live pages, can discover rendering issues |
| Test Code | Directly validates pasted HTML fragment | Pre-launch debugging, local development, unpublished pages |
Typical workflow: use code testing repeatedly during development → use URL testing after launch to verify what Googlebot actually sees. URL testing is especially important because it can expose JavaScript rendering issues—if your JSON-LD is injected via JS, code testing won't show rendering delays, only URL testing reflects reality (see JavaScript SEO Basics).
Understanding Test Results#
Test results list detected structured data items, each potentially with errors or warnings. Distinguishing these is key to troubleshooting:
| Type | Meaning | Impact | Priority |
|---|---|---|---|
| Error | Missing required field or invalid field value | Cannot get rich results | Must fix |
| Warning | Missing recommended field | Doesn't affect eligibility, but display less rich | Recommended to complete |
| Valid | No errors | Eligible for rich results | Can launch |
The principle is simple: zero out all errors first, then minimize warnings. Unfixed errors mean no rich results; incomplete warnings just reduce richness—can prioritize as needed.
Common Errors & Causes#
| Error Message (approx.) | Cause | Fix |
|---|---|---|
| "Unable to parse" / Syntax error | JSON has trailing comma, unescaped quotes, missing brackets | Check syntax with JSON validator |
| "Missing field X" | Required field for that type not provided | Add required field |
| "Invalid value for field X" | Wrong format (e.g., date not ISO 8601) | Fix value according to format |
| "No structured data detected" | type misspelled, JSON-LD not in rendered DOM | Check type, confirm in HTML |
| "Content mismatch with visible content" | Marked information doesn't exist on page | Make markup match visible content |
| Image/URL inaccessible | Referenced resource URL broken or blocked | Use publicly accessible absolute URLs |
A Validation Workflow#
- JSON syntax self-check: First ensure JSON-LD itself is valid JSON.
- Code testing: Paste page HTML (or fragment) into Rich Results Test "code" mode, see detected types and errors/warnings.
- Fix errors: Clear all Errors one by one, supplement Warnings as needed.
- schema.org validation: When more general syntax validation is needed, double-check with Schema Markup Validator.
- Launch: Deploy after validation passes.
- URL testing verification: After launch, test live page with URL mode to confirm Googlebot still sees it correctly after rendering.
- Continuous monitoring: Later track in Search Console (see next article).
JSON syntax self-check
↓
Rich Results Test (code mode) → Has Errors? → Fix → Retest
↓ All pass
(Optional) Schema Markup Validator double-check
↓
Launch
↓
Rich Results Test (URL mode) verify rendered results
↓
Search Console continuous monitoring
How This Site Validates#
Validation Checklist#
- JSON-LD passes JSON syntax validation
- Rich Results Test code mode has no Errors
- Complete recommended fields from Warnings as much as possible
- Detected types match expectations
- Referenced images/URLs are publicly accessible
- Marked content matches page visible content
- Verify with URL mode after launch for rendered results
- For JS-injected markup, prioritize URL mode validation
- Include in Search Console continuous monitoring
Frequently Asked Questions#
What's the difference between Rich Results Test and Schema.org validator?
Rich Results Test is Google's tool that only checks types Google supports and can render as rich results, telling you whether the page is "eligible" for specific rich result appearances. Schema Markup Validator checks syntax compliance with schema.org specifications, covering all types, but doesn't determine whether Google will display them. Simply put: use the former to check rich result eligibility, use the latter for general syntax validation.
Does passing the test guarantee rich results will display?
Not necessarily. Passing Rich Results Test only means "eligible," not "guaranteed display." Google comprehensively considers page quality, content meeting display standards, guideline compliance, search context, and other factors to decide whether and when to display rich results. Passing the test is a necessary but not sufficient condition—it's the part you can control; display is Google's decision.
What's the difference between Error and Warning?
Errors must be fixed—usually means missing required fields or invalid field values, preventing that type from getting rich results. Warnings are advisory—usually missing recommended fields, don't affect eligibility, but completing them makes rich results richer and more likely to appear. Priority-wise: clear all errors first, then minimize warnings.
What's the difference between URL testing and code testing?
URL testing has Google actually fetch and render the live page, reflecting what Googlebot actually sees—suitable for validating live pages, especially discovering JavaScript rendering issues. Code paste testing directly validates the HTML snippet you provide—suitable for pre-launch debugging, local development, or unpublished pages. Recommended: use code testing before launch, URL testing after launch for verification.