WooCommerce clásico vs. headless
La versión corta: mantén WooCommerce clásico cuando un servidor PHP con buena caché puede servir una tienda única, y pasa a headless cuando la velocidad en móvil limita los ingresos, el catálogo es grande, o un catálogo debe alimentar varios front-ends. El headless no es mejor de forma automática. Es mejor en condiciones específicas, y una reconstrucción fuera de esas condiciones solo añade coste.
WooCommerce headless significa que WordPress y WooCommerce siguen como backend, expuestos a través de la Store API o WPGraphQL, mientras el tema PHP se sustituye por un front-end desacoplado en Next.js o Astro que renderiza HTML en caché en el edge.
La matriz de decisión
| Criterio | WooCommerce clásico | WooCommerce headless |
|---|---|---|
| Tamaño del catálogo | Hasta unos pocos miles de SKU | Catálogos grandes, navegación facetada |
| Core Web Vitals en móvil | Bueno con caché de página completa | Mejor, cero PHP por petición en el edge |
| Coste de construcción y operación | Más bajo, una pila | Más alto, dos pilas que mantener |
| Experiencia editorial | WordPress nativo | WordPress nativo, vista previa en un dominio aparte |
| Varios front-ends | Una tienda | Un catálogo, muchos front-ends |
| Complejidad del proceso de pago | Nativa, la más simple | Autoritativa en el servidor, más cableado |
| Tiempo hasta el lanzamiento | Más rápido | En torno a seis semanas para una tienda de tamaño medio |
Cuándo el clásico todavía gana
Para una tienda única por debajo de unos pocos miles de productos, un WooCommerce clásico en alojamiento de calidad en la UE, con caché de página completa, base de datos limpia y recursos optimizados, alcanza un LCP móvil por debajo de dos segundos sin reconstrucción. Una tienda española con unos cientos de artículos y un tema limpio no necesita una segunda base de código para ser rápida. Si tu tienda va lenta hoy, la causa casi siempre es la infraestructura y la deuda técnica, no el modelo de renderización. Arregla eso primero. La guía de optimización del rendimiento de WooCommerce muestra exactamente cómo, y resulta mucho más barata que pasar a headless.
Una tienda a escala de tarjeta de visita, una tienda con catálogo pequeño, o un equipo sin capacidad de front-end para mantener una segunda pila debería quedarse en clásico. El coste de mantenimiento de dos pilas es real y recurrente.
Cuándo gana el headless
El headless gana su coste en tres situaciones. Primera, cuando los Core Web Vitals en móvil moldean directamente los ingresos y un monolito ajustado con caché todavía no logra mantener el LCP por debajo de dos segundos bajo carga. Segunda, cuando el catálogo es grande y la navegación facetada convierte la renderización en PHP en el cuello de botella. Tercera, cuando un único catálogo debe alimentar varias superficies, como una tienda web, una aplicación nativa y un quiosco en tienda física, desde una sola fuente de verdad. Un minorista español que afronta picos de tráfico en campañas como el Black Friday o las rebajas desde el móvil es justo el caso en el que la renderización en el edge compensa.
En esos casos, el front-end renderiza HTML preconstruido en el edge sin PHP por petición, lo que elimina los peores casos de latencia de cola, mientras WooCommerce sigue siendo dueño del catálogo, los pedidos, el impuesto y el stock.
La parte que todos subestiman: el proceso de pago
El proceso de pago es donde las migraciones de WooCommerce headless triunfan o fracasan. El pago, el impuesto y la creación del pedido deben seguir siendo autoritativos en el servidor, dentro de WooCommerce. El front-end orquesta los pasos, pero el backend es dueño del dinero. Reimplementar la lógica de pago en el front-end es como las tiendas acaban con pedidos mal cotizados y el IVA roto. Mantenemos el proceso de pago en el servidor y dejamos que el front-end conduzca la experiencia a su alrededor.
Cómo transcurre la migración
El calendario lo dominan dos cosas: mantener correcto el proceso de pago y trasladar el SEO sin pérdidas. Primero congelamos el contrato de datos, construimos el front-end contra la Store API, mantenemos el proceso de pago en WooCommerce, preservamos cada URL y cada bloque de datos estructurados, y después hacemos el cambio tras una CDN, con la tienda antigua aún accesible hasta que la nueva esté demostrada. Un diff de rastreo antes del lanzamiento es lo que evita las caídas de posiciones que dan mala fama al headless.
Newsletter WordPress
Consejos, actualizaciones y mejores prácticas de WordPress una vez al mes.
Respetamos tu privacidad. Sin spam.
¿No sabes de qué lado estás?
Descomponemos el equilibrio frente a tu catálogo real, tu tráfico y tu equipo antes de recomendar nada. A menudo la respuesta honesta es optimizar primero la tienda clásica y volver al headless más adelante.
¿Sopesando clásico frente a headless?
Solicita una evaluación de migración. Evaluamos tu tienda frente a la matriz de decisión, modelamos el coste en ambos sentidos y te decimos con claridad cuál encaja, incluso cuando la respuesta es quedarse en clásico.
Solicitar una evaluación →Recursos relacionados
- Optimización del rendimiento de WooCommerce - prueba esto antes de una reconstrucción
- Desarrollador de WooCommerce - cómo trabajamos en las tiendas
- Shopify Plus vs. WooCommerce headless - si también estás sopesando Shopify
- Headless WordPress: Next.js vs. Astro - la elección del framework de front-end
- Estudio de caso de migración: PageSpeed 18 a 99 - una reconstrucción real hacia una pila moderna, tiempo de carga 12 s a 0,3 s, con métricas completas
