Why Standard JSON-LD Alone Doesn't Improve AI Citations

JSON-LD adoption is up. 41% of pages now include it, according to the Web Almanac 2024 — up from 34% in 2022. If adding schema markup were sufficient to improve AI citation visibility, more sites would already be seeing the benefit. Research published in 2026 explains why the standard implementation falls short and what the distinction is.

Quick Navigation

• What the Research Found
• The Problem with Standard JSON-LD
• What Dereferenceable Entity Pages Are
• The @id Property: Making Your Entity Fetchable
• What the 29.6% Gain Actually Requires
• How Brass-SEO Surfaces Entity Signal Gaps
• Frequently Asked Questions

---

What the Research Found

Brass-SEO cites Volpini et al. (2026) as the primary source for the finding that complicates the standard "add schema markup" advice.

The research tested whether structured data — specifically JSON-LD — improved how accurately AI retrieval systems cited and attributed content. The finding: standard JSON-LD implementations did not produce the expected AI retrieval improvements. Pages with schema markup performed similarly to pages without it on AI citation accuracy.

The differentiating factor was a specific implementation pattern: dereferenceable linked data with properly implemented @id values. Pages with this pattern showed a 29.6% improvement in RAG (Retrieval-Augmented Generation) accuracy compared to standard JSON-LD.

The implication is precise. Markup quantity doesn't determine AI citation eligibility. Entity clarity does. And entity clarity requires something most JSON-LD implementations don't include.

The Problem with Standard JSON-LD

Brass-SEO references the Web Almanac 2024 and the schema.org specification to explain what "standard" implementation typically looks like — and where it falls short.

Schema.org defines over 900 types, maintained by Google, Microsoft, Yahoo, and Yandex. JSON-LD is the format all four recommend. A standard Organization JSON-LD block includes the type, name, URL, and perhaps some additional properties. This is better than no structured data. It communicates entity type and basic attributes.

What it doesn't do: create a resolvable identity for the entity.

When an AI retrieval system encounters a page with an Organization schema block, it reads the properties. If it then encounters a mention of that organization somewhere else — in a news article, another page, a different document — it has no reliable way to confirm those references point to the same entity. The markup describes the entity on this page. It doesn't anchor the entity in a web of interconnected identifiers.

That anchoring — the thing that makes an entity unambiguous across sources — is what dereferenceable linked data provides.

What Dereferenceable Entity Pages Are

Brass-SEO draws on the JSON-LD 1.1 W3C Recommendation to define what makes an entity "dereferenceable."

In linked data terms, a dereferenceable entity is one with an @id value that is a URL — a URL you can actually fetch and receive information about the entity in return. When an AI retrieval system or knowledge graph crawler encounters an entity with a dereferenceable @id, it can follow that URL and retrieve a complete, machine-readable description of the entity.

This is the difference between saying "I am an organization" and saying "I am this organization, and you can learn about me at this URL, and that URL is the same entity as this Wikidata item, this LinkedIn profile, and this other authoritative source."

The W3C JSON-LD 1.1 specification defines @id as the mechanism for expressing this: the value should be an IRI (essentially, a URL) that identifies the entity. When the @id URL is fetchable and returns structured data, it's dereferenceable. Most JSON-LD implementations use a URL for @id but don't ensure that URL returns entity-specific structured data.

The @id Property: Making Your Entity Fetchable

Brass-SEO treats the @id implementation as the practical pivot between standard JSON-LD and enhanced entity pages.

A minimal but functional implementation:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://brass-seo.com/#organization",
  "name": "Brass-SEO",
  "url": "https://brass-seo.com",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q[item-id]",
    "https://www.linkedin.com/company/brass-seo",
    "https://bsky.app/profile/brass-seo.com"
  ]
}

The @id value — https://brass-seo.com/#organization — is a fragment identifier that distinguishes the entity (the organization) from the page (the homepage). The sameAs values corroborate the identity: this entity is the same as that Wikidata item, that LinkedIn profile.

When a retrieval system encounters a mention of Brass-SEO in another document, it can use the @id and sameAs chain to resolve that mention to the same entity it encountered on the homepage. Without the @id, each encounter is treated as potentially a different entity. With it, the entity has a canonical identifier across sources.

The Wikidata item in the sameAs chain matters most. Wikidata is a primary data source for Google's Knowledge Graph (per Vrandečić and Krötzsch, CACM 2014). An entity that appears in both the @id chain and Wikidata is confirmed from two independent machine-readable sources. The entity SEO post covers the Wikidata piece in detail.

What the 29.6% Gain Actually Requires

Brass-SEO cites the specific conditions in Volpini et al. (2026) to avoid the overgeneralization that "any structured data improves AI citations."

The 29.6% RAG accuracy improvement was observed specifically for enhanced entity pages with dereferenceable linked data — pages where:

1. The @id value is a URL that returns structured data when fetched
2. The entity is corroborated by at least one external authoritative source (Wikidata, Wikipedia, or similar) via sameAs
3. The entity naming is consistent across the page and across the corroborating sources

Standard JSON-LD implementations typically satisfy none of these three conditions. The @id is present but points to a homepage that returns HTML, not structured entity data. The sameAs chain is absent or incomplete. The entity naming varies (the company is called "Brass SEO" in one place, "Brass-SEO" in another, "brass-seo.com" in a third).

The consistency requirement matters. AI retrieval systems trying to disambiguate entities do so by pattern-matching mentions across sources. Inconsistent naming forces the system to treat mentions as potentially different entities. That ambiguity degrades citation accuracy — the 29.6% improvement measures exactly what gets recovered when ambiguity is removed.

For the full structured data research literature, the Brass-SEO Structured Data research topic maintains primary sources including the Web Almanac 2024 JSON-LD adoption data, the schema.org specifications, and the Volpini et al. paper.

How Brass-SEO Surfaces Entity Signal Gaps

Brass-SEO's AI Citability analysis checks for the entity signals that separate standard JSON-LD from enhanced entity pages: @id implementation, sameAs coverage, and entity naming consistency. The Brass-SEO Generative Engine Optimization guide covers the full AI citation optimization picture.

The schema markup for AI search post covers the implementation patterns in more detail. The Brass-SEO Research Index links to the primary literature cited here, including the Volpini et al. research and the Web Almanac 2024 structured data chapter.

---

Frequently Asked Questions

Does adding JSON-LD improve AI citation visibility?

Not reliably, based on research by Volpini et al. (2026). Standard JSON-LD implementations — which include entity type and basic properties but lack a dereferenceable @id and sameAs corroboration — did not produce significant AI retrieval improvements in the study. Enhanced entity pages with dereferenceable linked data showed a 29.6% RAG accuracy improvement. The difference is entity clarity, not markup quantity.

What is a dereferenceable entity page?

A dereferenceable entity page is one where the @id value in JSON-LD is a URL that can be fetched and returns structured data about the entity. This allows retrieval systems to follow the @id URL and find a machine-readable entity description, rather than just reading the entity properties on one page. The W3C JSON-LD 1.1 Recommendation defines @id as the mechanism for expressing this identity.

How much JSON-LD is on the web currently?

41% of pages include JSON-LD, according to the Web Almanac 2024 — up from 34% in 2022. Schema.org defines over 900 types and is maintained by Google, Microsoft, Yahoo, and Yandex. Despite high adoption, most implementations lack the dereferenceable @id and sameAs corroboration that produces AI retrieval improvements.

What is the @id property in JSON-LD?

The @id property assigns a canonical URL identifier to an entity. In schema.org structured data, it distinguishes the entity (your organization) from the page (your homepage). A common pattern uses a fragment identifier: "@id": "https://example.com/#organization". When this URL returns structured data when fetched, the entity is dereferenceable — it can be looked up by a crawler or retrieval system seeking information about that specific entity.

What is the sameAs property and why does it help?

The sameAs property lists other authoritative URLs where the same entity appears — Wikidata items, Wikipedia articles, LinkedIn pages, Crunchbase profiles. Each sameAs URL is a corroboration signal: this entity on my page is the same entity as this Wikidata item. Retrieval systems encountering a mention of your organization elsewhere on the web can use the sameAs chain to confirm they're referencing the same entity. Wikidata is the most valuable sameAs target because it's a primary data source for Google's Knowledge Graph.