Most sites drop one schema block per page and call it done. That works for simple cases, but once you have multiple entities on the same page — an organization, a person, a breadcrumb trail, a webpage — isolated blocks leave connections on the table. The @graph pattern solves that by letting you define all entities in one array and wire them together with @id references.

What @graph Actually Does

In JSON-LD, @graph is a top-level key that holds an array of nodes. Each node gets a unique @id — typically a URL fragment like #organization or #webpage. Other nodes can then reference those IDs directly, so Google can build a connected graph rather than reading a pile of disconnected facts.

Without @graph, a page with both Organization and WebPage markup needs two separate script blocks, and the relationship between them is implicit at best. With @graph, you state it explicitly: this WebPage is isPartOf that WebSite, which is publisher of that Organization. Google prefers explicit over inferred.

Think of it as the difference between handing someone a stack of index cards about your business versus handing them a connected org chart. Same facts, different clarity.

The Basic @graph Structure

Every real deployment I build at Salterra starts from a template like this:

  • A single @context at the top level — not inside each node
  • An array under @graph containing all entity nodes
  • Each node has a unique @id using an absolute URL with a fragment identifier
  • Cross-references use the @id value, not a repeated copy of the entity

The key discipline: define once, reference many times. When publisher, isPartOf, and about all point to the same @id, Google traverses the graph rather than inferring connections.

Nesting vs. Referencing: Which to Use

There is a choice you face with each entity: inline it directly inside a property, or pull it out as a named node in the graph array and reference it by @id. The decision rule is straightforward:

  • Inline nesting — use for small, one-off entities that will not be referenced from anywhere else. A single image attached to an article is a fine candidate for inline nesting.
  • Named nodes — use whenever an entity appears in more than one relationship, needs to be linked to external knowledge bases via sameAs, or needs a stable identity across multiple pages.

If you have a Person who is both the author of an article and a member of the organization, define that person once as a named node and reference the same @id from both properties. Duplication creates inconsistency; references do not. This pattern pays off especially on author pages and team pages where the same individual appears across dozens of articles.

Entities Worth Including in the Connected Graph

  • Organization or LocalBusiness — your base entity, almost always present sitewide
  • WebSite — connects to Organization via publisher; enables the Sitelinks search box potential
  • WebPage or its subtypes (AboutPage, ContactPage, FAQPage) — connects to WebSite via isPartOf
  • BreadcrumbList — connects to WebPage via breadcrumb; rendered as breadcrumb trail in the SERP
  • Person — author entities; particularly valuable for E-E-A-T signals on article and bio pages
  • Article or its subtypes — connects to Person via author and to Organization via publisher
  • ImageObject — when used as a named node, allows multiple entities to reference the same image without duplication; the same named-node approach applies to VideoObject on pages with embedded video

A Real-World Homepage Graph

A homepage for a local service business might include: LocalBusiness, WebSite, WebPage, and BreadcrumbList. All four nodes live in a single @graph array. The relationships work like this:

  • The WebPage references the WebSite via isPartOf
  • The WebSite references the LocalBusiness via publisher
  • The BreadcrumbList is referenced from the WebPage via breadcrumb
  • The WebPage references the LocalBusiness via about — signaling the page is describing the business

That is four entities, multiple explicit relationships, one script block. Clean and connected. This is the same pattern I teach in my SEO University cohorts. The connected graph consistently outperforms four separate blocks because parsers can traverse it without guesswork — and increasingly, Google’s AI-driven surfaces rely on that traversal to understand entity relationships.

The Inner Page Pattern

For non-homepage content like service pages, blog posts, or location pages, the core graph stays the same but the WebPage type changes to match the content: a service page becomes a WebPage with a Service entity linked via mainEntity; a blog post becomes an Article entity with a Person author and the Organization as publisher; an FAQ page uses FAQPage as the WebPage subtype and includes Question/Answer pairs via mainEntity. The connection patterns are consistent even as the entity types vary.

Common Mistakes That Break the Graph

  • Using relative @id values — always use absolute URLs with a fragment identifier
  • Defining the same entity in two separate script blocks rather than as named nodes in one graph — creates duplicates, not connections
  • Forgetting that @context goes at the top level, not inside each node in the array
  • Using @id strings that do not match exactly across references — one trailing slash difference breaks the link silently
  • Nesting a full entity inline in one place and referencing it by @id in another — pick one approach per entity type and use it consistently

Validating a Connected Graph

Run the output through both the Schema.org validator and Google’s Rich Results Test. What you are looking for beyond error-free markup is that related entities are shown as connected in the validator output tree. If WebPage shows isPartOf: WebSite resolved to an actual node (not just a string), the references are working. If a reference shows as an unresolved string, the @id values do not match.

The full validation workflow — including what to check in Search Console after deployment — is covered in the schema markup validation guide.

When @graph Matters Most

For a basic blog post, a standalone Article block is functional. The connected @graph pattern pays its biggest dividends on high-value pages — homepage, about, services, author pages — where multiple entity types overlap and Google is actively building a knowledge model of your brand. The more complex the page and the more relationships it needs to express, the more the graph pattern earns its keep over isolated blocks.

Entity linking goes hand in hand with this. Once your nodes have stable @id values, the next step is anchoring them to the wider web with sameAs. I cover that fully in sameAs and entity linking.

If you want to work through implementing a full connected graph for your site — homepage, inner pages, and the entity sitewide template — my schema markup consulting work starts exactly there.