A product page for a cookbook contains a Product entity, multiple Recipe entities, an Organization entity for the publisher, a Person entity for the author, and Review entities that reference both the Product and individual Recipes. The author entity references the organization, which references its products, which reference the author. This circular reference structure is semantically accurate, but it creates an implementation challenge that most schema generators cannot handle. The JSON-LD specification explicitly supports circular data graphs through @id references. Google’s parser, however, follows these references to a limited depth, meaning deeply nested circular structures may be partially resolved or silently truncated.
How Google’s Parser Handles Circular Entity References in JSON-LD
The JSON-LD specification directly addresses circular graph topologies. According to the W3C JSON-LD 1.1 specification, graphs containing loops cannot be serialized using embedding alone. The @id property must be used to close the loop by referencing a previously declared node instead of re-embedding it inline.
Google’s structured data parser processes JSON-LD by resolving @id references to build an internal entity graph. When Entity A references Entity B via @id, and Entity B references Entity A via @id, the parser recognizes this as a loop rather than an infinite recursion. The parser resolves each reference once and stops, producing a finite graph with bidirectional edges.
However, the practical behavior differs from the specification in one critical way. Google’s parser appears to follow reference chains to a depth of approximately 3-4 levels before stopping resolution. This means a reference chain of A references B references C references D references A resolves correctly, but deeper chains may lose the final reference link. The truncation is silent, producing no validation error.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Product",
"@id": "#product",
"name": "The Complete Cookbook",
"author": { "@id": "#author" },
"publisher": { "@id": "#publisher" }
},
{
"@type": "Person",
"@id": "#author",
"name": "Jane Smith",
"worksFor": { "@id": "#publisher" }
},
{
"@type": "Organization",
"@id": "#publisher",
"name": "Culinary Press",
"employee": { "@id": "#author" }
}
]
}In this example, the Product references the Author, the Author references the Publisher via worksFor, and the Publisher references the Author via employee. Each entity is defined once in the @graph array and cross-referenced by @id. Google’s parser resolves all three bidirectional references correctly because the chain depth stays within the resolution limit.
Position confidence: Observed. The depth limitation is inferred from testing multi-level reference chains in Google’s Rich Results Test, where deep chains produce incomplete entity resolution without error messages.
When Nested Schema Creates Ambiguity About the Primary Entity
A page with multiple interconnected entity types creates ambiguity about which entity Google should treat as the primary subject for rich result purposes. If both Product and Recipe schema are fully implemented on the same page, Google must determine which rich result type to display. The page cannot simultaneously show a Product rich result and a Recipe rich result for the same organic listing.
Google resolves primary entity ambiguity through the mainEntity and mainEntityOfPage properties. When a WebPage entity declares mainEntity pointing to a specific entity, that entity becomes the primary candidate for rich result display. Without this declaration, Google infers the primary entity from the page’s content, title, and heading structure, which may not align with the intended schema.
{
"@type": "WebPage",
"@id": "#webpage",
"mainEntity": { "@id": "#product" }
}This declaration tells Google that the page’s primary subject is the Product, even though Recipe entities also exist on the page. The Recipe entities remain available for entity understanding and may contribute to Google’s knowledge graph, but the Product entity receives priority for rich result selection.
Without mainEntityOfPage, Google typically selects the entity type that appears first in the JSON-LD or the type with the most complete property coverage. This heuristic produces unpredictable results on pages with equally complete schema for multiple entity types. Explicitly declaring the primary entity removes this ambiguity.
A common mistake is declaring multiple entities as mainEntity, which reintroduces the ambiguity the property was designed to resolve. Only one entity should be designated as the page’s primary subject.
Implementation Patterns That Resolve Circular Dependencies Cleanly
Three JSON-LD implementation patterns handle circular dependencies without creating parsing issues.
The flat @graph pattern declares all entities as top-level members of a @graph array, each with a unique @id. Cross-references use @id values instead of inline nesting. This pattern eliminates the risk of infinite nesting, keeps each entity definition in a single location, and makes maintenance straightforward because updating an entity’s properties requires changing only one object in the array.
The anchor entity pattern designates one entity as the root and nests direct children inline while referencing back to the root via @id. This pattern works well when the entity hierarchy has a clear parent, such as a Product with nested Offers and Reviews, but the Organization referenced by the Product also references the Product catalog.
The separate script block pattern places independent entity declarations in separate <script type="application/ld+json"> blocks and uses @id for cross-block references. Google processes multiple script blocks on the same page and resolves @id references across them. This pattern is useful when different CMS components generate their own structured data independently, such as a product component generating Product schema and a review widget generating Review schema.
The choice between patterns depends on the implementation context. Template-driven CMS implementations benefit from the separate script block pattern because each template component manages its own schema output. Custom JSON-LD implementations benefit from the flat @graph pattern because it provides the cleanest structure for complex entity relationships.
In all patterns, the @id value convention matters. Using fragment identifiers like #product or #author creates page-scoped identifiers. Using full URLs like https://example.com/cookbook#product creates globally unique identifiers that can be referenced from other pages. The W3C recommends full URL-based identifiers for entities that appear across multiple pages.
The Validation Gap for Complex Nested Structures
Google’s Rich Results Test validates individual entity types against their required and recommended property lists. It does not validate the correctness of cross-entity references, the resolution of @id chains, or the logical consistency of the overall entity graph.
This creates specific blind spots. A Product with author referencing @id: "#author" will pass validation even if no entity with that @id exists in the document. The reference simply resolves to nothing, and the author property becomes effectively empty. The Rich Results Test does not flag unresolved references as errors.
Similarly, a @graph containing two entities with identical @id values produces undefined behavior. The parser may use either entity’s properties, merge them inconsistently, or ignore the duplicate. Validation tools do not flag duplicate @id declarations.
For complex nested structures, supplementary verification methods are necessary. The Schema Markup Validator (formerly the Structured Data Testing Tool) provides more detailed entity resolution information than the Rich Results Test. JSON-LD Playground (json-ld.org/playground) processes the JSON-LD according to the W3C specification and shows the fully expanded entity graph, revealing unresolved references and duplication issues.
Manual verification involves extracting the JSON-LD from the page, processing it through a JSON-LD expander, and confirming that every @id reference resolves to a defined entity with the expected properties. Automating this verification in the deployment pipeline catches reference breakage before it reaches production.
Practical Limits on Schema Complexity Before Diminishing Returns
Beyond a certain complexity threshold, additional nested schema adds implementation and maintenance cost without improving rich result eligibility or entity understanding.
The practical limit for rich result purposes is the primary entity plus its direct dependencies. A Product entity benefits from nested Offer, AggregateRating, Brand, and Organization (as manufacturer or seller) entities. Adding the Organization’s employees, the employees’ educational credentials, the university’s location, and the location’s geo-coordinates does not improve the Product’s rich result eligibility. Google’s rich result parser extracts properties relevant to the target rich result type and ignores deeply nested entities that do not contribute to the display format.
For entity understanding purposes, the practical limit extends one level further. Connecting your primary entity to its immediate semantic context (author, publisher, brand, category) helps Google classify the entity correctly. Connections beyond that immediate context contribute diminishing entity understanding value relative to the maintenance cost.
A reasonable complexity ceiling for most implementations is 4-6 entity types per page with a maximum reference depth of 3 levels. Beyond this, the JSON-LD becomes difficult to maintain, validation gaps widen, and the marginal benefit to rich result eligibility or entity classification approaches zero.
Simplification strategies for over-complex implementations include removing entity types that do not contribute to the page’s primary rich result type, replacing deep inline nesting with flat @id references, and consolidating redundant entity declarations that describe the same real-world entity with different property subsets.
Does Google penalize pages with circular references in structured data?
No. Circular references are a valid JSON-LD pattern recognized by the W3C specification, and Google’s parser handles them by resolving each reference once without infinite recursion. There is no penalty for using circular references when they accurately represent real entity relationships. The risk is not penalty but silent truncation if reference chains exceed Google’s approximate 3-4 level resolution depth.
Should each page on a site use the same @id values for shared entities like the Organization?
Yes. Using consistent @id values (such as https://example.com/#organization) for the same real-world entity across all pages allows Google to recognize these as references to a single entity rather than creating duplicate entity records. This strengthens entity recognition in the Knowledge Graph and ensures property updates on one page propagate to Google’s understanding of that entity site-wide.
Can multiple JSON-LD script blocks on the same page reference each other using @id?
Google resolves @id references across separate <script type="application/ld+json"> blocks on the same page. This allows different CMS components, such as a product module and a review widget, to generate independent schema blocks that connect through shared identifiers. The flat @graph pattern within a single block is cleaner architecturally, but cross-block referencing is functionally equivalent for Google’s parser.
