Nota revisada y reescrita el 18 de octubre de 2026: la versión original tenía errores y datos sin fuente.
Ha habido un error crítico en esta web. Es la pantalla que muestra WordPress cuando PHP lanza un error fatal. El mensaje no dice nada útil a propósito: la causa real está en otro sitio. Este es el orden en el que lo buscaría.
1. El email del modo de recuperación
Desde WordPress 5.2, cuando ocurre un error fatal se envía un email al administrador con el archivo, la línea y el plugin o tema que lo causó, y un enlace de modo de recuperación. Ese enlace te deja entrar al panel con el componente culpable desactivado solo para ti, mientras los visitantes siguen viendo el error.
Si el email no llega, revisa el correo del servidor o un SMTP. El aviso va a la dirección de administración de Ajustes → Generales, o a la definida en la constante RECOVERY_MODE_EMAIL.
2. El log de PHP
Activa el registro en wp-config.php, sin mostrar los errores en pantalla:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // escribe en wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // no los enseña a los clientes
@ini_set( 'display_errors', 0 );
WP_DEBUG_LOG también acepta una ruta en lugar de true (desde WordPress 5.1). Si puedes, ponla fuera de la carpeta pública: wp-content/debug.log es accesible por URL y puede filtrar rutas y datos.
Reproduce el error y busca la línea PHP Fatal error:
tail -f wp-content/debug.log | grep -A5 "Fatal"
Las causas típicas en el checkout son una función de un plugin que ya no existe tras una actualización (Call to undefined function), un tipo de dato inesperado en PHP 8 (TypeError, o Unsupported operand types) o una plantilla del tema que sobrescribe una de WooCommerce y se ha quedado vieja.
Desactívalo cuando termines: WP_DEBUG en producción ralentiza la web y llena el disco.
3. Los logs de WooCommerce
En WooCommerce → Estado → Registros (Logs) hay registros propios. Los fatales se guardan con la fuente fatal-errors, y las pasarelas de pago escriben los suyos (Stripe, PayPal...) si activas su modo de depuración. Un fallo de la pasarela no siempre es un error fatal: puede ser una respuesta de la API que solo aparece aquí.
En WooCommerce → Estado → Estado del sistema tienes las versiones de PHP, WordPress y WooCommerce, los plugins activos y las plantillas del tema que están desactualizadas respecto a las de WooCommerce. Esto último es una causa frecuente tras actualizar.
4. Aislar el culpable sin romper producción
Si el log no deja claro qué componente es, toca aislarlo. El plugin Health Check & Troubleshooting tiene un modo de resolución de problemas que desactiva plugins y cambia a un tema por defecto solo para tu sesión. Activa WooCommerce, pasa por el checkout y ve añadiendo plugins hasta que vuelva el error.
En una copia de staging, WP-CLI es más rápido:
wp plugin deactivate --all --exclude=woocommerce
wp plugin activate nombre-del-plugin # uno a uno hasta que falle
5. Después
- Revisa en el changelog del plugin si el fallo está corregido en una versión nueva. Si no, vuelve a la versión anterior (desde WP-CLI:
wp plugin install nombre --version=x.y.z --force). - Si el problema era una plantilla del tema, compárala con la de
woocommerce/templates/de la versión actual. - Antes de la próxima actualización, pruébala en staging y repite una compra completa en modo test de la pasarela.