Schema Nesting Tool

Schema nesting is the practice of embedding one schema entity inside another to express relationships between them. Instead of placing a Product and an Offer in two separate JSON-LD blocks with no connection, you nest the Offer inside the Product's offers property. The nesting tells search engines that this specific offer belongs to this specific product. The relationship is structural, not inferred.

Schema.org is built on relationships. A Product has Offers. An Article has an Author who is a Person. A LocalBusiness has an Address that is a PostalAddress. A Recipe has NutritionInformation. A WebPage has a mainEntity that might be a Product, Article, FAQPage, or any other type. Each of these connections is expressed by nesting one entity's properties inside another entity's structure.

Simple schema is flat. You define a type, list its properties, and you're done. Real-world pages aren't flat. A product page has a product with multiple offers at different prices, reviews from named people, a brand that's a separate entity, images with their own metadata, and a publisher organization with its own logo and address. All of these fit together in a tree, and the tree is what gives search engines a complete, connected picture of your page's content.

Flat, disconnected schema blocks leave gaps that search engines have to fill with assumptions. Nested schema eliminates those gaps by making relationships explicit.

• Disambiguation. A page with a flat Product block and a separate flat AggregateRating block forces Google to infer that the rating belongs to the product. Nesting the AggregateRating inside the Product's aggregateRating property removes all ambiguity.
• Richer data for rich results. Google's rich result features pull data from connected property chains. A product rich result with pricing requires the price to live inside an Offer nested inside the Product. The nesting is what makes the data chain complete.
• Entity relationship mapping. An Article with a nested author Person who has a worksFor Organization creates a three-entity chain: article, author, publisher. Each connection strengthens the entity signals for all three.
• Validation compliance. Google's structured data testing tools validate nested structures more favorably than disconnected blocks. A Product schema missing its Offer generates a warning. The same Product with a properly nested Offer passes validation and qualifies for richer result features.

Schema.org defines hundreds of properties that accept entity types as values rather than simple strings or numbers. These entity-accepting properties are where nesting happens.

• Content and its creator. Article, NewsArticle, BlogPosting, and other content types have author and publisher properties that accept Person and Organization entities.
• Product and its commercial details. Product's offers property accepts Offer entities containing price, currency, and availability. The brand property accepts a Brand or Organization entity. The aggregateRating property accepts an AggregateRating.
• Business and its location details. LocalBusiness contains address (PostalAddress), geo (GeoCoordinates), and openingHoursSpecification (OpeningHoursSpecification).
• Page and its primary content. WebPage's mainEntity property accepts any schema type as the primary content of the page.
• Event details. Event contains nested entities for location (Place), organizer (Person or Organization), performer (Person or Organization), and offers (Offer).

Deeper nesting expresses more relationships, but there are practical limits to how much depth search engines process and how much complexity is worth maintaining.

• Google's processing depth. Google reliably processes two to three levels of nesting. A Product containing an Offer containing a PriceSpecification is three levels deep, and Google handles this correctly. Nesting beyond four or five levels enters territory where Google may ignore the deeper entities.
• The usefulness threshold. Each level of nesting should add information that serves a concrete purpose. A Product with a nested Offer adds pricing to rich results. That Offer with a nested Seller Organization identifies who's selling. Going deeper than that for most common types doesn't produce additional search result benefits.
• Practical guideline. Nest to the depth that Google's rich results require, plus one level for entity enrichment. For a Product, that means: Product (level 1) containing Offer with price and availability (level 2), plus Brand as a named entity with a URL (level 2), plus AggregateRating with rating value and count (level 2).

This is one of the most debated implementation decisions in structured data. The answer depends on your specific situation.

• Single nested block advantages. Everything lives in one JSON-LD script tag. Relationships are expressed structurally through nesting, leaving no ambiguity about which entities connect to which. For pages with a clear hierarchy, a single nested block is the cleanest approach.
• Multiple separate blocks advantages. Each block is simpler, shorter, and easier to maintain independently. For pages with multiple distinct entities that don't have a clear parent-child relationship, separate blocks avoid forced nesting.
• The hybrid approach. Most sites end up with a hybrid: a primary nested block for the page's main content (Article with author and publisher, Product with offers and ratings) plus separate blocks for site-level entities (WebSite with SearchAction, BreadcrumbList).

This tool supports all three approaches. You can build one comprehensive nested structure, generate separate blocks for independent entities, or create a hybrid with one nested primary block plus separate supporting blocks.

• Nesting entities in the wrong property. Schema.org properties are type-specific. The author property accepts Person or Organization. Putting a PostalAddress in the author field is structurally invalid even if the JSON syntax is correct.
• Circular references. Entity A nests Entity B which nests Entity A. JSON-LD doesn't support circular references, and parsers will either fail or ignore the recursion. If two entities reference each other, use @id-based references rather than literal nesting.
• Duplicating data across nested and flat blocks. Placing a Product with a nested AggregateRating in one block and a separate flat AggregateRating in another creates ambiguity. Define each entity once, either nested or standalone, not both.
• Over-nesting simple values. Not every property needs a full entity. The brand property on a Product can accept a simple text string ("Nike"). Nest when the child entity carries multiple properties worth expressing.
• Forgetting @type on nested entities. Every nested entity needs its own @type declaration. An Offer nested inside a Product without "@type": "Offer" is just an anonymous object that search engines can't interpret.