BigCommerce has a reputation as the platform for deep catalogs, and the reputation is mostly earned. The catalog model separates variant options from modifiers, offers three different places to store extra product data, and lets one back office feed several storefronts and marketplaces at once. The catch is that every one of those features rewards a decision made early and punishes a decision made late.
Most catalog pain on BigCommerce does not come from missing features. It comes from a merchant who put size into a modifier, stored a GTIN in a custom field, or built a second storefront before deciding which data should differ by channel. This guide walks through how each catalog data type works, where it ends up, and which setup choices are cheap to make on day one and expensive to unwind on day five hundred.
In short
- Variant options create purchasable SKUs with their own price, stock and identifiers; modifiers only change the line item and never create a SKU.
- Custom fields are public name and value pairs that themes show on the product page; metafields are API-only, namespaced and hidden unless a permission setting exposes them.
- Channel feeds read structured catalog fields (brand, GTIN, MPN, variant attributes) far more reliably than free-form custom fields.
- Multi-storefront catalogs share one product record, so per-channel differences belong in channel assignments, price lists and category trees rather than duplicated products.
- Most suppressed listings trace back to a handful of fixable data errors: missing identifiers, mismatched variant images, and option names a feed cannot map.
If you are still deciding on a platform, our broader guide on how to choose the right e-commerce platform for your store covers the tradeoffs before you commit to a catalog model. This article assumes BigCommerce is already the choice and focuses on the data layer underneath it.
Variant options versus modifiers and why the difference matters
BigCommerce splits product options into two families, and the split is the single most consequential catalog decision you will make. Variant options (the control panel calls them variant options, the API calls the results variants) multiply out into SKUs. A T-shirt with four sizes and three colors produces twelve variants, and each one can carry its own SKU code, price, weight, stock level, image, UPC or GTIN, and MPN.
Modifier options do something different. They change the cart line without creating a new purchasable record. Engraving text, a gift-wrap checkbox, a file upload for a custom print, or a date picker for a delivery slot are all modifiers. A modifier can adjust price or weight through rules, but there is no separate inventory count behind it and no separate identifier for a feed to read.
The test that decides which family an attribute belongs to
Ask one question about every attribute: does a shopper choosing a different value receive a physically different item that you count in stock? If yes, it is a variant option. If the warehouse picks the same item and the choice only changes what you do to it, it is a modifier.
Size, color, material and pack count usually pass the test. Personalization text, gift messages, assembly service and extended warranty usually fail it. The gray zone is made-to-order goods, where a fabric choice may be a modifier for a small workshop but a variant for a brand that holds fabric stock per SKU.
Why getting this wrong is expensive
Feeds and marketplaces only see variants. If size lives in a modifier, Google Merchant Center receives one item instead of six, with no size attribute, and apparel listings in many markets need size and color to serve. Inventory sync to a marketplace cannot decrement stock for a size that does not exist as a record.
Converting modifiers to variant options later is not a toggle. Every affected product needs new options, new variants, new SKU codes, re-mapped images and a re-linked order history, and any external system that keyed on the old product-level SKU has to be updated. On a catalog of a few thousand products, that is a project, not an afternoon.
Limits worth knowing before you design
BigCommerce publishes per-product limits on SKUs and options in its developer documentation, and as of this writing the documented ceiling is 600 SKUs per product. That number sounds generous until a configurable product with five sizes, eight colors and three lengths reaches 120 combinations and someone proposes adding a fourth dimension. Check the current limits on the BigCommerce developer documentation before modeling a highly configurable line, because limits and recommended patterns change.
| Attribute behavior | Variant option | Modifier option |
|---|---|---|
| Creates a purchasable SKU | Yes, one per combination | No |
| Own inventory count | Yes | No (inherits from base product or variant) |
| Own GTIN, UPC and MPN | Yes | No |
| Own image | Yes | Only through rules, limited |
| Visible to shopping feeds | Yes, as separate items with a shared group | Generally not |
| Typical uses | Size, color, material, pack size | Engraving, gift wrap, file upload, delivery date |
| Cost of changing later | Moderate (re-mapping images and SKUs) | High when converting to variants |
Custom fields and metafields: where each belongs
Beyond the core product record (name, description, brand, weight, dimensions, identifiers, categories), BigCommerce gives you two general-purpose containers for extra data. They look similar in a spreadsheet and behave very differently in production.
Custom fields: public by design
Custom fields are simple name and value pairs attached to a product. Stock themes such as Cornerstone render them on the product page, often as a specifications list, and they are exportable through the standard product CSV. That makes them convenient for merchandisers who want to add “Fit: Relaxed” or “Care: Machine wash cold” without a developer.
The convenience is also the risk. Anything in a custom field is customer-facing by default, so supplier cost, internal buyer codes or compliance notes do not belong there. Custom fields are also product-level, not variant-level, which means they cannot describe something that differs between sizes or colors.
Metafields: private, structured and scoped
Metafields are created and read through the API rather than the product form. Each one has a namespace, a key, a value and a permission setting that decides whether only the creating app can see it, whether other apps can read or write it, and whether it is exposed to the storefront through the GraphQL Storefront API. Metafields can attach to products, variants, categories, brands and several other objects, which custom fields cannot.
That scope is the reason metafields suit integration data: an ERP item number, a PIM record ID, a supplier lead time, a per-variant hazardous goods flag, or the source of truth timestamp an integration uses to avoid overwriting newer edits. A headless storefront can also read them, which is one reason teams that run a decoupled front end lean on metafields, as covered in our piece on BigCommerce headless setup without a full dev team.
Where structured attributes should actually live
The most common mistake is using either container for data BigCommerce already has a dedicated field for. Brand, GTIN, UPC, MPN, weight, dimensions, condition and search keywords all have native fields, and feed integrations read the native fields first. A GTIN typed into a custom field called “EAN” may display beautifully on the page and still leave every Google listing flagged for a missing identifier.
| Data type | Best home | Why |
|---|---|---|
| Brand, GTIN, UPC, MPN | Native product and variant fields | Feed apps map these automatically |
| Shopper-facing specs (fit, care, material) | Custom fields | Themes render them without code |
| Variant-specific specs (color hex, size chart ID) | Variant metafields | Custom fields cannot vary by variant |
| Integration IDs and sync timestamps | Metafields, app-only or read permission | Hidden from shoppers, scoped to apps |
| Feed-only attributes (age group, gender, product type) | Feed tool mapping or metafields | Keeps the product page clean |
| Internal cost and margin | Native cost price field or ERP | Never expose in custom fields |
Product data discipline is not a BigCommerce-specific problem, and the same principle runs through our pillar on product data that sells across catalogs, attributes and the digital shelf: decide where each attribute lives once, then make every channel read from that single home.
Mapping catalog data to Google and marketplace feeds
BigCommerce merchants typically reach Google Shopping and free listings through the Google channel integration in the Channel Manager, and reach larger marketplace and ad networks through feed management, often Feedonomics, which BigCommerce acquired in 2021. Both routes read the same catalog, so a clean catalog pays off twice.
How variants become items in a feed
Google’s product data specification treats each variant as its own item, joined to siblings by an item group ID. In practice, the BigCommerce parent product becomes the group and each variant becomes an item with its own ID, price, availability, image and identifier. Variant option names need to map to Google attributes such as color, size, material and pattern, which is why an option called “Colour / Finish” is harder to map than one called “Color”.
Google publishes the full list of required and recommended attributes in its Merchant Center product data specification, and requirements differ by country and category. Apparel, for instance, has stricter attribute expectations in several markets than home goods. Treat the specification as the contract and your catalog as the source that must satisfy it.
The fields feeds care about most
- Identifiers: GTIN where one exists, otherwise brand plus MPN. Leaving both empty on branded goods is a leading cause of limited performance.
- Availability and price: these must match the landing page at crawl time, so variant-level stock and price need to be accurate, not approximated at product level.
- Images: each variant should point at an image that shows that variant. A red sweater item that lands on a blue default image invites a mismatch flag.
- Product category and type: your own category path helps feed tools assign a Google product category, but explicit mapping is more reliable.
- Shipping weight: accurate weight lets carrier-calculated shipping rates in Merchant Center reflect reality.
Google is also changing how merchants push data. It has announced the replacement of the Content API for Shopping with the newer Merchant API, and feed apps are migrating accordingly. We looked at what that shift may mean for smaller merchants in our analysis of the Content API sunset and two data tiers; the short version is that structured, complete catalogs carry over cleanly and patched ones do not.
Feeds for AI shopping surfaces
The same structured data now feeds AI shopping assistants and agent checkouts, which tend to reward completeness and consistent attribute naming over clever titles. If you are preparing a catalog for that use, our guide to product feeds for AI shopping agents and the fields that decide inclusion lists the attributes that matter beyond the classic Shopping set.
Multi-storefront catalogs and channel-level overrides
BigCommerce Multi-Storefront (often shortened to MSF) lets one store run several storefronts, each a channel with its own domain, theme and settings. Crucially, the storefronts share one catalog. A product exists once, and each channel decides whether it can see that product and how it is presented.
What can differ by channel
- Product assignment: which products are visible on which storefront.
- Category trees: each channel can have its own tree, so the same product can sit in “Workwear” on a trade site and “Outdoor” on a consumer site.
- Pricing: price lists can be assigned per channel, which is how a single SKU sells at different prices or currencies.
- Some content: depending on plan and current feature set, certain product fields can be overridden per channel; check current documentation before relying on any specific override.
The duplicate product trap
Teams that came from platforms without shared catalogs often clone products so each storefront can have its own copy. On BigCommerce this undoes the main advantage of MSF. Inventory splits across duplicates, reviews fragment, feeds publish near-identical items that compete with each other, and every price change has to be made twice.
The better pattern is to keep one product per real item and push differences into channel assignment, channel category trees and channel price lists. If a storefront genuinely needs different copy, that is a reason to look at per-channel content overrides or a headless front end that reads alternative copy from metafields, not a reason to duplicate the SKU.
Duplicate content and variant URLs
Separate storefronts on separate domains that show the same product description raise ordinary duplicate content questions. Canonical tags, distinct category copy and differentiated descriptions on the highest-traffic products are the usual answers. The same logic applies within one storefront to variant URLs, which we cover in product variant URLs and SEO: canonicalize, index or block.
Price lists, customer groups and B2B catalog data
Pricing is catalog data too, and on BigCommerce it has three layers: the base price on the product or variant, customer group rules, and price lists. Which layers you can use depends on your plan, so confirm current feature availability against the plan comparison before designing around one.
Customer groups
Customer groups bundle shoppers so you can apply category-level or product-level discounts, restrict category visibility, and segment checkout behavior. They are the simplest way to give trade buyers a percentage off or to hide wholesale-only categories from retail visitors.
Price lists
Price lists set explicit prices, including at the variant level, and can be assigned to customer groups and to channels. They suit negotiated pricing, multi-currency storefronts, and any case where a percentage discount does not describe the real deal. A price list record can also carry tiered pricing, so “10 or more units at this price” lives in the catalog rather than in a promotion.
B2B Edition and the account layer
BigCommerce B2B Edition adds company accounts, buyer roles, quotes, purchase order payment and shared shopping lists. From a data perspective, the key point is that B2B features layer on top of the same catalog, so clean variants and identifiers matter just as much for a wholesale portal. If you are weighing BigCommerce against its main rival for this use, see BigCommerce versus Shopify for B2B and high-SKU catalogs; for the cost side of that decision, our breakdown of BigCommerce pricing tiers without the marketing fluff shows which plan unlocks which pricing tools.
| Pricing tool | Granularity | Best for | Watch out for |
|---|---|---|---|
| Base price and sale price | Product or variant | Retail pricing and simple sales | Variant prices override product price in feeds |
| Customer group discounts | Store, category or product | Percentage trade discounts, visibility rules | Hard to audit when rules stack |
| Price lists | Variant, with tiers | Negotiated, contract and multi-currency pricing | Plan-dependent; needs ownership to stay current |
| B2B Edition quotes | Per quote | One-off or large orders | Quoted prices sit outside the catalog by design |
Comparable setups exist elsewhere: Adobe Commerce, for example, handles company accounts and shared catalogs in a related way, as described in our explainer on Adobe Commerce B2B company accounts, quotes and price lists. The concepts transfer even where the field names do not.
Bulk edits and the API routes worth knowing
Once a catalog passes a few hundred products, editing one product at a time stops being an option. BigCommerce offers three bulk paths, and each fits a different kind of change.
Control panel bulk edit
The in-panel bulk editor handles quick changes to price, stock, visibility and a few other fields across a filtered product list. It is the right tool for a merchandiser fixing twenty prices before a sale, and the wrong tool for restructuring options or identifiers.
CSV import and export
CSV import and export is the workhorse for catalog-wide edits that a non-developer runs. Export, edit in a spreadsheet, re-import with matching identifiers. The risks are well known: spreadsheets strip leading zeros from GTINs and UPCs, convert long numbers to scientific notation, and silently reformat dates. Format identifier columns as text before saving, and always test an import on a small subset first.
The Catalog API
For integrations and anything recurring, the REST Catalog API (version 3) is the reference route. The routes merchants and developers lean on most are:
- Products: create, read, update and batch update products, with include parameters to pull variants, images, custom fields and options in one call.
- Variants: read and batch update variants across products, which is the efficient way to sync stock, price and identifiers from an ERP.
- Options and modifiers: manage option structure per product; this is where a modifier-to-variant migration happens.
- Custom fields and metafields: separate sub-resources under products and variants, so a sync must handle them explicitly.
- Channel assignments and price lists: separate APIs that control MSF visibility and pricing per channel or group.
BigCommerce applies rate limits that vary by plan, and batch endpoints cap how many records one request can carry. A well-built integration batches updates, respects rate limit headers, and writes only fields that actually changed. Pushing a full product payload on every sync is the fastest way to overwrite a merchandiser’s manual edit and to hit throttling during a busy period.
Webhooks for keeping systems in step
Product, SKU and inventory webhooks let external systems react to catalog changes instead of polling. A PIM or feed tool that listens for product updates can refresh only what changed, which keeps feeds fresher and lowers API load. Webhooks are delivery notifications, not guarantees, so a periodic reconciliation job is still worth running.
Common data errors that suppress listings
Suppression in Merchant Center or a marketplace rarely has an exotic cause. On BigCommerce catalogs, the same handful of errors account for most disapproved or limited items, and nearly all of them start in the catalog rather than the feed.
Identifier problems
Missing GTINs on branded products, GTINs typed into custom fields instead of native fields, and GTINs shared across variants are the top three. Each variant that is a distinct trade item needs its own identifier. A product-level GTIN copied to every size will either fail validation or merge items that should be separate.
Price and availability mismatches
Feeds compare submitted price and stock with what the landing page shows. Customer group pricing that changes the displayed price for logged-in users, sale prices that expire between feed refreshes, and variant pages that default to an out-of-stock option can all trigger mismatches. Refresh feeds often during promotions and make sure the default variant on the page is the one the feed item describes.
Variant attribute and image problems
- Option names that do not map to standard attributes (“Shade” instead of “Color”, “Dimensions” instead of “Size”).
- Option values with internal codes (“BLK-01”) rather than shopper-facing words (“Black”).
- Variants with no image, which makes the feed fall back to the parent image showing a different color.
- Apparel items missing age group or gender, which some markets require for full eligibility.
Policy and content issues
Titles stuffed with promotional text, descriptions copied from manufacturers with prohibited claims, and landing pages blocked from crawlers also cause suppression, but these are content and site problems rather than catalog structure. The fix is the same discipline: write titles and descriptions as product facts, and keep promotions in promotion fields.
| Symptom in feed diagnostics | Likely catalog cause | Fix in BigCommerce |
|---|---|---|
| Missing identifier | GTIN stored in a custom field or left empty | Move to native GTIN or UPC field per variant |
| Price mismatch | Group pricing or expired sale price on the page | Align feed price source, refresh feed after changes |
| Availability mismatch | Product-level stock while variants track separately | Track inventory at variant level |
| Image mismatch | Variants without their own images | Assign an image to every variant |
| Missing color or size | Attribute stored as a modifier or unmappable option name | Convert to variant option and use standard names |
| Duplicate items | Cloned products across storefronts | Consolidate to one product with channel assignments |
A setup checklist that avoids rework later
The cheapest moment to fix catalog structure is before the first import. The next cheapest is now. A short checklist, agreed between merchandising, operations and whoever owns integrations, prevents most of the problems above.
- Write an attribute map. For every attribute, record its home (native field, variant option, modifier, custom field or metafield) and its owner.
- Standardize option names and values. Use the words feeds expect, and keep internal codes in SKUs or metafields.
- Track inventory and identifiers at variant level for anything sold in more than one size, color or pack.
- Decide channel differences before launching a second storefront. List what differs by channel and confirm the platform supports it without cloning products.
- Pick one system of record per field. If the ERP owns stock and price, the control panel should not be where those are edited.
- Protect identifiers in spreadsheets. Text-format GTIN and UPC columns every time.
- Review feed diagnostics weekly. New errors usually point at a recent catalog change, and catching them early keeps the fix small.
None of this is glamorous, and none of it shows up in a platform demo. It is, however, the difference between a catalog that scales into new channels with a configuration change and one that needs a rebuild every time the business adds a market. For the wider picture of how attribute quality drives visibility on every shelf, return to our pillar on product data and the digital shelf, which sets out the cross-platform framework this BigCommerce setup plugs into.
FAQ on BigCommerce catalog setup
What is the difference between a variant option and a modifier on BigCommerce?
A variant option creates separate purchasable SKUs, each with its own price, stock, image and identifiers. A modifier changes the cart line (for example engraving text or gift wrap) without creating a SKU, so it has no separate inventory or identifier and is generally not visible to shopping feeds.
Should I use custom fields or metafields for product specifications?
Use custom fields for shopper-facing specifications that are the same across all variants, because themes display them without code. Use metafields for data that is private, used by integrations, or differs by variant, because metafields can attach to variants and carry permission settings that hide them from the storefront.
Do custom fields show up in Google Shopping feeds?
Not reliably. Feed integrations read native fields such as brand, GTIN and MPN first, and custom fields usually require explicit mapping in a feed tool. Storing an identifier in a custom field is one of the most common reasons BigCommerce listings show a missing identifier warning.
How many variants can a BigCommerce product have?
BigCommerce documents a per-product SKU limit in its developer documentation, which stood at 600 SKUs per product as of this writing. Limits can change, so check the current documentation before modeling products with many option dimensions.
Can different storefronts show different prices for the same product?
Yes. With Multi-Storefront, price lists can be assigned per channel, so one product record can sell at different prices or in different currencies on different storefronts. Availability of price lists depends on your plan, so confirm it against the current plan comparison.
Is it a good idea to duplicate products for each storefront?
Usually not. Duplicates split inventory, fragment reviews, create near-identical feed items and double every price change. Keeping one product and using channel assignments, channel category trees and channel price lists preserves the main advantage of a shared catalog.
What is the safest way to bulk edit GTINs and UPCs?
Use the Catalog API for recurring syncs, or CSV import for one-off edits with identifier columns formatted as text. Spreadsheet software often strips leading zeros and converts long numbers to scientific notation, which corrupts identifiers silently. Test any import on a small subset first.
Why are my BigCommerce products disapproved in Merchant Center?
The most frequent causes are missing or shared identifiers, price or availability mismatches between the feed and the landing page, variants without their own images, and option names that do not map to standard attributes. Merchant Center diagnostics name the issue per item, and most fixes happen in the catalog rather than the feed.
Can I convert modifiers to variant options after launch?
Yes, but it is a migration rather than a setting. Each affected product needs new variant options and variants, new SKU codes, re-mapped images and updated identifiers, and any external system that referenced the old SKUs must be updated. Plan it as a project and run it on a test subset before touching the full catalog.