BigCommerce B2B Edition shipped Customer Groups and Price Lists as first-class features specifically because the previous workaround — a thicket of plugin-based pricing tiers, manual customer-specific catalogs, and gated category visibility — was painful for everyone running serious B2B on the platform. The new feature set is genuinely good. It's also the part of the platform where SEO most often gets misconfigured at launch, because the SEO implications of a feature designed for commerce aren't obvious until you're a few months in and something's getting indexed that shouldn't be.
Here's the practical view of how Customer Groups and Price Lists interact with SEO, what the engines should see, and what should stay gated.
What Customer Groups and Price Lists actually do
For readers coming from the SEO side rather than the commerce side, the short version:
- Customer Groups are buckets of customers — Wholesale, Retail, Contracted, Distributor, etc. Each customer belongs to one group, set at account creation or by the merchant.
- Price Lists are pricing tables tied to a Customer Group. The same SKU can have a $19.99 retail price, a $14.99 wholesale price, and a $12.49 contracted price, all expressed cleanly in different price lists.
- The storefront resolves the right price at runtime based on which customer is logged in and which Customer Group they belong to. Unauthenticated visitors see the default (usually retail) pricing — or no pricing, if the storefront is configured quote-only.
That's the commerce architecture. The SEO question is: when a crawler hits the page, what does it see, and is what it sees what we want the engines to know?
The default crawler view: retail or no price
By default, search engine crawlers and AI engine crawlers are unauthenticated visitors. They have no Customer Group. They see whatever the storefront serves to an anonymous user.
For most B2B Edition installations, that means crawlers see one of two states:
- Retail pricing. If the store publishes a default retail price, the crawler sees that price, and that's the price the engines will reference in answers.
- No pricing at all. If the store is quote-only, the crawler sees a "Request Quote" CTA where the price would be, and no transactional data.
Both can be valid. Neither involves customer-specific pricing leaking to the public layer — which is the correct outcome, both for SEO and for commercial confidentiality.
What the schema should claim
This is where many B2B Edition stores get it wrong at launch. The Product schema needs to honestly reflect what the unauthenticated user sees:
- If the page shows a retail price, the
Offer.priceshould match that retail price exactly. Schema mismatched to visible price is a known rich-result suppression trigger. - If the page shows no price (quote-only), the
Offerblock should either be omitted entirely, or useOfferwithoutpriceand withavailabilityset appropriately (InStock,PreOrder, etc.). Do NOT fabricate a price in schema to "fill the field." - For wholesale-only catalogs that are gated behind login entirely, the indexable page (often a category or product description with a CTA to log in for pricing) should use
Productwith spec data but noOffer.
The most common failure mode we see: a B2B Edition store with retail pricing visible to crawlers, but the schema still pulling the wholesale price from the default price list because someone set the schema source to the wrong list at integration time. Engines reading the schema then disagree with engines reading the rendered price, and both lose trust.
Quote-Only catalogs and indexability
Some B2B operators run quote-only catalogs across the board — no public pricing, every order routed through an RFQ. That model is valid commercially, but it raises the question of what's indexable at all.
The answer: the product detail pages should still be indexable, with full spec content, datasheets, manufacturer relationships, and Product schema (minus the Offer.price). The "Request Quote" CTA is the equivalent of "Add to Cart" for the engine — it's a transactional path, just not a self-serve one. The page still earns ranking on spec, part-number, and category intent.
What should NOT be indexable in a quote-only setup:
- Internal RFQ workflow pages.
- Quote summary pages with customer-specific terms.
- Any URL that displays customer-specific pricing or terms after authentication.
A quick robots.txt and noindex pass on those paths at launch prevents the slow leak of post-login pages into the public index.
The Customer-Group gating question
A more subtle case: some B2B Edition stores gate entire product categories or SKUs by Customer Group. "Distributor-only" products that retail customers shouldn't see at all. "Contract" products that only show up for contracted accounts.
For SEO, the question is whether those gated categories should be indexable at all.
The pragmatic answer in most cases is no. If the products are gated commercially, they should be gated from the engines too — they're not surfaces you're trying to win public ranking on, and exposing them in the index creates user friction ("I found this product but can't buy it") and competitive intel risk.
The exception: if a brand has a "distributor catalog" or "trade-only catalog" that's genuinely public but requires account approval to purchase, that can be indexable as an awareness surface — with clear CTAs about the approval path and Offer schema omitted from the gated items.
Punchout, OCI, and headless considerations
Larger B2B Edition installations often connect to buyer-side procurement systems via punchout (cXML, OCI) — Ariba, Coupa, SAP Business Network, Oracle Procurement. In those flows, the catalog is consumed in a session initiated from the buyer's procurement system, not from the public web.
Punchout sessions are inherently authenticated and inherently gated — they're behind cXML credentials. They are not an SEO surface, but the underlying product data feeding the punchout catalog IS the same data feeding the public storefront and the schema. The data quality work has compound benefits: better punchout catalogs and better SEO from the same source-of-truth improvements.
The same principle applies for headless storefronts on B2B Edition. The headless layer changes how the page renders, but the schema and the indexable content still need to be present and honest in the response the crawlers see. Headless without server-rendered (or pre-rendered) Product schema is a recurring source of SEO regressions on the platform.
Where AI engines fit
AI engines — ChatGPT, Perplexity, Claude, Gemini — read Product schema and use it to answer commerce queries: "where can I buy [product]," "what's the price of [SKU]," "what distributors carry [manufacturer] [series]." For B2B Edition stores, that means:
- Public retail pricing in schema gets cited as the price.
- Quote-only pages get cited as available but without a price quote — usually with a note that pricing is by quote.
- Schema misalignment (visible price ≠ schema price) gets the brand demoted in citation priority for that query.
Cleaning up the schema-to-visible-price match is one of the highest-yield AEO fixes for B2B Edition stores. We document the broader AI citation methodology on citation share monitoring; the data view is in /reports/state-of-ai-shopping-citations-2026.
Where to start
For a B2B Edition store operator who wants SEO and commerce architecture aligned:
- Audit what the unauthenticated crawler sees on each major page type — retail price, no price, login wall.
- Audit the schema for matching what's visible. Fix mismatches first; they're the easiest gains.
- Decide for each gated catalog whether it should be indexable as awareness or kept out of the index entirely.
- Confirm the quote-only paths have clean schema (Product without Offer.price) and clear "Request Quote" CTAs.
- Confirm the punchout/headless/API surfaces aren't accidentally exposing customer-specific data to the public crawler.
We cover the full platform-specific playbook on BigCommerce B2B SEO. The platform comparison for teams choosing between platforms is on BigCommerce vs Shopify for B2B. The broader B2B view is on B2B eCommerce SEO, and the paid side is on B2B PPC.
If you want to talk through what a B2B Edition SEO engagement looks like for your specific catalog and pricing structure, we'd like to hear from you.
