Audit Guide

A Verification-First Guide to Auditing Existing Schema Markup

Use evidence from Search Console, rendered pages, validators, and deployment history to classify each issue, assign an owner, correct the source, and verify the result without treating rich-result appearance as guaranteed.

See Your Site's Data
Martial NotarangeloBy Martial Notarangelo · Founder, Authority Specialist · Updated
Quick answer

What is the right order for auditing existing schema markup?

A schema markup audit should create an evidence record for every finding: the affected URL or template, observed validator or rendering result, severity, owner, corrective action, and validation step.

Use Search Console and live rendering to locate affected patterns, compare markup with the exact documentation in scope, and trace regressions back to the CMS, template, script, or deployment that generates them.

The source previously associated eligibility-gap changes with a 2-4 week re-indexing window, but no supporting source URL is present, so treat that range as historical editorial guidance rather than a guaranteed processing timeline.

A passing validator does not guarantee a rich result, and monitoring should supplement rather than replace root-cause diagnosis.

Key Takeaways

  1. Classify every finding with evidence: syntax or property errors, eligibility or content mismatches, missing rendered markup, or implementation drift after a site change.
  2. Use Search Console to identify affected URL patterns and dates, then confirm each representative issue on the live rendered page before assigning severity.
  3. A passing validator confirms only what that validator checks; it does not guarantee that Google will show a rich result for an otherwise eligible page.
  4. Required and recommended properties must be evaluated against the documentation for the exact supported feature and schema type in use, not against a generic completeness score.
  5. Implementation drift should be traced back to the template, CMS, plugin, deployment, or rendering layer that changed so the corrective action fixes the source rather than isolated URLs.
  6. Every audit stage should end with ownership and validation: record who will fix the issue, what changed, and the evidence that the live page now renders the intended markup.

Who Should Use This Schema Audit Guide

This guide is for SEOs, developers, and site owners auditing schema markup that already exists. It is designed for situations where a search appearance changed, markup is not being detected as expected, or a release needs structured-data verification before and after deployment.

  • A search feature changed or disappeared: capture the affected URLs, feature type, first observed date, Search Console evidence, and any related deployment dates before changing code.
  • Markup validates but the expected search appearance is absent: preserve the validation result as evidence, then check content and feature eligibility without treating rich-result display as guaranteed.
  • Pre-launch or migration verification: save a rendered baseline from the existing site, identify the owner of each schema template, and define how the production output will be validated after release.

This is a diagnostic guide rather than a from-scratch implementation tutorial. If the site does not yet have markup, use the linked implementation steps instead. Here, each audit stage should produce the same record: evidence, severity, owner, corrective action, and a validation step.

The process applies to whatever schema types are actually present, including Product, Article, LocalBusiness, FAQPage, HowTo, and others. The audit method is consistent, but the required properties and Google search-feature eligibility rules vary by type. FAQ content may still help readers, but do not add FAQPage markup expecting a Google FAQ rich result.

Passing validation is evidence that a specific test found no blocking issue in the tested markup. It is not evidence that a rich result must appear. Keep the audit focused on things the team can verify: rendered markup, documented requirements, content accuracy, template behavior, and whether the corrective action remains intact after deployment.

Classify the Three Main Failure Modes Before Fixing Anything

Begin by classifying the symptom before editing markup. Most actionable findings fit one of three categories, and each category requires different evidence and ownership.

1. Validation or Syntax Failure

Evidence: record the validator, URL, schema block, property, exact error text, and rendered code that triggered it. Severity: high when the error blocks processing of markup tied to an important page or supported feature; otherwise rank it by affected scope. Owner: the developer, CMS administrator, or template owner responsible for generating the markup. Corrective action: fix the property name, value format, JSON-LD structure, or template logic at the source. Validation: retest the live rendered page and confirm the error is gone without introducing a new one.

2. Eligibility or Content Mismatch

Evidence: save the clean validation result, identify the supported search feature being evaluated, and compare the page content and markup with the applicable Google requirements. Severity: high only when the mismatch prevents a business-critical supported feature or makes the markup inaccurate; otherwise treat it as a scoped eligibility issue. Owner: assign jointly when both content and implementation must change. Corrective action: correct inaccurate markup, add legitimately required information when the visible content supports it, or remove markup that does not match the page. Validation: retest the rendered markup and confirm the visible page still supports every marked-up claim.

3. Implementation Drift

Evidence: compare current rendered markup with a prior known-good version, deployment record, template history, or CMS configuration. Use the linked error guide to distinguish common implementation mistakes from unsupported assumptions. Severity: prioritize by number and importance of affected templates or URLs. Owner: the team responsible for the release or shared template. Corrective action: restore or correct the generating logic at the shared source. Validation: test representative pages across every affected template and confirm the fix persists after deployment.

Check all three categories in sequence. A clean syntax test does not close the audit if the markup is inaccurate, ineligible for the intended feature, missing from rendered output, or removed by a later template change.

Run the Audit as a Five-Stage Evidence Workflow

Work through the stages in order and create an audit record for each finding. Do not advance an issue without evidence, severity, an owner, a corrective action, and a validation step.

  1. Collect Search Console evidence. Identify the structured-data or rich-result report relevant to the site, export affected URLs, record the first observed date, and note whether the issue is an error, warning, or coverage change. Assign severity by affected URL importance and scope. The owner should confirm whether the pattern maps to a shared template or isolated page. Corrective action at this stage is diagnostic only: define the URL sample to inspect. Validate by confirming the sample represents every affected pattern.
  2. Validate representative live pages. Run affected URLs through Google's Rich Results Test and save the detected items, errors, warnings, and rendered output. Assign higher severity when a blocking error affects important pages or a repeated template. The implementation owner fixes the generating code rather than the test output. Validate by retesting the published page after the fix.
  3. Compare the markup with the exact documentation in scope. Review Schema.org definitions and Google's documentation for the supported search feature being evaluated. Record which required or recommended properties are relevant, whether the visible page supports them, and where the source generates them. Assign severity according to whether the issue blocks valid processing, creates inaccurate markup, or is merely optional completeness. Correct the source field or mapping, then validate both rendered markup and visible content.
  4. Inspect rendered output, not only page source. Save evidence from the rendered DOM or Google's live rendering tools, especially when JavaScript generates or modifies structured data. Assign severity based on whether markup is missing, duplicated, stale, or inconsistent after rendering. The owner should be the team controlling the script, tag manager, template, or application code. Correct the rendering path and validate the published result with the same rendering method used to find the problem.
  5. Test for implementation drift against a baseline. Compare current output with staging, version history, cached internal evidence, or deployment records. Assign severity according to the breadth and business importance of the regression. The release or template owner should fix the shared cause. Validate across representative page types after deployment and record the new known-good baseline.

Use the Evidence to Choose the Correct Remediation Path

After the audit stages, route each finding according to the evidence rather than the desired search appearance.

Search Console shows errors and the Rich Results Test confirms them

Evidence: matching live errors from both sources. Severity: prioritize blocking errors on important templates. Owner: the component owner generating the invalid markup. Corrective action: fix the source property or structure. Validation: rerun the live test, then monitor Search Console until its reporting reflects the recrawl.

Search Console shows errors but the live test is clean

Evidence: record the Search Console status date and the clean current live result. Severity: reduce only after confirming the fix across the affected URL pattern. Owner: the original implementation owner remains accountable until the pattern is verified. Corrective action: fix any remaining URLs or leave the resolved implementation unchanged if current output is correct. Validation: sample the full pattern and monitor reporting for convergence.

The live test is clean but the expected rich result is absent

Evidence: preserve the passing result and compare the page with Google's documented eligibility requirements for that feature. Severity: classify as an eligibility investigation, not a syntax emergency. Owner: content and technical owners as appropriate. Corrective action: correct inaccurate markup or visible content mismatches; do not add unsupported markup solely to force a result. Validation: confirm the final page and markup remain accurate, while acknowledging that rich-result display is not guaranteed.

Markup is missing from the rendered page

Evidence: capture the rendered output and compare it with the intended template or prior baseline. Severity: high when a shared implementation disappeared across important pages. Owner: the template, CMS, tag, or application owner. Corrective action: restore the intended generating logic at the shared source. Validation: retest representative live pages after deployment.

Markup differs across pages that should share the same template

Evidence: document which page variants contain, omit, or alter the schema block. Severity: based on the affected template coverage and whether the difference is intentional. Owner: the template or content-model owner. Corrective action: standardize the generating logic or document the legitimate exception. Validation: test each template variant and save the expected output as a new baseline.

Choose Tools by Audit Stage and Evidence Needed

Use each tool for the evidence it can actually provide. Do not substitute a passing validator for an end-to-end implementation check.

For Site-Level Triage

  • Google Search Console: use the available structured-data and rich-result reporting to identify issue patterns, affected URLs, and reporting dates. Record the evidence, assign severity by scope, and give ownership to the team responsible for the shared implementation. Correct the source issue, then validate representative URLs and monitor reporting.
  • URL Inspection: use live inspection to compare indexed or reported state with current rendered output. Save the test result as evidence, assign severity according to whether the current page is broken, route ownership to the responsible template or rendering layer, fix that source, and rerun the live test.

For Page-Level Validation

  • Google Rich Results Test: use it to inspect supported rich-result markup and property errors on a URL or code sample. Treat the result as evidence for technical eligibility checks, not a guarantee of search appearance. Correct the implementation owner source and retest the live page.
  • Schema.org Validator: use it to check vocabulary conformance separately from Google's feature-specific requirements. Record which vocabulary issue was found, assign severity based on validity and accuracy, fix the generating field or code, and validate again.

For Scale and Monitoring

For large URL sets, sampling alone can miss template-specific or newly introduced drift. Use crawl or monitoring tools when the audit scope requires repeatable coverage. The evidence should identify which URLs changed, severity should reflect affected scope, ownership should map to the source system, corrective action should fix the common cause, and validation should rerun the same URL set after deployment.

Monitoring is useful because it can reveal change between point-in-time audits. It does not replace diagnosis: every alert still needs evidence review, severity, an owner, corrective action, and validation before the issue is closed.

For JavaScript Rendering Checks

  • Chrome DevTools: compare initial source with rendered DOM to determine whether structured data is added, removed, or changed after load. Capture both states, assign severity by actual impact, route the fix to the script or template owner, and retest after correction.
  • Screaming Frog with JavaScript rendering: compare crawl results with rendering enabled and disabled to locate inconsistent schema presence at scale. Use the affected URL set as evidence, fix the shared source, and repeat the same crawl configuration to validate.

Escalate When the Evidence Points Beyond a Page-Level Fix

Escalation is appropriate when the evidence shows a shared template, rendering, deployment, or eligibility issue that cannot be resolved reliably one URL at a time.

Rich-result reporting changes across the site after a release

Evidence: align the first observed date with CMS, theme, plugin, template, or deployment history. Severity: high when the change affects many important pages. Owner: the release or shared-template owner. Corrective action: fix the common generator or rendering path. Validation: test representative pages from every affected template and save a new baseline.

Markup validates but the expected search appearance remains absent for more than 60 days

Evidence: preserve current validation, rendered markup, content eligibility review, and search observation. Severity: treat it as an eligibility or search-display investigation rather than proof of a technical failure. Owner: assign a reviewer who can confirm documentation and content accuracy. Corrective action: make only changes supported by documented requirements and visible content. Validation: confirm the page remains technically valid and accurate while accepting that display is not guaranteed.

Errors appear on pages nobody edited

Evidence: compare affected URLs with infrastructure and shared-component changes. Severity: based on breadth and business impact. Owner: the infrastructure, plugin, CDN, server-rendering, or template owner implicated by the evidence. Corrective action: repair the shared cause. Validation: retest untouched representative pages to prove the fix is systemic.

Validation tools disagree

Evidence: save outputs from each tool and note whether they tested source, rendered DOM, cached state, or live rendering. Severity: high when Google's live rendering cannot see markup that the browser or another validator can. Owner: the rendering or caching owner. Corrective action: resolve timing, injection, cache, or template differences. Validation: rerun the same tools under comparable conditions and document why their outputs now agree or legitimately differ.

When manual auditing cannot provide reliable coverage, use structured data tools for ongoing markup monitoring. The tool should support the audit record, not replace it: capture the alert as evidence, assign severity, name the owner, fix the source implementation, and validate the corrected live output.

Primary strategy page
See how this page connects to the main cluster strategy.
structured data tools for ongoing markup monitoring
Structured Data SEO Tools

Implementation playbook

This page is most useful when you apply it inside a sequence: define the target outcome, execute one focused improvement, and then validate impact using the same metrics every month.

  1. Capture the baseline in structured data tools: rankings, map visibility, and lead flow before making any changes.
  2. Ship one change set at a time so you can isolate what moved performance, instead of blending technical, content, and local signals in one release.
  3. Review outcomes every 30 days and roll successful updates into adjacent service pages to compound authority across the cluster.

Related resources

Use the hub, primary service page and adjacent deep dives as one coherent research path.

Start here

Deep dives

Frequently Asked Questions

When should I run a schema markup audit?

Run an audit after a significant CMS, theme, template, plugin, rendering, or migration change, and whenever Search Console or monitoring shows a new structured-data issue. For routine checks, choose a cadence based on how often the implementation changes and how costly silent drift would be.

Every audit finding should record evidence, severity, owner, corrective action, and validation rather than relying on a calendar alone.

Which schema audit red flags deserve escalation?

Escalate a sitewide change that aligns with a release, markup that remains technically valid while the expected search appearance is absent for more than 60 days, unexplained errors on unchanged pages, or conflicting results between rendered and source-based tests.

In each case, preserve the evidence, assign severity by scope, identify the shared-system owner, fix the common cause, and validate representative pages after the change.

Can I run this schema audit myself?

Yes, if you can use Search Console, inspect rendered markup, read validator output, compare documentation, and trace a finding back to the system that generates it. Escalate when the affected URL set is too large to sample safely, markup is generated dynamically across multiple systems, or the evidence points to rendering, caching, template, or infrastructure behavior you cannot change directly. The escalation should still include the audit evidence and a defined validation step.

Does passing the Rich Results Test guarantee a rich result?

No. A passing result only means the tested markup satisfied the checks performed by that tool at that moment. Search appearance can still depend on feature eligibility, visible content, query context, and Google's systems.

Record the passing result as evidence, close any confirmed technical errors, and do not create unsupported markup or promise a rich result simply because validation succeeds.

How can I prove a CMS or template update caused schema drift?

Compare the first observed issue date with deployment, CMS, plugin, or template history, then compare current rendered markup with a known-good baseline if one exists. Evidence is strongest when the same shared component changed across the affected URL pattern.

Assign ownership to that component, correct the generating logic, and validate representative pages after deployment rather than patching individual URLs.

What is the difference between a schema audit and schema monitoring?

An audit is a point-in-time investigation that explains the current state and produces evidence, severity, ownership, corrective action, and validation. Monitoring checks for changes between audits and can alert you when markup disappears or errors appear.

Monitoring finds the signal sooner; the audit process determines whether it is real, who owns it, what to fix, and how to confirm closure.

THIRTY SECONDS TO START

You've read enough.Your own data says more.

Connect your site and see it yourself: your rankings, your gaps, your blockers, and what AI tells your buyers. The plan and the priced options follow within 36 hours.

Your access code by SMS. We never call.No payment