A structured data validation checklist should answer two separate questions: is the markup valid Schema.org data, and does it meet the rules for a specific search feature? Test both before release, confirm that the markup describes the visible page, and retest the live URL after every template change.
Inventory the pages and markup
List every template that emits JSON-LD, Microdata, or RDFa. Record the page type, the Schema.org type, the code owner, the data source, and the search feature the markup is meant to support. Include pages created by plugins, theme components, tag managers, and server-side templates.
Do not assume that passing one sample proves the whole site works. Test examples with missing images, optional fields, unusual names, sale prices, archived content, and empty values. A template can produce valid output for one record and broken output for another.
Use the right validator
Google recommends its Rich Results Test to check which Google rich-result features a page may be eligible for. For general Schema.org validation, Google points to the Schema Markup Validator, which checks Schema.org markup without Google-specific feature rules (Google Search Central).
The Schema.org validator can fetch a URL or accept pasted markup. It extracts JSON-LD, RDFa, and Microdata, displays the resulting data graph, and identifies syntax mistakes (Schema.org). Use both tools when the goal is a Google search feature: one checks the vocabulary and structure, while the other checks Google's feature-specific expectations.
Compare markup with the page
Open the rendered page and compare each important property with what a visitor can see. Confirm names, dates, prices, availability, images, ratings, authors, breadcrumbs, and canonical URLs. Remove stale or hidden claims rather than preserving them only in markup.
Check that identifiers remain stable across templates and that nested objects describe the same entity as the page. If a plugin and the theme both emit markup for the same item, inspect the combined result for conflicting values.
Test code, preview, and live URLs
Validate the generated code before deployment, then validate a preview that uses realistic records. After release, test the public URL so redirects, JavaScript rendering, caching, and production data are included. Record the test date, tested URL, detected types, warnings, errors, and owner.
Treat warnings as review prompts, not automatic failures. Determine whether a recommended property is relevant and supported by visible content. Treat errors as blockers for the affected feature until corrected and retested.
Check crawl and canonical conditions
Confirm the public page returns the intended status, is not unexpectedly blocked from crawling, and points to the correct canonical URL. Validate the canonical page, not only a duplicate or parameterized version. If markup is injected with JavaScript, test the rendered public result rather than relying only on source code.
Monitor after changes
Revalidate when a CMS, theme, product feed, review provider, or page template changes. Watch Search Console enhancement reports where applicable, but keep a separate template-level test because reports may lag and do not exercise every record immediately.
Quick completion test
The review is complete when each markup-producing template has an owner, representative pages pass generic and feature-specific validation, the data matches visible content, live canonical URLs have been tested, duplicate markup is understood, and a repeat test is scheduled after future template changes.
Sources
- Understand how structured data works — Google Search Central
- Schema.org Markup Validator — Schema.org