Validate structured data on a website

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 Google Search no longer displays FAQ rich results as of 7 May 2026, according to its official updates.

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.

Distinguish an entity’s identity from the address of its describing document. In JSON-LD, @id supplies a node identifier; relative references must be interpreted with their base and context. Fictional example: two descriptions using the same absolute IRI https://example.com/#org identify the same node even if they contribute different properties. Two organisations sharing a name do not thereby become one entity. Avoid reusing an organisation identifier for its page, its author or each distinct establishment.

An @id containing #org does not automatically create an HTML element with id="org". If you also provide a navigation link to part of the page, test the HTML target separately. Keep reference entity identifiers across templates when they really describe the same entity, while identifying language pages and their content correctly. Then check properties against visible content: valid JSON, coherent identity and Google eligibility remain three separate checks. None guarantees a rich result.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

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.

Align JSON and visible content

Proposed case: service text was corrected but an old condition remains in page JSON. Valid syntax can still describe another offer.

Compare fields with their source and display. Keep type, value, origin and page; distinguish syntax errors, content inconsistency and eligibility for a search feature.

• Identify each field's source
• Compare JSON and displayed page
• Keep the check result

• Qualify missing data

  Audit and enrich directory or catalogue data