Using Structured Extraction to Audit Schema Markup Across a Domain

Auditing schema markup across a domain is a structured extraction problem. Crawl the domain, pull its markup into machine-readable records, and check those records against a specification that sets out the rules. That shows teams patterns in the errors they can fix and then watch for before the next template change spreads them again.

Why schema markup errors are now a citation problem, not just a rich-result problem

AI engines parse schema markup, map entities to knowledge graph nodes, and use confidence in those matches to rank sources. Schema gives them explicit information about who published a page, what it describes, and which claims belong to which entity. Errors can interrupt that chain before the quality of the prose enters the decision. A strong article with confused entity markup is rather like an expert arriving with someone else’s name badge.

That makes schema an AI visibility concern. Before 2026, its clearest rewards were star ratings, FAQ panels, and breadcrumb trails in search listings. Those visible features made success easy to picture, but they were never the whole job of structured data. The changing role of FAQPage and HowTo is a signal of that shift, rather than a reason to abandon markup that describes the page accurately.

Broken schema can weaken a source’s citation prospects on technical grounds, regardless of how useful its content is. Accuracy should be treated as infrastructure. The March 2026 update sharpens that concern for AggregateRating, with enhanced scrutiny where review counts cannot be verified. A valid-looking claim needs evidence that holds up.

What schema drift looks like at domain scale, and why spot-checking misses it

Schema drift begins when markup stops matching the visible page. A CMS update, template change, or content migration can change what readers see while leaving the schema layer as it was. Because templates generate structured data, the resulting error is rarely confined to the page where someone notices it. One broken Product template can corrupt thousands of URLs at once. The template is the photocopier, and checking one copy does not repair the glass.

The failures themselves are predictable, including missing required properties, invalid date formats, the wrong @type, missing or invalid image dimensions, and duplicate @id values. Their significance lies less in any single error than in how they cluster across pages built from the same template. Two or three representative checks cannot establish the extent of that pattern or cover the differences between listing, detail, blog, location, and pricing pages. Each page type has its own rules to meet, so a blog post with no errors says little about the product catalogue.

On JavaScript-heavy and headless sites, validators need to see the markup in server-rendered or prerendered HTML, while late-injected schema may be missed entirely by crawlers. That means an audit must distinguish absent markup from markup that exists but is unavailable at the point of extraction.

Pages can appear in AI search without FAQPage or HowTo markup, and content authority may outweigh schema completeness in some cases. Schema is one entity signal among many, so the relationship with citations is probabilistic. The case for a systematic audit is therefore not that every repair buys a citation, but that these errors are consistently detectable and correctable at scale.

The three-stage pipeline that turns a domain crawl into a structured audit

The first stage is to crawl with template coverage as the organising principle. A domain-wide crawl should account for home, product listing, product detail, blog, support, location, and pricing pages where they exist. Samples that reflect each template show what it produces, while checking more pages shows how far its faults spread.

Screaming Frog has a built-in structured data extractor for this work. Its settings sit under Configuration > Spider > Extraction > Structured Data, where JSON-LD, Microdata, and RDFa extraction can be selected. Schema.org Validation and Google Rich Result Feature Validation must also be explicitly enabled, because these options are not on by default. The crawl can then flag warnings, unparseable JSON, and missing required attributes instead of just collecting markup and wishing it well.

The second stage is extraction, with a DOM query first and an LLM only where needed. JSON-LD is the priority format because its structured blocks sit directly in HTML script tags and require no model to extract. The record for each URL should capture @type, @id, sameAs, about/mentions, language, and relevant properties such as price, availability, dates, and image dimensions. It should also record duplicate schema blocks or conflicting itemtypes. Microdata in element attributes needs a different extraction path, while pages with no structured data may justify an LLM to infer what should be present.

The third stage is validation against both formal requirements and the audit’s own specification. Schema.org validation and Google Rich Results validation catch different kinds of errors, so both should run, as markup can pass one and fail the other. The specification must also call for checks that the markup matches what readers see on the page. A page can pass the Rich Results Test without errors and still contribute little to AI visibility.

Which schema types produce measurable AI visibility, and which to prioritize

The specification should follow the entity-verification chain, beginning with the publisher. Organization establishes brand identity, while sameAs connects that identity to social profiles and authoritative directories. The audit should check whether those links let an AI system tell that the organisation is the same across sources, where separate identities might otherwise leave that unclear. This is foundational work because later claims about content, authors, and products need a clear owner.

Article and NewsArticle come next because they describe the content, its author, its publication date, and its last update. The audit should look closely at dateModified, which is frequently missing despite the importance of recent, well-attributed content to AI Overviews and AI Mode. It should also check the connection to Person schema on an author bio page. A date and a byline should describe the article readers can actually see.

Person schema adds the next link by spelling out what the author knows. Relevant properties include jobTitle, worksFor, sameAs links to LinkedIn and published works, alumniOf, hasCredential, and knowsAbout. The audit should check that the marked-up credentials, affiliations, and areas of knowledge match the author’s professional bio. This matters most for YMYL topics, where AI platforms give a lot of weight to what the author knows. BreadcrumbList then shows where that content sits in the site hierarchy, which adds entity context but does not promise a citation.

Product and Offer should be checked first where commercial intent matters. Their audit checks centre on pricing, availability, and ratings, because those fields make inventory readable to AI shopping agents and Google AI Mode. Complete Product markup is associated with stronger visibility on commercial-intent queries, but stale values undermine its purpose. AggregateRating adds a score and a count that systems can use when comparing options. Its review count must be verifiable, with a minimum of five genuine reviews remaining the practical threshold for safe use.

LocalBusiness lets identity verification cover a physical location or the area a business serves. Its details must match Google Business Profile exactly, because inconsistencies reduce citation confidence. For multi-location businesses, the audit should check for an Organization entity at the parent level and individual LocalBusiness entities for each location. That hierarchy lets the specification distinguish the business from its branches instead of treating every address as a competing identity.

FAQPage belongs in this discussion, but not as a universal priority or a dead format. Its role has changed, and neither its presence nor its absence settles whether a page can earn an AI citation. The audit should judge it against the questions and answers visible on the page. Across all these types, the useful priority is the same, namely markup that helps resolve identity, verify claims, and place content in context.

How to run the extraction pipeline at domain scale without prohibitive cost

Choosing whether to use an LLM in the extraction loop for every page has the biggest effect on cost. For JSON-LD, it need not be there at all, because a DOM query can retrieve the existing machine-readable blocks. There is no per-page LLM cost for that extraction. Paying a model to collect an already structured object is an expensive way to pick up a box.

Models become more useful when pages lack schema or when the audit must compare markup with visible content. Even then, the efficient pattern is to generate deterministic extraction logic once and reuse it across pages with the same structure. That separates the work of understanding a layout from the repeated work of collecting its fields. At tens or hundreds of thousands of URLs, that distinction matters far more than shaving a few words from a prompt.

The open-source tool trawl works this way. It calls an LLM once per site structure to work out how to extract the data, using CSS selectors internally, then runs later extractions in Go with no more API calls. Users describe what they want semantically. The broader production pattern is to keep AI outside the routine extraction loop, using it to monitor scripts and regenerate code when the site structure changes.

Crawl infrastructure is a separate cost from model inference. A unified web data API that handles crawling, clean Markdown or HTML output, and domain-wide batching can remove the work of managing proxies, rendering environments, and rate limiting. That leaves the team focused on validation rules. The goal is not to remove every moving part, but to keep the expensive ones from moving on every page.

Monitoring schema health after the initial audit, and what good ongoing instrumentation looks like

A clean initial audit does not stop the next CMS update from breaking a template. Schema errors can return across thousands of URLs without any visible alert, so a point-in-time report has a short shelf life. Monitoring gives the extraction pipeline its lasting value by detecting recurrence. The report is a snapshot, while the pipeline is the alarm.

That alarm needs field-level signals. A crawler can receive a 200 status while collecting empty or unusable schema fields. If the price field falls from near-full population to partial population across a domain, a layout change may have broken the extraction path.

Continuous checks should cover required-property fill rates per @type and template, @id uniqueness across the domain, and ISO-8601 validity for date fields. Sampled comparisons between schema and visible content add the accuracy check that syntax alone cannot provide. Together, these measures distinguish coverage gaps, broken identities, malformed values, and stale claims. They also make a template-wide change easier to separate from an isolated page problem.

The same discovery-and-extraction process used in competitive intelligence can run here too. A Search API can discover new pages on a schedule, an Extract API can pull structured content, and normalized JSON records can retain source citations for comparison against a specification. Biomedical evidence synthesis research provides the same design lesson in another setting, namely that deterministic extraction, typed schemas, and traceable provenance make outputs reproducible and auditable.

Scheduled monitoring still leaves a gap between deployment and detection. The most direct way to close it is to run the schema validation pipeline in CI on every deployment that touches a template. That moves the check to the point where a shared error can still be stopped. Catching it before production stops one broken template from making thousands of broken pages.