Schema Markup for LLM Citations: What Works Past the Basics
Most schema markup advice that circulates in the SEO community was written for classical search rich results. The advice carries over partially to retrieval-augmented language models, and misses in specific places that determine whether an LLM cites a page or skips it. This piece is the working note ScaleGrowth Digital uses on live engagements where the deliverable is measurable AI mention rate movement, not just SERP feature compliance.
Stating the Working Claim
The classical rich-results school treats schema as a way to qualify for SERP enhancements. Get FAQPage and you might get an accordion. Get HowTo and you might get steps. The retrieval school treats schema as the canonical statement of fact that an extraction model uses to resolve ambiguity. When body copy and schema agree, an LLM raises confidence and cites. When body copy and schema disagree, the LLM lowers confidence and skips the page in favour of one that is internally consistent. The implication is concrete. Schema validation is no longer about earning a SERP feature. It is about earning a citation slot.
The Failure Modes That Surface on Audits
On a 25,000 page NBFC audit ScaleGrowth ran in 2026, the structured-data validation pass surfaced 224 invalid structured-data items across the indexed footprint. Most fell into four buckets that recur across engagements regardless of vertical.
Body-schema drift. A product page describes a fixed-rate term loan in the visible copy. The Product schema lists the variable-rate variant. The Offer block holds last year’s APR. A retrieval model parsing this page detects three competing facts and drops confidence on all of them. The page may still rank in classical search. It rarely gets cited in a synthesised answer.
Empty Organization or Person markup with no sameAs entries. The most common implementation pattern: Organization schema with name, logo, contactPoint and nothing else. No sameAs. No subjectOf. No location. No founder linked to a Person record. The schema technically validates. The entity is undeclared. Retrieval models that rely on entity resolution against Wikidata, Crunchbase, LinkedIn and the open knowledge graph have nothing to resolve against, and the brand silently disappears from candidate sets for category queries.
FAQPage markup that does not match the visible FAQ. The visible page has six FAQs in the body. The schema lists four. The four in the schema are not the same four in the body. Or the schema answers are paraphrases of the body answers. The mismatch triggers the same confidence drop as the body-schema drift on a product page, and disqualifies the FAQPage from the citation-candidate ranking.
Article markup with stale dateModified. The dateModified field has not been touched since the page was first published, even though the body content has been edited multiple times. Extraction models use dateModified as a recency signal. A page on a fast-moving topic with an outdated dateModified gets deprioritised in favour of a peer page with current modification metadata.
What Past-the-Basics Actually Looks Like
Six structural moves separate a schema implementation that earns citations from one that just validates in the Google Rich Results Test.
Move 1. Fix the schema-to-prose match before adding any new types
The first audit pass is a diff. Pull every JSON-LD block and the corresponding visible text. Reconcile every fact. Match dates, names, prices, percentages, capacities, certifications. Where they disagree, the prose wins (because that is what the LLM is reading) and the schema gets updated to match. This single pass typically resolves 60 to 80 percent of citation-rate friction without any new schema types being added.
Move 2. Build the entity graph with sameAs as a primary citizen
Organization, Person, Product, Service and Place schemas all support sameAs. Use it. Point at Wikidata, Crunchbase, LinkedIn, G2, Glassdoor, official social handles, the brand’s GitHub if applicable, the founder’s Wikipedia entry if one exists. Cross-link the entities within the schema graph (founder Person record points back to the Organization, the Organization points forward to the Person). A multi-LOB wealth platform engagement ScaleGrowth ran surfaced that entity-graph completion alone moved AI mention rate from 40 percent baseline (on a 50-prompt sample) to a measurably higher figure inside one quarter, before any content additions.
Move 3. Use specific schema types, not just Article and WebPage
The Article type is a fallback. The specific types carry more semantic weight. A loan product page should use FinancialProduct with subtypes. A medical service page should use MedicalProcedure or MedicalCondition. A coworking listing should use Place plus LocalBusiness plus Service. A specialty chemical product should use Product with technicalSpecification, hasMeasurement, and material fields populated. The more specific the type, the higher the extraction confidence.
Move 4. Cite sources inside the schema, not only in the visible page
Article and ClaimReview support citation and isBasedOn fields. Where a page makes a factual claim, the schema can carry the source URL of the cited document. This converts a claim from “the page asserts” into “the page sources”, which materially raises citation probability on fact-sensitive queries (finance, healthcare, regulatory). The pattern is under-used in the Indian market and ScaleGrowth has observed it lifting mention rate on YMYL queries specifically.
Move 5. Validate the schema graph at the graph level, not just per-block
Google’s Rich Results Test validates individual blocks. The graph-level validation, ensuring every entity referenced is defined, every dateModified is current, every sameAs URL is live, every Offer has a valid currency and price, requires a custom validator. ScaleGrowth’s content engine ships a nine-JSON Pydantic validation per slug for this reason. The 100 percent Pydantic-pass rate on the final two batches of a 794-brief NBFC delivery (356 of 356 and 166 of 166) is the operational benchmark.
Move 6. Cache the JSON-LD versions for diff comparison over time
Every published version of every page’s JSON-LD goes into a content-addressable store. When AI mention rate moves on a topic cluster, the diff between the cached schema versions is the first place to look for the cause. This is the kind of forensic capability that pays back the first time leadership asks why a category visibility number dropped or jumped.
An Engine Output Reference
Stage 1. Inventory. Pull every JSON-LD block + visible text per URL.
Stage 2. Diff. Reconcile schema fields against visible copy. Flag drift.
Stage 3. Entity graph audit. Validate sameAs targets. Check Wikidata link integrity.
Stage 4. Type-specificity scoring. Score each page on Article-fallback vs domain-specific type.
Stage 5. Citation field audit. Flag claims without citation / isBasedOn.
Stage 6. Pydantic graph validation. Per-slug, nine JSON files. 100 percent pass required.
Stage 7. Cache versioning. Hash and store each pass for future diff.
Output: a per-URL schema readiness score, a fix list ordered by mention-rate impact, a baseline JSON cache.
Where the Effect Shows Up in the Data
On a 5,000 page Angular 17 fintech SPA audit ScaleGrowth ran, the diagnostic surfaced zero Open Graph tags across 3,677 pages, zero Twitter Cards, robots.txt being served as Angular HTML because of a router intercept bug, and a pre-JavaScript word count of one. The schema-extractable surface was effectively non-existent. The same diagnostic on the 25K page NBFC site surfaced 78 percent hreflang error rates across 4,330 tagged links and 81 percent of pages with no canonical. In both cases the AI mention rate sat well below the brand’s classical authority signals because the structured surface that retrieval models read was either missing or contradictory. The 8 percent ChatGPT mention rate on the NBFC’s category prompt set, against an Authority Score of 64, was the measurable consequence.
The fix sequence is identical across stacks. Reconcile schema to prose. Build the entity graph. Move from Article-fallback to specific types. Add citation fields. Run graph-level validation. Cache versions. The deliverable bundle for this kind of work is documented on the technical SEO audit page. The AI visibility measurement protocol sits on our AI visibility audit page.
Five Actions a Practitioner Can Run Monday
- Pull the JSON-LD from your top 20 pages and the corresponding visible text. Diff them. Reconcile every disagreement toward the prose, then republish.
- Audit your Organization schema. If sameAs is empty or limited to social profiles only, add Wikidata, Crunchbase, LinkedIn company page, G2 and any vertical-specific knowledge base.
- Replace Article fallback schema with domain-specific types on your top 50 commercial pages. FinancialProduct, MedicalProcedure, Product with technicalSpecification, Course, Service, LocalBusiness as appropriate.
- Add isBasedOn or citation fields to any page that makes a factual claim drawn from a public source. Reference the source URL directly.
- Set up a nightly job that re-pulls JSON-LD across your top 200 URLs into a versioned store. Diff weekly. Investigate any unexpected change.
FAQ
Does adding more schema types always improve LLM citation rate?
No. Adding mismatched or empty schema types lowers extraction confidence. The first move is always to reconcile existing schema to prose and to complete the entity graph. New types add value only after that base layer is internally consistent. The pattern observed on ScaleGrowth’s content engine is that fixing drift on existing blocks moves mention rate more than adding new types.
How does FAQPage schema affect citation versus rich results?
Google has reduced FAQPage rich result rollouts in classical SERPs, but retrieval models still extract FAQPage as a high-confidence question-answer source. A well-built FAQPage block with answers that match the visible page exactly serves the citation case independently of the SERP feature case. The two functions have decoupled.
What is the right cadence for re-validating schema after a publish?
Per publish at minimum, with a graph-level validator catching cross-block conflicts. A nightly job that diffs the cached schema state against the current state catches drift introduced by CMS edits, third-party plugin updates, or template changes. ScaleGrowth ships a Pydantic-validated pipeline that enforces this at the brief-render stage on every batch.
Do retrieval models read JSON-LD before or after JavaScript hydration?
Most current retrieval models read the initial server-rendered HTML and do not wait for client-side hydration. JSON-LD that is injected by JavaScript after page load is effectively invisible to retrieval. Schema must be in the source HTML response. The Angular and React stacks routinely miss this and the AI mention rate suffers without any classical search signal showing the problem.
Is there a measurable lift attributable to entity-graph completion alone?
Yes on the engagements ScaleGrowth has measured. The strongest reference point: a multi-LOB wealth platform engagement where AI mention rate moved measurably after sameAs completion across Organization and Person records, independent of any new content. The exact percentage depends on baseline and prompt cohort.
Commission the AI Visibility Baseline
If a brand’s schema implementation has never been audited against a per-LLM mention rate baseline, that is the first artefact to commission. The reference engagement detail and the full diagnostic methodology sit on our AI visibility audit service page.