Nested JSON-LD structured data done correctly

What nesting actually means

A JSON-LD object describes one thing, a webpage, an article, an organization, but real pages describe several connected things. A blog post is a BlogPosting that belongs to a WebSite and is written by a Person who works for an Organization. Nesting is how you express that relationship inside one JSON-LD structure or across a few that share an identity.

The structured data overview covers the type system. This page is about joining multiple types together without producing markup that contradicts itself.

The two ways to combine

You can nest directly, putting one object inside another:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How DNS propagation works",
  "author": {
    "@type": "Person",
    "name": "Sacha Ede",
    "worksFor": {
      "@type": "Organization",
      "name": "CSMBAC"
    }
  }
}

Or you can use @graph, which lists several top-level nodes in one document, useful when a page legitimately carries multiple equal things such as a WebSite plus a BreadcrumbList:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "WebSite", "@id": "https://example.com/#website", "name": "Example" },
    { "@type": "BreadcrumbList", "itemListElement": [] }
  ]
}

Nesting shows a part-of relationship. @graph keeps several independent objects together without forcing one to be a child of another. Choose by the relationship, not by which looks shorter.

Cross-referencing with @id

When the same entity, your organization, appears in several places, do not duplicate it with slightly different details. Give it an @id once and cross-reference it:

{
  "@type": "Article",
  "author": { "@id": "#author" },
  "publisher": { "@id": "#org" }
}

@id points to the same node again instead of re-declaring it. This is the correct mechanism for sharing an entity, and it is what keeps a three-block page from describing your organization three different ways.

Consistency rules that keep Google from struggling

• One authoritative statement per entity. If your organization appears three times, merge them into one @id-referenced node rather than three inline copies.
• Match the visible page. Google validates the structured data against what the page shows; an author in markup that is not on the page is a mismatch.
• Keep datePublished, dateModified, and headline identical between markup and page, because a difference is exactly what a structured-data validator flags.
• Use the most specific type that is true. BlogPosting is more specific than Article and only meaningful when the page is a blog post, so check the news versus article distinction before naming the type.
• Validate after editing. Run Rich Results or the schema validator on any page where you nested or merged types, and keep breadcrumb markup consistent with the page's visible trail.

Nested JSON-LD earns its keep when it mirrors real relationships: an entity that is genuinely one thing, referenced once, nested where a part-of belongs, and bundled with @graph where there are several equals. Done consistently, the markup is easier to maintain and easier for Google to trust.