BigCommerce Multi-Storefront: Architecture Guide

BigCommerce Multi-Storefront lets one store run several storefronts from a single back end. Each storefront is a channel that can have its own domain, theme, category tree, currencies, price list assignments and customer login rules, while products and inventory stay shared. It pays off when brands or regions sell from one catalogue but need different shopping experiences, and most of the architecture decisions are made per channel.

BigCommerce describes the feature in its Multi-Storefront overview. This guide walks through that model, the trade-offs it creates, and the checks to run before a second storefront goes live.

What is shared and what belongs to each storefront?

In BigCommerce Multi-Storefront, products, inventory and the admin live at store level, while channel assignments, category trees, currencies, price list assignments and login rules are set per channel. The table summarises the rules from BigCommerce's Multi-Storefront API guide and the reference pages linked in each section.

Multi-Storefront or multiple separate stores?

Merchants who want to run multiple BigCommerce stores have two routes: separate stores on separate accounts, or Multi-Storefront on one account. Multi-Storefront is the native way to build a multi-region store or a multi-brand set-up without duplicating the catalogue.

The strongest case is shared inventory with different customer experiences. A brand selling direct to consumers and to trade buyers, or a company running UK, EU and US storefronts from one catalogue, keeps one product record, one stock pool and one admin, with currencies and pricing set per storefront.

The case weakens when storefronts share almost nothing. If two brands have different products, different teams and different operations, separate stores keep permissions, reporting and app installs simpler. Multi-Storefront saves work only where data is genuinely shared.

A quick test: list the five data sets your teams edit most often. If most of them would be edited once and reused across storefronts, Multi-Storefront fits. If most would be duplicated per storefront anyway, it adds coordination without saving effort.

Availability and the number of storefronts allowed depend on your BigCommerce plan. Confirm both against BigCommerce's Multi-Storefront help article and your account manager before you scope the build.

How do category trees work across storefronts?

Each storefront gets its own category tree, so a UK site and a US site can organise the same products differently. BigCommerce notes that a tree can currently be assigned to one channel only and that sharing a tree across channels is on its roadmap. Until then, two storefronts with the same navigation need two trees kept in step, either by hand or by an integration.

Product availability is a separate step. A product is sold on a storefront only when it is assigned to that channel, and in a native Stencil storefront an unassigned product stays hidden. Someone has to own that assignment when a merchandiser adds a product, or new lines quietly miss a storefront at launch.

For larger catalogues, tree synchronisation and channel assignment usually belong in the PIM or middleware rather than in the admin. Our guide to PIM integration patterns for BigCommerce covers where that logic sits.

Can each storefront have its own prices and currencies?

Yes. Each channel has its own currency assignments, with a default currency and a set of enabled currencies, configured through the channel endpoints described in BigCommerce's storefront channels guide. A UK storefront can sell in GBP while an EU storefront on the same catalogue sells in EUR.

Price lists handle storefront-specific pricing. An assignment links a price list to a customer group and a channel, which lets one product carry a retail price on a consumer storefront and a negotiated price for a trade group on a wholesale storefront.

Plan the matrix before loading prices. Regions, customer groups and storefronts multiply quickly, and every combination needs an assignment. Agree a spreadsheet of channel, customer group and price list with finance before build, then test a basket on every storefront to confirm which price each customer group actually sees. For trade pricing on top of this, see our guide to BigCommerce B2B Edition pricing architecture.

Can customers use one login across storefronts?

Only if you allow it. Each channel has a setting that decides whether customers from other channels can log in. When global logins are switched off, a customer needs that channel listed in their channel_ids to sign in, as BigCommerce's guide to channel-specific customers explains.

Because emails are unique per channel, the same person can end up with two accounts on two storefronts. That is useful for separating a trade account from a personal one, but it affects CRM sync, marketing consent and loyalty balances. Decide early whether customers should have one identity across storefronts or one per storefront, and make your integrations follow that rule.

How do orders work with several storefronts?

All orders land in one admin, each tagged with the channel it came from. That is convenient for stock and fulfilment, but warehouse, finance and customer service teams need views and exports filtered by channel from day one.

Integrations need the same care. BigCommerce's Multi-Storefront overview notes that an order created through the V2 Orders API without a channel ID is associated with the default channel, so every order an ERP or marketplace connector creates that way is reported against the first storefront. Check every system that writes orders before launch; our notes on running the BigCommerce Management API in production cover where to set it.

Which settings should differ by storefront?

Shipping options, tax settings, payment methods and promotions can all differ by storefront. BigCommerce's Catalyst Multi-Storefront documentation lists them among the settings localised per storefront, so review each of them for every region before launch.

Which apps work with Multi-Storefront?

Not every app behaves well with several storefronts. BigCommerce's guidance for app developers says compatible apps must be channel aware, and that optimised apps must also keep correct channel assignments for the products, categories and orders they sync, and correct channel access for customers. Ask each vendor whether their app supports Multi-Storefront and test it on a second channel before you rely on it, because an app that only understands the default channel can block a launch late in the project.

How should SEO work across several storefronts?

Several storefronts selling the same products can compete with each other in search. Give each storefront its own domain, its own sitemap and canonical tags that point to itself. Where storefronts target different languages or regions, add hreflang annotations as Google describes in its guide to localised versions of a page. Canonical and sitemap separation should come first on any multi-storefront build, and our BigCommerce SEO service can handle it.

How does headless work with Multi-Storefront?

Headless builds use the same channel model. Each frontend is a channel with its own site URL, and a GraphQL Storefront API token is created for a list of channel IDs. Issue one token per storefront if each frontend should be limited to its own channel.

Catalyst, BigCommerce's Next.js storefront, follows the pattern. Its channel set-up guide creates a channel, adds the site URL and sets a checkout URL that must be a subdomain of the storefront domain. Stencil storefronts take a theme per channel instead: the Stencil CLI can push a theme and apply it to selected channels. For the framework choice itself, see Catalyst vs Hydrogen: the engineering decision.

What should you check before launching a second storefront?

1. Confirm plan availability and the number of storefronts your plan allows.
2. Map shared and channel-specific data using the table above, and agree it with operations and finance.
3. Create one category tree per storefront and decide how trees stay in step.
4. Assign products to channels and build a check that flags products with no channel.
5. Set currencies per channel and load the price list matrix of channel, customer group and price list, then test a basket on every storefront.
6. Set the global login rule per channel and align CRM and loyalty sync with it.
7. Review shipping, tax, payment methods and promotions for each storefront.
8. Confirm every order-writing integration sends a channel ID.
9. Test each app on a non-default channel.
10. Separate domains, sitemaps and canonicals, and add hreflang where storefronts target different languages or regions.

If you want this designed and built on your store, our BigCommerce development team can scope a Multi-Storefront rollout, from the data map to launch.

Newer related guide: BigCommerce Multi-Language Storefront: Stencil or Catalyst.