AI Schema Example: 74/100 with 11 Hallucination Risks Flagged
This example shows the aiwebpageseo AI Schema Audit for a SaaS marketing site. AI Schema Score is 74 of 100. 92% of pages have JSON-LD but 38 critical fields are missing across page types, 11 entity references are ambiguous and create hallucination risk in AI engines, and 12 authors lack proper Person objects with knowsAbout signals.
| Page type | Required for AI | Coverage | Status |
|---|---|---|---|
| Articles | author (Person), datePublished, dateModified, mainEntityOfPage | 84% | ⚠ 22 pages missing dateModified |
| Products | name, sku, brand, offers, availability, aggregateRating | 91% | ✅ Strong |
| FAQs | Question + acceptedAnswer with single string answer (not nested) | 78% | ⚠ 14 FAQs over-nested |
| HowTo | name, step (HowToStep with text + image) | 62% | 🔴 Missing images |
| Organization | name, url, logo, sameAs (social profiles) | 100% | ✅ Complete |
| Person (authors) | name, jobTitle, sameAs, knowsAbout | 34% | 🔴 12 authors missing |
Article author uses string instead of Person object (12 pages)
Blog articles list "author": "Jane Smith" with no Person @id. ChatGPT and Claude cannot link the same Jane Smith across articles — risk of attribution errors. Convert to Person object with @id, name and sameAs links.
Product reviewedBy missing @id (8 PDPs)
Review objects on PDPs use string author "TrustedSource" — AI cannot verify the reviewer. Add Organization or Person @id to enable trust evaluation.
Stale dateModified on /docs/* (47 pages)
Doc pages show dateModified from 2024 even though content was rewritten in 2026. There is no evidence that engines down-weight content by dateModified, so do not treat the field as a ranking lever — but a date that contradicts the page is a false statement in your structured data, and structured data must describe the page it is on. Wire dateModified to the actual last-edit timestamp, and never bump it without an edit.
74 out of 100 is a coverage figure. It says that most of your pages carry JSON-LD, that a lot of them are missing fields the relevant schema.org type defines, and that a handful contain references a machine cannot resolve. Every one of those statements is checkable by parsing your HTML, and that is the whole of what this audit knows.
What it does not know — what nobody outside the assistant operators knows — is whether any of it changes the probability of being cited. There is no verified evidence that AI engines preferentially cite pages carrying denser structured data, and any vendor implying otherwise is selling a correlation they cannot demonstrate. The honest, defensible claim is much narrower: retrieval systems generally parse served HTML rather than rendering it, so JSON-LD in the initial response reaches them, and it removes ambiguity about what your text means. Disambiguation is real. Volume is not a lever.
This distinction changes what you do with the report. It means the rows worth fixing are the ones where the markup is wrong or contradicts the page — not the ones where a percentage is merely lower than you would like. A page with three accurate schema types beats a page with nine, four of which describe content that is not there.
Of everything flagged, the eleven ambiguous entity references are the ones that genuinely degrade what a machine can conclude about your site — and they do it in the specific way that produces confident, wrong output.
Consider the author string. Twelve articles say "author": "Jane Smith" and nothing more. A system reading all twelve has no basis for deciding whether this is one person writing twelve pieces or twelve unrelated authors who happen to share a common name, and no route from that string to anything about her outside your site. If it then asserts that Jane Smith is a Head of SEO Research who specialises in Core Web Vitals, it did not derive that from your data. It guessed, plausibly, from context. That is the mechanism behind attribution errors, and the fix is not more markup but identified markup.
A Person object with a stable @id collapses twelve guesses into one entity. Every article referencing that same @id is unambiguously about the same person. The sameAs array then connects that entity to profiles elsewhere — which is entity disambiguation and nothing else. It is worth being blunt here, because the opposite claim is everywhere: no schema property confers E-E-A-T. E-E-A-T is a framework Google's human quality raters apply; it is not a score computed from your markup, and there is no field that raises it. sameAs helps a machine work out which Jane Smith you mean, and only if a Jane Smith exists to be found.
The same reasoning applies to the eight product reviews attributed to the bare string "TrustedSource". If the reviewer is an organisation, give it an Organization node with a URL. If the reviewer cannot be identified at all, the honest move is to stop claiming a reviewer — an unverifiable attribution is worse than none, because it invites a system to invent the missing detail.
The HowTo row is red because 38% of HowTo blocks lack step images. The FAQ row is amber because fourteen FAQ answers are over-nested. Before you schedule either, understand what fixing them buys.
HowTo rich results were removed by Google entirely
There is no HowTo enhancement in Search to earn back. Adding step images will not produce one. The markup remains valid schema.org and it does describe your page truthfully, which is the only reason left to keep it. It is not worth a sprint, and it should not be flagged as a lost opportunity, because the opportunity is gone for everyone.
FAQ rich results are restricted to recognised government and health sites
A SaaS site will not get FAQ dropdowns in the SERP regardless of how clean the markup is. FAQPage schema is still worth having — it makes your question-and-answer structure machine-readable in the served HTML — but the reason is parsing, not a SERP enhancement. Fix the over-nesting because a flat text answer is easier to extract, not because a rich result is waiting.
The general principle: a schema audit that scores you against enhancements Google has withdrawn is scoring you against nothing. Ask of every red row what specific outcome fixing it produces, and if the honest answer is "the markup will be more complete", weigh that against the rows where the answer is "the markup will stop being wrong".
The over-nesting warning points at a deeper problem than nesting. An acceptedAnswer takes a text value, and that value should be the answer — a self-contained passage that stands up when read on its own, with no page around it and no preceding paragraph to lean on.
Most FAQ answers fail that test not because of their JSON but because of their prose. "As mentioned above, this depends on your plan" is not an answer; it is a pointer to one. When an assistant summarises your page it is looking for a passage it can quote or paraphrase without importing context, and a passage that begins by referring to something else cannot be lifted cleanly. Write each answer as though it will be read by someone who has seen nothing else on the page, because that is precisely what happens.
Then mirror it. The schema answer and the visible answer must be the same text. A page whose FAQ answers exist only inside JSON-LD, or only inside a collapsed accordion that renders client-side, has given a parser structure without substance — and it has broken the rule that governs all of this: structured data describes what is on the page. It does not add claims the page does not make.
| Page type | Coverage | What fixing it actually buys |
|---|---|---|
| Products (91%) | High | Real and immediate. Product rich results exist, and price or availability that contradicts the visible page is grounds for item disapproval in Google's shopping surfaces. This is the one row where an error has a direct commercial cost. |
| Articles (84%) | High | Article enhancements exist. The 22 pages missing dateModified should carry the real edit date — not for freshness ranking, which is not what the field does, but because a machine-readable date that contradicts the page is simply false. |
| Person / authors (34%) | Low | Attribution clarity. Removes the ambiguity that produces invented biographies. Buys no E-E-A-T, because nothing does. |
| Organization (100%) | Complete | Nothing further. Leave it alone. |
| FAQs (78%) | Medium | Cleaner extraction of answers. No rich result — restricted to gov and health sites since 2023. |
| HowTo (62%) | Low | Nothing. The rich result was removed. Accurate markup, no enhancement. |
Reordered by consequence rather than by percentage, the work list inverts: the 91% row matters most and the 62% row matters least. A coverage score sorted by size will always point you at the wrong thing first.
Structured data is a machine-readable restatement of what a human can see on the page. It is not a second channel for claims the page does not make, it is not a place to assert ratings nobody left, and it is not a lever whose length you increase by adding types.
Every defect on this report is a violation of that one rule, expressed differently. A dateModified of 2024 on a page rewritten in 2026 is markup that contradicts the page. An author string with no identity is markup that under-describes the page. A review attributed to an unverifiable source is markup that over-claims. The fixes converge on the same instruction: say what is true, say it precisely enough that a parser cannot misread it, and say nothing else.
Do that and the score follows. Chase the score and you will end up marking up a HowTo enhancement that Google deleted.
Does more structured data make AI engines more likely to cite my page?
There is no verified evidence for that claim, and any tool that presents schema volume as a citation lever is overclaiming. The defensible version is narrower and still worth acting on: retrieval systems generally parse the HTML they are served rather than rendering it in a browser, so JSON-LD present in the initial response reaches them, and it disambiguates — it states unambiguously that a string is a price, a date, an author or a product name rather than leaving a parser to infer it from layout. That is a clarity benefit. It is not a volume game, and marking up types the visible page does not support is a structured data policy violation rather than an optimisation.
What is a 'hallucination risk' in schema terms?
It is an ambiguity that forces a machine to guess. When an article says its author is the string "Jane Smith" and nothing else, a system reading twelve of your articles has no way to know whether that is one person or twelve different people with the same name, and no way to connect her to anything outside your site. Any statement it then makes about her expertise is invented rather than derived. Giving Jane a Person object with a stable @id turns twelve guesses into one identified entity. The schema does not make the machine's summary true — only your content can do that — but it removes the specific ambiguity that produces confident nonsense.
Does author sameAs markup improve E-E-A-T?
No schema property confers E-E-A-T. E-E-A-T is a set of criteria Google's human quality raters use when assessing search results; it is not a score computed from your markup, and there is no field you can add that raises it. What sameAs does is entity disambiguation: it links your Person node to other profiles that describe the same person, so that a system can connect the author on your site to an author who exists elsewhere. That only helps if the person genuinely has a presence to connect to. sameAs pointing at three empty profiles disambiguates nothing, and it certainly does not manufacture authority.
Should I fix the HowTo image coverage?
Not as a priority, and it is worth knowing why before you spend a sprint on it. Google removed HowTo rich results entirely, so no amount of HowToStep markup with images will produce an enhanced result in Search. The markup remains valid schema.org, it is harmless to keep, and it does describe your page accurately — which is the only remaining argument for it. The same applies to the FAQ coverage row: FAQ rich results are restricted to recognised government and health sites, so a SaaS site will not get FAQ dropdowns in the SERP. Both are still worth having as machine-readable structure. Neither is worth having as a SERP play, and any tool that flags them in red as lost rich results is measuring something that no longer exists.
What does the 'over-nested FAQ' warning actually mean?
It means the acceptedAnswer contains a nested object structure where a plain text answer belongs. The Answer node takes a text property whose value should be the answer itself — a self-contained string that reads as a complete response. Wrapping it in additional layers, or splitting it across nested entities, gives a parser structure it has to unpick before it can find the sentence a human would actually quote. The test is simple: if you extract the answer text and read it on its own, does it answer the question without the page around it? If it does not, the problem is the writing, not the nesting.
Why does a stale dateModified matter if it is not a ranking factor?
Because it is a false statement about the page, and structured data is a machine-readable restatement of what the page contains. A doc page rewritten in 2026 that declares dateModified as 2024 is telling every parser something untrue. That is worth fixing on correctness grounds alone. What it is not worth doing is the opposite manoeuvre — bumping dateModified on unchanged pages in the hope of appearing fresh. That is misrepresentation, it produces no demonstrated benefit, and it destroys the value of the field for the systems and humans that were relying on it to mean something.
Where should the remediation effort actually go?
In order: fix anything where the schema contradicts the visible page, because that is a correctness failure and, on commercial pages such as products, it has real consequences in Google's shopping surfaces. Then add the missing required fields on page types that still have live rich results — Product and Article — because those are enhancements that still exist. Then create the twelve Person objects, not for E-E-A-T but because attribution should be unambiguous. Leave the HowTo and FAQ coverage numbers where they are: they are accurate descriptions of your content and they buy nothing further, so improving them is work with no return.
Related Demo Reports
Run AI Schema Audit on Your Own Site
Get your real AI-aware schema audit with field coverage by page type, hallucination-risk diagnostics and ready-to-paste fixes.