Structured data: 313 of 615 home pages gave no schema node an @id, and 14 reused one for two things

What does structured data use @id for, and what do its specifications say?

Two published documents govern this and they answer different questions. The JSON-LD 1.1 specification, a W3C Recommendation carrying the date 16 July 2020, defines the keyword: @id is "used to uniquely identify node objects that are being described in the document with IRIs or blank node identifiers". It then defines the thing that points at one: "A node reference is a node object containing only the @id property, which may represent a reference to a node object found elsewhere in the document." Those two sentences are the whole mechanism. One node says what something is, another says this is that same thing, and the identifier is the only string joining them.

The same specification is explicit that the identifier is optional. It states that "JSON-LD does not require all nodes to be identified using @id", and a node without one is a blank node, which is a valid way to describe something you never need to refer to twice. A page carrying no @id anywhere is therefore not malformed. It has given up two abilities: saying that two statements are about one thing, and letting anything outside the page refer to what it described. The vocabulary at schema.org supplies the types and the property names, and says nothing about identifiers, because identity belongs to the syntax layer rather than to the vocabulary.

Google's structured data general guidelines, carrying Last updated 2026-07-10 UTC, answer the second question, which is what happens when you skip it. That page sets out two ways to mark up multiple items on one page: nesting, "when there is one main item, and additional items are grouped under the main item", and individual items, "when each item is a separate block on the same page". For the second case the instruction is direct: "use @id in both the recipe and the video items to specify that the video is about the recipe on the page". Then the consequence: "If you didn't link the items together, Google Search may not know that it can show the video as a Recipe rich result."

That is documented behaviour from the largest consumer of this markup, not an inference. Two things in it matter for what follows. Nesting and identifiers are presented as alternatives that both work, so a page using either one is doing something the documentation sanctions. And the failure mode named for doing neither is not a validation error. It is a feature quietly not firing, which is the same shape as the case where a valid BreadcrumbList scored zero because of its syntax: markup that passes every checker and does not do the job. What follows is a count of which of those two shapes 615 real home pages shipped.

How many home pages carried an @id at all

Of the 1,081 home pages read, 622 carried at least one script element with type application/ld+json and 459 carried none. That is the same split this corpus produced on a smaller run when it counted home pages carrying no structured data in the raw HTML, and the same population that a run in mid September read when it counted microdata against JSON-LD.

Carrying a block is not the same as carrying usable JSON. 17 of the 622 served at least one block that did not parse, and on 7 of those every block failed, so those 7 pages published markup no consumer can read at all: trinityschoolofmedicine.org, unrivaledsportsco.com, bokksu.com, agoda.com, langhamhotels.com, ns.nl and danskebank.dk. That is the defect class counted when this corpus found 117 of 612 home pages with JSON-LD carrying a defect, and it leaves 615 pages with at least one parseable block as the denominator for every figure below.

Those 615 pages held 1,157 parseable blocks and 8,540 typed nodes between them. The median page declared 6 typed nodes. eltiempo.com declared 1,069 across three blocks and theglobeandmail.com spread 113 across 41 separate script elements. 247 pages carried more than one parseable block, and 142 of those 247 defined no @id anywhere. That last figure matters more than it looks, because separate script elements are separate JSON documents: without an identifier there is no syntax available to say that the Organization in the second block is the publisher named in the first.

313 of the 615 carried no @id on any node. The 302 that did held 2,767 @id values between them, of which 1,562 were distinct. Six of those values identify nothing. Three are empty strings, on distefanolandscaping.com, roberthalltaxes.com and villagedentaldtc.com, emitted by a template that wrote the key with no value behind it. Three are bare hostnames with no scheme: oist.jp wrote oist.jp, thuisarts.nl wrote www.thuisarts.nl and theglobeandmail.com wrote theglobeandmail.com. A relative reference resolves against the address the document was served from, so each of those three names a path on the site rather than the site.

This scanner does read the property, in one place. Its entity confidence diagnostic weights an absolute @id on the identity node at 15 points of 100, and the reason recorded beside that number in core/src/config.ts is structural rather than measured: an absolute @id is what makes the webflow-platform fixture's four nodes one linked graph instead of four islands. That weight is a decision somebody made. Nothing published by any answer engine says what an identifier is worth, and this post does not claim otherwise.

545 pages described more than one thing, and 193 linked them by identifier

545 of the 615 pages declared more than one typed node, and that is the population where the question has any force: a page describing exactly one thing needs no identifier to relate it to anything. Sorting those 545 by how the relation is expressed gives three groups, and the split is the main result of this run.

193 pages carried at least one node reference whose @id resolved to a node defined on the same page. That is what Google's guidelines describe as individual items linked by @id, and it is the only one of the three shapes that survives being read out of order, or out of one block rather than another.

311 pages expressed every relation by nesting alone: a typed node sitting inside another typed node's property, with no identifier on either. That is the other pattern Google's page presents as working, so it is not a defect, and it is worth being exact about what it costs rather than overstating it. A nested Organization under a WebPage's publisher property does state the relation, and Google says it reads that. What it does not do is give the organisation a name anything can reuse. The same company nested on forty pages of a site is forty descriptions of possibly forty things, and a consumer merging those pages cannot know it is one company unless the strings happen to match.

41 pages had neither: two or more typed nodes as flat siblings, no identifier and no nesting, so the markup states no relation between them at all. 26 of the 41 are Wix or Squarespace sites, which is the platform pattern a later section returns to. The rest include usa.gov, japan.go.jp, unesco.org, medlineplus.gov, rakuten.co.jp, bankofamerica.com and barclays.co.uk.

Two caveats keep the 352 honest. The first is that 352 pages resolving no reference is not 352 broken pages, because 311 of them are using a documented pattern and the finding is about what that pattern gives up rather than about validity. The second is that this measurement reads one page. The specification requires a consumer to treat every application/ld+json element on an HTML page as one dataset, which is why the blocks on a page are merged here before anything is resolved, but it says nothing about merging across pages, and the site-wide graph a publisher pictures is not something a single fetch can see. A crawler that reads your home page once gets exactly the identifiers that page carried. The practical version for one engine is in the notes on getting cited in Google AI Overviews.

18 pages pointed at an identifier nothing on the page defined

Separate from whether a page links its nodes is the case where it tries and misses. 18 of the 615 carried at least one node reference, an object whose only keys are @id and possibly @type, pointing at an identifier that no node on that page defines. 30 distinct references in all.

14 of the 18 point at the page itself or at a bare fragment of it, so the target could only ever have been defined locally and was not. harvard.edu is the clearest. Its single block is a WebPage carrying a headline, a url, an author, a publisher and three dates, and that node has no @id at all. Its mainEntityOfPage property holds a reference to a WebPage with the @id https://www.harvard.edu/, which nothing on the page defines. The page therefore describes itself twice: once as an unidentified node holding all the properties, once as an identifier holding none, with nothing stating that the two are the same page.

nbcnews.com ships three blocks. One defines a WebPage with the @id https://www.nbcnews.com. Two others are NewsMediaOrganization references pointing at https://www.nbcnews.com/#publisher, which nothing defines, so the publisher of the page is named by a pointer to nothing. sendbird.com carries six references using the bare fragments #identity and #creator, two of them typed Organization, and defines neither. truist.com carries one untyped reference to https://www.truist.com/#Organization and nothing that answers it. cnbc.com, hollywoodreporter.com, aalto.fi, spectator.co.uk, sonarsource.com, citi.com, hdfcbank.com, trueform.agency, grandstreetdental.com and estesvalleyvoice.com make up the rest.

The other 5 are a different case and should not be read as errors. hubspot.com, mistral.ai, acponline.org, smileisleorthodontics.com and citi.com reference identifiers that are the URLs of other pages on the same site. The mistral.ai home page defines its Organization and its WebSite, then references three product-page identifiers of the form https://mistral.ai/products/vibe/#webpage. Under the specification an @id is a global identifier and the node may legitimately be described at that address, so this is linked data working as designed. What remains true is narrower: a consumer reading only the home page receives three identifiers and no properties for any of them. That is the same one-fetch limit behind the finding that 412 of 1,080 home pages named their site in neither source Google reads first, and the same asymmetry as the sameAs measurement, where 85 of 317 organizations named a reference entry and one of those entries had been deleted. A reference is a promise that something is described elsewhere, and whether it is depends on a fetch nobody has made. You can see which identifiers your own page actually delivers with what GPTBot sees.

14 pages gave one @id to two things that disagree

The inverse defect is rarer and harder to defend. 14 of the 615 pages define the same @id on two or more nodes that carry a shared property with different values. It matters because of one sentence in the specification's node object grammar: "The properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node." Two nodes with one identifier are not two things. They are one thing whose description is the union of both.

visitbritain.org is the fullest example. The single URL https://www.visitbritain.org/ is the @id of five node objects on that home page: a GovernmentOrganization with a legal name, a telephone number and a postal address, a WebPage with a description, a WebSite with a name and a publisher, an Organization carrying only a url, and one bare Organization reference. Merged as the specification says, that is one resource which is at once a government body, a web page and a website.

rivm.nl does the same with https://www.rivm.nl/, the @id of an Organization with an address and a parent organisation, of a GovernmentOrganization, and of a WebSite. tec.mx uses https://tec.mx/es for both its Organization and its WebSite. broadinstitute.org uses https://www.broadinstitute.org for a ResearchOrganization with an address and a telephone number, and for a WebPage whose author and publisher are both references to that same identifier, so the page is its own author and publisher. cbsnews.com uses https://www.cbsnews.com/ for a NewsMediaOrganization named CBS News and for a WebPage whose name is written under the key @name, which is not a JSON-LD keyword. The specification's own note covers that case: terms starting with an @ character that are not JSON-LD 1.1 keywords "are ignored unless mapped to an IRI", so the name is discarded and that WebPage contributes only a type to the merge.

Four of the fourteen conflict on a value a reader would notice rather than only on a type. principal.com defines https://www.principal.com/ twice as a Corporation, once with a logo marked representativeOfPage True and once with the same property marked False. therightaccompany.com gives https://therightaccompany.com/#organization two names, which decode from the markup's HTML entities as A&L Heating & Plumbing and A & L Heating and Air, and two different type declarations. roberthalltaxes.com gives its website identifier two publishers, one an organization fragment and one an accountingservice fragment, so the site has two publishers depending on which node you read. confluent.io is the one that reaches outside the site: https://www.wikidata.org/wiki/Q16235208 is the @id of a Thing named Apache Kafka and of a Thing named Stream processing, so a public identifier for one concept is asserted on that page to be two.

The widest case is seota.com, where seventeen nodes claim the identifier https://seota.com/#organization and two of them define it with conflicting url, logo and sameAs values, including one that names a Wikidata item and one that does not. A merge of those two produces an organisation with two logos and two lists of external identities, from a page whose markup validates.

None of this is a validation error and every one of these documents parses, which is why the number is 14 rather than zero. Counting whether a page declares an organisation at all, which is how this corpus found 103 of 385 pages with JSON-LD naming no organization, is the presence question. Whether the declarations on one page agree with each other is the coherence question, and coherence is the part of AI visibility that no validator reports on.

The platform decided the answer more than the publisher did

Sorting the 615 pages by the corpus stratum each hostname is filed under makes the mechanism plain, and it is not effort. All 34 WordPress home pages that carried parseable JSON-LD declared an @id, 33 of the 34 used @graph, and not one of them left its multiple nodes unjoined. That is Yoast and RankMath output, and the pattern is already documented inside this repository: a comment in core/src/entity.ts records that those two plugins emit a flat @graph whose members are joined by @id stubs rather than by nesting, verified against a live page whose four nodes were wired by five such stubs.

At the other end, 53 Wix and Squarespace pages produced 4 with any @id and 2 using @graph, and 36 of their 40 multi-node pages joined nothing. 23 Shopify pages produced 5 with an @id and 1 using @graph. Neither figure says anything about those businesses. It says the template they bought writes a separate block per feature and never assigns identifiers, so a plumber on WordPress ships a joined graph and a plumber on Wix does not, for a reason neither of them chose and neither can see from the front of the site.

The industry strata sit between the two because they mix platforms. SaaS was the strongest, with 57 of its 89 pages carrying an @id and 40 using @graph. Ecommerce was the weakest at 11 of 40 and 2. Government produced 10 of 28, news 30 of 52, and education 21 of 31.

This is the shape this blog keeps reaching from different directions, and the honest reading is not that one platform is better at markup. It is that the largest single input to what a crawler receives is a decision made by a vendor, which is why a per-page score is in large part a score of a template. Lantad's own two readings of one page can disagree for a related reason, which a perfect schema score and a zero measured on the same page sets out in detail.

What this measurement does not show

No AI crawler fetched anything in this run. Every request came from LantadBot, so nothing here is evidence about what GPTBot, ClaudeBot or PerplexityBot does with an identifier, and none of the vendors behind those tokens documents it. Google's guidelines document a Search consequence for unlinked items, which is a statement about rich results and not about generative answers. Anyone saying that adding an @id produces a citation is making a claim nobody outside those engines can currently test.

This scanner does not grade what this post measured, and that is worth stating plainly rather than leaving a reader to find out. The composite score's schema sub-score is 10 points of 100, set in core/src/config.ts, and the function behind it parses each block, flattens arrays and @graph, and checks that nodes carry a type and the properties their type requires. It never reads an @id. So it cannot see a reference that resolves nowhere, and it cannot see one identifier asserted of two things. The Entity Confidence diagnostic does read the property, at 15 points of its own 100, but that diagnostic never feeds the composite. All 14 conflicting-identifier pages and all 18 broken-reference pages therefore score exactly as they would without the defect, and the rules that are enforced are set out in the methodology. The measurement exists because it was worth taking, not because the product acts on it today.

Only the home page was read on each host, once, from one network location, on one date. A site that assigns identifiers on its article template and not on its home page counts here as carrying none, so every count of an absence is a ceiling on what that site publishes rather than proof of what it does not. No JavaScript was executed, which is the point rather than a shortcut, because the question is what a crawler reading delivered bytes is handed. A page that injects its graph from a script counts here as having none, and this run cannot say how many of the 459 pages with no JSON-LD have some once their bundle has run.

The corpus is an editorial sampling frame assembled for platform and industry coverage rather than a random draw of the web, so every rate supports a statement about these 1,419 hostnames and nothing wider, a constraint set out at length in the crawlability study. The 244 hosts whose home page did not answer 200 with HTML are not missing at random, since a server that refuses an unknown crawler is likelier to refuse other automation, so the 1,081 read here lean towards sites that are open to being read. A further 30 hosts never returned a robots.txt status and were not asked for a home page in this run at all, and 64 disallowed LantadBot at the root. Platform-specific citation notes for one engine are in the guide to getting cited by Perplexity.