JSON-LD Nesting Patterns AI Engines Prefer: A Schema Architecture Guide

A SaaS brand audits its structured data. The validator passes. Every page has Article schema, Organization schema, and where relevant Product schema and FAQPage schema. The brand looks at the implementation. Each schema lives in its own script tag, none linked to the others. The Article schema mentions an author, but the Author entity is just a string, not a typed Person. The Organization schema mentions products but the products are not linked to the actual Product entities elsewhere on the page. The implementation is valid but flat.

The brand's AI citation rates have been stuck for months despite consistent content investment. The diagnosis is that the structured data is providing tags without providing structure. The AI engines extract the tags individually but cannot connect them into the brand's actual entity graph because the connections are not encoded.

JSON-LD has a documented graph syntax that connects entities through @id references. Brands that use the graph syntax explicitly produce schemas the AI engines can traverse to understand relationships. Brands that ship flat schema blocks leave the relationship signal on the table. This guide unpacks the architecture decisions that turn structured data from compliant to compounding.

Why JSON-LD Architecture Matters Beyond Tag Presence

Schema.org defines a vocabulary of types and properties. Article, Person, Organization, Product, Service, Place, Event, and dozens of others each have associated properties. A well-implemented schema uses the right types and the right properties for the entities on the page.

The schema architecture decision is how to express the relationships between entities. The same page contains an article (Article), written by a person (Person), employed by a company (Organization), describing a product (Product) made by another company. The relationships are real and meaningful. The question is whether the JSON-LD encodes them.

Three architectural patterns are common.

• Flat unrelated schemas - Each entity is in its own JSON-LD script tag. The Article schema mentions an author as a string. The Organization schema is in another block. The relationships are implicit at best, missing at worst. Validators pass; AI engines see fragments.
• Nested entities with inline definitions - Each entity is nested inside its parent. The Article schema has an author property whose value is a Person object with the author's name, jobTitle, and affiliation inlined. The relationships are explicit but redundant if the same Person appears in multiple contexts.

@id-referenced graph. Each entity is defined once with a unique @id. Other entities reference the @id. The Article schema's author property references the Person's @id. The Person's affiliation property references the Organization's @id. The graph is explicit, navigable, and non-redundant.

The third pattern is the gold standard for AI engine retrieval. Engines can traverse the graph to understand the brand's full entity structure from a single page's schema. The first pattern is the baseline compliance level; the second is intermediate.

The Graph Pattern: Using @id To Connect Entities

The @id-referenced graph pattern works through a few simple syntax rules.

Each entity gets a unique @id. The id is typically a URL fragment ("https://yourdomain.com/#organization", "https://yourdomain.com/people/jane-smith#person"). The fragment identifier scheme allows multiple entities on the same page or site to have distinct identities while sharing a base URL.

Entities reference other entities by @id rather than redefining them. The Article schema's author property points to {"@id": "https://yourdomain.com/people/jane-smith#person"} instead of inline Person properties. The Person definition exists once and is referenced wherever needed.

The references work across pages. The Organization entity defined on the homepage can be referenced by Article schemas on every blog post via the @id. The single Organization definition propagates across the site without duplication.

Within a single JSON-LD block, you can use @graph to bundle multiple entity definitions. The block becomes a list of entities, each with their own @id, that can reference each other.

The result is that a single page's JSON-LD encodes the full local entity graph: the article, its author, the author's affiliation, the article's subject organization, the product mentioned, the product's manufacturer, and so on. The AI engine reads the graph and understands the relationships.

The implementation overhead is moderate. The first implementation requires architectural thinking and template work. Once the template is in place, each new page or article uses the same pattern. The maintenance cost is comparable to flat schema and the value is substantially higher.

The Canonical Nesting Architectures By Page Type

Different page types have different canonical nesting architectures.

For an article or blog post, the canonical graph includes: the Article entity (the post itself) with @id, its author as Person with @id, the Person's affiliation as Organization with @id, the article's mainEntityOfPage referencing the WebPage with @id, and the publisher as Organization (often the same as the affiliation). Cross-references through @id connect them.

For a product page, the canonical graph includes: the Product entity with @id, the Product's brand as Organization with @id, the Product's offers as Offer entities (price, availability), the Product's reviews as AggregateRating and individual Review entities, and any related Products through isRelatedTo or isSimilarTo references.

For a service page, the canonical graph includes: the Service entity with @id, the service provider as Organization with @id, the service's areaServed as Place entities, the service's offers, and where applicable the service category and subservices.

For an author or executive bio page, the canonical graph includes: the Person entity with @id, the Person's affiliations as Organization references, the Person's authored Works as Article references, and the Person's knowsAbout properties for topical expertise.

For a homepage, the canonical graph includes: the WebSite entity, the Organization entity, the search potential action, and references to other key entity types (people, products, services) defined elsewhere on the site but referenced for entity establishment.

We have written about schema markup for AI search more broadly; the nesting architecture is the structural layer beneath the choice of schemas to deploy.

The Schema Graph vs Separate Script Blocks Debate

A long-standing debate in the structured data community is whether to use a single @graph block with multiple entities or separate script tags for each schema type. Both are valid; the implications differ.

The single @graph block approach bundles all entities into one JSON-LD script tag. The block contains an @graph array with each entity as an item. The relationships within the graph are cleanly expressed through @id references.

The separate script blocks approach uses one JSON-LD script tag per top-level entity type. Article schema in one block, Organization in another, Product in another. Each block is self-contained and validates independently.

The single @graph block approach is preferred for AI engine retrieval. The engine sees the full local graph in one place and can build the entity relationships immediately. The relationships are encoded in the JSON-LD itself rather than implicit across multiple blocks.

The separate script blocks approach has compatibility advantages. Some legacy tools and validators handle separate blocks more reliably. Some CMS plugins generate separate blocks by default. For brands working within tooling constraints, the separate approach may be the practical option.

The hybrid approach is also viable: separate blocks for major entity types (Organization, WebSite) loaded once site-wide, plus a single @graph block on each page for page-specific entities. The pattern balances reusability with explicit graph structure.

For brands implementing new schemas in 2026, the single @graph approach is the recommended default. Existing implementations with separate blocks do not need to be rebuilt unless other reasons drive the work.

Common Validation Issues With Nested Schemas

Nested schema implementations have a few common validation issues to watch for.

@id reference targets must exist. If the Article schema's author references @id "https://yourdomain.com/people/jane-smith#person" and no Person entity with that @id exists in the graph, the reference is broken. Some validators flag this; others do not. The fix is ensuring every referenced @id has a corresponding entity definition.

@id scheme consistency. Using mixed schemes (some @ids as full URLs, some as fragments, some as arbitrary strings) creates inconsistency. Pick one scheme and apply it across all @ids. Full URLs with fragment identifiers are the most defensible approach.

• Schema type validity - Some Schema.org types do not accept references in certain properties. For example, Article's author can be a Person or Organization but not a Place. The validator catches these but the errors can be cryptic. Cross-check property requirements when designing the graph.
• Circular references - If A references B which references A, some validators flag the cycle. Avoid circular references in the graph; structure entities hierarchically.
• Required property completion - Each schema type has required properties (Article requires headline, author, datePublished; Product requires name, description, image). Missing required properties produce validation errors that block rich result eligibility. The validator surfaces these.
• Recommended property coverage - Beyond required properties, each type has recommended properties that improve rich result quality. The full Article schema with all recommended properties (description, image, dateModified, mainEntityOfPage, etc.) is much more useful than the minimum-required version.

Google's Rich Results Test and the Schema.org validator are the standard tools for catching these issues. Run both on every page type as part of QA. The investment in validation catches problems before they affect AI engine extraction.

How AI Engines Actually Traverse The Nested Graph

The mechanics of how AI engines use the nested graph have been documented less explicitly than how they use search indexes, but the patterns are observable.

When an engine ingests a page, the JSON-LD is parsed alongside the HTML. The structured data is stored in a parallel representation: an entity graph extracted from the JSON-LD plus the page text from the HTML body.

For retrieval queries, the engine often consults both representations. The entity graph helps the engine confirm entity identity and relationships. The page text provides the substantive content the engine surfaces.

For citation generation, the entity graph informs how the engine describes the page. An article whose graph clearly identifies the author as a specific Person with named affiliation gets cited with attribution to that person. An article whose graph has author as a generic string gets cited without specific attribution.

The implication is that the graph affects citation quality, not just retrieval probability. Pages with rich nested graphs get cited with rich descriptive language. Pages with thin or flat graphs get cited with generic language.

For brand entities specifically, the graph contributes to disambiguation. A brand mentioned in an article whose graph clearly identifies the Organization with its @id, sameAs links, and identifying properties is less likely to be confused with a similarly-named other brand. The disambiguation matters most for brands with common-word names or names shared with other entities.

The work on graph quality compounds over time. Each well-structured page contributes to the engine's overall understanding of the brand and its entities. Hundreds of well-structured pages produce confident, accurate, descriptive citations across queries.

Six Architectural Mistakes That Flatten Schema Value

Six recurring architectural mistakes consistently reduce the value of structured data implementations.

1. Author as a string rather than a Person entity. Article schema with author as a string ("by John Smith") misses the entity attribution. Use Person type with @id, name, and ideally url to the author's page.
2. Organization redefinition across pages. Defining the same Organization entity with inline properties on every page wastes the @id reference benefit. Define once with @id, reference from every page.
3. Missing sameAs links on Organization. The sameAs array connects your Organization entity to external authority surfaces (Wikipedia, Crunchbase, LinkedIn, Wikidata). Without sameAs, the entity is harder to disambiguate.
4. Inline Place entities without canonical Place definition. If your brand has a physical location referenced in multiple schemas, the Place should have its own @id and be referenced, not redefined inline.
5. Product schema without manufacturer Organization reference. A Product without a brand reference loses the entity connection between product and company. Always reference the brand Organization via @id.
6. FAQPage and HowTo schemas without anchoring to the main page. These secondary schemas should reference the main WebPage or Article they are part of through mainEntityOfPage or isPartOf, not float as orphaned blocks.

Frequently Asked Questions

Do AI engines support the full Schema.org vocabulary or only the rich-result subset?

Mostly the full vocabulary, but with weighted attention. AI engines extract from any valid Schema.org markup but weight the rich-result types (Article, Product, FAQPage, HowTo, Event, Recipe, JobPosting, LocalBusiness, Organization, Person) most heavily. The less common types are extracted but less load-bearing.

Should I use the @graph syntax even for pages with only one major entity?

Yes, when the entity itself has nested sub-entities. A page with one Article entity that has an author Person and a publisher Organization benefits from @graph syntax even though there is only one top-level entity. The graph syntax expresses the nesting explicitly.

How do I migrate from flat schemas to nested graph schemas without breaking existing rich results?

Carefully and incrementally. Test the new schema on a small set of pages first. Run Google Rich Results Test to confirm the rich result eligibility is preserved. Compare the rich result output before and after. Once one page type validates cleanly, migrate the rest. Avoid mass changes without staged testing.

Will using @id with custom fragment URLs hurt my page in Google Search?

No. The @id is a JSON-LD construct that does not affect URL routing. The fragment identifier is internal to the JSON-LD graph and does not need to resolve to actual page content. Google handles this correctly and has documented the pattern in its structured data guidance.

Should I include Organization sameAs links on every page or only on the homepage?

For maximum cleanliness, define the Organization once (typically on the homepage) with full sameAs links, and reference it via @id from every other page. The sameAs links live with the canonical Organization definition and propagate to every page that references the entity.

Do I need separate JSON-LD for mobile and desktop views?

No. The same JSON-LD serves both. AI engines and search engines extract the structured data once per page; the rendered view does not affect the schema interpretation. The exception is if mobile and desktop versions of the page have meaningfully different content (rare in modern responsive design); in that case, ensure both versions ship the schema.

JSON-LD architecture is the structural layer that determines how much value brands extract from their structured data investment. Flat schema blocks deliver compliance but limited relationship signal. Properly nested graphs with @id references deliver the entity graph AI engines can actually use to understand the brand and its content.

The implementation is moderate effort once the template is in place. The compounding value across hundreds or thousands of pages is substantial. Brands serious about AI citation visibility should treat schema architecture as load-bearing engineering work, not as a tag-tagging compliance exercise.

If your team wants help auditing your current JSON-LD architecture and migrating to a properly nested graph implementation, that work sits inside our generative engine optimization program. The brands cited accurately and richly by AI engines are the brands whose structured data encodes the relationships, not just the entities.