A website knowledge graph is a connected model of the real things a site describes. The nodes are entities such as a person, organization, website, article, product, or topic. The edges are relationships such as author, publisher, about, mainEntity, isPartOf, or sameAs.

JSON-LD is one practical way to publish that model. Adding disconnected schema blocks is not enough. The graph becomes useful when the same entity keeps the same identifier, relationships are accurate, and the markup matches what a visitor can see.

Why This Topic Needs a Full Guide

The knowledge graph query cluster produced 149 Google Search impressions across 16 variants in the complete 28-day window ending September 12, 2026. The existing glossary definition also received 11 successful crawler retrievals in the comparable warehouse window. Those signals show a recurring information need. They do not show that a crawler adopted the site's graph or that an answer engine cited it.

The opportunity is to answer the implementation question behind the definition: how does a publisher turn pages and schema into one coherent entity model?

A Graph Is More Than a Pile of Schema

Five pages can each contain valid Article markup and still fail to express a useful website graph. If every block invents a new publisher object, changes the author's name, or omits the relationship to the website, a consumer has to guess whether the records describe the same things.

A coherent graph reuses identifiers. For example:

  • The Organization keeps one canonical @id.
  • The WebSite points to that Organization as publisher.
  • Each WebPage uses isPartOf to point to the WebSite.
  • Each Article points to its WebPage as mainEntityOfPage.
  • Each Article identifies the correct author and publisher.
  • The BreadcrumbList matches the visible navigation hierarchy.

Start With Stable Entities

Choose the entities that are actually important to the site. A typical publishing site needs an Organization or Person, a WebSite, a WebPage for each canonical URL, and an Article for editorial pages. Other content types should be added only when they describe the visible page accurately.

Give recurring entities stable identifiers. A fragment identifier attached to a canonical URL works well:

https://www.example.com/#organization
https://www.example.com/#website
https://www.example.com/about/#person

The exact fragments are less important than consistency. An @id is a reference within the graph. It should not change every time the entity appears.

Connect Entities With Meaningful Properties

Relationships carry the useful context. Common publishing relationships include:

  • author connects an Article to the person or organization responsible for it.
  • publisher connects a creative work or website to its publisher.
  • isPartOf connects a WebPage to its WebSite or a work to a larger work.
  • mainEntity identifies the primary thing a page describes.
  • mainEntityOfPage identifies the canonical page for an entity.
  • about names the subjects directly covered by the content.
  • sameAs points to another URL that represents the same entity.

Do not use sameAs for a related article, partner, topic, or source. Google's Organization documentation describes it as another URL for the organization. It is an identity assertion.

Use @graph to Publish Connected Nodes

JSON-LD supports a top-level @graph array. That lets one script publish several connected nodes without nesting the complete Organization and Person objects inside every Article.

{
  "@context": "https://schema.org",
  "@graph": [
    {"@type": "Organization", "@id": "https://www.example.com/#organization"},
    {"@type": "WebSite", "@id": "https://www.example.com/#website", "publisher": {"@id": "https://www.example.com/#organization"}},
    {"@type": "Article", "publisher": {"@id": "https://www.example.com/#organization"}}
  ]
}

The example is deliberately small. A production graph also needs names, canonical URLs, dates, headlines, and the properties required by the content type.

Keep the Graph Grounded in Visible Content

Structured data should describe what the page shows. Do not mark up reviews that are absent, invent author credentials, publish FAQ markup for questions hidden from visitors, or label a page as a product when it is only an article about a product.

Google's structured data guidelines make this visible-content requirement explicit. A technically valid graph can still be misleading or ineligible for a search feature.

A Practical Build Order

  1. Inventory the site's canonical pages and recurring real-world entities.
  2. Choose one canonical identifier for each recurring entity.
  3. Create Organization or Person and WebSite nodes first.
  4. Add WebPage, Article, and BreadcrumbList nodes per route.
  5. Connect nodes with references to the stable identifiers.
  6. Confirm every claim appears in or is supported by the visible page.
  7. Test the rendered output with the Rich Results Test and Schema.org validator.
  8. Crawl the site to find duplicate identifiers, conflicting names, and broken canonical URLs.

The companion guide, How to Test Schema Markup and Rich Results, explains what each validator checks and why passing a test is not a performance guarantee.

What to Measure Next

First measure coverage and consistency: percentage of canonical pages with valid JSON-LD, duplicate @id conflicts, missing entity relationships, and validator errors. Then measure search impressions and clicks for the page types involved.

A crawler request proves that a page was retrieved. Valid markup proves that the graph parses. Neither proves that an AI system used the graph in an answer. Keep the implementation evidence and the outcome evidence separate.