How to get BigCommerce data onto the live product page and into its JSON-LD, through the theme, a widget or a script

You've filled in a product's custom fields, dragged a widget in Page Builder or pasted a script into Script Manager, and you want to know whether any of it made it onto your live product page. On BigCommerce, looking at the admin isn't enough: between the admin and the page sit a theme that decides what gets rendered, a placement that may be inactive, and a publish button. This guide follows each road to the page's source code, with what BigCommerce's documentation says about each step, and it ends on something you can see: the HTML.

Where the data travels, and where it gets lost

On a store with a Stencil theme, the theme builds the product page. Its templates use Handlebars, and in production those instructions run on the server and generate the HTML the browser receives.⁠^{[1]BigCommerce Dev Center. Stencil Technology Stack} That's server-side rendering: whatever the theme renders is in the source code before any JavaScript runs. Three roads lead to that HTML, and Catalyst, BigCommerce's headless frontend, changes the rules for all three:

The five steps below walk the table in order: the data, the template, the widget, the script and the published page.

Step 1: check that the data is on the product

Before looking for data on the page, confirm it exists where the theme will look for it. For a product page, that's the product:

• The SEO fields. Each product's page title and meta description are edited on the product itself, in its SEO section.⁠^{[8]BigCommerce Help Center. SEO Fields} If they're empty, whatever the theme renders in their place is up to the theme.
• The custom fields. They are name and value pairs; both fields are required, each pair has to be unique within the product, and the limit is 200 per product and 250 characters per field.⁠^{[9]BigCommerce API Reference. Create Product Custom Field}
• The identifiers. SKU, MPN and GTIN. In Cornerstone, the structured data block writes each one only if the product has it, as you'll see in step 2.⁠^{[10]BigCommerce on GitHub. Cornerstone, the default Stencil theme (release 6.22.0): templates/pages/product.html, templates/components/products/ and templates/layout/base.html}

If the data isn't on the product, no theme is going to render it. If it is, the next suspect is the template.

Step 2: read what your theme's template renders

A Stencil template can only render the data it has at hand. The product page template, product.html, gets the product object by default; extra data (reviews, related products, videos) is requested with a YAML front matter block at the top of the files in templates/pages, and it can't be requested from templates/components or templates/layout.⁠^{[11]BigCommerce Dev Center. Using Front Matter}

In Cornerstone 6.22.0, the default theme, the product page is put together like this:⁠^{[10]BigCommerce on GitHub. Cornerstone, the default Stencil theme (release 6.22.0): templates/pages/product.html, templates/components/products/ and templates/layout/base.html}

• templates/pages/product.html calls the product view, declares the product_below_content region and, at the end, includes components/products/schema, which is the JSON-LD block.
• The product view renders the name in the <h1>, declares the product_below_price region, and renders the custom fields in the details list, unless the show_custom_fields_tabs theme setting is on, which moves them into a tab.
• The custom fields template loops over the product's list and writes each pair as a term and its definition:

{{#each product.custom_fields}}
  <dt class="productView-info-name">{{name}}:</dt>
  <dd class="productView-info-value">{{{value}}}</dd>
{{/each}}

The structured data block is a Product with the name, the SKU, the MPN and the GTIN if they exist, the URL, the brand, the description cut to 4,000 characters, the main image, the ratings and reviews if the store displays them, and an offer with the currency, the price (or the minimum and maximum if there's a range), the condition, the availability, and a price valid-until date that the template calculates as one year after the day the page is generated.⁠^{[10]BigCommerce on GitHub. Cornerstone, the default Stencil theme (release 6.22.0): templates/pages/product.html, templates/components/products/ and templates/layout/base.html} And two things missing: the node has no @id and includes no custom field. A shirt's fabric shows up on the product page for whoever reads it, and doesn't show up in its markup.

That's Cornerstone. A theme from the marketplace or from an agency is Stencil too, but it brings its own templates, so the only way to know what yours does is to read its files or the HTML it generates. If you're going to touch them, BigCommerce says so in its own exercises: make a copy of the theme first and test the changes on the copy.⁠^{[12]BigCommerce Developer Learning. Mini Use Case: Create a Customized Field}

Step 3: follow the widget to its region

A widget reaches a BigCommerce product page through one of two doors, and both end up in the same place.

Page Builder, for people who don't code. You open it at Storefront › Themes › Edit in Page Builder, and only on stores with a Stencil theme. You drag widgets from the menu on the left into one of the regions the theme comes with, and there's an HTML widget that accepts any HTML. The rule people forget most: saving doesn't publish. According to the Help Center, saved changes don't show on the storefront until you click Publish.⁠^{[4]BigCommerce Help Center. Page Builder} Under the hood, Page Builder places widgets with the Widgets API, the same mechanism the platform's own widgets use.⁠^{[13]BigCommerce Dev Center. Page Builder Overview}

The Widgets API, for an app or an agency. A widget is a Handlebars template plus a configuration, a JSON of up to 64 KB that carries the content the template renders. For it to appear on the storefront it needs a placement, which decides which region it goes into and in what order.⁠^{[2]BigCommerce Dev Center. Widgets API} When you create one, four fields decide whether you'll see it:⁠^{[3]BigCommerce API Reference. Create Placement}

• template_file: the page template, pages/product for product pages.
• entity_id: the product ID, if the widget is for that product page only. Without it, it shows up on all of them.
• channel_id: the channel; if you leave it out, the first one created in the store.
• status: active or inactive, and the default is inactive.

The region has to exist in the active theme. The endpoint GET /v3/content/regions?template_file=pages/product returns the regions the theme declares in that template,⁠^{[14]BigCommerce API Reference. List Theme Regions} and in Cornerstone 6.22.0 the product page has two, product_below_price and product_below_content.⁠^{[10]BigCommerce on GitHub. Cornerstone, the default Stencil theme (release 6.22.0): templates/pages/product.html, templates/components/products/ and templates/layout/base.html} The limit a large catalog hits early: 75 placements per page template.⁠^{[2]BigCommerce Dev Center. Widgets API}

What a widget publishes lives in its configuration, not in the catalog: BigCommerce defines the configuration as the JSON holding the content the template can render.⁠^{[2]BigCommerce Dev Center. Widgets API} If a widget carries a product page's markup, the price it shows is the one written into its configuration, and when the product's price changes, someone has to update the widget. One more for anyone who installs apps: the content an app's widget creates stays in the store even after you uninstall the app.⁠^{[15]BigCommerce Dev Center. Third-Party Widgets}

In the HTML, the region and the widget can be recognized by two attributes; the placement leaves no trace.⁠^{[2]BigCommerce Dev Center. Widgets API} This is what you look for on the product page (fictitious, simplified example):

<div data-content-region="product_below_content">
  <div data-widget-id="00000000-0000-4000-8000-000000000001">
    <script type="application/ld+json">
      { "@context": "https://schema.org", "@type": "Product", ... }
    </script>
  </div>
</div>

Markup that ends up in the <body> isn't a problem for Google: JSON-LD goes in a <script> tag inside the <head> or the <body>, and Google also reads it when a content management system's widgets inject it. Google uses it to understand the page and to show rich results.⁠^{[16]Google Search Central. Introduction to structured data markup in Google Search}

Step 4: check Script Manager and the theme's slots

Script Manager lives at Storefront › Script Manager and, according to the Help Center, it's a feature of stores with a Stencil theme.⁠^{[6]BigCommerce Help Center. Using Script Manager} (Catalyst reads its scripts its own way, as you'll see at the end.) Each script is configured with:⁠^{[6]BigCommerce Help Center. Using Script Manager}

• the placement, in the header or the footer;
• the pages where it loads: storefront pages, checkout, order confirmation, or all pages;
• the category for the cookie banner: essential, analytics, functional, or targeting/advertising;
• the type: a URL or the pasted code, up to 64 KB.

Look at the second line: Script Manager works by page type, not by product. A script for product pages comes out on every product page, so it's no use for one specific product's markup. That's what a widget's entity_id is for.

The script reaches the page through two slots in the theme. On Stencil, it goes into the header object or the footer object, and if the template doesn't have those expressions, the scripts for that location aren't rendered.⁠^{[5]BigCommerce Dev Center. Scripts API} Cornerstone 6.22.0 has them in templates/layout/base.html, the first before the closing </head> and the second at the end of the <body>:⁠^{[10]BigCommerce on GitHub. Cornerstone, the default Stencil theme (release 6.22.0): templates/pages/product.html, templates/components/products/ and templates/layout/base.html}

    {{{head.scripts}}}
  </head>
  ...
    {{{footer.scripts}}}
  </body>

A modified theme that has lost one of the two silently fails to render everything Script Manager sends to that location. Three more warnings from BigCommerce:

• Changes take a few seconds. Scripts have a 20-second cache, so one you've just created, changed or deleted may not show on the storefront right away.⁠^{[6]BigCommerce Help Center. Using Script Manager}
• You won't see them locally. If you develop the theme with Stencil CLI, scripts created with the Scripts API aren't rendered.⁠^{[5]BigCommerce Dev Center. Scripts API}
• The cookie banner decides. With the banner on, the shopper can reject script categories; essential scripts can't be opted out of.⁠^{[6]BigCommerce Help Center. Using Script Manager} When you check the product page, do it without accepting anything as well.

If what you're sending through Script Manager is structured data, tell two cases apart. An application/ld+json block pasted as is, is text the theme writes into the HTML like any other script. A script that builds the markup with JavaScript after the page loads is something else: Google warns that product markup generated that way can make Shopping crawls less frequent and less reliable, a problem for data that changes fast, such as price and availability.⁠^{[17]Google Search Central. Generate structured data with JavaScript}

Step 5: check it in the published HTML

Open the product page and ask for its source code: View page source in the right-click menu, or view-source: in front of the URL. Don't use the inspector in the developer tools, which shows the page after JavaScript has run. Look for:

• The exact value of the data: a custom field's text, the page title, the meta description.
• data-content-region, to see the regions your theme declares, and data-widget-id, to see the widgets that have landed in them.⁠^{[2]BigCommerce Dev Center. Widgets API}
• application/ld+json: how many blocks there are and which @type each one declares. On a product page with the theme's block and a widget's, there will be two Products, and it's worth knowing where each one comes from.
• The Script Manager scripts, in the header or just before the closing </body>, depending on the placement you chose.

What you find in the source code arrives with any download. What you see on the page and isn't there was put there by JavaScript, and only a web crawler that renders will read it; the guide on what an AI crawler sees explains who does and who doesn't.

Then look at what Google sees:

• The Rich Results Test with the URL, not by pasting the code, because pasted code comes with JavaScript limits.⁠^{[17]Google Search Central. Generate structured data with JavaScript} It tests as a smartphone unless you choose otherwise and tells you which rich result types it finds, with their errors and suggestions.⁠^{[18]Search Console Help. Rich Results Test}
• The URL Inspection tool in Search Console. View crawled page shows the HTML your server returned, the headers, the JavaScript console and the resources loaded, and the live test examines the URL at that moment, so it may not match the indexed version.⁠^{[19]Search Console Help. URL Inspection tool}

If what you want is to audit the markup itself, there's the guide to auditing a product page's structured data. And keep the two verbs apart: validating the markup is not the same as verifying it gets published. The second one, checking on the live page that every signal is there, is publication verification.

If your store runs on Catalyst

Catalyst is BigCommerce's headless frontend: a Next.js application with React Server Components that requests its data from the GraphQL Storefront API and is hosted on Vercel, on another provider that supports Next.js or, in closed beta, on BigCommerce itself.⁠^{[7]BigCommerce Dev Center. Catalyst} It doesn't load Stencil templates, and that changes all three roads:

• Widgets. Without Stencil templates there are no regions, which is where widgets land.⁠^{[2]BigCommerce Dev Center. Widgets API} The equivalent of Page Builder is Makeswift, the visual editor built into one version of Catalyst, and apps that modify the storefront, according to BigCommerce itself, generally don't work with Catalyst.⁠^{[20]BigCommerce Dev Center. Features (Catalyst)}
• Scripts. Catalyst reads the Script Manager scripts set for all pages or for storefront pages, ignores the rest, and loads them in the browser with a consent library; if the store has the banner on, the non-essential ones wait until the shopper accepts their category.⁠^{[21]BigCommerce Dev Center. Install Scripts in Catalyst} Scripts with Handlebars expressions made for Stencil don't work on Catalyst,⁠^{[20]BigCommerce Dev Center. Features (Catalyst)} and versions before 1.1 don't render the ones from the Scripts API.⁠^{[5]BigCommerce Dev Center. Scripts API}
• The template. The product page is rendered by the application's code. On the Catalyst development branch we read on October 7, 2026, the product page takes its title from the product's SEO page title or, if there isn't one, from its name; and its description from the meta description or, if there isn't one, from the first 150 characters of the description. It renders a Product block with the name, the URL, the description, the brand, the ratings, the image, the SKU, the GTIN, the MPN and an offer, and the custom fields come out in the page's specifications, not in the block.⁠^{[22]BigCommerce on GitHub. bigcommerce/catalyst, canary branch: the product page (core/app/[locale]/(default)/product/[slug]/)}

The check is the same as in step 5, with more reason: on Catalyst, what the code doesn't render doesn't exist, and the version your agency deploys may not be the one we read.

What we tested

What we checked from outside, on October 7, 2026

From one of our own computers, with no access to any admin, we read the code of Cornerstone 6.22.0 and of Catalyst on GitHub, and we requested a product page from BigCommerce's demo store, cornerstone-light-demo.mybigcommerce.com, which belongs to the platform itself.

• Two blocks, one Product. The product page answered with a 200 and two application/ld+json blocks: a BreadcrumbList and a Product. The Product has no @id, and its offer had October 7, 2027 as its price valid-until date, one year after our request, just as the template calculates it.
• Seven regions, no widgets. The HTML declared seven regions with data-content-region, among them the product page's two, product_below_price and product_below_content, and no data-widget-id: the slots were there, empty.
• A date that isn't ISO. The review inside the Product block carries "2015 Dec 15th" as its publication date. Schema.org defines the Date type as a date in ISO 8601 format,⁠^{[23]Schema.org. Date} and that string isn't one. It's the demo store, not yours, but it's a good reason to read your markup rather than take it for granted.
• No meta description. That product page's HTML had no <meta name="description"> tag.

The test on a Stencil store

• Setup. A fictitious product, labeled as such, with SKU, GTIN, page title, meta description and two custom fields, one with text and one with HTML in the value. Save the source code of its product page before you start, as a baseline.
• Five roads. (1) The custom field: does it show on the product page? And in the JSON-LD? (2) An HTML widget in Page Builder with an application/ld+json block, saved without publishing and then published. (3) A widget through the Widgets API with the product's entity_id, first without status and then active, with the API request and response. (4) A Script Manager script with an application/ld+json block pasted into the footer, in the essential category and then in analytics, with the cookie banner on and nothing accepted. (5) If the reviewer wants it, the same product on a Catalyst channel.
• For each road. Whether it appears in the source code (with the literal fragment), how long it took to appear, what the Rich Results Test detects with the URL and, if the store is verified in Search Console, View crawled page.
• Screenshots. The product page's source code with the region, the data-widget-id and the structured data blocks (the one for the image block in step 5), and the Rich Results Test, each with its date.

Tested on: store, theme and version, variant, channel, date.

The limits, as they are: one store, one theme, one version, one channel and one date. The platform's and the themes' behavior changes with every version.

When Clione publishes it

Clione publishes on BigCommerce by the road in step 3: its structured data graph is published with the Widgets API and rendered on the server, with a Product node with a stable @id next to the one the theme already renders, instead of duplicating it. Nothing reaches the store until you click Push, and then Clione requests the live product page and tells you, signal by signal, what was rendered and what wasn't.