Structured data: 141 of 382 home pages carried none in the raw HTML

How much structured data is on a home page?

Of the 392 hostnames asked, 382 answered HTTP 200. The other ten are recorded rather than dropped quietly: five returned HTTP 202, two returned 403, one returned 404, one returned 503, and one never completed inside a twenty second timeout. The five 202 responses are the shape we have seen before on this corpus, a short body that redirects to a challenge rather than a page, and they are excluded from every figure below because there is no document in them to parse.

Across the 382 that did answer, 241 carried at least one JSON-LD block and 141 carried none. Those 241 sites shipped 442 blocks in total, and the distribution is flatter than the single figure suggests: 124 sites ship exactly one block, 57 ship two, 44 ship three, 11 ship four, three ship five, and two sites ship six and seven respectively. One block is the mode and the median, which matters because a single block is usually a platform's generated organisation stanza rather than anything a person wrote about this particular business.

The 141 with nothing at all are not a uniform group either, and the next section but one takes them apart by platform. What can be said here is narrow and worth keeping narrow: 141 home pages returned bytes containing no machine readable description of what the site is, whom it belongs to, or what it sells. A reader arriving at those pages learns all three in a second. A parser learns none of it from markup and has to fall back to reading the prose, which is the layer prose parity measures and the layer that carries the most weight in this scanner's own grade.

This is a bigger frame than we have used for this question before. The earlier structured data work on this blog ran on five stored captures: three of five captured pages carried JSON-LD and one held 96 of the 102 nodes, and the follow up found that 70 of 146 markup values were not on the page at all. Five pages can show a mechanism. They cannot say how common anything is. 382 still cannot say what the web does, but it can say what these 382 did on this day.

Eight blocks that a JSON parser throws away

Eight of the 442 blocks failed to parse, one on each of eight different sites. We checked every one of them by hand afterwards rather than trusting the count, because a regular expression that reads a script element can truncate a block and manufacture a failure that is not there. None of the eight was truncated: each ended on a closing brace or bracket, so each is the whole block the site shipped, and each is invalid on its own terms.

Four failed on an unescaped line break inside a string value. A JSON string cannot contain a raw newline, and in every one of the four a human had typed a value across two lines in a content management field: opening hours at fullsteamcrossfit.com written as a day per line, a business name at westashevillefamilydentistry.com with a trailing newline before the closing quote, a customer quotation at elevatedestateplanning.law, and a description at unrivaledsportsco.com. Each is a single invisible character and each destroys the whole block.

Three failed because the block contains a comment. JSON has no comments, and a template that was written as JavaScript and pasted into a script element keeps them. websiteportland.com carries a telephone number followed by a double slash and the note main practice phone number. trinityschoolofmedicine.org wraps its entire EducationalOrganization block in slash star SCHEMA CODE star slash at the top and END SCHEMA CODE at the bottom, so a 3,209 byte block fails on its first character. bokksu.com is the one worth reading twice, because the comment is an instruction that was never carried out: the value of the telephone field is the literal string Service Phone Number, followed by a comment reading please fill in the service phone number. The eighth, at downtownnotarytoronto.com, closes its object early and then continues with an aggregateRating, which leaves content after the end of the JSON document.

The eight are a small share of 442 and they are not the point on their own. The point is that nothing told these eight sites. A rich result test reports on the page you paste into it, one page at a time, and none of these owners had a reason to paste. Google's introduction to structured data is clear that malformed markup is ignored, and ignoring is silent by construction. This is the same failure class as the syntax finding on our own captures, where a valid BreadcrumbList scored zero because of its syntax: the markup is present, a person believes it is working, and the machine sees nothing.

Which types the markup actually declares

Across the 382 responses the parsed blocks declare 45 distinct values in the @type field. The head of that list is scaffolding. WebSite appears on 188 sites, Organization on 150, WebPage on 81, BreadcrumbList on 59 and ImageObject on 43. These describe that a website exists, that it belongs to an organisation, and that this page sits inside it. All of that is true and almost none of it is specific.

Counting the other way is more revealing. Taking WebSite, Organization, WebPage, BreadcrumbList, SiteNavigationElement, ImageObject, CollectionPage, WebPageElement, SearchAction and ListItem as site scaffolding, 108 of the 241 sites with markup declare nothing outside that set, three declare no @type at all, and 130 declare at least one type that says something about the business rather than about the page furniture. So of the original 382, 130 carry markup that describes the subject, and that is the number to hold rather than the 241.

The tail is long and thin. Of the 45 types, 23 appear on exactly one site each, among them LegalService, MassageTherapist, EducationalOrganization, Dataset, ProductGroup and Brand. LocalBusiness reaches 55 sites, SoftwareApplication 27 and FAQPage 26, which is its own small story given that the FAQ rich result is gone and FAQPage is still scored by tools that never stopped looking for it. Article appears on seven sites and Product on five.

Two entries in that list of 45 are not what they look like. One site, gldn.com, declares the type Website. The schema.org type is WebSite with a capital S, which resolves, while the lowercase spelling returns HTTP 404 from the vocabulary, checked on the same day. The identifier is a URL and URLs are case sensitive, so that block parses as perfectly valid JSON and describes a type that does not exist. Separately, SiteNavigationElement appears 43 times in the corpus and on exactly one site, highlandscurrent.com, which emits one node per menu item. That is the same concentration effect the five page study found, where one page contributed 96 of 102 nodes and 39 of them described a navigation menu. A count of nodes measures enthusiasm. It does not measure description. The external picture agrees on the shape: only 16 schema.org types reach 10 million domains out of a vocabulary of 958.

The platform decides this more than the industry does

The corpus frame is grouped into ten categories by the kind of thing the site is and the stack it runs on, and splitting the result that way separates the sites almost perfectly. Hosted site builders emit markup by default and their customers inherit it: 53 of 54 Wix and Squarespace home pages carried JSON-LD, 35 of 37 WordPress small business sites did, and 28 of 30 local media sites did. At the other end, 8 of 31 documentation sites, 10 of 30 Framer sites, 12 of 41 Bubble and no-code sites, and 20 of 42 Webflow sites carried any.

That ordering is not about how sophisticated the owners are. It is about who writes the head of the document. On Wix and Squarespace the platform generates an Organization and a WebSite stanza whether or not the owner has ever heard of schema.org, which is the same mechanism we found when Squarespace generated a robots.txt naming 26 AI crawlers and blocking none and when Wix wrote four crawler names of which none belonged to an AI company. The platform's default is the site's behaviour for most sites, in both directions. Where the platform writes nothing, as on Webflow, where 20 of 40 robots.txt files held no rule at all, the median site ships nothing.

One result in that table needs stating plainly rather than being left to imply something it does not. Twenty three of the 34 Shopify stores carried JSON-LD, and none of the 34 declared a Product on the home page. That is expected and correct: a storefront home page is a collection, and Product markup belongs on product pages, which this measurement never requested. It is a reminder of the frame's edge rather than a finding about Shopify, and the thing worth knowing about those stores is on a different path anyway, since 38 Shopify stores served 1,112 products as open JSON at an address no robots.txt file mentioned.

The documentation and no-code end of the table carries the opposite caution. A low rate there is not proof that those pages are unreadable, because markup is one input and prose is another, and a docs site that ships clean server rendered text may be read perfectly well with no JSON-LD anywhere. What the absence does remove is the explicit statement of identity: with no markup, every claim about who publishes the page has to be inferred from the words, and inference is where entity confidence is won or lost.

What this measurement does not say

Five limits, and they are larger than the finding in places. First, home pages only. Every figure above describes one URL per hostname, and the pages that carry a site's richest markup are usually its product, article and location pages. Nothing here counts those.

Second, no JavaScript. We executed none, which is the point of the measurement, but it means the 141 with no markup are 141 sites with no markup in the raw response, not 141 sites with no markup. Some unknown share of them inject JSON-LD through a tag manager or a framework after load. We tried to measure that split this run and could not: the headless browser in this environment cannot reach the network, so the comparison between raw and rendered is missing and we are not going to estimate it. It matters, because markup that only exists after rendering reaches only the crawlers that render, and what those are is not documented by seven of nine operators. Something similar is already on record at the prose layer, where text in hydration JSON scored the same as no text at all.

Third, presence is not correctness. A block that parses can still describe the wrong thing, contain values that appear nowhere on the page, or name a type that does not exist, and gldn.com shows the last of those inside an otherwise valid document. Parsing is the floor, not the bar.

Fourth, no crawler was observed. We read no access log, and no figure in this post reports what GPTBot, ClaudeBot or any other AI crawler did with these pages. Whether markup moves citations is a separate question with its own evidence, and the most careful answer we have found put structured data third of six pillars in a 1,100 URL citation audit rather than first.

Fifth, one request each, on one day, from one network location. A site behind a CDN can answer differently to a different address, and two of the 392 returned 403 to this one. If you want the same reading for your own pages, the scanner will show you what a crawler receives before JavaScript runs, and the methodology page sets out how the score treats what it finds. The cheapest version takes a minute with no tool at all: open your home page's source, search it for ld+json, and paste each block you find into any JSON parser. Eight sites in this sample would have learned something.