¿Qué es el headless commerce?

«Headless», sin cabeza, describe un sistema al que se le ha quitado la capa de presentación. Según un analista de Forrester en 2019 y según la propia commercetools, el término lo propuso en 2013 Dirk Hoerig, cofundador de commercetools. En las páginas de sphere.io, el primer nombre del producto de commercetools, guardadas en el Internet Archive en abril de 2013, la palabra no aparece; la atribución queda, por tanto, como dato de esas dos fuentes.

Un motor de comercio guarda los productos, los precios, el stock y los pedidos, y los ofrece por API, por ejemplo REST o GraphQL. El frontend, una web, una app o cualquier otro canal, pide esos datos y construye las páginas. Según Shopify, así se puede vender en una web, en una app, en un videojuego, en un directo o con un botón de compra en otra web.

Junto al motor suele haber un CMS headless para los textos y las imágenes. La diferencia es de contenido: el CMS headless gestiona contenidos, el motor de comercio gestiona productos, precios y pedidos.

Fuente: Shopify, «About headless commerce»; BigCommerce, «Introduction to Headless Commerce» (consultados el 12.11.2026).

Algunos fabricantes hablan de composable para ideas parecidas, como Shopware con sus Composable Frontends.

Shopify presentó el 29 de junio de 2021 Hydrogen, entonces un framework de React para tiendas headless, y Oxygen, su alojamiento. En la versión 2026-10, Hydrogen funciona con frameworks como Next.js, React Router, Nuxt, Astro y SvelteKit. Shopware conecta sus Frontends a la tienda a través de la Store API, con una demo basada en Vue.js y Nuxt.

Lo que conviene medir en una tienda headless es lo que recibe Google. La herramienta de inspección de URLs de Google Search Console muestra una captura de la página renderizada, los recursos cargados y el código que generó el JavaScript. Una petición con curl a una ficha de producto dice si el HTML del servidor ya trae nombre, precio y texto, o si llegan después por JavaScript.

La ventaja es la libertad: cualquier tecnología para el frontend, un catálogo para varios canales y la opción de conectar un CRM, un ERP o un PIM.

El coste lo admite el propio Shopify: «A headless storefront costs more to build and run than a theme». Hace falta aceptar esa complejidad y tener desarrolladores después del lanzamiento. Shopify lo recomienda solo cuando el negocio no se puede resolver con sus temas y apps.

Para el SEO, headless no es mejor ni peor por sí mismo. Depende de la ejecución:

• El renderizado. Google pone a la cola de renderizado las páginas con código 200 y recomienda el renderizado en servidor o el prerenderizado, porque no todos los bots ejecutan JavaScript. Un frontend que monta las fichas de producto solo en el navegador (renderizado en cliente) depende de ese segundo paso.
• Los códigos de estado. En una aplicación de una sola página, una URL inexistente puede devolver 200 y convertirse en un soft 404. Google describe cómo evitarlo.
• Los recursos. Google advierte que no hay que bloquear en robots.txt los scripts sin los que no entiende la página.
• Los filtros. La navegación por facetas genera muchas URL; Google recomienda impedir su rastreo si no hacen falta en el índice.
• Los datos estructurados de producto, que el frontend genera desde la API.

Cómo lo resolvimos nosotros con un CMS headless y Astro está en nuestro artículo sobre headless CMS y SEO.

Un CMS headless separa contenidos y presentación; el headless commerce hace lo mismo con la lógica de venta. Una tienda puede usar los dos a la vez. El e-commerce es el concepto general de vender por internet; headless describe solo cómo está construida la tienda.

Fuente: documentación de cada fabricante (consultada el 12.11.2026). Orden alfabético, sin valoración.

Las cifras de los fabricantes sobre ventas o velocidad de las tiendas headless no explican su método, y esta entrada no las recoge. Tampoco hay una definición normalizada: cada fabricante la describe desde su producto.

• Comprueba si tu plataforma actual, con sus temas y apps, ya cubre lo que necesitas.
• Asegura un equipo de desarrollo para el frontend también después del lanzamiento.
• Elige un frontend que entregue HTML desde el servidor para categorías y fichas de producto.
• Planifica las redirecciones de las URL antiguas antes de cambiar.
• Genera los datos estructurados de producto a partir de la API.
• Revisa en Search Console el HTML renderizado de una categoría y de una ficha.

• Devuelve 404 real para productos que ya no existen, no una página vacía con 200.
• Deja accesibles a Googlebot los scripts y estilos que necesita para renderizar.

• Pasar a headless sin equipo propio para mantener el frontend.
• Lanzar un frontend que solo pinta el contenido en el navegador.
• Olvidar las redirecciones de la tienda anterior.

Esta entrada se redactó en noviembre de 2026 con ayuda de IA. Los datos proceden de la documentación de Shopify, BigCommerce, Shopware, Adobe Commerce, VTEX y commercetools, de un blog de Forrester, de la documentación de Google y del Internet Archive. Se revisó antes de publicarse y no contiene datos de clientes.