Error fatal WooCommerce: cómo solucionarlo en 2026

Un error fatal en WooCommerce es un error crítico de PHP que detiene la ejecución del sitio y muestra el mensaje «Se ha producido un error crítico en este sitio web». Las causas más frecuentes son conflictos entre plugins, versiones de PHP incompatibles y memoria insuficiente. Con el modo de recuperación de WordPress 5.2+ podés diagnosticarlo sin quedar bloqueado.

¿Qué es exactamente un error fatal en WooCommerce?

Un error fatal de PHP es un error que no se puede recuperar: el intérprete encontró algo que no puede manejar y detiene la ejecución ahí mismo. En el contexto de WordPress y WooCommerce, esto se traduce en la pantalla blanca de la muerte o, desde WordPress 5.2, en el mensaje «Se ha producido un error crítico en este sitio web. Por favor, revisá el buzón de correo electrónico de tu sitio web para obtener instrucciones.»

La diferencia con otros errores es importante. Un Notice o un Warning de PHP no interrumpe la carga: el sitio sigue andando aunque algo esté mal. Un Fatal Error lo para todo. La página no se renderiza, el carrito no carga, los pedidos no se procesan.

Desde WordPress 5.2, el core detecta estos errores automáticamente, activa un modo de recuperación y manda un email al administrador con un link para entrar al panel sin que los plugins problemáticos se carguen. Eso sí: ese email puede tardar, o caer en spam, o simplemente no llegar si el servidor de correo también está mal configurado (lo cual pasa más seguido de lo que quisieras).

Las cuatro causas principales del error fatal WooCommerce

Después de ver esto en docenas de tiendas, las causas siempre rotan entre las mismas:

Conflictos entre plugins

Ponele que tenés Elementor, WooCommerce Subscriptions y algún plugin de cacheo activos al mismo tiempo. Uno de ellos define una función que el otro ya declaró, o enganchan el mismo hook de manera incompatible. PHP tira un «Cannot redeclare function» o «Call to undefined function» y ahí termina todo. Este es el caso más frecuente, y también el más fácil de resolver con el método de desactivación por partes que explico más abajo.

Versión de PHP incompatible

WooCommerce requiere PHP 7.4 como mínimo, pero el equipo recomienda 8.0 o superior desde 2024. Si tu hosting todavía corre PHP 7.2 o 7.3 y actualizaste WooCommerce a una versión reciente, el conflicto es casi seguro. Los errores típicos acá son sobre tipos de argumentos o funciones que dejaron de existir en versiones nuevas del lenguaje. Relacionado: características avanzadas de WooCommerce.

Memoria PHP insuficiente

WooCommerce con varios plugins activos consume fácil 128MB de memoria PHP. En tiendas con muchos productos, variaciones y plugins de sincronización, 256MB se queda corto. Cuando PHP se queda sin memoria, lanza un fatal error de «Allowed memory size exhausted». No hay mucho misterio: hay que subir el límite.

Archivo .htaccess corrupto o mal configurado

Menos frecuente, pero pasa: alguna actualización o migración deja el .htaccess con reglas contradictorias. Apache no puede procesar las reescrituras y tira un error 500 que se parece bastante a un fatal error de PHP pero tiene distinto origen. Antes de asumir que es PHP, revisá el .htaccess.

Cómo diagnosticar el error fatal mediante logs y debug

Sin debug activado, el mensaje de error es genérico y no te dice nada útil. Estos son los pasos para obtener información real:

Paso 1: Activar WP_DEBUG en wp-config.php. Buscá estas líneas en el archivo y modificalas así:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

El WP_DEBUG_DISPLAY false es importante: evitás que los errores se muestren en pantalla (lo cual sería un problema de seguridad en producción) y los mandás al archivo de log.

Paso 2: Revisar los registros de WooCommerce. Desde el panel, andá a WooCommerce > Estado > Registros. Ahí buscá entradas con «fatal_error» o «critical». WooCommerce desde la versión 8.x tiene su propio sistema de logging más detallado que el de WordPress.

Paso 3: Leer el debug.log. El archivo está en wp-content/debug.log y tiene el stack trace completo del error. Buscá la línea que dice Fatal error: y el archivo y número de línea que la sigue. Esa información te dice exactamente qué plugin o tema está fallando. Lo explicamos a fondo en plugins que generan conflictos.

A finales de 2025, un error que apareció bastante en el foro de soporte de WordPress en español fue del tipo strpos(): Argument #1 must be of type string, null given. Ese error específico aparecía en instalaciones que todavía usaban PHP 7.x con versiones nuevas de WooCommerce que asumen tipos más estrictos.

Soluciones paso a paso del error fatal WooCommerce

El método que funciona es el de eliminación. Sin atajos:

• 1. Desactivar todos los plugins desde FTP. Entrá por FTP o el administrador de archivos del hosting y renombrá la carpeta wp-content/plugins a wp-content/plugins_bak. WordPress no va a poder cargar ningún plugin y el sitio debería volver a funcionar (con funcionalidad reducida, obvio).
• 2. Cambiar al tema por defecto. Si con los plugins desactivados el sitio sigue sin funcionar, el problema puede ser el tema. Desde phpMyAdmin o el archivo de opciones, cambiá al tema Twenty Twenty-Four o cualquier tema default de WordPress.
• 3. Reactivar plugins de a uno. Renombrá la carpeta de vuelta a plugins, entrá al admin y activá los plugins uno por uno. Cuando el sitio vuelva a tirar el error, encontraste al culpable.
• 4. Si el problema es PHP: aumentar el memory_limit. En wp-config.php agregá define('WP_MEMORY_LIMIT', '512M');. Si el hosting no lo permite desde ahí, hay que pedirlo desde el panel de hosting o el .htaccess con php_value memory_limit 512M.
• 5. Usar el Recovery Mode. Si recibiste el email de WordPress con el link de recuperación, usalo. Te permite entrar al admin con los plugins problemáticos desactivados automáticamente y tener más información sobre qué falló.

Para el max_execution_time, que también puede causar errores en procesos largos como importaciones, en wp-config.php: set_time_limit(300); o en php.ini max_execution_time = 300.

Requisitos técnicos mínimos de WooCommerce en 2026

Ojo con la columna «mínimo»: esos valores te permiten instalarlo, no necesariamente correrlo sin problemas en producción. Una tienda con 500 productos, 10 plugins activos y tráfico real necesita los valores recomendados como piso, no como techo.

Con WooCommerce 10.5 (febrero de 2026) hubo reportes de errores fatales en instalaciones con PHP 8.0 y algunos plugins de pago desactualizados. El patrón era consistente: el error aparecía al procesar el checkout cuando el gateway intentaba llamar a métodos que WooCommerce 10.5 movió o renombró. La solución fue actualizar los plugins de pago a versiones compatibles con la nueva API.

Conflictos comunes entre plugins y cómo identificarlos

Algunos plugins aparecen una y otra vez en los reportes de conflictos con WooCommerce. No es que sean malos necesariamente; es que tienen mucha superficie de integración con el core y cualquier cambio de versión puede romper algo.

Los más frecuentes: Elementor (especialmente con WooCommerce Blocks), Yoast SEO cuando hay actualizaciones menores simultáneas, Jetpack en instalaciones con muchos módulos activos, WooCommerce Subscriptions cuando cambia la estructura de las tablas de base de datos, y cualquier plugin de caché que no se limpia después de actualizar.

¿Por qué ocurren estos conflictos? Porque WordPress usa un sistema de hooks y filtros donde cualquier plugin puede engancharse en cualquier punto de la ejecución. Si dos plugins hacen add_filter('woocommerce_checkout_fields', 'my_function') y las dos funciones se llaman igual (porque alguien copió código sin cambiar el nombre), PHP tira un fatal error por función duplicada. O si un plugin espera que WooCommerce haya definido una clase antes de que se cargue, y el orden de carga cambió con una actualización. Ya lo cubrimos antes en durante migraciones a WooCommerce.

Incidentes masivos: mayo 2025 y el contexto de 2026

En mayo de 2025, el equipo de WooCommerce publicó un aviso urgente sobre un error fatal generalizado causado por un problema en BlockPatterns.php. El error venía de datos inválidos que retornaba un servicio remoto al intentar cargar patrones de bloque. Afectó múltiples versiones simultáneamente y generó una cantidad importante de reportes en el foro oficial y en GitHub.

La solución en ese momento fue actualizar a WooCommerce 9.8.4 o 9.8.5 (según la versión base). El equipo actuó relativamente rápido, pero el daño estaba hecho para quienes no tenían monitoreo activo: tiendas caídas durante horas en horario laboral.

Lo que dejó ese incidente como lección (que algunos aprendieron y otros no): el error no vino de un plugin externo ni de una configuración incorrecta del usuario. Vino de una dependencia de un servicio externo que WooCommerce llama en tiempo de carga. Algo que ningún análisis de conflictos previo iba a detectar.

Los reportes de febrero de 2026 con WooCommerce 10.5 siguieron un patrón diferente: errores más localizados relacionados con incompatibilidad de extensiones de pago y la nueva arquitectura de bloques. Ningún comunicado de urgencia de Automattic en ese caso, pero sí bastante actividad en el repositorio oficial en GitHub.

Errores que cometemos y cómo evitarlos

Dejar WP_DEBUG activado en producción. Lo activás para diagnosticar, lo resolvés, y te olvidás de desactivarlo. El problema es que con WP_DEBUG_DISPLAY true estás mostrando información interna del sistema a cualquier visitante. Creá un recordatorio inmediatamente después de activarlo.

Actualizar WooCommerce sin hacer backup primero. Sí, lo sabés. Y lo hacés igual. La actualización que rompe todo siempre pasa cuando no hiciste el backup porque «era una actualización menor». Automatizá los backups o usá un plugin que lo haga antes de cada actualización.

Asumir que el problema es el último plugin que instalaste. El fatal error puede aparecer días después de instalar algo porque un cron de WooCommerce recién lo ejecutó, o porque actualizaste otro plugin que creó el conflicto. El método de desactivación por partes existe por esto.

No revisar el changelog antes de actualizar. WooCommerce publica notas de versión detalladas. Si una actualización cambia APIs de extensiones o tiene breaking changes, lo dice ahí. Leer el changelog de un major release toma cinco minutos y puede evitar horas de troubleshooting.

Si alojás tu tienda en un hosting WordPress de Donweb, desde el panel podés cambiar la versión de PHP sin tirar el sitio, lo que facilita bastante el diagnóstico cuando el problema viene de incompatibilidad de versión. Es un detalle que simplifica el proceso cuando ya tenés suficiente presión encima con la tienda caída.

Qué está confirmado y qué no

Preguntas Frecuentes

¿Qué es un error fatal en WooCommerce y por qué aparece?

Un error fatal de WooCommerce es un error crítico de PHP que interrumpe completamente la ejecución del sitio y muestra el mensaje «Se ha producido un error crítico en este sitio web». Aparece cuando PHP encuentra una condición irrecuperable: una función no declarada, memoria agotada, un archivo requerido que no existe, o un conflicto de tipos introducido por actualizaciones incompatibles. A diferencia de los avisos o advertencias de PHP, estos errores no permiten que la página continúe cargando. Cubrimos ese tema en detalle en issues del núcleo de WordPress.

¿Cómo solucionar «Se ha producido un error crítico» en mi tienda WooCommerce?

El primer paso es entrar al panel usando el link del Recovery Mode que WordPress manda por email, o acceder por FTP y renombrar la carpeta de plugins para desactivarlos todos. Si el sitio vuelve a funcionar, reactivá los plugins uno por uno hasta identificar el conflicto. Si el problema persiste con todos los plugins desactivados, revisá la versión de PHP en uso (debe ser 7.4 como mínimo, recomendado 8.2) y el memory_limit (mínimo 256MB para tiendas activas).

¿Cuál es la causa del error fatal al actualizar WooCommerce?

Al actualizar WooCommerce, los errores fatales más comunes vienen de extensiones o plugins que usan APIs que la nueva versión movió, cambió o eliminó. En mayo de 2025 hubo un caso específico donde el error venía del propio core de WooCommerce (BlockPatterns.php con datos inválidos de un servicio remoto), no de plugins de terceros. En febrero de 2026 los reportes apuntaron a plugins de pago desactualizados incompatibles con WooCommerce 10.5. Siempre revisá el changelog y actualizá extensiones antes o inmediatamente después de actualizar el core.

¿Cómo activar el debug para diagnosticar un Fatal Error?

En wp-config.php, agregá o modificá estas tres líneas: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); y define('WP_DEBUG_DISPLAY', false);. Los errores se guardan en wp-content/debug.log con el stack trace completo. También podés revisar WooCommerce > Estado > Registros desde el panel para ver los logs propios del plugin. Acordate de desactivar WP_DEBUG una vez que resolviste el problema.

¿Qué versión de PHP necesita WooCommerce para evitar errores fatales?

WooCommerce requiere PHP 7.4 como mínimo, pero el equipo recomienda 8.0 o superior. En 2026, con WooCommerce 10.x, correr PHP 8.2 es lo más seguro para evitar incompatibilidades tanto con el core como con las extensiones principales. PHP 7.x en producción con versiones recientes de WooCommerce es fuente garantizada de problemas: hay funciones que WooCommerce usa que directamente no existen en esas versiones del lenguaje.

Conclusión

Los errores fatales en WooCommerce no son raros ni van a desaparecer. El incidente de BlockPatterns.php de mayo de 2025 mostró que incluso con una instalación limpia y bien mantenida, una dependencia externa puede tirar todo. Los problemas de febrero de 2026 con WooCommerce 10.5 confirmaron que las actualizaciones siguen siendo el momento de mayor riesgo.

Lo que cambia cuando tenés el proceso claro es la velocidad de resolución. Con WP_DEBUG activado, backups automáticos antes de cada actualización, y el método de desactivación por partes incorporado como reflejo, pasás de horas de tienda caída a minutos de diagnóstico. La «gran solución» no existe; hay proceso, y hay preparación.

Si todavía corrés PHP 7.4 o menos, ese es el primer cambio que tenés que hacer hoy, antes de actualizar cualquier cosa. Todo lo demás puede esperar; eso no.

Fuentes

• WooCommerce Developer Blog – Fatal Error: Immediate Action Required (mayo 2025)
• GitHub WooCommerce – Issue tracker de errores fatales reportados
• WooCommerce Docs – Guía oficial de troubleshooting de errores fatales
• WooCommerce Docs – Diagnóstico de errores PHP en WooCommerce
• WordPress.org en español – Foro de soporte: WooCommerce error crítico