JSON-LD Architecture

You have spent the last six sessions building individual pieces of structured data: Person schema, Organization schema, Article schema, Course schema. Now comes the critical question: do these pieces connect into a coherent whole, or are they isolated fragments scattered across your site?

Most sites have disconnected schema. The homepage declares an Organization. The About page declares a Person. Blog posts declare Articles. But none of them reference each other. From a search engine's perspective, these might be completely unrelated entities. The architecture of your JSON-LD determines whether your structured data tells a unified story or a collection of disconnected facts.

The Problem with Fragmented Schema

Fragmented schema is like having employees who never mention which company they work for. Each piece of information might be accurate, but the system cannot assemble a complete picture. The Organization on your homepage and the author on your blog post might be treated as separate, unrelated entities.

The fragmented version has four pieces of schema that are invisible to each other. The connected version has four pieces of schema that form a knowledge graph. Same content. Dramatically different entity signal.

The @id System: Your Schema's Backbone

The @id property is the mechanism that connects schema across pages. It works like a database primary key. You define an entity once with a canonical @id, then reference that @id from any other schema block on any page of your site.

Designing Your Schema Architecture

Before writing any code, design your schema architecture on paper. Map which entity types appear on which pages, how they reference each other, and what relationship properties connect them.

A typical site schema architecture follows this hierarchy:

1. Homepage: Organization (or Person for personal brands) + WebSite. This is the root of your schema graph.
2. About page: Person with full details, referencing Organization via worksFor/founder.
3. Blog/content pages: Article with author (Person @id), publisher (Organization @id), about (topic), isPartOf (hub).
4. Hub/pillar pages: WebPage or CollectionPage with hasPart referencing cluster articles.
5. Course/event pages: Course or Event with provider/organizer (Organization @id), instructor/performer (Person @id).
6. Service pages: Service with provider (Organization @id), serviceType, areaServed.

The @graph Property

When a single page needs to declare multiple entity types, use the @graph property to contain them in one JSON-LD block. This keeps your schema organized and makes cross-references within the same page explicit.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://yoursite.com/#org",
      "name": "Smith SEO",
      "founder": { "@id": "https://yoursite.com/#person" }
    },
    {
      "@type": "WebSite",
      "@id": "https://yoursite.com/#website",
      "name": "Smith SEO",
      "publisher": { "@id": "https://yoursite.com/#org" }
    }
  ]
}

Google supports both the @graph approach and separate <script> tags for multiple entities on the same page. The @graph approach is cleaner and makes the relationships more explicit.

Finding and Fixing Disconnections

After mapping your architecture, crawl your site and audit every page's structured data. Look for these common disconnections:

• Author without @id: Article author is a text string instead of a reference to your Person entity.
• Publisher missing: Articles have author but no publisher linking to your Organization.
• Mismatched @id: Different pages use different @id formats for the same entity.
• Orphaned schema: Course or Event schema that does not reference your main entity.
• Missing sameAs: Person or Organization exists but has no cross-platform connections.

Further Reading

• JSON-LD Specification (json-ld.org)
• Use JSON-LD to Add Schema.org Data to Your Website (Yoast)
• JSON-LD Schema Markup: The Complete Implementation Guide (SEO Strategy)
• Generate JSON-LD Schema at Scale (Screaming Frog)