WooCommerce no genera el correo de un pedido: estados y notificaciones
Comprueba el evento del pedido y la notificación configurada antes de investigar SMTP. Un correo que nunca se generó necesita un diagnóstico distinto de uno rechazado.
Si falta el correo de un pedido, primero comprueba si WooCommerce llegó a generar la notificación esperada. El estado del pedido, el evento que la inicia, los ajustes y las personalizaciones pueden impedir que exista un mensaje para entregar. En ese caso, cambiar el SMTP no corrige el origen.
Esta guía investiga la generación de notificaciones de pedidos. Si ya hay evidencia de que el mensaje se entregó al transporte, sigue el recorrido de envío y entrega de correo desde WordPress, teniendo en cuenta que sus comprobaciones posteriores no son exclusivas de formularios.
Definir qué notificación debería existir
Anota pedido, destinatario previsto, evento y momento esperado. Un aviso al administrador y uno al comprador pueden tener ajustes y disparadores distintos. No busques un correo genérico de pedido si la operación esperaba una notificación específica.
Comprueba el recorrido de ese pedido y sus notas, sin publicar datos personales. Identifica cuándo se confirmó el pago, qué estados se registraron y si hubo intervención manual. El historial disponible ayuda a reconstruir el recorrido, pero no es automáticamente un registro de entrega de correos.
Comprobar el evento antes de cambiar estados
La documentación de diagnóstico de WooCommerce relaciona la generación de determinados mensajes con cambios de estado y ajustes habilitados. También advierte de errores que pueden ocurrir antes de completar esa transición.
No fuerces un pedido a completado solo para intentar recibir un email. Un cambio de estado puede activar otros procesos, integraciones o comunicaciones. Define primero qué transición correspondía y si la pasarela o el flujo personalizado debían haberla realizado.
Revisar ajustes y destinatarios de esa notificación
En la configuración de emails de WooCommerce puedes revisar las notificaciones disponibles. Comprueba si la esperada está habilitada y qué destinatario utiliza cuando ese dato es configurable.
Las extensiones pueden añadir notificaciones y reglas propias. Distingue el aviso estándar de uno creado por una personalización, suscripción o herramienta de marketing. No atribuyas a los ajustes generales una condición que se mantiene en otro componente.
Como ejemplo hipotético, un mensaje al negocio podría estar habilitado mientras el destinado al comprador depende de otro evento. Recibir el primero no verifica la configuración del segundo.
Localizar errores entre el evento y la preparación del mensaje
Busca errores correlacionados con la hora de la operación. Una plantilla modificada, un dato inesperado o un fallo en código añadido pueden interrumpir el recorrido. Conserva el detalle técnico sin mostrarlo públicamente ni exponer información del pedido.
Compara un caso que funcione con otro que no: tipo de producto, método de pago, estado y personalizaciones. La finalidad es reproducir una diferencia concreta, no desactivar componentes al azar en una tienda que recibe ventas.
Investigar tareas pendientes cuando el flujo las utilice
Si la extensión o el recorrido aplaza el trabajo, identifica la tarea y su resultado. No todos los mensajes comparten el mismo mecanismo ni una cola sin errores acredita que ese evento se hubiera programado.
Elimina la confusión entre tarea ausente, pendiente, fallida y finalizada. Reejecutar una acción sin entender sus efectos puede repetir comunicaciones u otras operaciones. La guía de consumo de recursos WooCommerce aporta contexto sobre tareas, pero una cola acumulada necesita conservar evidencia antes de limpiarla.
Validar sin generar cobros ni notificaciones accidentales
Prepara un entorno de pruebas aislado y un recorrido representativo con destinos de correo controlados. Prueba el evento que debería producir la notificación, no únicamente un botón de envío de prueba del transporte.
Si debes intervenir en producción, acuerda qué acciones están autorizadas y qué destinatarios recibirán mensajes. Una recuperación manual debe distinguir una notificación nunca generada de otra cuyo resultado es incierto para evitar duplicados.
Qué debe quedar documentado
Registra evento esperado, ajustes revisados, causa comprobada y prueba posterior. No cierres la incidencia solo porque un mensaje de prueba SMTP llegó: falta confirmar el recorrido real del pedido.
Podemos revisarlo mediante mantenimiento WooCommerce, diagnóstico WordPress o desarrollo WordPress cuando el flujo necesario no coincide con el estándar.