How this was measured
On 2026-09-23 we fetched the homepage of 78 well-known domains and extracted every <script type="application/ld+json"> block from the response. 61 returned a usable page โ 42 over a direct connection and 19 over a local proxy. Of those 61, 32 contained at least one JSON-LD block.
One caveat governs everything below, so it belongs at the top rather than the bottom: this measures what is present in the server-rendered HTML. A page that injects its structured data with JavaScript will look empty here even though a browser โ and Google, which renders โ would see it. Single-page applications are the obvious case. So when this article says a site "ships none", read it as "none in the initial HTML response", which is a different and weaker claim.
For the sites where we did find markup, that caveat disappears: everything about blocks, @graph, @id and node types is measured on markup that was actually present.
Finding 1: about half ship nothing in the HTML
29 of the 61 homepages contained no JSON-LD block at all. The list includes github.com, youtube.com, wikipedia.org, w3.org, mozilla.org, linkedin.com, x.com, spotify.com, npmjs.com, nodejs.org, kubernetes.io, mit.edu, stanford.edu, khanacademy.org, theguardian.com, slack.com, notion.so, trello.com, tumblr.com, vimeo.com, archive.org, wikimedia.org, digitalocean.com, squareup.com, uber.com, cdc.gov, go.dev, rust-lang.org and developer.mozilla.org.
Some of those are certainly JavaScript-rendered and will have markup in a browser. But wikipedia.org is not a JavaScript application, and neither is w3.org or github.com โ those responses were 119KB, 51KB and 576KB of ordinary server-rendered HTML with no structured data anywhere in them.
The honest conclusion is narrower than "half the web has no structured data" and more useful than nothing: shipping JSON-LD is a choice that a large share of serious sites have not made, and it is not a precondition for ranking.
Finding 2: 14 sites still ship markup for a retired feature
This was the most surprising result. Google retired the sitelinks search box on 21 November 2024 โ the search field that used to appear under a brand's result. The markup that powered it, a SearchAction on the WebSite node, now produces nothing.
Fourteen of the 32 sites with JSON-LD still carry it: cnn.com, forbes.com, walmart.com, atlassian.com, zoom.us, pinterest.com, docker.com, python.org, screamingfrog.co.uk, yoast.com, cloudflare.com, heroku.com, airbnb.com and who.int.
Two of those are SEO tool vendors. That is the interesting part: this is not a case of amateurs leaving stale markup around. It is a case of markup that was correct when it was written, that nothing broke when it stopped mattering, and that no tool flags because it is still valid schema.org. There is no error, no warning, and no rich result โ just a few lines of JSON that no longer do anything.
It is worth being fair about this: leaving it in place costs nothing measurable. We are not suggesting the markup is harmful. The point is that it is invisible dead weight, and the only way to notice is to know the feature was retired โ which is exactly the kind of thing that a site audit will never tell you.
If you are auditing your own markup, this is the check that pays: is any of it aimed at a feature that no longer exists? The schema generator on this site does not emit SearchAction for that reason.
Finding 3: a single block is the norm, and @graph is the minority
Of the 32 sites with markup, 24 used exactly one block, four used two, three used three, and one used four. So the "many small blocks" pattern that our @graph guide warns about is not actually the common shape โ one block is.
Within that single block, however, the split matters. Only 13 of the 32 (41%) use a @graph array. The rest put a single node at the top level.
The 13: gitlab.com, atlassian.com, zoom.us, asana.com, docker.com, twitch.tv, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, stripe.com, netlify.com and heroku.com.
Look at that list again. Four of the thirteen are SEO tool vendors or SEO publications โ Moz, Screaming Frog, Yoast and Search Engine Journal. When the people who build the tooling converge on a pattern, that is usually worth more than a spec reading, and it is consistent with the argument in the @graph guide: one connected graph beats several disconnected blocks.
Finding 4: most markup is boilerplate
Twenty of the 32 sites ship only generic node types โ Organization, WebSite, WebPage, ContactPoint, PostalAddress โ with nothing specific to the page being viewed.
The type frequency across all 32 tells the same story. The most common types were PostalAddress (33 occurrences), Organization (25), Place (24), WebSite (20) and ImageObject (20). BreadcrumbList appeared 6 times. SoftwareApplication 6 times. VideoObject 6 times.
More addresses than web pages. For a homepage that is defensible โ the homepage is where the organization describes itself. But it means that on most of these sites, the structured data says "here is a company" and never says "here is what this particular page is about".
Finding 5: the pattern at full size
stripe.com packs 54 nodes into a single @graph โ by a wide margin the largest we found, and more than the next three sites combined.
That is the @graph pattern doing what it is for. Fifty-four connected nodes with @id references resolve to one coherent description of the site rather than fifty-four independent assertions that must agree with each other by hand.
What we did not find: almost no dangling references
Our @graph guide warns that referencing an @id which is never defined causes the property to be silently ignored. We expected to find this in the wild.
One site out of 32 โ paypal.com, with a single reference to https://www.paypal.com/c2/home#website that no node defines.
Two other things we expected and did not find: zero JSON parse failures across every block we extracted, and no site shipping markup in more than four blocks. Invalid JSON-LD and block sprawl both turn out to be much rarer than the advice would suggest.
This is the second time in two surveys that a widely repeated warning did not appear at all in a sample of this size. That is not an argument for ignoring the warnings โ a dangling reference is still a bug โ but it is an argument for checking how often the thing you are worried about actually happens before you spend a week refactoring.
What to check on your own markup
Is any of it aimed at a retired feature? SearchAction is the one to search for today. Check the markup against the current list of supported rich results rather than against a tutorial you followed in 2023.
Does it say anything about this page? If every page on your site emits the same Organization and WebSite nodes and nothing else, the markup is describing your company and not your content.
Is it one connected graph or several disconnected blocks? Neither is an error. One is easier to keep consistent.
Does every @id you reference exist on the page? Extract the defined @id values and the referenced ones and compare the lists. It takes a minute by eye on a page with under ten nodes.
Limitations
The sample is 61 reachable homepages chosen by hand to span categories โ representative of well-known sites, not of the web. Homepages only: article, product and FAQ markup lives on inner pages and is not measured here.
The server-rendered caveat is the big one. Any JavaScript-injected markup is invisible to this method, so the true rate of sites using structured data is certainly higher than 52%. The findings about @graph, node types and SearchAction are drawn only from markup we actually retrieved, so they are unaffected โ but the headline number is a floor, not a rate.
Finally, this is a single-day snapshot of pages that change constantly.
Reproduce it
The extraction script and the domain list ship with this site and run in about two minutes. It writes the extracted JSON-LD for every domain, so each claim above can be checked against the markup itself rather than our summary of it.
If a row is wrong, the markup settles it. Corrections via the contact page โ and if you know why the sitelinks search box markup is still so widespread two years after retirement, we would like to hear that too.