Shopware Headless en 2026: la decisión de frontend detrás de la palabra de moda

"Shopware headless" aparece en RFPs y propuestas de agencia como si fuera un único interruptor: encendido o apagado. En la práctica no es una decisión, es un conjunto de decisiones más pequeñas. ¿Con qué API habla realmente tu frontend, qué pasa con el storefront de Twig, qué funcionalidad de Shopware se queda en el servidor, y qué tienes que reconstruir tú mismo? Este post responde a eso antes de que te comprometas con cualquier proyecto de frontend.

Qué significa realmente "Shopware headless"

Shopware 6 trae dos APIs que importan aquí: la Store API (REST/JSON) para datos de producto, precios, carrito y checkout, y la Admin API para configuración, campos personalizados y objetos de backend. Headless significa que tu frontend habla con estas APIs en lugar de que Shopware renderice la página él mismo mediante plantillas Twig y el theme del storefront.

Esa es la sustancia real del término. No "hemos construido una app", sino: ¿quién renderiza la página, y de qué API extrae los datos ese renderizado? Mientras la respuesta sea "el theme de Twig, en el mismo proceso que Shopware", la tienda no es headless, sin importar lo moderno que parezca el theme.

Qué pasa con el storefront de Twig

El storefront por defecto (theme Bootstrap, plantillas Twig, sistema de herencia de theme) se queda instalado sin importar si vas headless o no. La pregunta es qué rol conserva después:

• Camino | Qué se queda en Shopware | Qué reconstruyes
• Desacoplamiento parcial | El storefront de Twig sigue sirviendo páginas legales, casos límite del checkout o áreas de bajo tráfico | Solo los tipos de página críticos para la conversión (PDP, PLP, categoría, home) se vuelven a renderizar contra la Store API
• Desacoplamiento total | Solo la funcionalidad de backend (gestión de producto, lógica de precios, procesamiento de pedidos) | Todo el storefront, incluida la UI del checkout, corre contra la Store API
• El propio stack PWA de Shopware | Backend sin cambios | Una capa PWA basada en Vue Storefront/Alokai, la propia recomendación oficial de Shopware, pero con adopción limitada en la base de instalaciones DACH

El tercer camino vale la pena conocerlo precisamente porque Shopware lo recomienda directamente. En la práctica, la adopción se mantiene baja porque el stack PWA sigue exigiendo su propio proyecto y su propio equipo de frontend, no muy distinto de construir una capa headless completamente desde cero.

Qué pierdes, qué conservas

Conservas, en cualquier escenario: el catálogo de producto, los libros de precios, la lógica de grupos de clientes, las automatizaciones de Flow Builder y la lógica core del checkout (las integraciones de pago y envío siguen corriendo a través de procesos de Shopware, incluso cuando la UI del checkout en sí vive en el frontend desacoplado).

Tienes que reconstruir o sustituir: cada plugin de theme que renderiza directamente dentro de una plantilla Twig. En una tienda Shopware típica con 20 a 50 plugins, esta es la parte más subestimada del esfuerzo, porque no todos los plugins tienen un equivalente en la API. Las personalizaciones de snippets SEO mantenidas antes dentro del theme también se trasladan a la capa de frontend.

Cuándo ir headless en Shopware es la decisión equivocada

Ningún post sobre headless es honesto si no dice también cuándo no vale la pena hacerlo.

• Catálogo estándar, theme de Twig ya lo bastante rápido. Si tu LCP móvil ya está por debajo de los 2,5 segundos y tu equipo no tiene una demanda insatisfecha de velocidad de marketing, un proyecto de desacoplamiento es esfuerzo puro sin una victoria medible.
• Sin equipo de frontend, sin presupuesto para una capa gestionada. Un stack headless operado por cuenta propia sin un equipo de frontend dedicado suele acabar exactamente donde acaban la mayoría de los setups de Vue Storefront abandonados: levantado, medio mantenido, con el tiempo deuda técnica.
• Fuerte dependencia de plugins en el área del storefront. Si una gran parte de tus 20 a 50 plugins se engancha directamente al theme, el esfuerzo de migración se multiplica con cada plugin que no tiene equivalente en la API.
• Una migración de Shopware 5 a 6 ya está en marcha. Correr dos grandes proyectos de frontend a la vez casi nunca es el orden correcto. Para la estrategia de desacoplamiento en ese caso concreto, consulta Shopware 6 Upgrade Path and Frontend Strategy.

Si nada de esto aplica, pero la escala multi-brand, el cumplimiento de accesibilidad o la velocidad de marketing son el verdadero cuello de botella, headless es el siguiente paso correcto, solo que uno deliberado en lugar de uno guiado por la palabra de moda.

La checklist de decisión

Cuatro preguntas que responder antes de la decisión de arquitectura:

1. ¿Qué tipos de página se desacoplan, todos o solo los críticos para la conversión?
2. ¿El checkout se queda en Shopware, o la UI se traslada al nuevo frontend?
3. ¿Cuántos de tus plugins de storefront tienen un equivalente en la Store API, y cuántos no?
4. ¿Operas el frontend tú mismo, o necesitas una capa gestionada?

Para la modernización del storefront en general, independientemente de la pregunta del backend, consulta Shopware Storefront and Frontend Modernization, y la pregunta agencia frente a plataforma gestionada se cubre por separado en Shopware Agency or FMP.

Dónde encaja Laioutr en este panorama

Laioutr se conecta directamente a la Store API de Shopware y se hace cargo por completo del renderizado, sin que tú toques el catálogo de producto, la lógica de precios ni el procesamiento de pedidos. Eso corresponde al camino de desacoplamiento total descrito arriba, menos la carga de construir y operar tu propio stack PWA. Como Agentic Frontend Management Platform, el layout, la composición de campañas y el A/B testing viven en el editor, no en el backlog de desarrollo. Para comerciantes de Shopware que operan varias marcas o mercados, eso es lo que más importa: los setups multi-brand corren sobre un único código base en lugar de n forks de theme. Para el conector técnico en sí, consulta Shopware-Laioutr Connector, Open Source.

Preguntas frecuentes

¿Tengo que sustituir todo el storefront para ser "headless"? No. El desacoplamiento parcial, donde solo se desacoplan los tipos de página críticos para la conversión, es un estado intermedio válido, no un compromiso a medias.

¿Esto funciona si sigo en Shopware 5? La Store API también existe en Shopware 5. Desacoplar primero el frontend y cambiar el conector solo cuando más adelante migres a Shopware 6 es una forma habitual de mantener el riesgo de frontend fuera de la migración de backend.

Próximos pasos

Si actualmente estás valorando el mantenimiento del theme de Twig, el propio stack PWA de Shopware o un proyecto de desacoplamiento total: consulta Headless Frontend for Shopware para repasar cómo se configura realmente el conector de la Store API.

Más desde la plataforma Laioutr

• Headless Frontend for Shopware
• Agentic Frontend Management Platform
• Multi-Brand · Multi-Market

Sobre el autor: Marcel Thiesies es cofundador de Laioutr y lidera producto y arquitectura para la Frontend Management Platform.