Choose an entity and a clear purpose
Identify what the page really represents: an organisation, article, product, event or list. Describe its main entity before adding properties. A service page does not become a fixed-price product because a schema type exists, and a visible FAQ is not automatically eligible for a rich result.
Consult Google’s supported rich-result gallery for the type you intend to use. Schema.org offers a wider vocabulary than the search features Google supports. Semantic description and rich-result eligibility are separate questions.
Compare values with published content
Compare names, descriptions, images, authors, dates, addresses, prices and availability with what a visitor can see. Remove invented reviews, ratings, amounts or locations. Google’s policies require representative visible content and do not guarantee a rich result.
For translated pages, use the values and URLs of that language. Dates should describe actual publication or modification. Avoid presenting a service area page as a separate physical business location.
- Values verifiable on the page.
- Consistent dates and images.
- No guaranteed feature claims.
Validate syntax and identifiers
Read the JSON-LD from the final page, including the rendered result if JavaScript creates it. Check required or recommended properties for the target feature, absolute URLs, duplicates and stable @id values. Rich Results Test and Schema.org Validator answer different questions: Google support and vocabulary validation.
Fix syntax problems at the template or data source, then sample several pages of that type. A single example will not reveal empty fields, escaping errors or unusual entry data elsewhere.
Monitor changes and limitations
After publication, review Search Console errors if a report exists for that type. Compare several URLs and crawl dates; the absence of a rich result alone does not prove broken markup. Features and criteria can change.
Include markup in editorial checks: when content, images, prices or templates change, recheck their structured representation. The prelaunch guide places this check in a broader release review.
- One example of each template checked.
- Errors tracked with dates.
- Recheck after content or code changes.
