BigCommerce SEO: A Working Guide for Operators
Quick answer. BigCommerce SEO is mostly four decisions: which URL a product canonicalises to, which filter combinations may be indexed, what your Stencil template outputs as structured data, and which third-party scripts are allowed to load. The platform supplies generated sitemaps, editable meta fields, redirect tools and theme-level canonicals. Strategy is still yours, and defaults are not a strategy. Audit each of the four on your own storefront first.
What matters most
- BigCommerce builds a product path from the category it is filed in, so one product filed twice can be reached at two URLs; the canonical tag, emitted by the theme, decides which one competes.
- There is no per-product canonical override on the product record, so unusual canonical decisions are Stencil template work rather than a settings toggle.
- Faceted filter URLs multiply by combination and almost none deserve to rank; pick the indexable set and canonicalise or noindex the rest.
- Product JSON-LD lives in your theme, so every theme upgrade and every Page Builder edit is a structured-data regression risk.
- Script Manager and marketplace apps are the most common cause of slow Largest Contentful Paint on a BigCommerce storefront, and uninstalling an app does not always remove its script.
What does BigCommerce actually do for SEO out of the box?
More than most operators assume, and less than they need. Every BigCommerce store ships a generated XML sitemap, canonical tags emitted by the storefront theme, editable SEO fields on products, categories, brands and content pages, a redirect manager, and a Script Manager that decides which third-party code loads on which page type. That is plumbing. It sets a floor for crawling and indexing; it does not choose what you rank for.
Day one is an inspection, not a content sprint. Fetch /xmlsitemap.php and confirm products, categories and brands appear and that retired URLs do not. Open a product filed in two categories and read which URL the canonical names. Search a category page’s source for application/ld+json. Fetch robots.txt instead of assuming what it says.
Where the work lands depends on your storefront type. A Stencil theme follows the theme’s logic, so much of the control sits in Handlebars templates. A headless build on the Storefront API puts the same decisions in your own front-end code, which is more flexible and easier to get wrong.
| Surface | Where it lives | What to verify |
|---|---|---|
| Product URL and canonical | Product edit SEO tab, plus the category path the product sits in | The canonical names the URL you want indexed, not a secondary path |
| Faceted filters | Storefront product filtering settings and theme templates | Which combinations are indexable and what they canonicalise to |
| Structured data | Stencil templates, typically product.html and its components | JSON-LD price, currency and availability match the visible page |
| Third-party scripts | Storefront Script Manager and app-injected tags | What loads before the hero image renders |
| Redirects | Redirect manager, or the Redirects API for bulk work | Every legacy path resolves in one hop to a live 200 |
| Sitemap and robots | /xmlsitemap.php and the generated robots.txt | New sections included, dead paths excluded, sitemap reference present |
Where to go next
How do BigCommerce product URLs and canonicals actually behave?
A product URL on BigCommerce is not just the product name. The storefront builds the path from the category the product is filed in, so a chair filed under both outdoor and sale can be reached at /outdoor/chairs/stacking-chair/ and /sale/chairs/stacking-chair/. The custom URL field on the product’s SEO tab controls the final segment; the category portion comes from the catalogue structure. Test one product on a staging storefront before a large re-categorisation, because the exact behaviour depends on how the primary category is set.
BigCommerce’s theme places a canonical link on product and category pages, and it points at the path the theme considers primary. There is no per-product canonical override field, so anything unusual is a Stencil change rather than a toggle. Do check the SEO tab on your own store before planning around that.
Pagination is a separate decision. Page two of a category should canonicalise to itself, not to page one, so the products on it remain discoverable. Google’s guidance on consolidating duplicate URLs is the reference. Internal search results are the opposite case: they generate endless near-duplicate pages and belong out of the index.
Brand pages and category pages often chase the same head term. Pick a winner per query and link to it consistently, or two pages with identical intent will split internal links and leave the canonical arguing with itself.
Are faceted filters the biggest crawling risk on BigCommerce?
Usually, yes. Product filtering multiplies paths by combination: attribute values, brands, price bands, ratings, sort orders and pagination. A catalogue with eighty filter values does not produce eighty extra URLs, it produces a combinatorial number of them. Almost none deserve to rank, and each one competes with the category page it came from.
The decision to make is which small set of filtered views may be indexed. Category plus brand is the common choice, because those combinations match real search demand. Everything else should exist for shoppers and stay out of the index.
- Canonical an unmanaged filtered view back to its parent category.
- Add noindex to parameter patterns you never want indexed, including sort and view switches.
- If you block in robots.txt, remember a disallowed URL can still be indexed when other pages link to it; blocking stops crawling, not indexing.
- Keep pagination crawlable on the filtered views you do want indexed.
- Apply the same policy to internal search results, which are filters by another name.
What should a BigCommerce product template output?
Start with the rendered page. One H1 carrying the product name, the price and availability present in the initial HTML, a specification table with the attributes buyers search for, and short descriptive alt text on the main image. Those are merchandising inputs: alt text lives on the image record, specs live on custom fields or the attribute set.
Then the JSON-LD. Product schema needs a name, image, and offers with price, priceCurrency and availability, plus sku and brand where you have them. Use AggregateRating only where reviews are real and visible, which on most stores means the platform’s native product reviews. If you show customer-group pricing or several currencies, choose the offer the default shopper sees and keep the markup consistent with it.
Page Builder is the quiet failure point. It can add rich content to a category or product page and, with it, a second H1 or a hero image that pushes the product image down the page. Check heading order on any page that uses it.
Images deserve their own pass. Stencil’s image helper outputs responsive sources; hardcoding a link to the original CDN asset undoes that and costs you Largest Contentful Paint. A well-built product card in a grid will beat a custom card that loads full-size images.
How do you keep a BigCommerce storefront fast enough to rank?
Script Manager is the highest-leverage control you have. It governs which third-party tags load on which page type, where in the document they sit, and whether they are deferred. Most slow BigCommerce product pages are slow because a chat widget, a personalisation app, a reviews widget and a tag manager all load before the hero image.
Audit it as a list rather than a feeling. For each script: does it need to run on every page, does it need to run before the product image renders, and does anyone still own it? Remove the orphans. When an app is uninstalled, scripts it added manually often stay behind.
Some app scripts are injected in ways Script Manager cannot defer, and some themes ship their own blocking JavaScript. Confirm in the rendered HTML what actually happens instead of trusting the setting. Lab scores and field data from real users will disagree; when you must choose, choose the field data.
What breaks when you restructure a BigCommerce catalogue?
Category work is where URLs go to die. Moving a product to a different primary category can change its path; splitting a large category into subcategories changes every product beneath it. Build the redirect map before the change, not after launch.
For a handful of paths, the redirect manager is fine. For hundreds, use the Redirects API, because hand-keying a spreadsheet into a control panel is how single-hop redirects become chains. Point each old URL at the nearest live equivalent, not the homepage, and use a 301.
Before you announce anything: fetch the sitemap and confirm the new structure is in it, check old paths resolve in one hop to a 200, view source on three templates for canonical and JSON-LD, confirm robots.txt still references the sitemap, and check that app scripts survived the theme work.
Multi-storefront setups add a quieter trap. Several channels can share one catalogue, so the same product may be live on more than one domain. Each storefront needs its own canonical behaviour and its own sitemap discipline, or you create duplicate content at scale and blame the platform for it.
Where does BigCommerce SEO stop being a settings job?
Several things operators ask for do not exist as platform features. There is no automatic internal linking engine that understands query intent, no built-in cannibalisation report, and no per-URL canonical field that overrides a template decision. The native blog is limited enough that most content programmes run on a separate CMS or a headless front end.
Headless changes the answer but not the work. On a Storefront API build, metadata, canonicals, structured data, sitemaps and redirects move into the front end. BigCommerce still holds the catalogue; your framework holds the SEO output, and a missing canonical becomes your bug rather than the theme’s.
Robots.txt is worth checking rather than assuming. BigCommerce generates one for the store, and how much you can edit it has changed over time, so look at the current control panel before planning crawl rules around a file you may not control.
Frequently asked questions
Is BigCommerce good for SEO?
It does not hold you back. The platform generates sitemaps, emits canonicals, gives you editable metadata on products and categories, and provides redirect tools. What it will not do is decide your filter policy, keep structured data valid across theme changes, or stop apps from slowing the storefront. Those are operational jobs, and they are the same jobs on any commerce platform.
Do I need an SEO app for BigCommerce?
Usually not for the basics. Metadata, canonicals, sitemaps and redirects are platform features or theme output. Apps earn their place when they do something you cannot: bulk metadata editing across thousands of SKUs, structured internal linking, or feed work. Every app is another script, so weigh the feature against load cost and check what it injects before installing.
Should I shorten my product URLs?
Only when the path is wrong. Changing an indexed product URL costs a redirect and a period of uncertainty while the new URL is recrawled. Short paths are tidier, not automatically better. Spend the effort on products whose URL carries a category they should not be filed under, or whose slug still contains an old product code.
How long does it take for BigCommerce SEO changes to show?
There is no honest fixed answer. Recrawling depends on how often search engines visit your store, which depends on authority, sitemap accuracy and how many URLs you keep generating. Use URL Inspection to request a recrawl of important pages, watch coverage reports for the rest, and judge changes on trend lines rather than single days.
Can I edit robots.txt on BigCommerce?
Check the current control panel before planning around it. BigCommerce generates a robots.txt for the storefront, and the ability to edit it has not always been available. Fetch the live file and confirm what it contains, including the sitemap reference. If you need rules it will not accept, noindex tags in the theme or a headless front end are the practical routes.
Does BigCommerce product filtering create duplicate content?
It can. Filtered views are combinations of the same products, so many present near-identical listings. The fix is a policy rather than a plug-in: choose the filter combinations worth indexing, canonicalise the rest to the parent category, and noindex or disallow the patterns with no search demand. Inspect the URLs your theme actually generates first.
Sources
- Stencil theme structure and the template files that emit canonicals and structured data
- BigCommerce management APIs, including the Redirects endpoints used for bulk URL changes
- Google guidance on consolidating duplicate URLs and how canonical selection works
- Product schema properties used in JSON-LD, including offers, price and availability
Audit the four levers on your storefront
The audit checks product URL and canonical behaviour, filter crawling, structured data and script load, then hands you a prioritised list. It is a starting point for the work, not a promise about rankings.