Most sites that “have schema” added it years ago, through a plugin or a one-off developer ticket, and nobody has looked at it since. That was tolerable when structured data mostly earned a star rating in a search result. It is less tolerable now that AI answer engines read pages to work out what an organization is, what it sells, who wrote a given piece and when it was last true. Markup that contradicts the visible page, describes a product you discontinued or names an author who left two years ago is not neutral. At best it is ignored; at worst it adds one more conflicting signal to the pile a model has to reconcile.
This is a practical audit process for operators who own a site and want their structured data to help rather than hurt. It assumes no special tooling beyond a crawler, a validator and a spreadsheet.
Why an audit, not another plugin setting
Structured data drifts for the same reasons content drifts. Templates get redesigned, plugins get swapped, prices change, people change roles, and the markup quietly keeps saying whatever it said on the day it was generated. Search engines have long said that markup should describe content that is visible on the page, and AI systems that use structured data as a hint are working from the same premise: it is a summary of the page, not a separate claim. When the two disagree, you have handed the reader a puzzle.
The goal of the audit is simple to state: every important fact in your markup should be true, current and visible on the page it sits on.
Step 1: Inventory what you actually ship
Crawl the site and extract every JSON-LD block, microdata and RDFa you find. Most desktop crawlers can do this with a custom extraction rule. Record, per URL:
- Which types are present (Organization, LocalBusiness, Product, Article, Person, FAQPage, BreadcrumbList and so on).
- Where each block comes from: theme, SEO plugin, ecommerce plugin, tag manager or hand-coded.
- Whether the same type appears more than once on a page, often from two plugins that both think they are in charge.
Duplicate, competing Organization blocks with different names, logos or URLs are one of the most common findings, and one of the easiest to fix.
Step 2: Validate syntax, then ignore the green checkmark
Run representative templates through Google’s Rich Results Test and the Schema.org validator. Fix outright errors: broken JSON, missing required properties, wrong value types. Then accept that a passing validator tells you almost nothing about whether the markup is accurate. A Product block with a price from last spring validates perfectly.
Step 3: Check markup against the visible page
This is where the real work happens. For each template, pick a handful of URLs and compare the markup line by line with what a visitor sees. Typical mismatches:
- Prices and availability in Product or Offer markup that differ from the page, usually because the markup is cached or generated from a different field.
- Dates: datePublished and dateModified that update on every deploy, or never update at all, regardless of whether the content changed.
- Authors: a generic “admin” Person, or a byline in markup that does not appear on the page.
- FAQ markup for questions that are no longer on the page, or that live inside collapsed widgets the markup generator scraped once.
- Business details: hours, phone numbers and addresses in LocalBusiness markup that disagree with the footer or contact page.
Log each mismatch with the URL, the field, what the markup says, what the page says and which source is correct.
Step 4: Tie your entity markup together
Pick one canonical Organization block, ideally on the home or About page, and give it a stable @id. Reference that ID from Article publisher fields, Product brand or manufacturer fields and author affiliations instead of redefining the organization on every page. Do the same for key people: one Person entity per author, referenced from their articles. Use sameAs only for profiles you actually control or that are unambiguously about you.
The point is consistency. When every page describes the organization the same way, a system reading your site sees one entity rather than several near-duplicates.
Step 5: Remove what you cannot keep true
Operators tend to add markup and never remove it. Be willing to delete. If nobody owns keeping review counts current, drop the aggregate rating rather than leave a stale one. If FAQ blocks were generated for pages that no longer have FAQs, remove them. Less markup that is accurate beats more markup that is half right.
Step 6: Put markup into the change process
The audit is a snapshot. To keep it from decaying again:
- Generate markup from the same data source that renders the page, so price, hours and dates cannot diverge.
- Add a structured data check to the release checklist for template changes and plugin updates.
- Assign an owner for the canonical Organization and Person entities, and update them when names, roles, addresses or logos change.
- Re-crawl quarterly and diff the extraction against the last run.
How to tell whether it mattered
Do not expect a dramatic jump from a markup cleanup alone. Structured data is a supporting signal, not a lever that forces citations. What you can measure is whether AI answers about your business get more accurate: keep a short set of factual prompts about your hours, products, prices and people, run them before and after the cleanup, and record which facts come back wrong and which source the answer appears to rely on. If errors trace back to your own pages, you know the audit is not finished.
If you would rather have outside eyes on this, a team offering generative engine optimization services can run the audit alongside the content and off-site work it depends on. Either way, the principle holds: your markup is a set of claims about your business, and every one of them should be true.