Cambiar el checkout de una tienda WooCommerce no debería tratarse como un simple cambio de diseño.
Si tu tienda lleva tiempo funcionando, es posible que alrededor del proceso de compra se hayan acumulado métodos de pago, reglas de envío, campos adicionales, cupones, integraciones, código personalizado o extensiones instaladas hace años. Sustituir el checkout clásico por el checkout basado en bloques puede afectar a alguna de esas piezas.
Eso no significa que debas evitar el checkout por bloques. WooCommerce lo utiliza como experiencia predeterminada en las tiendas nuevas desde la versión 8.3 y recomienda actualmente sus bloques de carrito y checkout. Pero la propia documentación de WooCommerce también advierte de que determinadas extensiones y personalizaciones pueden necesitar adaptación específica.
Por eso, antes de hacer el cambio en una tienda que ya vende, conviene responder a una pregunta bastante más importante que «¿me gusta más este checkout?»:
¿Todo lo que necesita mi tienda para completar una venta seguirá funcionando después del cambio?
En el checkout clásico de WooCommerce es habitual encontrar una página basada en el shortcode woocommerce_checkout.
El checkout por bloques utiliza el Checkout Block y una arquitectura diferente, integrada con el editor de bloques y con las interfaces modernas de WooCommerce.
Para el propietario de una tienda, la consecuencia práctica es sencilla: no conviene asumir que una funcionalidad añadida al checkout clásico aparecerá automáticamente en el checkout por bloques.
WooCommerce explica expresamente que las extensiones que utilizaban determinados hooks para insertar contenido en carrito o checkout —por ejemplo, algunos campos personalizados— suelen necesitar trabajo de integración para ser compatibles con los bloques.
Por tanto, cambiar de checkout no consiste únicamente en comprobar que la página tiene buen aspecto.
Hay que comprobar qué ocurre cuando alguien intenta comprar.
La primera comprobación es averiguar qué tienes ahora.
En una instalación antigua puedes estar utilizando el checkout clásico mientras que una tienda creada recientemente probablemente haya comenzado ya con los bloques, ya que WooCommerce convirtió Cart y Checkout Blocks en la experiencia predeterminada para nuevas tiendas a partir de WooCommerce 8.3.
Puedes revisar la página asignada como checkout desde la configuración avanzada de WooCommerce y editarla para ver cómo está construida.
Si encuentras el bloque Checkout, estás utilizando el sistema basado en bloques.
Si la página depende del shortcode clásico de WooCommerce, estás utilizando el checkout tradicional.
No necesitas modificar nada todavía. El objetivo de esta primera revisión es simplemente saber cuál es el punto de partida.
Este probablemente sea el paso más importante.
Una tienda que lleva varios años funcionando puede tener funciones que nadie recuerda que fueron añadidas expresamente.
Antes de sustituir el checkout, revisa al menos:
No todas estas funciones tendrán necesariamente un problema con los bloques.
Precisamente por eso hay que inventariarlas: para saber qué comprobar.
Una tienda sencilla que vende unos pocos productos y utiliza una pasarela estándar presenta un escenario muy distinto al de un ecommerce que lleva siete años acumulando extensiones y modificaciones a medida.
Esta es una de las dudas más importantes cuando se plantea la migración.
Imagina que actualmente solicitas durante la compra:
No debes asumir que esos campos seguirán apareciendo porque actualmente funcionen en el checkout clásico.
WooCommerce dispone de una API específica para registrar campos adicionales en el Checkout Block. En su implementación actual permite situarlos en información de contacto, direcciones o información del pedido.
Esto demuestra precisamente que las personalizaciones del nuevo checkout tienen sus propios mecanismos de integración.
Además, la compatibilidad depende de cómo se creó tu campo actual.
Puede proceder de:
Cada caso debe comprobarse por separado.
Incluso entre plugins comerciales existen diferencias. WooCommerce mantiene documentación de extensiones que son compatibles con los bloques, otras que presentan limitaciones y otras que todavía requieren utilizar el checkout clásico.
Por eso no existe una respuesta universal del tipo «los campos personalizados funcionan» o «los campos personalizados no funcionan».
La pregunta correcta es:
¿Cómo está creado este campo concreto y está preparado ese mecanismo para el Checkout Block?
Una migración también puede descubrir algo útil: quizá tu checkout está pidiendo más información de la necesaria.
Con los años es fácil acumular campos porque en algún momento alguien pidió añadirlos y después nadie volvió a cuestionarlos.
Antes de invertir tiempo en reproducir cada personalización en el sistema nuevo, revisa para qué se utiliza cada dato.
Pregúntate:
No se trata de eliminar información necesaria. Se trata de evitar migrar automáticamente una complejidad que quizá ya no tiene sentido.
Un checkout visualmente perfecto sirve de poco si el cliente no puede pagar.
WooCommerce señala que una pasarela incompatible con Checkout Blocks puede incluso dejar de aparecer como opción de pago en el nuevo checkout.
No basta, por tanto, con comprobar que tienes instalada una extensión de Stripe, PayPal, tarjeta o cualquier otra pasarela.
Hay que confirmar la compatibilidad de la extensión y versión concretas que utiliza tu tienda.
Para las extensiones comercializadas en WooCommerce.com, WooCommerce muestra información de compatibilidad con Cart y Checkout Blocks en las páginas correspondientes.
Si utilizas un plugin de otro proveedor, consulta su documentación oficial y su historial reciente de actualizaciones.
Y después pruébalo.
La documentación puede decir que existe compatibilidad, pero tu tienda puede añadir otras extensiones, configuraciones o personalizaciones que cambien el resultado.
Los métodos de envío también forman parte del recorrido de compra.
Comprueba escenarios reales como:
No pruebes únicamente el pedido más sencillo posible.
Prueba las situaciones que realmente utilizan tus clientes.
Si dispones de estadísticas de pedidos anteriores, pueden servirte para identificar los escenarios más habituales de la tienda y priorizarlos.
Este es uno de los puntos que más incertidumbre puede generar en una tienda antigua.
Puede que visualmente no exista ningún indicio de personalización, pero haya código modificando el checkout desde:
functions.php;Ese código podría añadir un campo, modificar una validación, cambiar información del pedido o comunicarse con otro sistema.
Y aquí conviene evitar una conclusión excesivamente simple.
No es correcto afirmar que cualquier código creado para el checkout clásico dejará de funcionar con los bloques. Depende de qué hace exactamente y del mecanismo que utiliza.
Sí sabemos, porque WooCommerce lo documenta, que las extensiones que dependían de ciertos hooks para insertar elementos en el antiguo carrito o checkout suelen necesitar integración específica con Cart y Checkout Blocks.
Si nadie sabe qué modificaciones tiene la tienda, el trabajo previo no consiste en migrarlas inmediatamente.
Consiste en identificarlas y entender para qué sirven.
Una tienda que está vendiendo no es un laboratorio.
Si tienes la posibilidad de utilizar un entorno de staging o preproducción, realiza allí primero el cambio.
La idea es disponer de una copia separada en la que puedas:
Esto es especialmente importante cuando intervienen varias extensiones.
WooCommerce también recomienda realizar las pruebas de conflictos en un entorno de staging cuando sea posible en lugar de desactivar componentes indiscriminadamente en una tienda en producción. En nuestra guía sobre qué hacer cuando el checkout de WooCommerce no funciona explicamos por qué experimentar directamente sobre una tienda activa puede afectar a pagos, impuestos, envíos, suscripciones y otras funciones críticas.
Tener staging reduce el riesgo, pero no sustituye una buena copia.
Antes de intervenir en una tienda deberías saber:
En WooCommerce hay además un factor que no puede ignorarse: los pedidos siguen entrando.
Restaurar alegremente una copia antigua sobre una tienda en producción puede hacer que desaparezcan de la base de datos pedidos o cambios realizados después de esa copia.
Por eso «tenemos un backup» no es todavía un plan de vuelta atrás.
En nuestra guía sobre copias de seguridad de WordPress explicamos la diferencia entre generar copias y saber realmente que puedes recuperar una web con ellas. En un ecommerce esa diferencia es especialmente importante porque la base de datos cambia con cada pedido.
Una prueba seria no consiste en entrar en la página, comprobar que carga y dar por terminada la migración.
Hay que completar pedidos.
Como mínimo, reproduce un recorrido real desde que un cliente incorpora un producto al carrito hasta que el pedido aparece correctamente en WooCommerce.
Prueba diferentes tipos de productos que tenga la tienda.
Especialmente aquellos que presenten condiciones distintas: variaciones, productos virtuales, promociones, suscripciones o cualquier configuración relevante para tu negocio.
Comprueba:
Comprueba tanto un cliente nuevo como, si procede, uno que ya tenga cuenta.
Revisa los campos obligatorios y cualquier información personalizada.
Prueba las zonas y situaciones importantes para la tienda.
El método correcto debe aparecer y el importe debe calcularse adecuadamente.
Verifica que los impuestos aplicables sean los esperados para los escenarios relevantes de tu negocio.
Prueba todos los métodos de pago importantes.
No basta con que aparezca su nombre.
El proceso debe poder completarse correctamente.
Después de pagar, entra en WooCommerce y comprueba:
Verifica los emails relacionados con el pedido tanto desde el punto de vista del cliente como del negocio.
Si el pedido debe llegar posteriormente a facturación, logística, CRM, ERP, una herramienta de email marketing o cualquier servicio externo, comprueba también esa parte.
Un checkout puede aceptar el pedido correctamente y aun así romper un proceso posterior del negocio.
Haz al menos una compra de prueba desde un dispositivo móvil.
El checkout es una función demasiado importante para comprobarla únicamente desde el ordenador en el que administras WordPress.
No ignores el aviso.
WooCommerce puede mostrar una advertencia cuando una extensión ha declarado que no es compatible con Cart y Checkout Blocks. En esos casos también puede ofrecer la posibilidad de volver al checkout clásico.
El siguiente paso debería ser identificar qué extensión provoca la advertencia y comprobar:
No sustituyas un plugin importante simplemente para eliminar el aviso sin entender qué función cumple.
En una tienda real, una extensión aparentemente secundaria puede intervenir en precios, impuestos, envíos o información necesaria para procesar pedidos.
Sí, en determinadas circunstancias.
WooCommerce continúa documentando el checkout clásico y reconoce que, en algunos casos, las versiones basadas en shortcode pueden ofrecer mayor compatibilidad con determinadas extensiones.
Por tanto, volver temporalmente al checkout clásico no tiene por qué interpretarse como un fracaso.
Puede ser una decisión prudente si una funcionalidad imprescindible para tu negocio todavía no es compatible con bloques y no dispones de una alternativa segura.
Lo importante es saber por qué mantienes el sistema clásico.
No es lo mismo decir:
«No cambio porque los bloques son malos»
que:
«Esta extensión concreta es necesaria para nuestras ventas, hemos comprobado su documentación y todavía no soporta nuestro caso de uso».
La segunda es una decisión técnica y empresarial razonada.
Mantener el checkout clásico indefinidamente únicamente por miedo tampoco debería ser la estrategia.
Los bloques son la dirección actual de WooCommerce para carrito y checkout y son la configuración predeterminada de las nuevas tiendas desde 8.3.
Si la tienda puede migrar sin perder funciones críticas, adaptarse al sistema actual puede reducir dependencia de soluciones heredadas y facilitar el uso de las capacidades que WooCommerce desarrolla alrededor del nuevo checkout.
La decisión puede tener especialmente sentido cuando:
En una tienda muy personalizada, esta migración puede convertirse además en una buena oportunidad para documentar qué hace realmente cada pieza.
En ese momento ya no estás ante una decisión de migración sino ante una incidencia.
No empieces a desactivar plugins al azar sobre la tienda en producción.
Identifica primero el síntoma:
Cuanto más concreto sea el síntoma, mejor podrá investigarse la causa.
Nuestra guía sobre qué comprobar cuando el checkout de WooCommerce no funciona aborda precisamente esa fase de diagnóstico y explica cómo investigar la incidencia sin empezar a tocar componentes de una tienda activa a ciegas.
Antes de activar definitivamente el nuevo checkout en una tienda existente, deberías poder responder «sí» a estas preguntas:
Si varias respuestas son «no lo sé», todavía no significa que no puedas utilizar el checkout por bloques.
Significa que aún no sabes lo suficiente sobre tu tienda para hacer el cambio con seguridad.
WooCommerce está avanzando hacia un carrito y checkout basados en bloques, pero una tienda que ya está funcionando tiene una realidad que una instalación nueva no tiene: historial.
Plugins instalados durante años, modificaciones de antiguos desarrolladores, campos añadidos para resolver necesidades concretas, integraciones con otros sistemas y clientes que esperan poder comprar hoy.
Por eso la migración debería hacerse en este orden:
inventariar → comprobar compatibilidad → hacer copia → probar → corregir → validar → publicar.
No al revés.
Si después de revisar la tienda descubres que una extensión imprescindible todavía no está preparada, mantener temporalmente el checkout clásico puede ser razonable.
Si, por el contrario, todo lo importante es compatible y las personalizaciones pueden adaptarse correctamente, ya tienes las condiciones para realizar el cambio con mucha más seguridad.
Y si nadie sabe exactamente qué depende del checkout actual, antes de sustituirlo merece la pena hacer una revisión técnica.
Porque el objetivo no es tener el checkout más nuevo.
El objetivo es que el cliente pueda terminar su compra y que todo lo que ocurre después del clic en «realizar pedido» siga funcionando.
