Schema Audit

1. What a schema audit evaluates

A schema audit examines markup you inherited from a predecessor, accumulated across three plugins, or deployed long enough ago that no one can account for it. Auditing existing markup is harder than checking a new deployment because the markup must satisfy two consumers with opposite failure modes.

The second row runs counter to a common assumption. The belief that invalid markup is harmless because it gets ignored applies only to parsers. Mark Williams-Cook demonstrated the other case with a fictional company whose address appeared only in deliberately broken JSON-LD that used a fabricated @context and invented types. Both ChatGPT and Perplexity returned the address anyway. His explanation: “They were not parsing it as schema. They were doing what LLMs always do: Reading the visible-ish text of the page” (Search Engine Journal, June 2026). A controlled test a year earlier provided complementary evidence: live-fetch chatbots did not extract JSON-LD as structured data (searchVIU, 2025).

The audit therefore ranks findings by whether the markup makes assertions that do not appear on the page, rather than by the number of validator errors. A block with three vocabulary warnings but accurate content is a minor finding. A block that passes validation while stating a price the page never charged is the most serious kind of problem.

Keep the expected outcome in perspective when you define the scope. Ahrefs compared 1,885 pages that added JSON-LD with roughly 4,000 matched controls and found no meaningful change in citations on any AI platform (Ahrefs, 2026). Google’s own guidance states that structured data “isn’t required for generative AI search” (AI optimization guide). The GEO benchmark does not provide evidence to the contrary because it changed content and structure but never tested markup as a variable (Aggarwal et al., KDD ‘24 · paper summary). Williams-Cook notes an important limitation: the Ahrefs sample consisted of “already strong, well-understood entities”, where little disambiguation remained to be done. Taken together, the evidence supports using an audit to remove misleading assertions and resolve identity, not to increase citations directly.

2. Before you audit: scope, sample, and evidence

Four decisions determine how every later finding should be interpreted.

Gather the inputs before you start. You need an inventory of the available templates and the data each one uses, plus a list of the CMS, theme, and plugins for the provenance check in §6. You also need an authoritative list of the organization’s official profiles and identifiers for the external comparison in §7. Search Console access is useful but optional because three of the four rungs can be completed without it.

Run the audit when the markup may no longer match the site. Common triggers include taking over a site you did not deploy; upgrading the CMS, theme, or a plugin; completing a migration or redesign; changing an entity through a rename, merger, or rebrand; receiving a structure-and-machine-readability finding in a full GEO audit; or reaching a vendor deprecation date, including the one discussed in §5. If the first crawl finds no markup, stop the audit and follow the deployment process in Schema Implementation.

3. The four-rung ladder

Each rung depends on the one below it. The cost and significance of a finding increase from coverage through truth.

The Who notices column explains why order matters. Rung 3 findings are invisible to every tool in the workflow, so they can persist for years on inherited sites and must be checked manually. Rung 4 findings are the only ones that carry a documented penalty.

Start with Rung 1 and proceed in order. Running validators on page after page is wasted effort when client-side injection prevents every non-rendering AI crawler from receiving the markup. The command in §4 can establish that condition immediately.

For a single page, the free Schema Markup Checker automates all four rungs with one no-JavaScript fetch. It checks delivery, parsing and @context, the graph within the page, and the machine-checkable portion of §7, while quoting the evidence for every finding. It does not perform template-scale sampling, so use it as the per-page instrument within the sample defined in §2.

4. Rung 1: Coverage and delivery

This rung requires two forms of evidence, and neither can replace the other.

Crawl-scale extraction shows which templates emit which types of markup. Any crawler that can extract JSON-LD across an entire site will work. Screaming Frog provides public documentation for this capability, stating that it has “built our own structured data validator into the Screaming Frog SEO Spider to help make the auditing process more efficient and at scale”. Its separate options include JSON-LD, Microdata, RDFa, Schema.org Validation and Google Rich Result Feature Validation (Screaming Frog). Record one row per URL, including the detected types and errors, and group the rows by template.

A no-JavaScript fetch shows whether a non-rendering crawler receives the markup. Googlebot renders JavaScript; GPTBot, ClaudeBot, and PerplexityBot are not observed to (JavaScript SEO basics). One command per template provides the answer:

# Blocks a non-rendering crawler actually receives, per template sample
curl -sL https://example.com/your-page | grep -c 'application/ld+json'

Record the result in a coverage matrix:

Keep two verdicts separate because they require different fixes. Absent means the template emits no markup. Whether that is a finding depends on your standard; without one, only a missing core entity graph qualifies as a blocker. Unavailable to non-rendering crawlers means the block appears in the rendered DOM but not in the response body. This pattern indicates tag-manager or client-side injection and explains why a team may believe schema is deployed even though no AI crawler has ever received it. See SSR vs CSR for AI crawlers for the rendering trade-off and AI crawlers for information about which engines execute JavaScript.

5. Rung 2: Validate syntax and interpret reports

The four instruments answer different questions. Pay particular attention to the third column, which states what each instrument cannot establish.

The unparsable report is especially useful in an audit because it isolates critical syntax errors from warnings and valid items. It lists structured data that “could not be parsed because of a serious syntax error”, and “All items in this report are critical structured data errors; there are no warnings or valid items.” It also identifies the pattern an audit needs to find: “The most common cause of a single error affecting multiple pages is an underlying template error”. For the validation states used in revalidation requests, see Fix structured data issues in Search Console.

Treat the report inventory as evidence about the property, not as a list of supported features. Google documents that a rich result report appears “only if: Google finds valid markup in your property, and The markup is a supported rich result type”. The reports visible in a given console therefore depend on that site’s markup. For the list of supported types, use the search gallery, which is much longer than the report list for any single property. Even the console documentation may lag behind changes: it still describes rich result reporting for practice problems, although a changelog entry says that reporting is scheduled for removal. A listed report does not prove that the feature remains active.

The FAQ timeline is still changing. FAQ rich results stopped appearing in Google Search on May 7, 2026, and Google removed the FAQ rich result documentation in June 2026 (Search Central changelog · Search Engine Land). Removal of FAQ support from the Search Console API is scheduled but not confirmed complete. As of August 11, 2026, Google’s API documentation still labels it an “Upcoming deprecation” and states, “We’ll be deprecating support for the FAQ search appearance in the Search Console API in August 2026”, without naming a day (Search Analytics: query). If your reporting pipeline queries that appearance type, test the call instead of relying on the calendar.

Do not assign severity from a validator result alone. A validation failure means that the parser dropped the block. It does not mean that the block was inert, because the live-fetch model described in §1 still reads it. A Rung 2 finding should record what failed. Assign severity only after §7 establishes what the block claimed.

6. Rung 3: Check graph integrity and identify each emitter

This check differs from a deployment review, where one emitter is known by design. On an inherited site, begin with the assumption that several emitters may exist and that no one knows the exact number.

Identify the source of each block first. A theme and an SEO plugin may each emit an Article, or two plugins may each create an Organization. This is the most common structural finding on an unaudited site. Field style, indentation, and @id naming conventions usually reveal the emitter, and the CMS plugin inventory from §2 can confirm it. To make a finding actionable, identify its emitter and assign the fix.

Then read the graph. None of these produce an error anywhere in the toolchain:

Once you have the crawl output from §4, you can detect these patterns systematically. Extract every @id across the site, group the records by value, and flag values associated with more than one @type. Then reverse the grouping and flag entities associated with more than one @id. See JSON-LD for the reference semantics and Entity Recognition for the consequences of a graph that does not connect correctly. To prevent recurrence, Schema Implementation describes using one @graph per page with nodes connected by reference.

7. Rung 4: Verify claims against the page and external sources

Perform two separate comparisons.

Compare the markup with the page. Place the emitted block beside the rendered page and confirm that every asserted fact is visible, including the author, dates, price, rating, description, and address. No tool performs this comparison, and this is the only class of finding with a documented penalty. Google states the consequence and its limit precisely: “A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search” (General Structured Data Guidelines). Live-fetch engines encounter the same mismatch more directly because they do not parse the markup as structured data. They read it as unusually punctuated prose, so a contradiction on the page gives the model two competing versions of the same fact.

Verify identity against external sources. Open every sameAs target and confirm three things: the target resolves, it identifies the same entity rather than a parent company, sibling brand, or namesake, and it remains active. Check that logo does not return a 404 and that each Wikidata item genuinely exists rather than serving as a placeholder. A sameAs property can connect entities, but it cannot create the external entity it points to. See Knowledge Graph Presence for details.

These recurring findings are organized by how you detect them:

Google’s guidance on dates is relevant to the first row because the mismatch often comes from a default rather than a deliberate error. Publication dates must describe the page, must not be in the future, and “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values” (Article publication dates).

If you cannot make a block agree with the page, remove the block. Do not remove an accurate fact from the page to preserve inaccurate markup.

8. Review common omissions by type

Missing information is generally less serious than incorrect information, so rank omissions instead of treating completeness as the goal. Be cautious with any checklist labeled “required fields.” Google states that both Organization and Article have recommended properties but no required ones (Organization · Article).

The Product row contains valid findings, but they rank below the AI-related issues. A missing gtin affects rich-result eligibility, which concerns commerce and search results rather than retrieval. A mismatch between offers and the visible page, however, belongs with the blockers in §9.

9. Assign severity and decide what to fix

Use the same severity levels as the full GEO audit and crawler access audit. Base the rating on the rung and on whether the markup contradicts the page.

Fix markup when it contradicts the visible page, prevents evaluation of a later rung, or connects the entity graph incorrectly. A type that no longer produces a rich result does not meet any of those conditions. Removing accurate markup solely because the feature was deprecated creates a large engineering task with no benefit, which can consume much of an inherited site’s audit budget.

Do not reduce the results to a single score. A composite 0–100 grade with an unpublished formula is not an interpretable measurement. The citability audit applies the same provenance requirement to citability scores. Report severity for each finding. Then rank the findings by impact, confidence, and effort to establish priority, using the method in the full GEO audit.

10. Prepare the report and schedule follow-up audits

Every report should contain:

• Header: Audit date, templates in scope, sampled URLs, the standard used for evaluation, and whether Search Console evidence was available.
• Coverage matrix: The table from §4, organized by template and including the no-JavaScript column.
• Finding list: Each finding stated as an assertion, evidence, rung, severity, and the responsible layer (template, plugin, content, or entity).
• Prioritized plan: The findings from §9, reordered by priority.
• Changes since the previous audit: What changed and whether it resulted from your action or a vendor change.

Run a new audit in response to a trigger, not on a fixed calendar. Triggers include template or theme changes, CMS and plugin upgrades, entity changes, rendering-mode migrations, and vendor deprecation dates. Use the calendar only for a quarterly review of the highest-value templates.

Add one inexpensive safeguard to the continuous-integration pipeline on any site with a build step. Check for collisions among the @id values from one representative URL per template, and verify that the number of blocks does not decrease between builds. This catches plugin upgrades that silently remove or duplicate the core entity graph, the §6 failure that no other tool in the workflow reports.

11. Validity threats and pitfalls

• Auditing only the rendered DOM in developer tools. This prevents you from checking delivery in §4, which every later rung depends on.
• Treating passing validator results as a completed audit. Rung 3 and Rung 4 problems pass every validator because validators do not perform those checks.
• Using the Rich Results Test as a correctness check. It measures eligibility for one feature, not conformance.
• Sampling only the primary templates. Plugin defaults often appear in edge cases, such as pages with no author or image, discontinued products, and page 7 of a listing.
• Using your own console’s report list as the list of Google-supported types. Reports appear only when the property already contains valid markup for a supported type.
• Reporting deprecated but accurate markup as a finding. This creates work without providing a benefit (§9).
• Auditing markup that you recently deployed. That requires a predeployment validation check. Schema Implementation provides the four-check process.
• Expecting a clean audit to increase citations. The evidence does not support that causal claim (§1). The value comes from removing contradictions and making the entity resolvable.
• Auditing only once. A plugin upgrade can change the results without your involvement.

12. Further reading

• Concepts: Schema.org for AI explains what each type signals and why markup is not a citation lever. JSON-LD covers the reference semantics of @id, @context, and @graph.
• Entities: Entity Recognition explains how identity claims are evaluated. Knowledge Graph Presence explains what a sameAs property points to.
• Related procedures: Schema Implementation covers deployment and predeployment checks. AI Crawler Access Audit applies the same comparison method to access. Full GEO Audit places these findings within its six-layer framework.
• Delivery: SSR vs CSR for AI Crawlers and AI Crawlers explain which engines execute JavaScript.
• Scoring: Citability explains why per-check pass-or-fail results are more useful than a composite score.