A perfect schema score and a zero, measured on the same page

Two checks, one block of markup

Every scan that gets far enough to be graded runs two independent readings over the JSON-LD in the HTML a crawler receives. They are not two views of one calculation. They are two different questions, they live in two different modules, and only one of them can move your grade.

The first is the schema sub-score. It performs exactly three checks and no others: does the block parse as JSON, does each entity in it declare an @type, and do the entities carrying a recognised business type also carry that type's required properties. The requirements are stored as data rather than logic, and there are five of them. Organization needs a name and a url. Product needs a name. Article needs a headline. FAQPage needs mainEntity. BreadcrumbList needs itemListElement. Six aliases route subtypes to those five, so NewsArticle, BlogPosting, TechArticle and ScholarlyArticle are checked as Article, and LocalBusiness and Corporation are checked as Organization. Partial credit is graded rather than binary: an entity with no @type at all scores 0.4, and an entity of a recognised type missing a required property scores 0.6, because a type is what a retrieval system keys on and a missing property is the smaller failure. Each entity scores, each block averages its entities, the page averages its blocks, and the result enters the composite at 10 percent. That is the whole of what markup contributes to the graded number.

The second reading is Entity Confidence, and it asks something the sub-score never asks: does this markup identify anybody. It walks the same blocks looking for an Organization-family node that carries all three of a type, a name and an absolute http or https url, then scores three further properties of that node, plus a category signal that reads the node first, a specific subtype, additionalType, an industry code or knowsAbout, and only falls back to a document-wide scan when the node itself says nothing. The five signals sum to 100. Identity is 35, because every other signal is a statement about the node it finds. External identifiers via sameAs are 25, the largest non-gate weight, because sameAs is the one property in the set whose schema.org definition is itself an identity-resolution statement, a reference page that unambiguously indicates the item's identity. A stable absolute @id is 15, a logo is 15, and a machine-readable category is 10. How those weights were derived, and which two signals were deleted when we measured them, is the subject of an earlier post on the five signals and is not re-argued here.

The category signal reading the whole document is a deliberate exception rather than an oversight, and the comment above the type list in core/src/entity.ts records why. A sibling SoftwareApplication node in the same graph is a real declaration of what a company sells, even though it is not a property of the identity node, so narrowing the list of types that count was the fix rather than narrowing where we look. The same comment records what was narrowed. An Offer node used to count as a category declaration, and on a stored salesforce.com capture a price node anywhere in the document earned one, which describes availability and money rather than what the organisation is. A description used to count too, which meant prose was being read as a machine-readable declaration. Both are gone.

The consequential difference is what happens to each result. The schema sub-score is 10 percent of a graded report. Entity Confidence is 0 percent of it. It is printed beside the grade rather than inside it, and the composite figure on the methodology page puts Retrievability and Entity Confidence outside the bar under a note saying that both never enter the 100. That is not a hedge about the quality of either one. It is the only honest place to put a measurement that no platform document we have read connects to any behaviour of the system it describes.

One capture, 1.0 on one reading and 0 on the other

The stored capture that makes this concrete is the Wikipedia article on web crawlers, captured 15 July 2026 and held as a golden fixture since. Every figure in this section is transcribed by hand from core/fixtures/wikipedia-web-crawler/expected.json, and each one is a snapshot of that day rather than a description of the page as it stands now.

That capture scores a composite of 91.4 and an A. Prose parity is 0.994, access is 0.9, structure is 0.615, and the schema sub-score is a flat 1.0, the maximum. The stored schema report explains why in one line: one JSON-LD block, one entity, type Article, no required properties missing. The checker asked its three questions, got three good answers, and had nothing further to ask. The rest of that capture, and the five others taken on the same day, are worked through in the storefront teardown rather than here.

Entity Confidence on the same capture is 0 out of 100, tier not_declared, source none. The detail string it printed for the identity signal is the whole story: "Found Organization but it is missing an absolute url. Add an absolute url to that node so it identifies one thing unambiguously." The sameAs signal added that one sameAs URL sits on the Article node instead, which is not the same claim as a sameAs on an identity node, because an Article can perfectly well be about someone other than its publisher.

That zero is younger than the capture, and the way it got there is worth stating rather than hiding. Until 26 July 2026 the same fixture scored 25, earned by that single sameAs on the Article node, which is a Wikidata identifier for the article's subject rather than for any publisher. The report then printed a sentence about identifiers connecting an identity the page had never declared. When the deeper traversal landed it reached the two named Organization nodes on that page and rejected both, because neither carries a url. The points and the contradiction went away together, which is the useful part: the 25 was never a reward for anything the page had done.

So one reading found an Organization node and rejected it, while the other never saw an Organization node at all. That is not a disagreement of judgement. It is a difference in traversal, and it is deliberate. The schema checker flattens a document by descending arrays and @graph members only. Entity Confidence uses a deeper flattener that also descends ordinary property values, bounded at 64 levels and 4096 nodes so that a pathological document cannot exhaust the call stack. A node parked inside a property value is therefore visible to one reader and invisible to the other. The shallow traversal was left shallow on purpose: the schema sub-score feeds the composite, so deepening it would move the score of every stored capture we calibrate against.

Both answers are right about their own question. The markup on that page is well formed and complete for the type it declares, which is what a validator should say. The markup on that page also does not resolve to a publisher a machine can point at, which is what an identity reading should say. A page can hold a perfect schema sub-score and still declare nothing that identifies it, and if you only ever look at one of those two numbers you will not know which situation you are in.

That is why the pair is worth printing together. Anyone can produce a green tick from a validator. A green tick means the syntax is legal. It does not mean an AI crawler that fetched your page came away knowing who published it. If you want the formal grounding for why an absolute identifier behaves differently from a relative one, the JSON-LD 1.1 Recommendation is the source: a relative reference is resolved against the document that carried it, so it only identifies something inside that document. That is a specification fact rather than a Lantad opinion, and it is the reason our identity check refuses relative urls.

What the schema sub-score will not tell you

It is worth being blunt about the scope of the 10-point reading, because three checks is a much narrower thing than the words schema score suggest.

Lantad's schema sub-score recognises five types and six aliases. It is not a schema.org validator. It does not know Recipe, Event, JobPosting, Review, Course, HowTo, or the rest of the vocabulary, and it will not tell you that your Recipe is missing cookTime. It also does not test rich-result eligibility for any search feature. If that is what you need, Google's Rich Results Test is the tool for it, and we would rather point you there than pretend our three checks are the same product. Rich-result eligibility and what we measure are different things, and neither one is evidence about an AI answer.

Two caps matter more than the type list does. The first is for markup that carries no business fact at all. A page whose entire JSON-LD is unrecognised types, a lone WebPage or a WebSite block and nothing else, is capped at 0.4 rather than scoring full marks. It has structured data. It has no business type we can validate, so it cannot earn the same score as a page that declared an Organization and completed it. The asymmetry is deliberate: a generic WebPage sitting beside a real Organization block costs nothing, because the cap only fires when nothing recognised is present anywhere on the page.

The second cap is the one that catches modern front ends. Structured data that exists only after JavaScript runs is worth at most 0.25 of the schema sub-score, because a crawler that does not execute JavaScript never receives it. Two synthetic fixtures in the repository exist to hold that behaviour still. A client-rendered single-page app and a hydration-style app both hold schema 0.25, Entity Confidence 0, source rendered_only, and a composite of 34.4 with an F. Entity Confidence gives client-injected markup nothing at all, not even the partial credit the sub-score allows, because the crawler view is that diagnostic's entire premise. If your Organization block is emitted by a client component, one of our readings will hand you a quarter of the points and the other will hand you none, and both are telling you the same thing.

That is a fixable problem rather than a fatal one, and it is a rendering problem rather than a markup problem. The stack guides for Next.js and React cover where the block has to be emitted so that the raw HTML carries it. If you want to see the crawler view of your own page before changing anything, what GPTBot sees shows you the raw fetch. The same distinction drives prose parity, which is 50 of the 100 points and dwarfs everything else discussed in this post: markup a crawler never receives is one special case of content a crawler never receives, and a fetcher that came away with the empty shell of your page has a bigger problem than your type list.

One more scoping note, since it is the honest half of the answer to the search that brought you here. The JSON-LD format itself is defined at json-ld.org and the vocabulary at schema.org, and neither of those sources claims anything at all about AI systems. They define a syntax and a vocabulary. Everything anyone says about what AI does with them is inference stacked on top of that.

The blind spot we have not closed

The two-traversal design has an unflattering consequence, and since this whole post rests on the disagreement being principled, we should say plainly where it is not.

Entity Confidence fixed the nested-node problem for itself. The schema sub-score, which is the reading that actually affects your grade, still has it. Its alias table maps LocalBusiness and Corporation to Organization but does not carry the subtypes beneath them, so a Store or a more specific local-business subtype is never routed to Organization's requirements. Combine that with the shallow traversal and a real failure shape appears: a publisher-nested Organization, the pattern where the Organization sits inside an Article's publisher property rather than as a sibling node, is invisible to the schema sub-score. A page in that shape can present as carrying no recognised business type, which means the 0.4 cap can fire, which means the composite moves for a reason that is about our traversal rather than about the page.

We have not fixed it. The reason is written in the code: extending the alias list changes which types are canonical, which changes the recognised-type test, which changes the cap, which moves the schema score and therefore the composite on every stored capture. That is a re-baselining job with a calibration argument attached rather than a one-line patch, and doing it carelessly would silently rescore historical reports. It is logged as a follow-up and it is not done. On an Article page the nested publisher Organization is never checked at all, so the sub-score neither penalises nor validates it. The shapes that do trip the cap are the ones with no recognised type anywhere: an Organization under an unrecognised parent, or a page whose only business node is an unaliased subtype. We would rather you learn that here than infer it from a number.

Three more limits belong in the same breath, because they are the ones a buyer would reasonably assume we have and we do not. Our diff engine does not compare Entity Confidence between scans, so change tracking and monitoring cannot tell you that your structured-data reading moved. Entity Confidence is not in the MCP output, not in the report emails and not in the digest, and the developer documentation does not list it, though it does ship inside the verdict JSON that the report endpoint returns. And any Entity Confidence score produced before 26 July 2026 is on the previous signal scale and is not comparable with a current one, which is why a stored report renders the signal set it was actually measured with instead of restating it in today's terms.

We also ship no standalone structured-data tester. There is no free schema validator among the free tools on this site, and this post is not a soft launch of one. Our two numbers are a scoring input and a diagnostic, in that order, and a post that let them read as a validator would be selling the thing we have just said we do not have.

Refusing to report a measurement we did not take is a habit here rather than a one-off. The reasoning behind withholding a grade on a page we could not measure is the same reasoning that keeps Entity Confidence out of the AI Visibility Score entirely. If you want to see what we can publish across many scans instead of one, the research page aggregates live from the database and states its own minimum-sample gate rather than quoting a figure that would be stale the day it was written. On the stack side, we hold exactly one stored Shopify capture with a schema reading: gymshark.com on 15 July 2026, which carries an Organization block, a schema sub-score of 1.0 and Entity Confidence 75, with the absolute @id and the machine-readable category absent. One capture is one capture, and it supports no sentence about the platform.

What the platform owners actually document

Now the part that cuts against our own feature, which is the part worth publishing.

Google's AI features documentation, updated 10 December 2025, states that no special schema.org structured data is needed for a page to appear in those features. That is a narrow statement and it should stay narrow. It does not say that Google's AI features ignore structured data, and we are not going to upgrade it into that. What it does say is that there is no schema entry fee, which is close to the opposite of what most content on this topic implies.

Google does document consumers of structured data elsewhere, and that documentation is specific. The Organization structured data reference, updated 15 April 2026, lists logo among its recommended properties and states that the markup can influence which logo is shown in Search results and in the knowledge panel. That is a real, attributable, scoped outcome sentence about one platform's own surfaces, and it is the only outcome sentence anywhere in our Entity Confidence report copy. The other thing Google keeps repeating, in its structured data general guidelines, is that markup should match the visible content of the page. That recommendation deserves more attention than the type list gets, because it means markup describing a page the reader never sees is a policy problem before it is ever a scoring problem.

Then the absence. OpenAI, Anthropic and Perplexity publish nothing about structured data in their crawler documentation. That is a claim about documentation rather than about behaviour, and the distinction is the entire point: we cannot see what those systems do internally, so the only checkable statement available is what they have written down. Check it yourself. Here is OpenAI's bots documentation, here is Anthropic's crawler article, and here is Perplexity's bots guide. All three tell you about user agents, IP ranges and how to block them. None tells you to add schema. If you find a page on any of those hosts that does, we will correct this post.

That is why our scoring code carries a rule rather than a caveat. No string in the Entity Confidence module is permitted to say that a signal produces a citation, a ranking or visibility, and the weights file states directly that no weight expresses what a property is worth to any AI system, only how strongly it discriminates among sites that are demonstrably cited. That rule is enforced by a test rather than by editorial discipline, which matters because editorial discipline is exactly what fails on the fortieth report string. It is also why the platform pages on this site, Google AI Overviews, ChatGPT, Claude and Perplexity, describe each system's documented fetching behaviour rather than promising a markup recipe that gets you cited.

We have published an external finding that undercuts one of our own features before, most recently on what the evidence says about llms.txt, a file we also ship a tool for. The reason is the same both times. A measurement business that only publishes evidence flattering to its own features is not a measurement business, and the first person that habit protects is us: a number we have talked ourselves into is a number we will keep selling long after it stops being true.

How to read your own two numbers

There are four combinations of the two readings, and each one carries a different meaning and a different next action. The examples below all come from captures taken 15 July 2026 and are stated as that day's measurements rather than as current facts about those sites.

High schema and high Entity Confidence. Webflow's homepage capture scores a composite of 96.7 with an A, a schema sub-score of 1.0 and Entity Confidence 100, tier anchored. It is the only stored fixture at 100. Its single block holds four nodes, Organization, WebSite, SoftwareApplication and WebPage, and the Organization carries an absolute @id, which is what makes those four nodes one linked graph instead of four unrelated objects. The Gymshark capture is close behind at 94.3 with an A and schema 1.0, but Entity Confidence is 75: identity, sameAs and logo fired, the absolute @id and the machine-readable category did not, and the capture also carries a truncation caveat because the raw HTML exceeded our size limit before we finished reading it. Both are the good case, and neither needs anything doing.

Zero schema and zero Entity Confidence. The astro.build capture scores 88.8 with a B, and the MDN HTML documentation page capture scores 88.3 with a B, and both carry schema 0 and Entity Confidence 0. Both server-render extremely well, with parity of 1.0 and 0.988 respectively, which is the reading that matters most on either page. That two widely referenced documentation sites carry no JSON-LD at all is worth holding onto the next time somebody tells you markup is mandatory. The same shape turned up in the hand-picked sample of 30 pages behind our signal weights, and it is reported in the five-signals post rather than restated here.

Perfect schema and zero Entity Confidence. This is the Wikipedia shape described above, and it is the combination most likely to be misread as a clean bill of health. The action is not to add more types. It is to make one identity node complete, meaning a type, a name and an absolute url on an Organization-family node, and then anchor it with an identifier that resolves outside the page. The report generates that block for you from the scan's own findings rather than from a template, in two shapes: a complete script block when no identity node exists, and a properties-only merge fragment when one does, so that nobody pastes a rival identity onto a page that already has one. Every value we did not measure is a placeholder marked as one, because guessing your legal name or your logo path would be inventing data. The schema.org Organization reference is where to check what each property means before you fill those in.

Quarter schema and zero Entity Confidence. This is the client-rendered case, and the fix is a build change rather than a markup change. Move the block into the server-rendered HTML, which for most stacks means the framework's document or metadata layer rather than a component effect. The two stack guides linked earlier in this post cover where that is on each of them, and a single crawler-view fetch will confirm it once you have made the change.

The word printed beside your number is worth reading before the number itself. The tier is computed from the signal booleans and never from the score, because 50 points is reachable both with an outside identifier and without one, so no threshold on the number can name the state. Not declared means there is no identity node in the crawler-view HTML at all. Declared means the node is present and complete but nothing outside the page points at it. Anchored means it carries at least one identifier that resolves outside the page. Wikipedia's capture is not declared at 0. Gymshark's is anchored at 75. The tier names the state and the number ranks within it, which is the order to read them in.

One last operational note, and then the summary. The Entity Confidence section only renders when the scan produced a schema reading at all, so a degraded scan shows no structured-data section rather than a misleading zero next to a grade. And the honest summary of this whole post is short. Fix the 50 points of prose parity first, then the access and structure points, and treat the schema work as the last 10 rather than the first move. The two structured data readings are worth having because they answer different questions and because one of them is free, not because markup is a lever anybody has published evidence for.