Commerce Cloud Storefront
A Commerce Cloud Storefront is the shopper-facing website built on Salesforce Commerce Cloud.
Definition
A Commerce Cloud Storefront is the shopper-facing website built on Salesforce Commerce Cloud. It is where customers land on the homepage, browse categories, open product detail pages, run searches, add items to a cart, and complete checkout. The Storefront is the visible front end of the commerce engine. Behind it sit the catalog, pricing, promotions, inventory, and order data that the shopper never sees directly.
In B2C Commerce, a Storefront is usually built from the Storefront Reference Architecture (SFRA) or as a Composable Storefront running the PWA Kit on Managed Runtime. In B2B and D2C Commerce, the Storefront is an Experience Cloud site built with a Lightning Web Runtime (LWR) template in Experience Builder. Both models read from the same Commerce Cloud data and surface it through pages a shopper can use. The Storefront inherits branding, content, search, and SEO settings from the store configuration sitting underneath it.
How a Commerce Cloud Storefront is built and run
SFRA: the B2C reference architecture
Storefront Reference Architecture (SFRA) is the standard starting point for a B2C Commerce site. Salesforce ships it as a blueprint that pairs site-design best practices with a tested technical structure, so teams are not building a storefront from a blank page. SFRA uses a JavaScript controllers model and a model-view-controller (MVC) pattern, and it renders pages with the Bootstrap UI framework so the layout adapts across phone, tablet, and desktop. The code is organized as cartridges. The base cartridge is named app_storefront_base, and it carries the standard pages: homepage, category, product detail, search results, cart, and checkout. Customization goes into overlay cartridges that sit on top of the base in a cartridge stack, which keeps your changes separate from the Salesforce-maintained code underneath. Standard features live in the base cartridge, and optional features such as Apple Pay or a gift registry ship as separate overlays you can add. This layering is why SFRA storefronts are easier to upgrade than a fully bespoke build. You take Salesforce updates to the base and reapply your overlays on top.
Composable Storefront and the headless model
A Composable Storefront is the headless B2C option. Instead of rendering pages from cartridges, you build a custom front end with the PWA Kit, an open-source React framework, and host it on Managed Runtime, a serverless environment that Salesforce operates. The front end talks to the commerce engine through the Salesforce Commerce API (SCAPI) rather than server-side templates. The PWA Kit ships with the Retail React App, a server-side rendered storefront that already includes the pages shoppers expect: product listing, product detail, cart, and checkout. The trade is control for convenience. You get full command over markup, design, and front-end behavior, and you give up the stock UI that SFRA hands you for free. Because the front end is decoupled, you can compose other vendors into the experience, for example a third-party search provider or a separate content management system. Salesforce also supports hybrid implementations, where part of a site stays on a traditional SFRA storefront and part moves to a Composable Storefront. That lets a team roll out headless in phases instead of rebuilding everything at once.
B2B and D2C Storefronts on Experience Cloud
B2B and D2C Commerce take a different path. Their Storefront is an Experience Cloud site created in Experience Builder from a Lightning Web Runtime (LWR) template, often the commerce-specific Build Your Own template. Because the site runs on the Salesforce Platform, it sits close to Sales Cloud and Service Cloud data, which suits buyer accounts, contract pricing, and account-based ordering. You assemble pages by dropping standard Commerce components onto the canvas, then style and arrange them without writing front-end code for the common parts. When the standard components are not enough, developers add custom Lightning Web Components (LWC). Those custom components call Storefront APIs to read catalog data and run actions like adding a product to the cart, applying a coupon, or updating a wishlist. A B2B Storefront usually exposes features a consumer site does not need, such as selecting which buyer account you are purchasing on behalf of, role-based pricing, and reordering from past orders. The same template approach powers D2C stores, so a single platform skill set covers both the wholesale and direct-to-consumer fronts.
The pages a Storefront has to get right
Every Storefront, whatever the architecture, comes down to a handful of pages that carry the sale. The homepage sets the brand and routes traffic. Category and search-results pages, often called product listing pages, are where shoppers filter and compare. The product detail page is where a single item gets its description, images, price, variations, and the add-to-cart button. The cart holds selected items before purchase, and checkout collects shipping, billing, and payment to turn the cart into an order. Each page reads from the same underlying data. The catalog supplies products and categories, pricing rules set the numbers shoppers see, and promotion configuration decides which discounts apply at the cart. A weak catalog hurts findability no matter how good the design is. Confusing pricing erodes trust. A clumsy checkout drives abandonment late in the funnel, after the shopper already decided to buy. Getting these pages right is less about visual polish and more about making sure the data behind each one is clean, the price is correct, and the path from product to confirmation is short.
Performance, mobile, and SEO as design disciplines
For consumer commerce, speed is a feature. Storefront load time feeds Google Core Web Vitals such as Largest Contentful Paint, and those scores influence search ranking, so a slow site gets less traffic and converts less of what it does get. Typical B2C optimization work targets these numbers directly: compress images, lazy-load offscreen content, cache at the edge, and trim the JavaScript bundle that ships to the browser. Mobile is not a secondary surface for most retail, it is the primary one, so touch targets, page weight, and form usability on a phone decide whether a shopper finishes. SFRA renders mobile-responsive out of the box through Bootstrap, but heavy custom CSS can break that, so real-device testing matters more than a desktop browser preview. SEO is the third discipline, and it pays back over years. URL structure, meta tags, structured data, and the sitemap determine how much organic traffic the catalog earns. These are design-time decisions. Retrofitting performance, accessibility, and SEO onto a finished storefront costs far more than building them in from the start.
Personalization and the wider Salesforce connection
A Storefront rarely runs alone. It surfaces Einstein product recommendations, the "you might also like" and "customers also bought" blocks that adapt to shopper behavior, directly on category and product pages. It connects to Marketing Cloud for triggered, personalized content and to Data Cloud for a unified customer profile that can segment the experience across channels. Page Designer, the visual content tool in B2C Commerce, lets merchandisers build and schedule promotional layouts without a developer, and those layouts can flow into both SFRA and Composable Storefronts. After the sale, the order hands off to order management for fulfillment, returns, and post-purchase service, often through Service Cloud. The point is that the Storefront is the presentation layer over a connected stack. Catalog, pricing, and promotions decide what shoppers see. Einstein and Marketing Cloud decide how it is tailored. Order management and Service Cloud decide what happens after checkout. Treating the Storefront as a window onto that whole system, rather than a standalone website, is what separates a storefront that just displays products from one that actually sells them.
How to set up a B2C Commerce SFRA storefront
At a high level, standing up a B2C Commerce SFRA storefront means provisioning a site, attaching its cartridge stack, importing catalog and pricing data, and configuring search, content, and checkout. The exact steps run through Business Manager and your code repository. This is the shape of the work, not a click-by-click runbook.
- Provision the site and cartridge path
Create the storefront site in Business Manager, then set its cartridge path so the custom and SFRA overlay cartridges resolve on top of app_storefront_base. The order in the stack decides which code wins, so custom cartridges sit ahead of the base.
- Import catalog, pricing, and inventory
Load the product catalog, category structure, price books, and inventory lists the storefront will display. Pages render from this data, so nothing meaningful shows until the catalog and at least one price book are assigned to the site.
- Configure search, content, and SEO
Set up search refinements and sorting, build content slots or Page Designer pages for the homepage and landing areas, and define URL rules, meta data, and the sitemap so the catalog is findable.
- Wire up checkout and payments
Connect a payment processor, configure shipping methods and tax, and test the full cart-to-order path. Add optional features like Apple Pay through their overlay cartridges if the storefront needs them.
The ordered list of cartridges for the site. Custom overlays go before the SFRA base so your changes take precedence over app_storefront_base.
Which storefront catalog and price books the site uses. Without an assigned catalog and active price book, product and listing pages have nothing to show.
Where merchandisers place promotional content and landing layouts. Page Designer offers a visual canvas; content slots inject markup at defined positions.
The processors, shipping methods, and tax rules that drive checkout. These gate whether a shopper can actually complete an order.
- A wrong cartridge path order silently breaks customizations, because the base cartridge code runs instead of your overlay.
- Pages render empty when the catalog or price book is not assigned to the site, even though the storefront itself is live.
- Heavy custom CSS can break SFRA mobile responsiveness; test on real devices, not just a desktop browser resize.
- Skipping technical SEO at setup time is expensive to fix later, after URLs and structure are already indexed.
Prefer this walkthrough as its own page? How to Commerce Cloud Storefront in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Storefront Reference Architecture (SFRA) OverviewSalesforce
- Composable Storefront OverviewSalesforce
Straight from the source - Salesforce's reference material on Commerce Cloud Storefront.
- SFRA Features and ComponentsSalesforce
- B2B Commerce: Build Custom ComponentsSalesforce
Hands-on resources to go deeper on Commerce Cloud Storefront.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which best describes a Commerce Cloud Storefront on the Salesforce platform?
Q2. Which pair names the two main Commerce Cloud Storefront flavors?
Q3. What role does SFRA play in building a B2C Commerce Storefront?
Discussion
Loading discussion…