Schema validation guide

What schema validation can and cannot tell you

Structured data makes page and entity information machine readable. Validation checks whether a tool can parse it; it does not prove that content is useful, true, eligible for every search treatment, or likely to be cited by an AI system. In an agency report, state what the tool checked rather than implying a prediction.

Google’s structured data testing guidance recommends the Rich Results Test for Google features and the Schema Markup Validator for general Schema.org validation. The latter extracts JSON LD, RDFa, and Microdata and summarizes the graph. Use the AEO audits hub to place schema work in the wider readiness review.

Use the right tool for each layer

The Schema.org Markup Validator focuses on Schema.org. It can fetch a page or inspect supplied markup, extract supported formats, display the graph, and identify syntax mistakes. Use it to ask what entities, properties, and relationships are present. It is not a Google eligibility checker, and its JSON LD interpretation does not cover every possible context.

Google’s Rich Results Test asks whether a page has markup recognized for a supported Google feature and reports feature specific issues. A result type absent from the test is not automatically invalid Schema.org; generic validity does not establish Google eligibility. Check current documentation for the feature you actually target, since supported appearances and requirements can change.

Build a representative test set before testing

A homepage test does not cover a site whose schema varies by template or data. Before testing, list the templates, intended types, and data variations that change output. A deliberate sample is more useful than many nearly identical URLs.

1. 01Inventory templates that emit structured data: for example, service pages, product pages, editorial articles, locations, and event pages. Record the intended entity type and the source of each data field.
2. 02Choose a representative URL for each template, including meaningful variants such as a page with no image, multiple offers, a changed date, or optional author information. Include any page where a CMS migration or recent deployment changed the output.
3. 03For each sample, capture the live URL, test date, intended type, actual extracted types, warnings or errors, and the page template. Note whether the test used a fetched URL or manually supplied markup.
4. 04If a page is personalized, gated, or rendered differently by device or region, note the limitation and inspect the publicly accessible version that search systems can retrieve.

Diagnose failures from syntax to feature requirements

Separate an error into layers rather than rewriting the whole schema. First check JSON LD syntax: a missing comma, mismatched quote, or bracket can prevent parsing. Then inspect the graph for the expected `@context`, `@type`, property names, and relationships. Capitalization or a string supplied where an object is expected can produce a parseable fragment with the wrong meaning.

Next compare the graph with the targeted Google feature’s documentation. A missing required property differs from an optional recommendation and from a Schema.org vocabulary issue. For example, an Article graph may parse while the feature test flags a missing feature specific value; add it only when accurate and available on the page.

If live URL testing disagrees with pasted markup, inspect the deployed output. Template conditions, JavaScript injection, redirects, caching, or a stale build may explain the difference. Pasting code isolates a fragment; it does not verify the rendered page.

Audit the graph against what people can see

A parseable graph can still mislead. Compare names, descriptions, prices, dates, authors, locations, and images with visible content and its source data. Confirm the markup describes this page, not a related page or convenient sitewide default. Do not keep a hidden, outdated, or contradicted value simply because a validator accepts it.

Google’s structured data policies require markup to represent visible content and follow general and feature specific guidelines. Automated tools cannot test every quality rule. For terminology, see what structured data means and schema markup.

Review entity relationships and duplicates

Do not stop at the type name. Follow the graph: is the main entity linked to the right organization, author, product, or location? Are identifiers stable where related entities should connect? For example, an article author should not accidentally resolve to the company as if they were the same person, and a branch page should not inherit a generic address.

Check whether plugins or theme components emit competing versions of an entity. Duplicates are not always errors, but conflicting names, URLs, or values make interpretation less dependable. The validator’s graph view helps expose this. See the JSON LD templates guide, adapting examples only when they fit the page.

Turn validation into a release and audit control

An agency deliverable should record scope: URL, template, date, tool, detected types, errors, reviewed warnings, and the change made. Rerun tests on the deployed URL after release. A staging result does not prove production received identical markup, and later content or template changes can invalidate an earlier check.

For large sites, prioritize template coverage and important pages rather than claiming a few samples certify every URL. A failure across a template points to a shared component; a one record error may come from CMS data. Connect findings to the AEO audit checklist and readiness testing process. Track search observations separately with AEO KPIs and tracking; a validator pass is not a visibility metric.

Interpret eligibility without overpromising

A successful Rich Results Test means Google recognized markup for a supported feature in the tested page; it does not promise display. Page quality, policy compliance, indexing, technical access, and feature requirements still matter. Schema.org validity makes a narrower claim: the validator interpreted the markup it found. Neither test proves an AI system will retrieve or cite the page.

In reports, say “the tested URL contains markup recognized for this feature,” not “schema is ranking” or “citations are secured.” Record unresolved policy or content questions for human review and retest after material changes.