I run some version of the same checklist on every structured data engagement, whether it is a brand-new implementation or an audit of something a previous team built years ago. The steps below are the actual sequence, not a marketing simplification of it.
1. Confirm Visibility Match
Before touching validators, I check whether the data in the schema block actually reflects what a visitor sees on the rendered page. This is the single most common failure I find in inherited implementations: a database field feeding the schema that no longer matches the visible content, often because a content editor updated the page copy without knowing a separate schema field existed. Google’s guidelines require this match, and violations here can result in manual actions on rich result eligibility, not just a wasted opportunity.
2. Run Google’s Rich Results Test
This catches syntax errors and missing required properties, but it does not catch everything — it validates structure, not accuracy. A page can pass the Rich Results Test cleanly while still describing the wrong author, the wrong price, or a review that does not exist. Treat a clean pass as the floor, not the finish line.
3. Check for Duplicate or Conflicting Schema
This is the audit finding I hit most often on sites that have been through a redesign or platform migration: two separate systems both outputting Organization or WebSite schema, sometimes with conflicting data between them. A theme-level schema plugin and a manually added JSON-LD block are a common combination that causes this. Search Console will often flag the conflict, but not always immediately, so I check the rendered page source directly rather than relying only on Search Console surfacing it.
4. Verify Nesting and @graph Structure
On pages with multiple related entities — an Article with a Person author, nested inside a WebPage, connected to a WebSite — I check that the relationships are actually expressed through proper nesting or @graph and @id references, not just multiple disconnected schema blocks sitting on the same page with no relationship declared between them. Disconnected blocks technically validate but leave Google to infer relationships it should not have to guess at.
5. Confirm sameAs and Entity Links Are Current
Person and Organization schema should point to verified, currently active profiles — social profiles, Wikipedia or Wikidata entries where applicable, other authoritative mentions. I check every sameAs URL for a live redirect or a dead link at least once during an audit; profiles get renamed, deactivated, or migrated, and a stale sameAs reference is worse than none at all. This connects directly to the broader practice of entity linking, which matters more for AI-era search than it used to.
6. Cross-Check Against Search Console
The Enhancements reports in Search Console (formerly under separate reports per rich result type) show validation errors and warnings Google has actually detected in the wild, which sometimes differ from what the Rich Results Test shows for a single URL in isolation. I check this on a schedule, not just at launch, because template-level regressions often show up here weeks before anyone notices manually.
7. Test After Every Template or CMS Change
This is the step teams skip most consistently, and it is the source of the majority of the “silent breakage” I find in older implementations. Any redesign, theme update, or migration to a new CMS is a structured data regression risk until proven otherwise. I build this check into the QA process for any site change now, rather than treating structured data as a one-time project that is done once it launches. Concretely, that means a schema diff runs as part of staging review before any template deploy goes live — comparing the JSON-LD output on a sample of page types before and after the change, not just eyeballing whether the page still looks right visually.
8. Check for Orphaned Schema
The inverse of missing schema is schema that outlived the content it was describing. A FAQPage block referencing questions that were removed from the visible page months ago, a Review block citing a product review that was deleted, an Event schema for an event that already happened and was never cleaned up — these are common on sites where content gets edited by people who do not know the schema exists as a separate layer. I specifically search a site’s rendered JSON-LD for content strings and cross-check each one still appears in the visible page body, rather than assuming a passing validator means the data is current.
9. Confirm Indexation Coverage Matches Expectations
A schema implementation that is only live on a fraction of the pages it should cover is a common half-finished state I find on inherited sites — often because a template rollout stalled partway through a migration, or a plugin was configured for one post type and never extended to others. I spot-check a representative sample across every page type and template variant the site uses, not just the homepage and one blog post, before signing off that an implementation is actually complete.
10. Document What Was Found and Fixed
The last step, and the one that is easiest to skip under deadline pressure, is writing down what the audit found, what was fixed, and what is still outstanding, in a form the next person to touch the site’s templates can actually find. Most of the recurring breakage I see on long-running client sites traces back to an earlier fix that was never documented, so a later developer redid a migration without knowing schema depended on a specific field structure, and broke it again. A short audit log attached to the project saves the next audit real time.
11. Re-Prioritize Types Annually
Rich result eligibility and Google’s supported schema types change over time. I revisit which types are worth the maintenance cost roughly once a year per site, using the same reasoning laid out in which structured data types matter most, and I frame every finding from this checklist against the honest expectations set in structured data for SEO — a clean audit supports visibility, it does not guarantee a ranking change.
Running this checklist on a schedule, rather than only at launch, is what actually protects the investment. Structured data does not stay correct on its own once a site starts changing hands across content editors, developers, and platform migrations.