Product Page SEO for BigCommerce: What to Fix First
Quick answer. Product page SEO on BigCommerce is won or lost in the product record: page title, meta description, unique description copy, image alt text, a clean custom URL, plus a canonical tag and Product structured data that the theme outputs. Clean the catalogue data first, then the theme, then the filter and pagination URLs. Feeds and site search inherit the same record.
What matters most
- Most BigCommerce product page problems are catalogue data problems, not template problems: empty page titles, supplier descriptions and missing alt text do more damage than theme code.
- The Search Keywords field drives storefront search only; it is not a Google ranking input, so treat it as merchandising data.
- Decide which facets are indexable before you touch robots.txt; a disallow stops crawling and also stops Google following product links on filtered pages.
- Structured data has to match the rendered page and the theme may already emit JSON-LD, so audit the source before adding a second block.
- Measure groups of pages fixed in the same pass, using Search Console page-level data, because single-product traffic is too noisy to read.
What does product page SEO on BigCommerce actually involve?
Five things decide whether a BigCommerce product page ranks: the product record, the theme that renders it, the URL and canonical tag, the structured data in the page source, and the feed that sends the same data to shopping engines. Three of those are data entry. Only one is code, and even that is usually a theme setting rather than a build.
Most stores lose organic traffic long before the template. A product with an empty Page Title, a description pasted from the supplier and an image alt of IMG_0432 gives Google nothing to separate it from the other retailers selling the same SKU. BigCommerce will publish it without complaint. The fix is a catalogue pass, not a redesign.
Work in order: data, template, URLs, markup, feed. Each layer inherits from the one before it. Changing the template while the fields are still empty just renders blank fields faster.
- Product record: name, Page Title, Meta Description, description, brand, SKU, images and alt text, custom URL.
- Theme: the Stencil product template and its partials, or a headless storefront, whichever controls the title tag, canonical, breadcrumbs and JSON-LD.
- URL policy: canonical tags, filter parameters, pagination, variant handling.
- Structured data: Product and Offer markup that matches what the buyer sees.
- Feed: the Merchant Center or marketplace feed built from the same catalogue rows.
Where to go next
Which BigCommerce fields actually control what Google sees?
Each product carries an SEO panel with a Page Title, a Meta Description, a custom URL and a Search Keywords field. Two of those are Google-facing. The third is not.
Search Keywords is read by the storefront’s own search and by category product matching. It has no effect on Google rankings and on most themes it never reaches the page source. It is still worth filling in, because internal search converts well, but do not spend a day on it expecting organic lift.
Page Title is where the leverage sits. Left blank, most Stencil themes fall back to the product name, which is survivable but generic. Product name plus the attribute that actually differentiates the listing — model, material, size, pack count — is better. Meta Description behaviour when blank is theme-dependent, so check the rendered HTML of a live page rather than assuming a fallback exists.
| Element | BigCommerce field | Where to edit | What to check |
|---|---|---|---|
| Title tag | Page Title | Product editor, SEO panel | Blank falls back to product name on most themes |
| Meta description | Meta Description | Product editor, SEO panel | No reliable default; confirm in page source |
| On-page copy | Description | Product editor, WYSIWYG or HTML | Supplier copy duplicated across retailers |
| Image alt text | Set per image record | Product images | Alt text should describe the product, not the file |
| URL | Custom URL | Product editor, SEO panel | Changing it later needs a 301 redirect |
| Storefront search | Search Keywords | Product editor | Not a Google signal; merchandising only |
How should you handle filter, variant and pagination URLs on BigCommerce?
The built-in product filtering produces URLs with parameters, and the exact shape depends on the theme. A Stencil storefront and a headless one can generate different patterns for the same facet. Crawl your own store to see what you actually emit instead of copying a fix from a forum thread.
Decide in advance which facets deserve to be indexed. A brand facet or a product-type facet usually earns a crawlable URL and its own copy. Colour, size and price sorts usually do not. Everything else stays parameter-only, kept out of the index with canonical tags or a noindex meta tag rather than a robots.txt disallow. A disallow stops Google crawling the page, which also stops it following the product links that only appear on that page. Canonicals are the safer tool for near-duplicate facet pages.
Pagination needs the same care. Page two of a category is a real page with real products on it, and Google’s guidance is to let each page represent itself rather than pointing every page at page one. For variants, one canonical product URL is enough unless each variant carries genuinely different content, which is rare outside configurable products with their own copy.
Fix URL shape before a launch or a replatform, not after. Every later change costs redirects, and redirect chains accumulate on commerce sites faster than anyone expects.
- One canonical product URL per product; variants inherit it unless the content genuinely differs.
- Let paginated category pages canonicalise to themselves.
- Choose a handful of indexable facets with real copy, not forty empty ones.
- Never robots-block a page you rely on for product discovery.
- Keep filter parameters out of the sitemap.
What structured data should a BigCommerce product page carry?
A Product block with name, image, description, sku, brand and an offers section covering price, priceCurrency, availability and url. Add priceValidUntil and shipping details where you have accurate data. Follow Google’s product structured data documentation rather than a snippet from an agency blog, because the required and recommended properties change.
Audit what the theme already outputs before adding anything. Many Stencil themes ship JSON-LD, and a second hand-added block that disagrees with the first is worse than no markup at all. View source on a live product page and search for application/ld+json. If there is one block, extend it; if there are two, delete one.
For reviews, mark up only reviews you actually collect and display, and re-check eligibility rules periodically. Google has changed which review snippets it shows more than once, and a markup block that does not match the visible page is a liability. Markup cannot rescue a wrong price, a missing variant or an out-of-stock item either.
Use gtin, mpn, color, size and material attributes only where the values are real. Invented GTINs get feeds disapproved and undermine the identifiers that tie a page to a product across the web.
Do product feeds need different data from the page?
A Merchant Center feed is built from the same catalogue rows but has its own field list: id, title, description, link, image_link, availability, price, brand, and GTIN or MPN where applicable. The feed title and the page title can legitimately differ, because the feed has a tight character budget and no room for a brand suffix. Price and availability must match the landing page, or the item gets disapproved.
The same record also feeds AI answer engines, which read the rendered page rather than a feed file. Unique description copy, a spec table and unambiguous availability help both channels, which is why it pays to fix the record rather than patching the feed.
Feed tooling earns its keep on large catalogues. BigCommerce’s channel manager and third-party feed apps can map fields and apply rules across thousands of SKUs. That is plumbing. It will not write a description that differentiates your listing from the same product on a competitor’s site.
How do you measure whether the work paid off?
Search Console is the primary source. Filter the Performance report to your product URL pattern and compare a defined before-and-after window. Use the Page indexing report to catch products excluded by a canonical or noindex rule you did not intend. Merchant Center covers the feed side, where disapprovals are usually a data problem rather than a policy problem.
On the revenue side, segment ecommerce reporting by landing page. Compare groups of pages fixed in the same pass, such as every product in one category, rather than a single page. Single-product traffic is noisy enough that a good week proves nothing.
Be honest about the limits. You cannot cleanly separate SEO from seasonality, a price change or a paid campaign running at the same time, and BigCommerce’s built-in reporting is thin on query-level detail. Site search terms are visible if you capture them in your analytics platform, and they often reveal gaps in the catalogue that matter more than any meta description.
This is the kind of work we run for brands on BigCommerce and other commerce platforms, and it starts with a technical audit of the catalogue rather than a content calendar.
Frequently asked questions
Do BigCommerce product pages come SEO-ready out of the box?
They come with the fields, not the content. Every product has slots for Page Title, Meta Description, a custom URL and image alt text, and most Stencil themes output a canonical tag and some JSON-LD. What is missing is filled-in copy: titles, descriptions and alt text. The platform provides the mechanism; the catalogue work is still yours.
Does the BigCommerce Search Keywords field help Google rankings?
No. Search Keywords is read by the storefront’s own search and by category product matching. It is not a ranking input for Google and on most themes it never appears in the page source. Fill it in because internal search converts well, but treat it as merchandising data rather than an SEO field.
Should I noindex faceted filter URLs on BigCommerce?
Usually yes for the ones that cannot earn traffic, but use canonical tags or a noindex meta tag rather than a robots.txt disallow. A disallow stops Google crawling the page, which also stops it following the product links on it, and blocked URLs can still be indexed if something links to them. Keep a few facets indexable with real copy.
How do I bulk-edit product SEO fields in BigCommerce?
Use the product export and import. Export the catalogue, edit the Page Title and Meta Description columns in a spreadsheet, then import back, checking the exact header names your store uses first. For repeated or partial jobs, the Catalog API lets you read and patch products by ID, which is safer than re-importing thousands of rows to change a few.
Why don’t my BigCommerce product reviews show stars in Google?
Usually one of three causes: the review markup is not in the rendered HTML, it does not match what is visible on the page, or the page is not eligible under Google’s current review snippet rules. Check a live URL in the Rich Results Test, confirm the aggregate rating is computed from reviews you actually display, and expect the eligibility rules to change.
Sources
- BigCommerce Catalog products API, including product SEO fields such as page_title, meta_description and custom_url
- Google’s product structured data requirements and property list
- Google guidance on ecommerce site structure, faceted navigation and pagination
- schema.org Product type definition
Start with the catalogue, not the content calendar
A 5 Kings SEO audit checks your BigCommerce product records, canonical and filter rules, structured data and feed against what Google and shopping engines actually see. You get a prioritised list of what to fix and in what order.