SEO en BigCommerce Catalyst: mejores prácticas para tiendas en Next.js

Catalyst es la tienda de referencia headless de BigCommerce. Es una aplicación Next.js construida sobre el App Router, se comunica con BigCommerce a través de la GraphQL Storefront API y es el camino oficial de la plataforma para los comerciantes que quieren un front end moderno basado en React mientras mantienen BigCommerce como motor de comercio. Reemplaza el papel que Stencil (la plataforma de temas heredada basada en Handlebars) cumplió durante la última década, e introduce consideraciones de SEO propias de BigCommerce Catalyst que todo comerciante debe atender de forma proactiva para proteger su posicionamiento durante y después de una migración de plataforma.

Somos Elite BigCommerce Partner desde 2012, lo que significa que llevamos haciendo proyectos de comercio en esta plataforma más tiempo del que la mayoría de las agencias lleva existiendo. Hemos lanzado proyectos tanto en Stencil como en Catalyst. Este artículo es la lista de verificación SEO para lanzar una tienda en Catalyst sin perder nada de la indexación, los datos estructurados y la facilidad de rastreo que un tema de Stencil bien construido tenía por defecto.

Por qué el SEO en BigCommerce Catalyst es un terreno distinto al de Stencil

Stencil renderizaba cada página en el servidor. El motor de plantillas Handlebars producía HTML completo, BigCommerce lo servía desde su CDN y Googlebot recibía el documento completo desde el primer byte, sin necesidad de ejecutar JavaScript. El SEO en Stencil dependía sobre todo de si el tema se había construido correctamente (meta etiquetas, canonical, schema, sitemap), no de si la plataforma misma estorbaba.

Catalyst es distinto. Es una aplicación Next.js con App Router que tú, el comerciante, despliegas y operas, lo que significa que el SEO ya no se resuelve por ti de forma predeterminada. La elección de hosting (Vercel, Netlify o tu propia infraestructura) determina el modo de renderizado, el comportamiento de la caché, la geografía del edge y la división entre build y tiempo de ejecución. Cada una de esas decisiones tiene implicaciones SEO directas en BigCommerce Catalyst que simplemente no existían en Stencil, lo que convierte la elección de infraestructura en una de las decisiones tempranas más importantes de cualquier proyecto en Catalyst.

Para la comparación directa, consulta BigCommerce Stencil vs Catalyst: comparación del impacto en SEO.

App Router, RSC y lo que ve Googlebot

Catalyst está construido sobre el App Router de Next.js con React Server Components (RSC). El modo de renderizado predeterminado es el renderizado en el servidor, lo cual es bueno, pero el término "renderizado en el servidor" en el contexto del App Router abarca varios comportamientos distintos:

• Renderizado estático en el momento del build. Las rutas sin datos dinámicos se pre-renderizan y se sirven desde la CDN.
• Renderizado dinámico en el momento de la solicitud. Las rutas que optan por un comportamiento dinámico (mediante dynamic = "force-dynamic", llamando a headers() o cookies(), o usando una consulta de datos dinámica) se renderizan en cada solicitud.
• Streaming con Suspense. Las partes lentas de una ruta pueden enviarse por streaming mediante <Suspense> mientras la estructura base se envía de inmediato.

Para comercio, la matriz de renderizado de una app en Catalyst debería verse así:

• Estático para /, /about, /contact y otras rutas de contenido que cambian poco (considera Incremental Static Regeneration para el contenido que cambia de vez en cuando).
• SSR dinámico para /category/[slug] y /product/[slug]. Estas rutas necesitan datos actualizados de inventario, precios y merchandising. Usa la caché de forma agresiva en el edge, pero renderiza en el momento de la solicitud.
• Streaming solo donde el contenido indexable se pueda diferir: nunca envíes por streaming los encabezados H1, el texto principal ni los datos estructurados que Googlebot necesita en la primera respuesta del servidor. El producto, el precio y el JSON-LD deben estar resueltos antes de que empiece el streaming.

La capa de datos de Catalyst: la GraphQL Storefront API

Catalyst obtiene los datos a través de la GraphQL Storefront API de BigCommerce. Es rápida, está bien tipada y admite paginación, filtrado y facetas de forma nativa. Desde el punto de vista del SEO, la capa GraphQL es casi invisible: la pregunta relevante es si tus manejadores de rutas la consumen correctamente.

Los patrones que importan:

• generateMetadata para cada PDP y PLP. Es la primitiva del App Router de Next.js para emitir el título, la descripción y Open Graph en la respuesta SSR. Usa el resultado de la consulta GraphQL, no una consulta del lado del cliente, para llenar estos campos.
• JSON-LD como una etiqueta <script> literal en la ruta, insertada directamente a partir del resultado de GraphQL. No dependas de una librería del lado del cliente para inyectar el schema después de la hidratación.
• Etiqueta canonical mediante el campo de metadatos alternates.canonical del App Router. Emítela desde generateMetadata.

Estructura de URLs y la historia de los slugs en BigCommerce

BigCommerce admite URLs personalizadas a nivel de producto y de categoría. Los valores predeterminados de la plataforma son sensatos (/category/, /product/, sin barra final), pero Catalyst le da al desarrollador libertad para reasignarlas. Algunas reglas:

• No cambies las URLs ya establecidas en una migración de Stencil a Catalyst. Cada URL de producto, categoría y contenido debe coincidir exactamente con la estructura heredada, o necesitas un mapa completo de redirecciones 301 que cubra cada ruta modificada. Catalyst es una excelente excusa para limpiar las URLs; también es una excelente manera de perder seis meses de autoridad de posicionamiento si lo haces sin un plan de redirecciones.
• Usa el campo de URL canonical de BigCommerce en los productos. El canonical a nivel de plataforma permite a los responsables de merchandising corregir problemas de contenido duplicado en productos con varias categorías sin cambiar código.
• Evita las variaciones de producto mediante parámetros de consulta a menos que tengas un manejo explícito del canonical. Las URLs de variantes de BigCommerce (?sku=...) pueden colarse en el índice si un tema o una app descuidados las inyectan en las etiquetas de enlace.

B2B Edition, grupos de clientes y visibilidad de precios

Si la tienda en Catalyst también atiende a clientes de B2B Edition, aparece un conjunto adicional de consideraciones SEO. B2B Edition admite grupos de clientes, catálogos solo por cotización y visibilidad basada en listas de precios. El rastreador es, por definición, anónimo: ve la vista B2C. Ese es el comportamiento correcto. Pero significa que:

• Las páginas de producto deben mostrar un precio (o una CTA de "solicita una cotización") en la vista anónima. Un campo de precio vacío es una señal de alerta para Merchant Center y para el posicionamiento.
• Los productos solo por cotización necesitan una página equivalente B2C indexable o una directiva noindex. Los catálogos que están completamente detrás de un inicio de sesión deberían llevar noindex en todo el sitio.
• El Offer.price del JSON-LD debe coincidir con lo que ve el usuario anónimo. No emitas en el schema un valor de una lista de precios B2B si la página visible muestra un precio B2C.

El análisis a fondo está en SEO en BigCommerce B2B Edition para catálogos solo por cotización.

Manejo de imágenes en Catalyst

Catalyst usa el componente <Image> de Next.js, lo que significa que las variantes responsivas y la carga diferida ocurren automáticamente. El detalle: el componente <Image> requiere las props width y height explícitas para evitar cambios de diseño. La GraphQL API de BigCommerce devuelve URLs de imágenes con tamaños fijos; confirma que el tamaño que solicita tu componente sea uno que la CDN de BigCommerce realmente sirve, o estarás pagando el cómputo de optimización de imágenes de Vercel en cada página de producto.

Configura el dominio de las imágenes en next.config.js:

images: {
  remotePatterns: [
    { protocol: 'https', hostname: 'cdn11.bigcommerce.com' },
  ],
}

Sitemap, robots y el problema de los despliegues de vista previa en Catalyst

Los proyectos de Catalyst desplegados en Vercel reciben una URL de vista previa única por rama y por commit. Cada una de esas URLs de vista previa es accesible públicamente por defecto. Sin un bloqueo explícito, Googlebot terminará encontrándolas (normalmente a través de un enlace accidental en un mensaje de Slack indexado por otra vía, o de una URL de revisión compartida) y empezará a indexarlas.

Dos soluciones:

• Protección con contraseña de Vercel en cada despliegue que no sea de producción.
• Encabezado X-Robots-Tag: noindex en cualquier nombre de host que no sea de producción, controlado mediante la configuración de encabezados de next.config.js o una función de middleware.

El sitemap de producción debe generarse de forma dinámica desde un manejador de rutas (app/sitemap.ts) que consulte la GraphQL API de BigCommerce en el momento de la solicitud, con la caché adecuada.

Regresiones SEO comunes en Catalyst

En las auditorías de Catalyst que hemos hecho, estas son las fallas recurrentes:

• generateMetadata devuelve un valor de respaldo solo del lado del cliente porque la consulta GraphQL se movió a un componente de cliente.
• Faltan etiquetas canonical en las PLP porque el estado de la paginación no se tuvo en cuenta en la función de metadatos.
• El JSON-LD de Producto se emite dos veces (una desde un componente personalizado y otra desde una app de terceros), lo que produce advertencias de schema y, en ocasiones, la supresión de resultados enriquecidos.
• Despliegues de vista previa indexados por Googlebot.
• La optimización de imágenes de Vercel se ejecuta en cada página de producto, disparando los costos de cómputo de Edge Functions sin ningún beneficio SEO (la CDN de BigCommerce ya sirve variantes optimizadas).

Puntos clave

• Catalyst es una app Next.js con App Router: el modo de renderizado (estático, SSR dinámico, streaming) lo eliges tú, no la plataforma.
• Usa generateMetadata y JSON-LD emitido por SSR en cada PDP y PLP. No dependas de la inyección de schema del lado del cliente.
• Migrar de Stencil a Catalyst requiere un mapa completo de redirecciones 301. No te lo saltes.
• Los catálogos de B2B Edition necesitan decisiones explícitas sobre la visibilidad de precios para los rastreadores anónimos.
• Bloquea la indexación de los despliegues de vista previa. Las URLs de vista previa de Vercel son públicas por defecto.

Para la guía de referencia específica de Catalyst, consulta nuestra práctica de SEO en Catalyst. Las prácticas más amplias de agencia de SEO para BigCommerce y expertos en BigCommerce se aplican tanto a Stencil como a Catalyst. Para proyectos B2B empresariales, BigCommerce Enterprise cubre el lado estratégico. La visión general de SEO para comercio headless también aplica aquí. Cuando estés listo, hablemos.