Nesting Schema: Building Rich Entities for AI Search

Published April 9, 2026 · ClickRadius Institute

Most structured data on the web is a pile of disconnected facts: an Article block here, an Organization block there, an author reduced to a name string, none of them aware the others exist. That is enough to earn a rich snippet, but it is not how machines that reason over entities understand the world. Those systems think in graphs — nodes connected by typed relationships — and the sites that describe themselves as a connected graph give AI engines something a flat pile cannot: the ability to follow a chain from a claim to its author to that author's employer to the organization's credentials. This guide covers nesting, @id referencing and @graph arrays: the mechanics of turning isolated blocks into a coherent entity model.

From strings to things to graphs

When Google introduced the Knowledge Graph in 2012, it framed the shift as moving from "strings to things" — from matching text to understanding real-world entities and their relationships. According to Google's original Knowledge Graph announcement, the goal was to understand entities and the connections between them, not just index words. More than a decade later, generative engines extend that logic: they compose answers by reasoning over entities, and the relationships between entities are as important as the entities themselves.

A relationship is only useful to a machine if it is stated explicitly. If your Article block names an author as plain text and your author's identity lives in a separate, unlinked Person block, a parser has no reliable way to know they are the same person — it is left to guess from a matching name string, exactly the ambiguous "strings" the Knowledge Graph was built to move past. Nesting and referencing are the two tools that replace guessing with declaration.

A flat set of schema blocks tells a machine a list of facts. A connected graph tells it a story: this article, by this person, who works for this organization, which serves this area and holds these credentials. Engines cite sources whose story they can follow.— ClickRadius Institute analysis

Nesting: entities inside entities

Nesting places one entity as the value of another entity's property. It is the right tool when the child entity exists only in the context of its parent and is not reused elsewhere — a PostalAddress inside an Organization, an Offer inside a Product, an author who genuinely appears on just one page. Here an Article nests its author and the author's employer directly:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Choosing a Structural Engineer",
  "author": {
    "@type": "Person",
    "name": "Jane Rivera",
    "jobTitle": "Licensed Structural Engineer",
    "worksFor": {
      "@type": "Organization",
      "name": "Rivera Structural"
    }
  }
}
</script>

This reads cleanly, and for a one-off page it is perfectly correct. The relationships — Article has author Person, Person worksFor Organization — are all explicit. The weakness appears at scale: if Jane writes forty articles and Rivera Structural is your own publishing organization, this pattern redeclares both entities forty times. Any edit — a new job title, a corrected organization URL — must be made in forty places, and the day one copy is updated and thirty-nine are not, you have thirty-nine subtly different Janes and a machine with no way to know which is authoritative.

Referencing with @id: declare once, link everywhere

The fix is to give reusable entities a stable identifier and refer to it. In JSON-LD, @id assigns an entity a unique IRI (typically a URL you control), and any other node can point to it by repeating that @id without redeclaring the entity's properties. You declare Jane once, on her author page, and every article references her:

"author": { "@id": "https://example.com/team/jane-rivera#person" }

Now there is exactly one canonical Jane node. Forty articles reference the same identifier, so a parser understands they share one author, and an edit to her credentials happens in a single place and propagates by reference. This is the same principle behind referencing your canonical Organization node by @id sitewide: declare the hard entity once, point at it from everywhere it is relevant. The rule of thumb is simple.

• Nest an entity when it is local, single-use and meaningless outside its parent — an address, an offer, a page-specific rating.
• Reference by @id when the entity is reused across pages — your Organization, an author, a recurring product line — so its definition never drifts.

The @graph array: a connected model on one page

Once you are referencing entities by @id, the natural container is @graph: a top-level array holding multiple entities in a single JSON-LD block, each with its own identifier, all able to cross-reference one another. Instead of scattering three separate <script> blocks that cannot see each other, you declare a small graph where the WebPage knows about the Article, the Article knows its author, and the author knows its employer:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Rivera Structural",
      "url": "https://example.com/"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-rivera#person",
      "name": "Jane Rivera",
      "jobTitle": "Licensed Structural Engineer",
      "worksFor": { "@id": "https://example.com/#org" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/guides/choosing#article",
      "headline": "Choosing a Structural Engineer",
      "author": { "@id": "https://example.com/team/jane-rivera#person" },
      "publisher": { "@id": "https://example.com/#org" },
      "isPartOf": { "@id": "https://example.com/guides/choosing#webpage" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/guides/choosing#webpage",
      "url": "https://example.com/guides/choosing",
      "about": { "@id": "https://example.com/team/jane-rivera#person" }
    }
  ]
}
</script>

Every node is declared once and linked by identifier. The Organization appears a single time yet is referenced by both the Person's worksFor and the Article's publisher. A parser reading this does not have to infer connections — the connections are the data. This is the structure many mature content-management systems and SEO frameworks emit by default, precisely because it is the cleanest way to express a page's full entity model without duplication.

An @graph is not a stylistic preference. It is the difference between handing a machine four sentences it must correlate and handing it a diagram with the arrows already drawn.— ClickRadius Institute analysis

Why a linked graph beats flat blocks for machines

The comprehension advantage is concrete. Consider what an engine can do with the graph above that it cannot do with four disconnected blocks. It can determine that the article's author is the same entity the page is about, that the author works for the same organization that publishes the article, and — if Jane's Person node also lists her other articles via @id references — that she has a body of work on a topic. That last inference is an authority argument: "this person has published repeatedly and credibly on this subject." No single flat Article block can make it, because the argument lives entirely in the relationships between nodes.

This is why the graph matters more now than it did five years ago. As engines shift from returning links to composing answers and attributing a small set of sources, the clarity of your entity relationships becomes a selection input. Industry trackers estimated that roughly 45% of searches were ending without a click in early 2026, with AI-generated result surfaces expanding rapidly through the period — an environment where being the source whose entity model a machine can fully resolve is a measurable advantage. And industry data suggests a large majority of brands currently have zero presence in AI-generated answers, so a coherent graph is a differentiator, not table stakes.

To be clear about the boundary: structure amplifies substance, it does not manufacture it. According to the Princeton-led GEO study (Aggarwal et al., KDD 2024), the content changes that raised generative-engine visibility by up to roughly 40% were quotations, statistics and cited sources in the writing itself. A flawless entity graph wrapped around thin content is a well-labeled empty box. The compounding pattern is dense, sourced content described by a clean, connected graph — each layer making the other more useful.

Common nesting and referencing mistakes

1. Redeclaring the same entity with drift. Nesting your Organization inline on every page guarantees that, eventually, the copies disagree. Reference one @id instead.
2. Dangling references. Pointing at an @id that is never defined anywhere leaves a parser with a link to nothing. Every referenced identifier must be declared somewhere the engine can reach.
3. Inconsistent identifiers. #org in one block and #organization in another are two different nodes to a machine. Pick a convention and hold it sitewide.
4. Over-nesting single-use data as references. Not everything needs an @id. A page-specific address or offer is fine nested; reserve identifiers for entities that genuinely recur.
5. Graphs that contradict the page. A relationship asserted in schema that the visible content does not support is a consistency failure. The graph must describe the page that actually exists.

Frequently asked questions

Should I nest entities or reference them with @id?

Use nesting for entities that exist only in the context of their parent, and use @id referencing for entities that are reused across pages, such as your Organization or an author. Referencing a stable @id avoids redeclaring the same entity many times, which prevents the values from drifting apart and lets a parser recognize that every mention points to the one canonical node.

What is an @graph array and when should I use it?

An @graph is a top-level array that holds multiple entities in a single JSON-LD block, each with its own @id, so they can cross-reference one another. It is the cleanest way to express a connected model on a page — for example a WebPage that references an Article, which references an author Person, which references the publishing Organization — because every node is declared once and linked by identifier rather than duplicated.

Does a connected entity graph actually help AI engines?

A linked graph gives a machine explicit, unambiguous relationships instead of isolated facts it must guess how to connect. When an author node references the organization it works for and the articles it wrote, an engine can assemble an authority argument that no single flat block conveys. The graph does not replace good content, but it makes the relationships behind your content legible and verifiable.

ClickRadius maps your site's entity graph — organization, people, content and the links between them — and flags drift, dangling references and missing connections as part of its six-category AI-citation score. Get your free AI Readiness Score, or see plans on the pricing page.