How should a site structure JSON-LD as a connected entity graph instead of isolated schema blocks?

Treat structured data as a graph of recurring real-world entities, not as a collection of independent snippets.

Assign stable @id values to entities that persist across pages. For example, the organization can use a canonical homepage fragment ID, a real location can use its location-page URL plus an entity fragment, and an author can use the professional profile URL. Reuse those identifiers whenever another page references the same entity.

Then connect page-specific objects to those stable entities. An Article can reference its author and publisher; a Service can reference provider and areaServed; a Product can reference brand; a WebPage can use about, mainEntity, isPartOf, and breadcrumb relationships where appropriate.

Keep facts consistent. Name, logo, address, telephone, URL, sameAs references, and other identifiers should not drift between templates. If the same business has different names or addresses in separate schema blocks, you are creating ambiguity rather than clarity.

Do not mark up entities or claims that are not supported by visible page content. Schema should describe the page, not become a hidden database of promotional assertions.

Build the graph from shared CMS data so updates propagate. A central organization record, location record, author record, and product/service model are safer than hand-authored JSON-LD on individual pages.

Validate at three levels: valid JSON-LD syntax, correct Schema.org relationships, and factual consistency with the canonical page. Rich-result eligibility is a separate layer and may require additional properties.

A connected graph will not guarantee rankings or AI citations. Its value is reducing ambiguity and making the site's own entity relationships explicit and consistent.