Website schema markup: 158 of 338 sites declared both nodes and connected neither

What does website schema markup actually declare?

The WebSite type is defined by schema.org as "a set of related web pages and other items typically served from a single web domain and accessible via URLs". That is a definition about pages and a domain. It says nothing about ownership, and it does not have to, because ownership is carried by a separate property. The schema.org WebSite page lists publisher among the properties inherited from CreativeWork, with an expected type of Organization or Person.

The description schema.org gives that property is worth reading literally. It is "The publisher of the article in question", which is legacy wording from the type it was defined on, and it appears unchanged on a type that is not an article. The vocabulary is telling you to name a publisher while describing a page you are not marking up. That is a small thing, and it is the sort of small thing that explains why a property goes unused.

Across the 613 corpus home pages that held at least one JSON-LD block Lantad could parse on 9 October 2026, 407 declared a WebSite node, 427 nodes between them. url was the most widely declared property, on 422 of the 427. name followed on 382, and the 45 nodes without one are the population behind an earlier finding that 412 of 1,080 home pages named their site in neither source Google reads first. potentialAction appeared on 219, which is the sitelinks search box Lantad counted when it found robots.txt closing 57 of 224 declared search endpoints. publisher appeared on 185, which leaves it absent from 242. An @id, the identifier that makes a node referenceable by anything else in the document, appeared on 203, slightly under half.

That ordering is the finding in miniature. The two properties almost everybody sets are the two that Google's site names documentation asks for. That page, last updated 10 December 2025, says to add WebSite structured data to your home page and names exactly two required properties, name and url, with alternateName as an optional recommendation. It does not mention publisher at any point. The properties that get set are the properties somebody was told to set, which is not a criticism of anyone and is the most reliable predictor in this whole corpus.

338 sites described a site and a company, and 158 joined them with nothing

A WebSite node on its own cannot be unconnected from anything, so the count that matters is over pages carrying both halves. 510 of the 613 parseable pages declared an organisation node, counting Organization and the subtypes sites actually use: Corporation, LocalBusiness, NewsMediaOrganization, GovernmentOrganization, MedicalOrganization and the rest. 338 pages declared both a WebSite node and one of those.

On 180 of the 338, some property joined them. On 158, nothing did. The test was deliberately generous: a join counted if the WebSite node pointed at the organisation through publisher, author, creator, copyrightHolder, provider, sourceOrganization or parentOrganization, whether by reference or with the organisation written inline, and it also counted if the organisation pointed back at the WebSite through mainEntityOfPage, subjectOf or owns. Any one of ten properties in either direction was enough, and 158 pages used none of them.

The shape of a disconnected pair is easier to see than to describe. fieldguide.io, a SaaS marketing site, served a WebSite node named Fieldguide with a url of https://www.fieldguide.com, and an Organization node named Fieldguide with the same url. Two nodes, the same name twice, the same url twice, no @id on either and no property between them. A reader infers the obvious. A parser is handed two separate things that happen to share a string.

downtownnotarytoronto.com, built on one of the hosted builders, went further and emitted three: a WebSite node with a name, an Organization node carrying no properties at all, and a LocalBusiness node carrying the name again. None of the three had an identifier, so none of them could have referenced another even if the markup had wanted to. This is the condition an earlier run found behind the @id numbers, where 313 of 615 home pages gave no node an identifier of any kind. A node without an @id is not just unlabelled. It is unaddressable, and a graph of unaddressable nodes is a list.

None of this is a defect the way a missing required property is a defect. Lantad has published what markup values that are absent from the page look like, and what an organisation node too incomplete to identify a publisher looks like, and both of those are failures against a stated rule. This one breaks no rule. It is a choice not to state something, repeated 158 times.

How the 180 that did it made the connection

Of the ten properties the test accepted, one carried almost all of the traffic. 157 of the 180 joins were a publisher property on the WebSite node holding a reference to an organisation node's @id. A further 21 wrote the organisation inline inside publisher, as a full object rather than a pointer. One used sourceOrganization inline. One had the organisation point back at the site with subjectOf. The other seven properties were used by nobody.

The dominant pattern is the one JSON-LD 1.1, a W3C Recommendation since 16 July 2020, calls a node reference: "a node object containing only the @id property, which may represent a reference to a node object found elsewhere in the document". That is the mechanism by which a flat list of nodes becomes a graph, and it is worth being precise that this measurement used the specification's own definition rather than a looser one. An object whose only key is @id was counted as a reference. An object with other keys was counted as a node written in place.

Where references were used at all, they worked. 190 of the 613 sites emitted at least one, 1,362 in total, and 1,336 of those resolved to a node carrying that identifier in the same document. 26 pointed at an identifier no node in the document declared, and all 26 came from just 8 sites. acponline.org and hubspot.com both referenced product nodes that were not in the markup they served. grandstreetdental.com referenced its own website and organisation identifiers while declaring neither.

That ratio is the honest counterweight to the headline. Broken references are rare, about one in fifty, and concentrated in a handful of sites. The common condition is not a reference that fails. It is no reference at all. The failure mode here is omission, and omission is invisible to every validator anybody runs, which is precisely why it survives on 158 home pages.

WordPress wired 24 of 26, the hosted builders 2 of 40

Split the 338 by how the site was built and the variation stops looking like a judgement call. 26 of the WordPress small-business sites in the corpus declared both nodes, and 24 of them were joined. Among the Wix and Squarespace sites, 40 declared both and 2 were joined. That is 92 percent against 5 percent, on the same property, in the same format, for the same purpose.

Nobody on either side made a decision about publisher. On WordPress the dominant SEO plugins emit a single connected graph as their output, with an organisation node, a website node and a reference from one to the other, because that is what the plugin was written to do. The hosted builders emit the nodes their templates carry, separately, and offer no place to express a relationship between them. The author's intent is absent from both numbers. appalshop.org, a WordPress site, served an Organization node identified as https://appalshop.org/#organization and a WebSite node whose publisher held exactly that identifier. Its owner almost certainly never saw either string.

The pattern holds across the other strata and reads as a platform story rather than a sector one. The single page application startups joined 16 of 19, the local media sites 17 of 20, Webflow 6 of 7, and Framer 2 of 4. Shopify storefronts joined 3 of 16, and the broader ecommerce stratum 2 of 22, which are the two worst results in the corpus after the hosted builders. Lantad publishes a Shopify guide that covers what the platform does and does not put in front of a crawler, and this belongs on that list.

The lesson is not that one platform is better at schema. It is that on most of the web this property is set by whatever generated the markup, so asking site owners to care about it is aimed at the wrong party. The same conclusion arrived from a different direction when a run counted main landmarks and found 53 of 54 Wix and Squarespace pages declaring one against 7 of 42 built on no-code tools. On that signal the hosted builders were the ones getting it right. A platform is not uniformly good or bad. It emits what it emits, and which signals that covers is close to arbitrary from the owner's point of view.

Eight WebSite nodes named a domain the page was not served from

One other thing fell out of reading 427 WebSite nodes. Eight of them declared a url whose host was not the host that served the page, and was not a subdomain of it either. These are not typos. They are migrations, caught mid-move.

spectator.co.uk served a WebSite node named The Spectator with a url of https://spectator.com/, an @id of https://spectator.com/#website, and a publisher reference to https://spectator.com/#organization, which the same document declared. The graph is internally perfect and every identifier in it describes a different domain from the one that answered the request. skyscanner.net served a node named Skyscanner US pointing at skyscanner.com. tewhatuora.govt.nz, a health service mid-rebrand, pointed at healthnz.govt.nz. Two local news sites, highlandscurrent.com and nowhabersham.com, pointed at highlandscurrent.org and nowgeorgia.com. Two startups, dollyglot.com and societies.io, pointed at dotwave.ai and societies.ai.

Six of the eight also carried an organisation node, and four of those six joined it correctly. So the most carefully constructed graphs in this group are the ones describing the wrong domain, which is what you would expect: a site with the discipline to wire publisher by @id is a site using a tool that generates identifiers from a configured canonical domain, and changing that domain changes every identifier at once. Discipline does not protect you here. It propagates the error.

Whether that matters depends on something this measurement cannot see, which is how any given consumer treats a url that disagrees with the host it fetched. A canonical tag pointing elsewhere is a documented instruction with documented handling, and 63 of 1,069 home pages sent one naming a URL the page was not served at. A WebSite node's url is not an instruction. It is an assertion inside a description, and none of the crawler vendors Lantad tracks documents what it does when that assertion is wrong. If you have moved domains, it is worth checking what your old host still says it is.

What this measurement does not show

The number this post cannot give you is the one you want, which is what the missing join costs. Lantad did not measure that and has no way to, so here is what is actually known.

No engine documents reading the property. Google's Organization structured data page, last updated 8 September 2026, recommends placing the markup on your home page or a single page describing the organisation, and says you do not need it on every page. It does not mention @id, node references, or connecting the organisation to anything else. The site names page does not mention publisher. Those are the two pages that tell a site owner to emit these two nodes, and between them they never ask for a relationship. A reader following Google's documentation exactly would land in the 158, correctly.

So this is not a post saying 158 sites made a mistake. It is a post saying that a document describing a site and a company, with nothing stating they are the same concern, is a weaker description than one that states it, and that the weakness is undetectable by the tools people run. Whether an AI crawler or an answer engine uses the link is not established, and anyone who tells you the number is guessing. Lantad publishes what its own scan sample does and does not support for the same reason. What entity confidence rests on is whether a machine can tell which real-world thing a page is about, and an explicit reference is better evidence than two strings that match.

The limits of the method are worth stating plainly, in the terms our methodology sets out. One page per site, the home page only, so a site that wires its graph on an interior template and not the home page reads here as unconnected. One request each from one network location, so a site serving different markup elsewhere or to a different client is not captured. No JavaScript executed, which matters more than it sounds: a previous run found 27 of 404 pages gained structured data only when a browser ran them, so some of the 158 may join their nodes in markup a crawler reading raw bytes never sees. The 613 denominator is sites with parseable JSON-LD, not all sites, and 15 blocks on 15 sites failed to parse as JSON and were excluded rather than guessed at.

Finally, the generous test cuts both ways. Accepting any of ten properties in either direction means 180 is an upper bound on connectedness, not a strict count of correct publisher usage. By the narrow reading, only 157 sites did the thing the vocabulary and the common tooling actually intend. Both numbers are in this post because the difference between them is a judgement, and the judgement is the reader's.