WordPress headless para WooCommerce: cuándo compensa y qué evitar
Detrás de la pregunta “¿encaja WordPress headless con WooCommerce?” casi nunca hay una duda tecnológica. Lo que se quiere saber es si la tienda seguirá funcionando durante la migración, si las extensiones actuales sobrevivirán y si la nueva arquitectura se amortiza dentro del ciclo presupuestario. La respuesta honesta: depende de la tienda.
Este artículo concreta la decisión. Complementa nuestra página de servicio de WordPress headless y nuestro texto sobre la economía del headless, donde se describe el modelo de costes.
Para qué tiendas sirve WooCommerce headless
- Buena opción para tiendas donde las Core Web Vitals en móvil limitan la conversión.
- Buena opción para tiendas con catálogos estables que se cachean bien en el edge.
- Mala opción para tiendas pequeñas donde el coste de orquestación supera el ahorro.
- Mala opción para tiendas con extensiones pesadas de WooCommerce que dan por hecho un front-end renderizado en PHP.
- Runtime de edge: Cloudflare Workers sirve tanto Astro como Next.js, con un origen WordPress detrás.
Qué significa realmente WooCommerce headless
WordPress con WooCommerce conserva el flujo editorial, la gestión de pedidos, el inventario y el procesamiento de pagos. El front-end headless (Astro o Next.js) muestra el catálogo público, las fichas de producto y la interfaz del carrito y del checkout. Ambos se comunican a través de la Store API de WooCommerce, la REST API o GraphQL.
Hay tres piezas de la arquitectura que importan:
El origen. Sigue siendo WordPress. Sigue siendo WooCommerce. El mismo panel, los mismos plugins, los mismos flujos de pago. Los editores no cambian de herramientas.
El front-end. Astro o Next.js sobre Cloudflare Workers. Sirve HTML pregenerado para el catálogo y las fichas de producto y recurre a SSR para el carrito y el checkout. Lee del origen WordPress.
La frontera. REST o GraphQL entre ambos. Cookies y cabeceras se conservan a través de la frontera para que la sesión mantenga la continuidad. Es la pieza que sostiene todo, y la primera que se rompe si quien entrega es un perfil júnior.
Cuándo compensa WooCommerce headless
Escenarios concretos en los que el balance sale positivo:
- Una tienda de moda con 200 productos, un 70 por ciento de tráfico móvil y un LCP móvil por debajo de 2 segundos directamente ligado a la conversión.
- Un catálogo B2B con 5000 SKU estables, en el que la mayoría de las páginas permanece horas en la caché del edge.
- Una tienda WooCommerce que también sirve de fuente de catálogo para una app móvil o un agente de compras con IA (Universal Commerce Protocol).
- Un sitio que ya sirve su propio bundle JS con mucha interactividad, donde WordPress editorial más Next.js no cuesta mucho más que la configuración actual.
En los cuatro casos, la ganancia combina Core Web Vitals renderizadas en el edge (efecto en ingresos) y un coste predecible de Cloudflare Workers (efecto de ahorro).
Cuándo no compensa WooCommerce headless
Escenarios concretos en los que no compensa:
- Tiendas de un solo producto o con menos de 20 SKU y poco tráfico. El coste de la migración supera con creces el ahorro.
- Tiendas con más de 10 extensiones activas de WooCommerce que tocan el front-end. Cada una necesita una auditoría, a menudo una reimplementación o un build híbrido.
- Inventario muy volátil (subastas en directo, ventas flash, reservas en tiempo real). El coste de invalidar la caché crece más rápido que el ahorro en el front-end.
- Precios muy personalizados por cliente. La caché en el edge pierde eficacia y la arquitectura pierde buena parte de su ventaja.
La versión polémica: el headless no es la opción por defecto. Por defecto, se mantiene el monolito hasta que el cuello de botella pasa al front-end. Cuando el cuello de botella son las Core Web Vitals en móvil, el cambio empieza a compensar.
Qué auditar antes de pasar a WooCommerce headless
La auditoría que hace un ingeniero sénior antes de comprometerse con cualquier migración:
- Liste todas las extensiones activas de WooCommerce. Marque cada una como “compatible con headless”, “requiere reimplementación” o “bloquea headless”.
- Tome una instantánea de las Core Web Vitals en móvil de las 50 fichas de producto principales. Si el LCP y el INP ya están en buen estado, el ahorro del headless es menor.
- Analice el perfil de tráfico: volumen de visitas, proporción de visitantes recurrentes, proporción móvil, distribución geográfica. Mucho móvil y una geografía diversa favorecen el headless en Cloudflare Workers.
- Mapee el historial de redirecciones. Los sitios WooCommerce acumulan redirecciones por productos renombrados y reestructuraciones de categorías. La migración debe conservarlas.
- Identifique precios por cliente y contenido dependiente de la sesión. Cuanto más haya, menor será la ventaja del headless.
El resultado es un sí o un no. Hemos desaconsejado migraciones a headless tantas veces como las hemos recomendado.
Qué incluye un build de WooCommerce headless
Cuando la auditoría sale favorable, el build de un equipo con experiencia queda así:
- WordPress con WooCommerce en un pequeño alojamiento gestionado, como origen.
- Front-end en Astro o Next.js (según la matriz de decisión Next.js vs Astro).
- Cloudflare Workers + Pages para la entrega desde el edge.
- Redis en el origen WordPress para object cache y almacenamiento de sesiones.
- WooCommerce Store API activada, con limitación de peticiones en el Worker.
- Los siete patrones SEO para WordPress headless, todos conservados.
Las decisiones siguen ese orden. El modelo de TCO del texto sobre la economía del headless cierra el círculo.
Artículos relacionados sobre WordPress headless
Este artículo de cola larga se apoya en nuestra página de servicio de WordPress headless y en tres textos de apoyo. Para los riesgos de la migración, la lista de siete patrones SEO para WordPress headless es la referencia. Para enmarcar la decisión, la matriz Next.js vs Astro y el texto sobre la economía del headless llevan el peso.
Para comparar plataformas, consulte Shopify Plus vs WooCommerce headless.
