Si tu equipo cambia campañas todas las semanas, un CMS junto a Shopify te ordena el trabajo, baja la dependencia de desarrollo y evita duplicar precios, stock y textos.
Yo lo resumiría así: Shopify maneja la venta y el CMS maneja el contenido. Cuando separo esas dos partes, puedo publicar landings, FAQs, blogs y módulos de campaña sin tocar el theme en cada cambio. Además, sigo leyendo desde Shopify datos que no conviene copiar, como stock, variantes o precios en ARS 1.234,56.
En esta guía, el punto central queda claro desde el arranque:
Hay un dato simple que suele mover esta decisión: si marketing, ecommerce y marca intervienen en una misma página, el uso de workflows, versionado y aprobaciones pasa de “nice to have” a algo básico. Y si además trabajo con contenido local en es-AR, fechas como 24/07/2026, medidas en cm o temperatura en °C, conviene resolverlo desde el modelo de contenido, no al final.
Comparación rápida
| Modelo | Cuándo lo suelo elegir | Carga técnica | Control del contenido |
|---|---|---|---|
| Nativo | Equipo chico y flujos simples | Baja | Media |
| Híbrido | Más campañas, más edición y algo de soporte dev | Media | Alta |
| Headless | UX a medida, varios canales o varias regiones | Alta | Muy alta |
Mi lectura corta del tema es esta:
un stack sano no mezcla narrativa con datos de comercio. Si el precio cambia en Shopify, no quiero editar el CMS. Si cambia una guía de talles o una política, no quiero tocar código. Esa separación hace que todo el sistema sea más ordenado, más claro y mucho menos propenso a errores.
Eso es lo que desarrolla el artículo.
Modelos de Integración CMS + Shopify: Nativo vs Híbrido vs Headless
Definí desde el arranque qué contenido vive en Shopify y qué contenido publica el CMS. Esa frontera tiene que quedar clarísima para todo el equipo antes de escribir una sola línea de código. Cuando esa división está bien resuelta, elegir el modelo de integración pasa a ser mucho más simple.
Hay tres caminos posibles, y cada uno encaja con un tipo de equipo distinto.
El modelo nativo de Shopify usa Online Store 2.0, secciones, plantillas, metafields y metaobjects para gestionar contenido directo desde el admin. Suele funcionar bien para equipos chicos, de 1 a 3 personas, que manejan un catálogo estándar y no necesitan flujos de aprobación complejos.
El modelo híbrido mezcla metafields y metaobjects de Shopify con un CMS externo para contenido editorial más rico, como landing pages de campaña, artículos largos y módulos reutilizables. El storefront sigue corriendo sobre el tema de Shopify, pero el CMS suma borradores, aprobaciones, programación de publicaciones y control de versiones. Este esquema calza muy bien en equipos medianos con un desarrollador part-time o una agencia que sostenga la integración.
El modelo headless desacopla por completo el frontend de Shopify y usa frameworks como Next.js, Hydrogen o Nuxt, con Shopify como backend de comercio vía Storefront API y el CMS como centro de contenido. Hace falta equipo interno o un partner técnico firme, y suele tener sentido cuando hay pedidos más avanzados de UX, personalización o experiencias omnicanal. Para marcas en Argentina que piensan crecer hacia varias regiones o canales, este modelo da el mayor control sobre la localización.
Compará los tres modelos por equipo, complejidad y mantenimiento:
| Criterio | Nativo (Shopify solo) | Híbrido | Headless |
|---|---|---|---|
| Tamaño del equipo | 1–3 personas | Equipo de contenido + dev a tiempo parcial o agencia | Equipo interno o socio técnico sólido |
| Complejidad de contenido | Moderada | Media-alta | Alta |
| Flujos editoriales | Básicos | Borradores, aprobaciones y programación | Completos, multi-canal |
| Mantenimiento técnico | Bajo | Medio | Alto |
| Localización es-AR | Más acotada | Buena | Máxima flexibilidad |
Una vez definido el modelo, toca bajar eso a estructuras de contenido, IDs y reglas de sincronización.
Después de elegir el modelo, el paso siguiente es definir los tipos de contenido y cómo se conectan con Shopify. La práctica recomendada es guardar el ID de producto o GID de Shopify dentro de cada entrada del CMS. Así, los templates pueden mezclar datos de comercio - precio, stock, variantes - con contenido editorial - narrativa, FAQs y módulos de campaña - sin duplicar información.
Por ejemplo, una entrada del tipo "Historia de producto" en el CMS puede incluir campos como shopify_product_gid, descripción larga, tips de uso y módulos de cross-sell. Cuando el template renderiza la página, toma el precio en ARS y la disponibilidad directo desde Shopify, y el copy localizado desde el CMS. Entonces, si el precio cambia en Shopify, no hay que tocar nada en el CMS.
Para Argentina, las reglas de localización tienen que definirse desde el modelo de contenido, no pegarse al final como parche. Eso incluye voseo, precios en ARS, unidades métricas y temperatura en °C, todo resuelto desde la base del modelo.
La tabla de abajo muestra qué tipo de recurso debería quedar a cargo de cada sistema:
| Tipo de recurso | Sistema responsable | Atributos clave |
|---|---|---|
| Productos | Shopify | SKU, precio (ARS), stock, peso (kg) |
| Colecciones | Shopify | Agrupación de productos, reglas de merchandising |
| Landing pages | CMS | Hero, copy de campaña (vos), módulos de layout |
| Blog y artículos | CMS | Contenido editorial, SEO, autor |
| Metafields técnicos | Híbrido | Especificaciones en Shopify, descripciones ricas en CMS |
| Políticas y legales | CMS o Shopify, según el flujo de aprobación | Términos, privacidad |
Esta separación también ordena la gobernanza. El equipo de merchandising trabaja en Shopify, el equipo de contenido trabaja en el CMS, y cada uno sabe bien qué puede editar sin pisarse con el otro. Con esta arquitectura ya definida, el paso que sigue es conectar Shopify y el CMS sin duplicar datos.
El paso que sigue es técnico. Y, por suerte, casi todas las integraciones maduras siguen una lógica bastante parecida: credenciales, scopes, esquemas y webhooks.
Creá una Custom App en Settings > Apps and sales channels > Develop apps, instalala y copiá el token shpat_. Acá hay una regla simple que conviene respetar desde el arranque: mínimo privilegio.
Dicho en criollo, dale al CMS solo los permisos que necesita para leer el catálogo y escribir el contenido que de verdad va a manejar. Si le abrís permisos de escritura sobre productos, precios o inventario sin un motivo claro, es muy fácil que aparezcan roces entre el equipo de merchandising y el de contenido.
| Scope recomendado | Para qué lo usa el CMS |
|---|---|
read_products | Listar y referenciar productos en bloques de contenido |
read_collections | Vincular contenido a colecciones específicas |
read_content | Acceder y sincronizar metafields y metaobjects |
write_metafields / write_metaobjects | Escribir contenido aprobado desde el CMS hacia Shopify |
read_webhooks / write_webhooks | Administrar suscripciones de webhooks desde el CMS |
El precio en ARS, el stock y las reglas de descuento deben quedar solo en lectura dentro del CMS. El sistema puede consultarlos para mostrarlos en las plantillas, pero no debería sobrescribirlos.
Con el acceso resuelto, toca definir qué va a leer y qué va a escribir el CMS.
Cada entrada del tipo "Historia de producto" debería tener un campo de referencia al GID del producto en Shopify (admin_graphql_api_id) y, además, campos de contenido enriquecido que Shopify no maneja de forma nativa.
Los campos que suelen rendir mejor son estos:
La idea es modelar estos campos como piezas chicas y reutilizables. Eso hace más simple reutilizar la misma narrativa en otros canales propios, sin tener que rehacer todo cada vez.
Con los modelos ya armados, la sincronización automática ayuda a evitar desvíos entre un sistema y el otro.
Los webhooks son los que mantienen al CMS al día cuando cambia el catálogo en Shopify. Como base, conviene suscribirse a products/create, products/update, products/delete y collections/update.
Cada evento llega como un JSON a un endpoint HTTPS del CMS o del middleware. A partir de ahí, el handler verifica la firma HMAC de Shopify, transforma el payload y ejecuta un upsert usando el ID numérico del producto. Hay un punto clave acá: los handlers deberían actualizar solo datos de referencia, como GID, handle, estado de publicación y precio en ARS. El contenido editorial tiene que quedar intacto.
Del lado del flujo de publicación, cuando una persona editora aprueba una entrada en el CMS, el sistema ejecuta una mutación GraphQL - metafieldsSet o metaobjectUpsert - para escribir ese contenido aprobado en Shopify y dejarlo visible en la tienda o en un frontend headless.
Para el preview, la opción más prolija es combinar un namespace de metafields de staging con una URL de vista previa protegida por token. Así, los equipos de contenido, merchandising y growth pueden revisar cómo va a quedar una página antes de mandarla a producción. Y sí: conviene bloquear la publicación si el producto está en borrador.
Con la sincronización y el preview ya resueltos, el siguiente paso es mapear ese contenido al tema o al frontend.
Con el contenido ya sincronizado, el tema solo tiene que leer esas referencias y mostrarlas en pantalla.
En temas Liquid, el patrón que mejor suele andar es este: un metaobject para el bloque reutilizable, un metafield de referencia en el recurso y fuentes dinámicas para conectarlo con la sección.
Hay varios bloques que encajan muy bien con ese esquema:
hero_section con titulo, subtitulo, imagen_desktop, imagen_mobile, cta_label y cta_link. Se referencia desde la página o desde el inicio con un metafield y fuentes dinámicas. Eso le permite al equipo de contenido cambiar una promo estacional, como Promo invierno – 20% OFF, sin meter mano en el código.product_education_block con ícono, título y texto corto. Se referencia desde el producto y se muestra como una lista de bloques debajo de la descripción.routine_step con nombre, descripción y producto asociado. Una sección en la PDP recorre los pasos en orden. Va muy bien en marcas de cosmética o fitness que quieren mostrar cómo usar cada sérum o proteína.editorial_card con imagen, título, extracto y enlace. El CMS define qué artículos destacar y el tema los pinta en una grilla.En Liquid, leer un metafield es así de simple: {{ product.metafields.namespace.key }}. Para metaobjects, Liquid toma la referencia y renderiza la sección. El tema queda estable, mientras el contenido se actualiza desde Shopify Admin o desde el CMS.
En un frontend headless con Next.js, la lógica cambia un poco. La página de producto hace dos llamadas en paralelo. La primera va a la Storefront API de Shopify para traer el producto por handle o ID, con precio en ARS y stock en tiempo real. La segunda va al CMS para traer el contenido editorial por slug o entry ID. Después, el componente junta ambas respuestas y arma la página completa.
La regla que más pesa acá es separar lo que cambia rápido de lo que cambia lento. Los precios en ARS, el stock y los descuentos tienen que venir en tiempo real desde Shopify y no conviene dejarlos mucho tiempo en caché. El contenido editorial - banners principales, guías, FAQs y cuadrículas - sí puede vivir en caché de CDN durante minutos o incluso horas, porque cambia bastante menos seguido y además suele pesar más en transferencia.
En Argentina, donde gran parte del tráfico ecommerce entra desde smartphones, pensar primero en mobile no es un lujo: es el piso. Cada metaobject de banner principal debería tener un campo imagen_mobile separado de imagen_desktop, y las secciones de Liquid o los componentes React tienen que elegir cuál servir según el viewport. Los módulos de routine builder y FAQ conviene que usen componentes colapsables con áreas de toque amplias, no paredes de texto. Las guías de talles deberían mostrar tablas en cm con scroll horizontal en pantallas chicas. Y los detalles de cuotas, como 3 cuotas sin interés, tendrían que poder cambiarse desde un metafield sin tocar el tema, porque esas condiciones suelen moverse seguido.
Cuando el equipo crece, el orden deja de ser un detalle y pasa a ser parte del sistema. Por eso conviene definir desde el arranque una convención de nombres clara: content.hero_* para banners principales, faq.* para preguntas frecuentes y size_chart.* para guías de talles. También ayuda que cada tipo de contenido tenga un responsable claro: el equipo de ecommerce para los bloques educativos, el equipo de producto para las guías de talles. Y, antes de publicar, el CMS debería tener un flujo de aprobación para evitar errores que después aparecen en la tienda. En el código, además, siempre hacen falta valores de respaldo cuando falta una referencia de metaobject. Si no, una entrada incompleta puede romper la estructura de la página.
Ese trade-off marca qué camino conviene según el stack.
| Dimensión | Liquid + metafields del CMS | Frontend headless |
|---|---|---|
| Complejidad | Baja; usa infraestructura nativa de Shopify | Alta; requiere frontend propio, hosting y DevOps |
| Flexibilidad | Moderada; limitada por Liquid y las secciones del tema | Total; control completo sobre UX y stack |
| Performance | Buen rendimiento si se optimiza; depende del CDN de Shopify | Excelente; puede usar computación en el borde y SSG/ISR |
| Localización | Soporte nativo de Shopify; fácil de gestionar | Implementación custom; requiere lógica por API y estrategia de localización |
| Mantenimiento | Bajo; Shopify gestiona actualizaciones de plataforma | Alto; requiere recursos de desarrollo dedicados |
Cuando el CMS ya alimenta la tienda, ese mismo contenido también puede empujar soporte y campañas. Los bloques que ya modelaste - como rutinas o políticas de devolución - sirven en varios canales sin caer en el clásico copiar y pegar.
Y no es solo una cuestión de orden. Ese mismo modelo también permite activar respuestas y flujos de venta sin duplicar contenido. Ahí aparece Burbuxa: usa datos de Shopify en tiempo real y contenido del CMS para automatizar ventas, soporte y marketing en WhatsApp e Instagram.
La diferencia en la operación se ve rápido:
| Dimensión | Operación manual | CMS + Shopify + Burbuxa |
|---|---|---|
| Consistencia | Riesgo alto de información desactualizada | Un solo origen |
| Velocidad | Cambios manuales | Un cambio en el CMS se propaga automáticamente |
| Auditabilidad | Cambios dispersos en múltiples herramientas | Historial en el CMS y logs de conversación en Burbuxa |
| Personalización | Mensajes genéricos sin contexto | IA que combina datos de Shopify con contenido del CMS |
| Reportes | Métricas separadas por canal | Atribución unificada: soporte, campañas y conversión |
Con ese circuito en marcha, la decisión central sigue siendo la misma: separar el contenido editorial de los datos transaccionales. Shopify se ocupa de precios en ARS, stock y pedidos. El CMS maneja los bloques reutilizables que después se mapean a productos y colecciones.
De ahí salen las demás decisiones del sistema. Por un lado, elegir la arquitectura según la complejidad del equipo. Por otro, definir un flujo de aprobación antes de publicar cualquier cambio que llegue a la tienda o a un flujo automatizado.
Cuando esa base está bien armada, pasa algo simple pero potente: un cambio en la política de devoluciones se actualiza una sola vez en el CMS y después fluye de forma automática a la PDP, al email de confirmación y a las respuestas de soporte en WhatsApp. Menos trabajo manual, menos idas y vueltas, y menos riesgo de inconsistencias.
Depende de cómo necesitás trabajar y del nivel de sincronización que buscás. En la práctica, conviene elegir un CMS o una plataforma externa con sincronización bidireccional en tiempo real. Así evitás demoras por procesos por lotes y reducís desajustes entre sistemas.
En Argentina, Burbuxa puede ser una jugada muy útil: conecta Shopify con WhatsApp e Instagram y sincroniza productos, pedidos, clientes e inventario en tiempo real, sin desarrollos complejos ni impacto en la velocidad de carga.
Te conviene cuando buscás un equilibrio entre automatización avanzada y control humano, sobre todo al sumar nuevas herramientas o sistemas.
Funciona muy bien si querés que la IA se haga cargo de tareas repetitivas y de mucho volumen, como la atención al cliente o la recuperación de carritos, pero todavía necesitás mirar de cerca lo que hace antes de dejarla sola. Con un enfoque supervisado, como el de Burbuxa, podés revisar las sugerencias, validarlas y recién después pasar a piloto automático.
Para no duplicar precios ni stock cuando integrás un CMS o herramientas externas con Shopify, aplicá idempotencia. En criollo: si un webhook o una notificación llega más de una vez, el sistema tiene que detectar que ya fue procesado y evitar cambios repetidos.
La forma más simple de hacerlo es usar identificadores únicos, como X-Shopify-Webhook-Id, y chequear si ese evento ya quedó registrado antes de ejecutar cualquier acción.
Además, conviene responder con HTTP 200 en menos de 5 segundos y dejar las tareas más pesadas en colas asíncronas. Así evitás demoras, reintentos innecesarios y desajustes en la tienda.
Burbuxa ayuda a mantener catálogo, precios y stock sincronizados en tiempo real.