Product schema for BigCommerce

BigCommerce sits between Shopify and WooCommerce on the schema-completeness spectrum. Cornerstone — the default theme — ships JSON-LD that’s more thorough than WooCommerce core but lighter than Shopify’s Dawn. The gap is in attribute coverage, not the basic properties.

This guide walks through the Stencil + Handlebars pattern for product schema on BigCommerce, what Cornerstone produces, and the helpers that fill the missing properties without forking the theme.

What Cornerstone ships

The current Cornerstone theme (verified against the late-2025 release) generates this Product markup automatically on product detail pages:

• name
• description
• image (array of all gallery images at full resolution)
• sku
• brand (when set on the product)
• mpn (when populated)
• gtin13 (when the UPC field is populated — note: the field is labeled “UPC” in the admin but BigCommerce maps it to gtin13)
• offers with price, priceCurrency, availability, and url
• aggregateRating (when reviews are enabled and the product has any)

That’s a stronger baseline than WooCommerce. The properties that still need adding for full AI surfacing:

• category mapped to a Google product category
• countryOfOrigin
• additionalProperty for category-specific attributes (material, fit, certifications)

Where the schema lives

In a Stencil theme, product schema is generated by the product detail template. The Handlebars partial that emits it:

templates/components/products/product-view.html

Within that file, look for a <script type="application/ld+json"> block. In Cornerstone the block is wrapped in a Handlebars expression that pulls from the product context object. The flow:

The product context exposes most of what BigCommerce stores. Custom fields, custom attributes, and products-with-multiple-options-as- variants are all reachable via Handlebars expressions.

The Handlebars extension pattern

Cornerstone’s default schema block is conservative. Extending it follows a uniform pattern: read from the product.custom_fields array, conditionally render the additional Schema.org properties.

A custom-field-driven extension looks like:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "{{product.title}}",
  "description": {{json product.description}},
  "sku": "{{product.sku}}",
  {{#if product.upc}}
  "gtin13": "{{product.upc}}",
  {{/if}}
  {{#if product.brand}}
  "brand": {
    "@type": "Brand",
    "name": "{{product.brand.name}}"
  },
  {{/if}}
  {{#each product.custom_fields}}
    {{#ifEquals name "Google Product Category"}}
    "category": "{{value}}",
    {{/ifEquals}}
    {{#ifEquals name "Country of Origin"}}
    "countryOfOrigin": {
      "@type": "Country",
      "name": "{{value}}"
    },
    {{/ifEquals}}
  {{/each}}
  "offers": {
    "@type": "Offer",
    "url": "{{product.url}}",
    "priceCurrency": "{{currency.code}}",
    "price": "{{product.price.without_tax.value}}",
    "availability": "https://schema.org/{{#if product.availability}}InStock{{else}}OutOfStock{{/if}}"
  }
}
</script>

The {{#ifEquals}} helper is a Cornerstone-provided Handlebars extension; if the theme is custom and doesn’t include it, register it once in assets/js/theme/global/utils.js or use a different pattern-matching approach.

Variant handling

BigCommerce’s variant model differs from Shopify’s. BigCommerce calls them “variants” but the catalog also has “options” and “modifiers” — three layers, only one of which (variants) carries unique SKU and inventory.

For schema:

• Default product page: render the parent product’s schema with hasVariant enumerating each variant.
• Variant-specific URL: when a variant is selected via URL parameters or a dedicated variant page, render that variant’s schema as the primary Product.

In Cornerstone, the product.variants array is reachable from the template. Iterate it to build the hasVariant array:

"hasVariant": [
  {{#each product.variants}}
  {
    "@type": "Product",
    "sku": "{{sku}}",
    {{#if upc}}
    "gtin13": "{{upc}}",
    {{/if}}
    "offers": {
      "@type": "Offer",
      "price": "{{price.without_tax.value}}",
      "availability": "https://schema.org/{{#if available}}InStock{{else}}OutOfStock{{/if}}"
    }
  }{{#unless @last}},{{/unless}}
  {{/each}}
]

Q&A pairs as a sibling FAQPage block

If the catalog has product-specific Q&A content, FAQPage is its own Schema.org type — render it as a second JSON-LD block alongside the Cornerstone-generated Product block. Don’t nest one inside the other; Schema.org models them as peers.

BigCommerce stores Q&A pairs naturally in custom fields. A pattern that works: name the field Q: <question> with the answer as the field value, then a Handlebars block in the product template that emits the FAQPage schema:

{{#if product.custom_fields}}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {{#each product.custom_fields}}
      {{#startsWith name "Q:"}}
      {
        "@type": "Question",
        "name": {{json (replace name "Q: " "")}},
        "acceptedAnswer": {
          "@type": "Answer",
          "text": {{json value}}
        }
      }{{#unless @last}},{{/unless}}
      {{/startsWith}}
    {{/each}}
  ]
}
</script>
{{/if}}

The custom-field convention is Q: Does this run true to size? as the field name, with the answer as the field value. Inelegant but works without extending BigCommerce’s catalog model. For larger catalogs, a feed-management app handles this more cleanly.

This is the rendering pattern. Note that testing in late 2025 suggests that AI agents may not consistently extract JSON-LD on direct page fetch; the value of structured Q&A markup appears to come through index and feed paths rather than agents reading the page directly.

BigCommerce-specific quirks

• Page Builder vs. Stencil. Pages built in BigCommerce’s Page Builder do not run the Stencil templates the same way. Schema injected via product-view.html doesn’t render on Page Builder pages. Use a script tag in the page’s content area for those.
• Headless storefronts (Catalyst, Next.js). BigCommerce’s headless reference architecture (Catalyst) ships product schema as a React component. The component is light by default — extend it with the same property additions as the Cornerstone version.
• Multi-storefront. Each storefront has its own theme files. A schema extension in one storefront’s product-view.html does not propagate to others. Apply changes to each storefront’s theme.

Where it breaks

• CDN caching. BigCommerce’s CDN caches rendered pages aggressively. Schema changes can take hours to propagate. Use the admin’s “Refresh CDN” option after deploying schema changes.
• Custom-field name drift. Custom field names in BigCommerce are free text. Catalogs that use “Google Product Category” in some products and “google_product_category” in others will inconsistently populate the category schema property. Standardize the field name before the schema extension can rely on it.
• Reviews from external apps. Apps like Yotpo and Stamped inject their own aggregateRating schema separately. With Cornerstone’s built-in review schema also rendering, you get duplicate aggregateRating properties. Disable one source.

The contrarian take

BigCommerce’s stronger baseline schema (vs. WooCommerce) gives some operators the impression that no further work is needed. The default output passes Schema.org validation, so the assumption becomes “we’re done.” But BigCommerce users report missing rich-results fields on default product pages, and rich-results eligibility is a separate bar from validation.

Validation is not the same as surfacing readiness. Attribute coverage, identifiers, and category mapping are documented inputs to Google Merchant Center and Bing Shopping that go beyond what schema validation checks. Cornerstone’s defaults are weak on all three; extending the Handlebars template to populate them is the work that closes the gap.

Where Cornerstone won’t be enough

• B2B catalogs with quote-based pricing. BigCommerce supports quote-pricing through B2B Edition; the schema needs to use priceSpecification with “Contact for pricing” rather than a numeric price.
• Pre-orders and backorders. Cornerstone’s default availability output is binary (in stock / out of stock); schema supports PreOrder and BackOrder states. Extend the conditional in the template to map BigCommerce’s preorder field onto the Schema.org URL.
• Product bundles. BigCommerce’s bundle product type doesn’t map cleanly to Schema.org’s Product model. Bundles often need to ship as their own products with explicit additionalProperty describing what’s included.

Validation

The same three-tool stack — Rich Results Test, Schema.org Validator, manual JSON inspection. BigCommerce-specific errors to watch for:

• The availability URL malformed when a custom condition expression is used in the template
• gtin13 rendered as the SKU when the catalog has SKU but no UPC (the conditional in the template must check the field separately)
• Empty aggregateRating when reviews are enabled but the product has none

What to ship this week

1. Open templates/components/products/product-view.html. Find the existing JSON-LD block (Cornerstone’s default).
2. Add the four extensions above (category, countryOfOrigin, hasVariant, full availability mapping).
3. Push the theme through Stencil CLI, refresh the CDN.
4. Validate ten products through the Rich Results Test.
5. Two-week wait, then re-check AI agent surfacing.

For a typical mid-market BigCommerce catalog (1,000–5,000 products), this is a one-day project that pulls the schema from validation-grade to surfacing-grade.