Practical guides

Validate structured data on a website

Valid markup cannot repair an inaccurate page. Start with what visitors see, then inspect the code, identifiers and any eligibility for a search presentation.

Go to the method

Person comparing page information with its structured representation

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.