Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Errors & Diagnosis

El carrito de WooCommerce se vacía en el checkout: sesiones, cookies y caché

Un carro vacío en checkout normalmente significa que el WooCommerce sesión cookie o los datos del carro se perdieron entre solicitudes. Trace la transición.

Qué importa primero: El producto fue añadido, pero el sesión utilizado por checkout no contiene el mismo carrito. La ruptura es generalmente cookie alcance, caché de página completa, inconsistencia objeto-caché o un cambio de dominio/sistema.

Qué indica realmente este síntoma

La configuración refrescante puede enmascarar el problema brevemente, pero el navegador cookies y el servidor sesión muestran si el cliente cambió de identidad entre el carro y checkout.

Recopila pruebas antes de cambiar nada

  • Graba el carro y checkout URLs, servidor, esquema y cadena de redireccionamiento.
  • Inspecciona WooCommerce sesión y cargue cookies antes y después de la transición.
  • Prueba cerrada con la página/CDN caché bypassed.
  • Comprueba el espacio de almacenamiento sesión para objetos-caché, nodos balanceados de carga y bases de datos.

Causas más habituales

  • Carro en caché o checkout: Una respuesta compartida en caché ignora el carro privado del visitante.
  • Desajuste del dominio Cookie: El carrito pertenece a www, non-www, HTTP u otro subdominio.
  • Coherencia objeto-caché: Diferentes nodos o prefijos devuelven un estado sesión diferente.
  • Reglas agresivas de cookie: El código de consentimiento u optimización elimina WooCommerce cookies.

Secuencia segura de diagnóstico y reparación

  1. Excluir carrito, checkout, cuenta y WooCommerce AJAX rutas desde caché de página completa.
  2. Alinea el dominio canónico y HTTPS redirige a un servidor establa.
  3. Verifica el almacenamiento compartido sesión y los prefijos caché en cada nodo web.
  4. Repetir los viajes de producto a salida en el escritorio limpio y móvil sesiones.

Cómo distinguir entre las causas probables

No trates Carro en caché o checkout y Desajuste del dominio Cookie como causas equivalentes. Una respuesta compartida en caché ignora el carro privado del visitante. En cambio, el carrito pertenece a www, non-www, HTTP u otro subdominio. Para distinguirlas, usa estas dos comprobaciones: Graba el carro y checkout URLs, servidor, esquema y cadena de redireccionamiento; y inspecciona WooCommerce sesión y cargue cookies antes y después de la transición. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Excluir carrito, checkout, cuenta y WooCommerce AJAX rutas desde caché de página completa— o si debes conservar el estado actual y ampliar la investigación.

En una tienda activa, reproduce el problema con un pedido de prueba controlado y sigue el mismo recorrido de pago, stock, impuestos y notificaciones que usan los clientes. No cambies varios componentes del checkout a la vez, porque destruirías la evidencia necesaria para atribuir el fallo. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.

Qué no debes hacer

No desactives permanentemente cada capa caché. Identifica qué capa cachés estado privado y Mantén la caché segura en otro lugar.

Cómo verificar la reparación

  • Un carrito logged-out persiste a través del carrito, checkout y la selección de pagos.
  • Cookies permanece en el esquema canónico de servidor y seguro.
  • Los visitantes separados nunca reciben el estado del carro del otro.

Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia