BigCommerce B2B Edition: Customer Groups + Price Lists, y lo que el SEO debería ver

BigCommerce B2B Edition lanzó Customer Groups y Price Lists como funciones principales precisamente porque la solución anterior (una maraña de niveles de precios basados en plugins, catálogos manuales por cliente y visibilidad restringida de categorías) era un dolor de cabeza para todos los que manejaban un negocio B2B serio en la plataforma. El nuevo conjunto de funciones es realmente bueno. También es la parte de la plataforma donde el SEO se configura mal con más frecuencia al lanzar, porque las implicaciones de SEO de una función diseñada para el comercio no son evidentes hasta que pasan unos meses y algo que no debería indexarse se está indexando.

Esta es la visión práctica de cómo interactúan los Customer Groups y las Price Lists con el SEO, qué deberían ver los buscadores y qué debería quedar restringido.

Qué hacen realmente los Customer Groups y las Price Lists

Para quienes vienen del lado del SEO y no del comercio, la versión corta:

• Los Customer Groups son grupos de clientes: mayoristas, minoristas, con contrato, distribuidores, etc. Cada cliente pertenece a un grupo, que se asigna al crear la cuenta o lo define el comerciante.
• Las Price Lists son tablas de precios vinculadas a un Customer Group. El mismo SKU puede tener un precio minorista de $19.99, un precio mayorista de $14.99 y un precio por contrato de $12.49, todos expresados de forma limpia en distintas listas de precios.
• La tienda determina el precio correcto en tiempo real según qué cliente inició sesión y a qué Customer Group pertenece. Los visitantes sin sesión ven el precio predeterminado (normalmente el minorista), o ningún precio si la tienda está configurada solo para cotizaciones.

Esa es la arquitectura comercial. La pregunta de SEO es: cuando un rastreador llega a la página, ¿qué ve, y lo que ve es lo que queremos que sepan los buscadores?

Lo que ve el rastreador por defecto: precio minorista o ningún precio

Por defecto, los rastreadores de los motores de búsqueda y de los motores de IA son visitantes sin sesión. No tienen Customer Group. Ven lo que la tienda le muestra a un usuario anónimo.

En la mayoría de las instalaciones de B2B Edition, eso significa que los rastreadores ven uno de dos estados:

1. Precio minorista. Si la tienda publica un precio minorista predeterminado, el rastreador ve ese precio, y ese es el precio que los buscadores mencionarán en sus respuestas.
2. Ningún precio. Si la tienda funciona solo con cotizaciones, el rastreador ve un CTA de "Request Quote" donde iría el precio, y ningún dato transaccional.

Ambos pueden ser válidos. Ninguno implica que los precios específicos por cliente se filtren a la capa pública, que es el resultado correcto tanto para el SEO como para la confidencialidad comercial.

Lo que debería declarar el schema

Aquí es donde muchas tiendas de B2B Edition se equivocan al lanzar. El schema de Producto debe reflejar honestamente lo que ve el usuario sin sesión:

• Si la página muestra un precio minorista, el Offer.price debe coincidir exactamente con ese precio minorista. Un schema que no coincide con el precio visible es un detonante conocido de la supresión de resultados enriquecidos.
• Si la página no muestra precio (solo cotización), el bloque Offer debe omitirse por completo, o usar Offer sin precio y con availability configurado de forma adecuada (InStock, PreOrder, etc.). NO inventes un precio en el schema para "llenar el campo".
• En los catálogos solo para mayoristas que están completamente detrás de un inicio de sesión, la página indexable (a menudo una categoría o una descripción de producto con un CTA para iniciar sesión y ver precios) debe usar Producto con datos de especificaciones pero sin Offer.

El error más común que vemos: una tienda de B2B Edition con el precio minorista visible para los rastreadores, pero con el schema todavía tomando el precio mayorista de la lista de precios predeterminada porque alguien configuró la fuente del schema con la lista equivocada durante la integración. Entonces, los buscadores que leen el schema no coinciden con los que leen el precio renderizado, y ambos pierden confianza.

Catálogos solo de cotización e indexabilidad

Algunos operadores B2B manejan catálogos totalmente basados en cotizaciones: sin precios públicos, con cada pedido canalizado a través de una RFQ. Ese modelo es válido comercialmente, pero plantea la pregunta de qué se puede indexar.

La respuesta: las páginas de detalle de producto deben seguir siendo indexables, con contenido completo de especificaciones, fichas técnicas, relaciones con fabricantes y schema de Product (sin el Offer.price). Para el buscador, el CTA de "Request Quote" es el equivalente de "Add to Cart": es una ruta transaccional, solo que no es de autoservicio. La página sigue ganando posiciones por especificaciones, números de pieza e intención de categoría.

Lo que NO debería ser indexable en una configuración solo de cotización:

• Páginas internas del flujo de RFQ.
• Páginas de resumen de cotización con condiciones específicas del cliente.
• Cualquier URL que muestre precios o condiciones específicas del cliente después de iniciar sesión.

Una revisión rápida de robots.txt y noindex en esas rutas al lanzar evita la filtración lenta de páginas posteriores al inicio de sesión hacia el índice público.

La cuestión de las restricciones por Customer Group

Un caso más sutil: algunas tiendas de B2B Edition restringen categorías de productos completas o SKU por Customer Group. Productos "solo para distribuidores" que los clientes minoristas no deberían ver en absoluto. Productos "por contrato" que solo aparecen para cuentas con contrato.

Para el SEO, la pregunta es si esas categorías restringidas deberían ser indexables en absoluto.

La respuesta práctica en la mayoría de los casos es no. Si los productos están restringidos comercialmente, también deberían estarlo para los buscadores: no son superficies en las que intentes ganar posiciones públicas, y exponerlas en el índice genera fricción para el usuario ("Encontré este producto pero no puedo comprarlo") y el riesgo de dar información a la competencia.

La excepción: si una marca tiene un "catálogo para distribuidores" o un "catálogo solo para el gremio" que es realmente público pero requiere la aprobación de una cuenta para comprar, puede ser indexable como superficie de reconocimiento, con CTA claros sobre el proceso de aprobación y sin schema de Offer en los artículos restringidos.

Consideraciones sobre punchout, OCI y headless

Las instalaciones más grandes de B2B Edition a menudo se conectan con los sistemas de compras del comprador mediante punchout (cXML, OCI): Ariba, Coupa, SAP Business Network, Oracle Procurement. En esos flujos, el catálogo se consume en una sesión iniciada desde el sistema de compras del comprador, no desde la web pública.

Las sesiones de punchout son por naturaleza autenticadas y restringidas: están detrás de credenciales cXML. No son una superficie de SEO, pero los datos de producto que alimentan el catálogo de punchout SÍ son los mismos que alimentan la tienda pública y el schema. El trabajo de calidad de datos tiene beneficios acumulativos: mejores catálogos de punchout y mejor SEO a partir de las mismas mejoras en la fuente única de verdad.

El mismo principio aplica a las tiendas headless en B2B Edition. La capa headless cambia cómo se renderiza la página, pero el schema y el contenido indexable deben seguir presentes y ser honestos en la respuesta que ven los rastreadores. Un headless sin schema de Product renderizado en el servidor (o prerenderizado) es una fuente recurrente de retrocesos de SEO en la plataforma.

Dónde encajan los motores de IA

Los motores de IA (ChatGPT, Perplexity, Claude, Gemini) leen el schema de Product y lo usan para responder consultas de compra: "dónde puedo comprar [producto]", "cuál es el precio de [SKU]", "qué distribuidores venden [fabricante] [serie]". Para las tiendas de B2B Edition, eso significa:

• El precio minorista público en el schema se cita como el precio.
• Las páginas solo de cotización se citan como disponibles pero sin un precio, normalmente con una nota de que el precio es por cotización.
• Un schema desalineado (precio visible ≠ precio del schema) hace que la marca baje en la prioridad de citas para esa consulta.

Corregir la coincidencia entre el schema y el precio visible es una de las correcciones de AEO con mayor rendimiento para las tiendas de B2B Edition. Documentamos la metodología más amplia de citas en IA en monitoreo de la cuota de citas; los datos están en /reports/state-of-ai-shopping-citations-2026.

Por dónde empezar

Para el operador de una tienda de B2B Edition que quiere alinear el SEO con la arquitectura comercial:

1. Audita lo que ve el rastreador sin sesión en cada tipo de página principal: precio minorista, ningún precio o muro de inicio de sesión.
2. Audita que el schema coincida con lo que se ve. Corrige primero las discrepancias; son las ganancias más fáciles.
3. Decide para cada catálogo restringido si debe ser indexable como superficie de reconocimiento o quedar completamente fuera del índice.
4. Confirma que las rutas solo de cotización tengan un schema limpio (Product sin Offer.price) y CTA de "Request Quote" claros.
5. Confirma que las superficies de punchout, headless y API no estén exponiendo por accidente datos específicos de clientes al rastreador público.

Cubrimos el manual completo específico de la plataforma en SEO B2B para BigCommerce. La comparación de plataformas para equipos que están eligiendo entre ellas está en BigCommerce vs. Shopify para B2B. La visión B2B más amplia está en SEO para eCommerce B2B, y el lado pagado está en PPC B2B.

Si quieres hablar sobre cómo sería un proyecto de SEO para B2B Edition con tu catálogo y tu estructura de precios específicos, nos encantaría escucharte.