Nesting, Relationships, and the @id Pattern

Every schema block you have written so far, Organization, Person, LocalBusiness, Product, Service, FAQ, HowTo, is an island. Each describes something, but without explicit connections between them, Google has to infer the relationships. And as we established in Session 2.1, inference is probabilistic. Declaration is deterministic.

This session introduces the @id pattern, nesting, and the @graph construct. Together, they turn isolated schema blocks into a connected entity graph. This is where structured data becomes genuinely powerful.

The Problem With Isolated Schema

Consider a website with three pages, each containing its own schema block:

• Homepage: Organization schema for "Acme Corp"
• About page: Person schema for "Jane Smith"
• Service page: Service schema for "Automation Consulting"

Without connections, Google sees three separate data objects. It may or may not realize that Jane Smith founded Acme Corp, or that Acme Corp provides Automation Consulting. With @id references, these three objects become a single, connected graph that explicitly describes the relationships.

How @id Works

The @id property assigns a unique identifier to a schema object. This identifier is a URI (usually your website URL with a hash fragment). When another schema object references that same @id, Google knows they are talking about the same entity.

// On the homepage
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.acmecorp.com/#organization",
  "name": "Acme Corp",
  "founder": {
    "@type": "Person",
    "@id": "https://www.acmecorp.com/#person-jane-smith"
  }
}

// On the about page
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.acmecorp.com/#person-jane-smith",
  "name": "Jane Smith",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://www.acmecorp.com/#organization"
  }
}

The @id values are arbitrary strings, but the convention is https://yourdomain.com/#identifier. The hash fragment ensures the URI is unique and does not conflict with actual page URLs. Common patterns:

Nesting vs. Referencing

There are two ways to connect schema objects: nesting (inline) and referencing (via @id).

Nesting means putting the full object inside another:

"founder": {
  "@type": "Person",
  "name": "Jane Smith",
  "jobTitle": "CEO"
}

Referencing means pointing to the object using @id:

"founder": {
  "@type": "Person",
  "@id": "https://www.acmecorp.com/#person-jane-smith"
}

Use nesting when the referenced entity has only a few properties and does not appear elsewhere. Use @id referencing when the entity has its own dedicated schema block (on the same or different page) with full details. The @id approach is cleaner and avoids duplicating data.

The @graph Construct

Instead of separate <script> tags for each schema block, you can use @graph to put them all in one block:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.acmecorp.com/#organization",
      "name": "Acme Corp",
      "url": "https://www.acmecorp.com",
      "founder": { "@id": "https://www.acmecorp.com/#person-jane-smith" }
    },
    {
      "@type": "Person",
      "@id": "https://www.acmecorp.com/#person-jane-smith",
      "name": "Jane Smith",
      "jobTitle": "CEO",
      "worksFor": { "@id": "https://www.acmecorp.com/#organization" }
    },
    {
      "@type": "WebSite",
      "@id": "https://www.acmecorp.com/#website",
      "name": "Acme Corp",
      "url": "https://www.acmecorp.com",
      "publisher": { "@id": "https://www.acmecorp.com/#organization" }
    }
  ]
}
</script>

The @graph approach has two advantages: all entities share a single @context declaration, and the relationships between them are visually clear in one block. Either approach (separate scripts or @graph) is valid. Google processes both identically.

Cross-Page @id References

The @id pattern works across pages. Your homepage defines the Organization with @id: "https://example.com/#organization". Your blog post references that same @id in its Article schema's publisher property. Google crawls both pages and connects the dots.

This is why consistent @id values are critical. If your homepage uses #organization and your blog post uses #org, Google cannot connect them. Establish your @id conventions early and document them.

Common Relationship Properties

Further Reading

• W3C: JSON-LD Node Identifiers (@id)
• W3C: JSON-LD Named Graphs (@graph)
• Google: Combining Multiple Schema Entities
• Schema.org: Data Model Documentation