Best Practices: Product Detail Pages

Modified on Tue, 19 May at 5:54 PM

This Best Practices document is intended to support clients who are maintaining Product Detail Pages and Schema App users who want to author accurate and effective markup. There is a strong relationship between page content and structure, and what Schema App can target.

This documentation focuses primarily on Product Detail Pages (PDPs) using the Schema.org Product type.

TABLE OF CONTENTS

Overview: Product & ProductGroup
Required or Schema App Recommended
Conclusion

Overview: Product & ProductGroup

The Product Type is used to describe an individual purchasable item, while ProductGroup is used to describe a parent product entity that contains multiple variants of a product. The distinction between Product and ProductGroup is important because Google treats variant differently depending on how products are represented on-page. This article will focus primarily on single Product detail pages, as Product Variants require a full exploration.

Common PDP implementations include:

Single Product PDPs — One purchasable SKU with one price and one offer
Variant PDPs — A parent product with selectable variants such as size, color, material, or storage capacity
Parameterized Variant URLs — Individual URLs for specific variants
Dynamic JavaScript Variant Switching — Product information changes client-side without page refreshes

Note: Google supports Product structured data for both Product Snippet and Merchant Listing experiences. Merchant Listing eligibility typically requires more detailed commerce data including offers, shipping, returns, and availability.

Required or Schema App Recommended

At minimum, the content on a Product Detail Pages should clearly describe:

What product is being sold (name, description, image)
Who sells or manufactures the product (brand, offeredBy)
Note: This may be implied based on all products being manufactured/sold by one company who owns the website.
Pricing and offer details (Offer, AggregateOffer)
Reviews and ratings where applicable (review, aggregateRating)
Availability (availability)
Variant relationships (hasVariant, isPartOfGroup)

Note: Structured data should always align with visible page content.

name

The name property is one of the most critical Product properties because it is often used by search engines to label rich results and distinguish products from one another.

Note: For variant-specific products, Google recommends including distinguishing attributes directly in the product name where appropriate.

Examples:

"Resolve" Cotton T-Shirt - Large - Navy

Property Path Checklist

name

Common Best Practices

Use a consistent HTML element (e.g. <title> or <h1> to contain the Product name as you would want it to appear
Do not use that reserved HTML element for marketing language (e.g. <title>The Best Shoes on the Market</title>)

description

The description property provides a human-readable summary of the product itself. This content should describe the actual product and not the webpage. High-quality product descriptions help search engines understand a product's purpose, features, specifications, composition, use cases and intended audience.

Schema App will typically source descriptions from visible PDP product descriptions or expandable product detail sections

Property Path Suggestions

description
disambiguatingDescription
This is occasionally used to differentiate between similar products (e.g. to capture sizing, colour, or similar variations)

Common Best Practices

Avoid generic marketing language without product context
Ensure descriptions are visible, rather than hidden text.
Use disambiguatingDescription only when products require additional differentiation

image

The image property describes images associated with the Product. Product images are one of the most important commerce signals for Google Merchant Listing experiences. Google recommends high-resolution images that accurately represent the product and consistent canonical image URLs

Many ecommerce platforms may implement components that require manual XPath strategies or rendered DOM inspection when authoring Highlighter templates. These components include:

Image carousels
Lazy-loaded images
Responsive image sets
JavaScript-rendered galleries

Property Path Suggestions

image~ImageObject~url
image~ImageObject~contentUrl
image~ImageObject ~creator or creditText or copyrightNotice or license
image~ImageObject~height
image~ImageObject~width

Common Best Practices

Use product-specific images with URLs resolve successfully
Avoid duplicate image URLs across variants when possible
Confirm lazy-loaded images can be targeted

brand

The brand property identifies the brand associated with the Product. Google expects a Brand type entity for specifically Merchant Listing experiences, even though schema.org allows Organization and subtypes.

Brand implementation strategies typically fall into two categories:

Single-brand merchants — The brand may be defined using a reusable linked data item or conditional tag
Multi-brand retailers — Brand names are usually extracted dynamically from page content

Property Path Suggestions

brand~Brand~name
brand~Brand~sameAs

Common Best Practices

If a website is a multi-brand retailer, ensure brand names match visible page content
Reuse linked Brand entities where possible

sku, gtin & mpn

Stable identifiers like sku, gtin and mpn are among the strongest signals for ecommerce product disambiguation. Google considers GTINs and MPNs to be strong identifiers that help match products across merchants and product graphs. Each identifier serves a different purpose:

sku — Merchant-specific inventory identifier
gtin — Global Trade Item Number standardized by GS1
mpn — Manufacturer Part Number assigned by manufacturers

Property Path Checklist

sku
gtin
mpn

Common Best Practices

Use variant-specific identifiers whenever possible
Avoid placeholder or duplicated values
Confirm whether barcodes qualify as GTINs
Use MPNs when GTINs are unavailable

Note: GTIN values are often not visible on-page but may exist in rendered HTML, JSON configuration objects, or ecommerce platform metadata. Confirm the value is accessible to Schema App.

offers~Offer or offers~AggregateOffer

Offer or pricing information is required for a Merchant Listing Rich Result and is critical to eCommerce markup. This is one of the most important sections for Product rich result eligibility because it allows users to more seamlessly move from searching to purchasing. Offer information must always match visible page content.

Property Path Checklist

offers~Offer~price or offers~AggregateOffer~lowPrice
offers~Offer~priceCurrency
offers~Offer~availability
offers~Offer~itemCondition
offers~Offer~offeredBy
offers~Offer~seller

Note: In terms of property paths, Offer and AggregateOffer can be used almost interchangeably. However, Google will treat them differently (e.g a Merchant Listing must have an Offer, not a just a range of prices.

Common Best Practices

Use canonical currency codes (e.g. USD, CAD, GBP)
If the product is a variant, ensure prices and offer data update dynamically with variants
Avoid stale availability values

aggregateRating or review

Reviews and ratings communicate customer sentiment and can contribute to rich result appearances. The aggregateRating property summarizes all ratings associated with the Product, while individual Review nodes represent written reviews or customer feedback.

Property Path Checklist

aggregateRating~AggregateRating~ratingValue
aggregateRating~AggregateRating~ratingCount
aggregateRating~AggregateRating~reviewCount
review~Review~author~Person~name
review~Review~reviewBody
review~Review~reviewRating
review~Review~datePublished

Common Best Practices

Ensure reviews are visible on-page and available
Ensure aggregate rating data is accessible as a full numeric value

hasMerchantReturnPolicy

The hasMerchantReturnPolicy property describes return policies associated with the Product offer. Google Merchant Listings can use this information to enhance Shopping experiences and communicate return expectations directly in Search.

This data can be highly dependent on a user's location, so develop consistent rules around where pages are indexed and how they appear for users in different countries.

Property Path Checklist

hasMerchantReturnPolicy~MerchantReturnPolicy~applicableCountry
hasMerchantReturnPolicy~MerchantReturnPolicy~merchantReturnDays
hasMerchantReturnPolicy~MerchantReturnPolicy~returnFees
hasMerchantReturnPolicy~MerchantReturnPolicy~returnMethod

Common Best Practices

Align return policies with current, visible site policies
Use ISO country codes
Coordinate with Organization-level shipping and return policy markup

Dimensions & Measurements

QuantitativeValue properties such as width, height, depth, and weight are commonly used for physical goods. These properties often require careful extraction strategies because dimension data may appear within specification table, freeform text blocks, JS-rendered tabs or as combined dimensional values. Revisiting formatting choices during page design is highly recommended for customers who want to capture this information in their markup.

Property Path Checklist

width~QuantitativeValue~value
height~QuantitativeValue~value
depth~QuantitativeValue~value
weight~QuantitativeValue~value
hasMeasurement~QuantitativeValue~value

Common Best Practices

Use UN/CEFACT unit codes
Confirm dimension ordering with the client
Use conditional tags when units vary (e.g on different countries, etc

Additional Properties

Not every product feature can be captured using existing schema.org properties. In this scenario, explore additionalProperty~PropertyValue as a way to represent custom information. This can be a complex process depending on how this data is formatted across Product Detail Pages. Similar to dimensional information, these properties often require careful extraction strategies because they may appear within specification tables, freeform text blocks, JS-rendered tabs or as combined dimensional values. Revisiting formatting choices during page design is highly recommended for customers who want to capture this information in their markup.

Conclusion

Effective Product structured data requires alignment between visible ecommerce content, structured data semantics and Google rich result requirements.

During page redesign, subject matter experts should collaborate with the Schema App Customer Success team to identify content recommendations and define best practices specific to their website(s).

Additional implementation guidance can be found in: