Resources · 64
Structured data: verify meaning, evidence and supported features
Connect JSON-LD to visible content, separate vocabulary validity from Google support and review templates and exceptions after changes.
· 3 min
What this guide helps achieve
- Describe the actual page
- Separate validation levels
- Check sensitive fields
- Test templates and exceptions
Quick check
- Does error-free validation guarantee a rich result?
- Should a useful FAQ be removed?
- What if a property is missing?
Step-by-step method
- 01
Describe the actual page
Choose entities actually described: article, product, organisation or another relevant object. Connect each property to visible, verifiable information. Google requires markup representative of reader-accessible content.
Deliverable: property-to-editorial-evidence map.
- 02
Separate validation levels
Valid JSON does not ensure correct vocabulary; valid vocabulary does not ensure a Google feature. Consult current type and feature documentation during acceptance. Technical validity guarantees no appearance.
Deliverable: validators and their respective roles.
- 03
Check sensitive fields
Inspect authors, dates, prices, availability and reviews where used. Do not create ratings or client outcomes to fill a field. A missing optional property is preferable to an unverifiable claim.
Deliverable: provenance and consistency review.
- 04
Test templates and exceptions
Sample languages, pagination, records without images and removed content. Inspect entity identifiers and URLs. If server and browser versions differ, examine both representations.
Deliverable: outcomes per template and page state.
- 05
Maintain feature support
Track documentation changes and distinguish a retired feature from defective markup. Google FAQ and HowTo search features have been retired; useful questions may remain without promising rich results.
Deliverable: feature register and review date.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Entity | Type, identifier and URL |
| Property | Value and visible evidence |
| Feature | Documentation and verification date |
| Acceptance | Template, language, outcome and correction |
Worked example
Illustrative situation
Fictional example: a product template retains an old JSON-LD price after the displayed price changes.
Decision and expected evidence
Acceptance detects the discrepancy and makes both representations use the same verified source.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Valid JSON | Read serialized structure | Do not infer correct semantics |
| Recognised vocabulary | Describe entities and properties | Do not infer Google feature support |
| Supported feature | Assess current criteria | Do not promise appearance or ranking |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Justified properties | Fields linked to visible evidence | Correct unsupported assertions |
| Tested templates | Page states and languages exercised | Name uncovered exceptions |
| Markup/render discrepancies | Contradictory information | Correct the common source rather than duplicating |
Common pitfalls
- Do not infer correct semantics
- Do not infer Google feature support
- Do not promise appearance or ranking
Frequently asked questions
Does error-free validation guarantee a rich result?
No. Google states technical and quality requirements are needed for eligibility without guaranteeing display.
Should a useful FAQ be removed?
No. Its editorial value does not depend on rich results. Assess content and feature support separately.
What if a property is missing?
Check whether it is required for the intended type, then obtain reliable information or adjust markup; do not invent it.
Official references
References consulted on 2 October 2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
