Schema structured data: a valid BreadcrumbList scored zero because of its syntax

Is schema structured data the same as JSON-LD?

No, and the confusion is understandable because in practice they travel together. The schema.org getting started page, which carries the version marker V30.0 and the date 19 March 2026 at its foot, puts it in one sentence: you use the schema.org vocabulary along with the Microdata, RDFa, or JSON-LD formats to add information to your Web content. Schema.org is the list of types and properties. The three formats are the ways of attaching that list to a document. A Product with a name is the same fact in all three, and switching between them changes not one thing about what you are asserting.

The three formats differ in where the assertion physically lives. JSON-LD puts it in a separate script block, so the markup sits beside the document rather than inside it, and the specification for that serialisation is maintained at json-ld.org. Microdata and RDFa both put it on the elements that already render the content, as attributes. Microdata's attributes are defined in the WHATWG HTML Standard, in its microdata chapter at html.spec.whatwg.org/multipage/microdata.html, which is not a host this site links. RDFa Lite 1.1, a W3C Recommendation whose Second Edition is dated 17 March 2015, is deliberately the small version of RDFa and states in its own words that it consists of five simple attributes: vocab, typeof, property, resource and prefix.

Google's position on the three is worth quoting exactly, because it is the reason JSON-LD dominates and it is also weaker than it is usually reported to be. Google's introduction to structured data, carrying Last updated 2025-12-10 UTC, states that Google Search supports structured data in JSON-LD, Microdata and RDFa unless documented otherwise, and that Google recommends using JSON-LD if your site's setup allows it, as it is the easiest solution for website owners to implement and maintain at scale. That is a recommendation about maintenance effort. It is not a statement that the other two are ignored, and Google's own page marks all three as supported.

Which leaves an open question this post cannot answer and will not pretend to. No AI crawler vendor documentation read for this site has ever named a structured data format it parses, in either direction. That gap is the same shape as the one found when three crawler documentation pages named robots.txt and none named TDMRep, and it means every sentence below is about what a page ships and what this scanner reads, never about what an answer engine does with either.

Which syntax did five real pages actually use?

The method is a plain HTML parser run over both stored documents for each capture, the raw HTTP response body and the rendered DOM, giving ten documents. For microdata the parser counted every element carrying itemscope, itemtype or itemprop. For RDFa it counted every element carrying typeof, vocab or property, and recorded the attribute values rather than only the totals, because the totals turn out to be misleading on their own.

Microdata is the short result. Across all ten documents, itemscope appears zero times, itemtype appears zero times and itemprop appears zero times. Not one element on any of these five pages uses the format. That is a five page count and not a survey of the web, and the pages are a homepage, a storefront, a reference article, a marketing site and an encyclopedia entry rather than a sample of anything, so the honest reading is that microdata was absent here rather than that it is dead. It is still a striking zero for a format that Google lists as supported.

RDFa produces 204 occurrences of typeof, which looks like a real result and mostly is not. 199 of them are on the Wikipedia capture, and every one sits in the mw namespace: mw:Extension/ref 54 times, mw:Entity 53, mw:Extension/templatestyles mw:Transclusion 35, mw:Transclusion 26, mw:Extension/templatestyles 19, and a long tail of file, math and nowiki markers. Those are Parsoid's internal annotations describing how the wikitext was transformed, not schema.org types, and the same page carries zero vocab attributes. Its six property attributes are five Open Graph values and one more mw marker. Counting typeof attributes and calling the total structured data would have produced a headline number that is wrong by a factor of forty.

The five that remain are all on the MDN HTML reference, and they are the real thing. One vocab attribute names https://schema.org/ as the vocabulary. The typeof values are BreadcrumbList once, ListItem twice and WebPage twice. Eight property attributes carry itemListElement twice, item twice, name twice and position twice. That is a two step breadcrumb trail written correctly in RDFa Lite, using exactly the attributes the specification defines, and it is the only schema.org markup in the set that is not JSON-LD.

One more comparison is worth recording because it closes off a failure this scanner has published about before. For all three syntaxes the raw HTTP response and the rendered DOM gave identical counts: 4 JSON-LD blocks in both, 0 microdata attributes in both, 204 typeof attributes in both. None of these five pages injects structured data with JavaScript. That matters because client injected markup is a documented way for a page to look marked up in a browser and bare to a crawler, the same class of problem as text inside shadow DOM reaching the browser and not the extractor and as hydration JSON scoring the same as no text at all. On this set it simply did not happen.

What the scanner reads, and what it walks past

The extractor that produces every structural figure on this site is a streaming HTML parser in core/src/extract.ts. When it opens a script element it reads the type attribute and sorts the block into one of four buckets. If the type contains ld+json the block is kept as JSON-LD. If the type is empty, or contains javascript, or is module, the block is plain script and its contents are discarded. If the type contains json but not ld+json it is other JSON, which is how the hydration payload case is recognised. Anything else is dropped.

Everything the schema sub-score sees comes out of that first bucket. There is no second path. Searching core/src for the words itemscope, itemtype, itemprop, microdata and rdfa returns nothing, and searching for the typeof and vocab attributes returns nothing either. The scanner has no code that could read a microdata or RDFa assertion even in principle, which means it does not fail to parse them: it never looks. A page can carry a perfectly formed schema.org graph in attributes and this product will describe it as having no structured data.

Calling that a bug is a judgement rather than an observation, and the honest version of the judgement has two sides. On one side, JSON-LD is what Google recommends, it is by far the most common format in the field, and building a scanner around it is a defensible allocation of effort for a small product. On the other, the report does not say "no JSON-LD found". It reports a schema score, and a reader takes that to mean a claim about their structured data. The gap between what the number measures and what its label implies is the same problem this site wrote up when the same JSON-LD read two defensible ways produced a perfect score and a zero, and the resolution then was to publish the ambiguity rather than pick a number and be quiet.

Nothing about the check itself is hidden. The rules are on the methodology page, the schema requirements are five short lists in core/src/schema.ts naming name and url for an Organization, name for a Product, headline for an Article, mainEntity for a FAQPage and itemListElement for a BreadcrumbList, and the sub-score asks only that a block parses, that its entities carry a type, and that recognised types carry their required properties. What was never stated anywhere, until this post, is the precondition sitting above all of it: that the graph has to arrive in a script tag.

Why did a page with a valid BreadcrumbList score zero?

Open the stored verdict for the MDN capture and the schema sub-score is 0. The composite is 88.3 and the grade is B. Its other sub-scores are healthy: access 1, structure 0.923, prose parity 0.988. The one zero on the page is for structured data that the page demonstrably has.

The detail that makes this sharper than a general complaint is which type MDN chose. BreadcrumbList is one of exactly five types this scanner recognises as a business type in SCHEMA_REQUIREMENTS, and the single property it requires is itemListElement. MDN's markup carries itemListElement twice. The type is on the list, the required property is present, the vocabulary is declared as schema.org, and the whole thing is written in the five attributes the W3C Recommendation defines for exactly this purpose. Had the same two step breadcrumb been serialised into a script tag as JSON-LD, it would have satisfied the requirement as written. We did not run that rewrite, so that sentence is arithmetic on the shipped rules rather than a second measurement, but the rules are four lines long and they are not ambiguous.

The cost is quantifiable because the weights are published. SCORE_WEIGHTS in core/src/config.ts sets parity at 0.5, access at 0.25, structure at 0.15 and schema at 0.1, and those weights are a decision somebody made rather than something anybody measured, which is a distinction this site insists on. A schema sub-score of 0 rather than 1 removes 10 points from the composite. MDN scores 88.3. The A band, in GRADE_BANDS, starts at 90. So the page sits under the boundary by 1.7 points while forfeiting 10 for markup it published correctly, and the grade on the report is decided by a format choice the report never mentions.

It is worth being precise about who is wrong here, because it is not MDN. The page did what the specification and Google's own supported formats list permit. The scanner narrowed the world to one syntax and then reported the result as though it had looked at all three. That is the failure mode this site named on day one when it argued for withholding a grade rather than guessing one, and this is a case where a grade was issued with a component silently measured at zero for a reason nobody stated.

Two pages scored zero for schema, for different reasons

The Astro homepage also scores 0 for schema, with a composite of 88.8 and a grade of B, which is a remarkably close pair of numbers to MDN's. On Astro the zero is simply true. That page carries no JSON-LD, no microdata attributes and no typeof attributes: nothing in any of the three formats. On MDN the zero is an artefact of what this scanner reads. The two pages are within half a point of each other on the composite and the identical zero underneath means two completely different things.

That is the useful generalisation, and it is a caution about reading any tool's structured data score, this one included. A zero is a statement about what the tool found, and a tool's coverage is rarely printed next to its output. If a scanner reads one syntax and your site uses another, you get the score of a page with nothing, and the report and the reality agree on the digit while disagreeing on everything the digit is for. This is the same reasoning behind reporting prose parity as a measured ratio rather than a prediction, and behind the counts on the research page carrying their method with them.

The three pages that score 1 all reached it through JSON-LD, and the earlier posts on this set have taken those graphs apart in a few directions already: three captured pages scored full marks for schema and one of them carried a date, seven of 102 schema nodes named an author, and 70 of 146 markup values were not on the page. Every one of those findings is a finding about JSON-LD, because JSON-LD is all this scanner has ever seen. The coverage limit that this post identifies applies retroactively to all of them, which is why it is being written down rather than filed.

The broader field data is consistent with the choice even while it does not excuse the reporting. A previous post here established that only 16 schema.org types reach 10 million domains, and the concentration of real world usage into a small set of types is the same pattern as the concentration into a single syntax. Building for the common case is reasonable engineering. Describing the common case as the whole case is where it becomes a reporting problem, and the fix is a sentence in the output rather than a rewrite of the parser.

What to check on your own site

The practical version of all this is short, and none of it requires a tool. Open the page source, not the rendered inspector, and search it for three strings. Search for ld+json to find script based markup. Search for itemscope to find microdata. Search for typeof to find RDFa, then check whether a vocab or prefix attribute nearby actually points at schema.org, because as the Wikipedia capture shows, a typeof attribute on its own proves nothing about which vocabulary is in use.

If you find markup in an attribute syntax and you are being scored by anything, the safe assumption is that you are being scored as though it were not there. That is not a reason to rewrite a working site, and it is emphatically not advice to add a second copy of the same graph in JSON-LD, which creates two sources of truth that will disagree within a quarter. It is a reason to know which number is about your page and which is about a parser. If a rewrite is on the table anyway, JSON-LD is the format with the fewest surprises, both because Google recommends it and because every tool in this category reads it.

The check worth more than the syntax audit is the one this site has published on twice: whether the values in the markup appear in the visible text of the page. That is a claim about your document that survives every parser question, and on this same fixture set 70 of 146 markup values were absent from the page publishing them. A crawler's eye view of a URL will show you the text side of that comparison directly. Structure work that is not anchored in the visible document tends to be work that does not survive contact with an AI crawler, which is the argument behind heading ids being useful only when Google can deep link into a section that really exists.

Last, treat structured data as a description of the page rather than a lever on a ranking, whatever the format. Google removed the FAQ rich result documentation and this scanner still scores FAQPage, on the reasoning that the markup describes something true about the document regardless of what any surface does with it today. Applied here, the same reasoning says the syntax question is a tooling question and the content question is the real one. A breadcrumb in RDFa that matches the page is worth more than a graph in JSON-LD that does not, even though only one of them currently scores. The fix for the scoring belongs to us, and it will be recorded on the entity confidence and GEO side of the product where structure claims are already tracked, rather than left in a post.