Cómo reparar el fatal error en WordPress

El fatal error en WordPress es un error de PHP que detiene por completo la ejecución del sitio. Aparece cuando el servidor no puede completar una operación, ya sea por memoria insuficiente, un plugin roto o código incompatible. Saber cómo reparar error fatal WordPress te ahorra horas de crisis.

Qué es el Fatal Error en WordPress

Un fatal error en WordPress es un error de PHP que interrumpe completamente la ejecución del script, dejando el sitio inaccesible o mostrando una pantalla en blanco (lo que en el argot se conoce como White Screen of Death). No es un aviso ni un warning que podés ignorar: cuando PHP lanza un Fatal error, se detiene todo.

Hay diferencia entre un fatal error genérico y los que WordPress reporta con su propio sistema de mensajes. Desde WordPress 5.2, el núcleo tiene un «modo de recuperación» que intenta aislar el plugin o tema que rompió todo y manda un email al admin. Pero no siempre funciona, y cuando el error está en el núcleo o en el servidor, no hay modo de recuperación que alcance.

PHP tiene distintos niveles de error: E_NOTICE, E_WARNING, E_ERROR. El fatal error corresponde a E_ERROR y sus variantes (E_PARSE, E_CORE_ERROR). Esos no se pueden atrapar en tiempo de ejecución: si PHP los encuentra, el proceso muere.

Causas principales del Fatal Error

Hay un puñado de causas que explican el 90% de los casos. Conocerlas antes de empezar a manotear archivos te ahorra tiempo.

• Memoria insuficiente: WordPress arranca con un límite de 40MB definido en el núcleo, pero muchos hostings lo dejan en 64MB o 128MB. Un plugin de caché, un page builder o una galería con regeneración de thumbnails pueden disparar el consumo y romper la carga.
• Plugin incompatible o desactualizado: un plugin que no fue actualizado para PHP 8.x, o que usa funciones deprecadas, puede lanzar un fatal error en cuanto se activa. También pasa cuando dos plugins se pisan entre sí.
• Tema con errores de código: los temas hijos mal construidos, o actualizaciones de temas padre que rompen compatibilidad, aparecen como fatal error en el front.
• Extensiones PHP no disponibles: algunos plugins requieren extensiones como mbstring, gd, zip o curl. Si el servidor no las tiene activas, el plugin falla con un fatal error al intentar cargarlas.
• Timeout o límite de ejecución: si max_execution_time es muy bajo (30 segundos es el default en muchos servidores), operaciones largas como importaciones o backups pueden morir a mitad de camino.

¿Cuál es la más común? La de memoria, por amplio margen. Si tenés un sitio con varios plugins activos y empezó a fallar después de instalar uno nuevo, empezá por ahí.

Solución 1: Cómo reparar error fatal WordPress aumentando la memoria

Este es el arreglo más frecuente. Abrís wp-config.php (está en la raíz de tu instalación WordPress), y antes de la línea que dice /* That's all, stop editing! Happy publishing. */, agregás esto:

• define( 'WP_MEMORY_LIMIT', '256M' ); — para el front del sitio
• define( 'WP_MAX_MEMORY_LIMIT', '512M' ); — para el panel de administración (operaciones más pesadas)

El valor de 256MB es el que WordPress recomienda para sitios con plugins moderados, según la documentación oficial de wp-config.php. Para sitios más complejos, 512MB o más es razonable.

Eso sí: que WordPress le pida 256MB al servidor no significa que el servidor lo vaya a dar. Tu proveedor de hosting tiene su propio límite en php.ini. Si después de editar wp-config.php el problema persiste, el límite real del servidor es más bajo que lo que pedís. En ese caso tenés que modificar el php.ini directamente (si tenés acceso), o crear un archivo .htaccess con php_value memory_limit 256M (solo en servidores Apache), o pedirle al soporte del hosting que lo suba.

Para verificar cuánta memoria PHP está usando realmente, podés crear un archivo phpinfo.php temporal con <?php phpinfo(); ?> y buscar el valor de memory_limit. Acordate de borrarlo después, porque deja expuesta información del servidor.

Solución 2: Desactivar plugins y tema

Ponele que el error aparece justo después de activar un plugin, o que no podés entrar al admin porque el fatal error aparece antes de cargar el dashboard. La solución es desactivar todo vía FTP o el administrador de archivos del hosting.

El método más directo: conectate por FTP, navegá a wp-content/plugins/ y renombrá la carpeta del plugin sospechoso (por ejemplo, de elementor a elementor_OFF). WordPress no lo va a encontrar y lo va a desactivar automáticamente. Si el sitio vuelve, ese era el responsable.

Si no sabés cuál plugin es, renombrá la carpeta entera plugins a plugins_OFF. WordPress va a desactivar todos y vas a poder entrar al admin. Después los reactivás de a uno para identificar el culpable. (Sí, es tedioso. Pero funciona.)

Para el tema: navegá a wp-content/themes/ y renombrá el tema activo. WordPress va a caer al tema por defecto (Twenty Twenty-Four o similar). Si el error desaparece, el problema estaba en el tema.

Solución 3: Habilitar Debug Mode para ver el error real

Sin ver el mensaje exacto del error, estás adivinando. Activar el modo debug te da el archivo, la línea y el tipo de error. Eso cambia completamente el diagnóstico. Tema relacionado: proteger tu landing page del error.

En wp-config.php, agregá o modificá estas tres líneas, según la guía de debugging oficial de WordPress:

• define( 'WP_DEBUG', true ); — activa el modo debug
• define( 'WP_DEBUG_LOG', true ); — guarda los errores en wp-content/debug.log
• define( 'WP_DEBUG_DISPLAY', false ); — NO muestra los errores en pantalla (para no exponerlos a visitantes)

Con eso, los errores se escriben en wp-content/debug.log. Abrís ese archivo y buscás las líneas con Fatal error. Te van a decir algo como:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wp.php on line 742

Ese mensaje ya te dice exactamente qué pasó (memoria), en qué archivo y en qué línea. Con eso podés buscar la solución correcta en vez de aplicar parches a ciegas.

Acordate de desactivar WP_DEBUG cuando termines. Dejar el debug activo en producción expone información sensible del servidor a cualquiera que sepa dónde mirar.

Solución 4: Escalar al soporte del hosting

Hay casos donde el problema no está en WordPress ni en los plugins, sino en los límites del servidor. Si ya aumentaste la memoria en wp-config.php, desactivaste plugins y el error persiste, es momento de hablar con el soporte técnico del hosting.

Qué preguntar específicamente:

• ¿Cuál es el límite actual de memory_limit en PHP?
• ¿Cuál es el valor de max_execution_time?
• ¿Hay logs de errores del servidor (no solo de PHP) que muestren qué pasó?
• ¿El plan actual tiene restricciones de recursos que podrían estar causando el error?

Los planes de hosting compartido más básicos suelen tener límites de 128MB o 256MB en PHP. Si tu sitio creció y consume más, o si instalaste plugins pesados, quizás necesitás un plan con más recursos. Un hosting WordPress pensado para sitios reales, como el hosting WordPress de Donweb, arranca con límites razonables y tiene soporte técnico que puede ajustar los valores de PHP si el plan lo permite.

Si el soporte no puede (o no quiere) subir los límites, es una señal de que el plan tiene un techo y quizás sea momento de migrar a uno con más capacidad.

Comparativa de soluciones según tipo de error

Prevención y buenas prácticas

La mayoría de los fatal errors son evitables. No con magia, sino con hábitos concretos. Más contexto en probar la solución en staging primero.

Actualizá WordPress, plugins y tema regularmente. Una cantidad importante de fatal errors viene de incompatibilidades entre versiones viejas. Un plugin que no se actualiza en más de un año y sigue activo en tu sitio es una bomba de tiempo (si es que eso cuenta como mantenimiento).

Usá un entorno de staging antes de aplicar actualizaciones grandes. Subir una actualización de WooCommerce directo a producción sin probarla antes es apostar. La mayoría de los hostings con planes WordPress incluyen entornos de staging o podés armar uno con un plugin.

Elegí plugins con historial de actualizaciones activo y buenas reseñas. El directorio oficial de WordPress muestra la fecha de última actualización y la compatibilidad con la versión actual del núcleo. Un plugin que no se toca hace dos años y que instalás en un WordPress 6.7 es candidato a problemas.

Monitoreá el uso de memoria. Plugins como Query Monitor o Health Check & Troubleshooting te muestran el consumo de memoria en tiempo real. Si estás viviendo al límite del memory_limit, tarde o temprano algo va a romper.

Errores comunes al intentar reparar el fatal error

Error 1: Subir el límite de memoria a valores absurdos. Ver en foros «ponele 1024M y listo» es un consejo pésimo. Si el sitio necesita 1GB de RAM para cargar una página, el problema no es el límite, es el código. Aumentar la memoria tapa el síntoma pero no arregla el plugin o tema mal escrito que la consume. 256MB cubre el 95% de los casos reales.

Esto lo cubrimos más en detalle en Fatal error – how to fix it.

Error 2: Activar WP_DEBUG_DISPLAY en true en producción. Si dejás que los errores se muestren en pantalla, cualquier visitante ve información del servidor: rutas de archivos, versiones de software, estructura de la base de datos. Siempre usá WP_DEBUG_LOG para escribir al archivo y WP_DEBUG_DISPLAY en false.

Error 3: Borrar el debug.log sin leerlo. El archivo wp-content/debug.log puede tener cientos de líneas, pero las que importan son las de Fatal error. Buscar con Ctrl+F en el archivo ya es suficiente para dar con la causa. Cubrimos ese tema en detalle en revisar otros problemas del sitio.

Error 4: Reinstalar WordPress pensando que eso arregla todo. Si el error viene de un plugin o del límite de memoria, reinstalar el núcleo no cambia nada. Además, si hacés una reinstalación mal hecha podés perder configuración. Antes de reinstalar, agotá las otras opciones.

Preguntas Frecuentes

¿Cómo reparar el error fatal en WordPress si no puedo acceder al admin?

Conectate al servidor por FTP o el administrador de archivos del hosting. Navegá a wp-content/plugins/ y renombrá la carpeta del plugin que instalaste antes de que apareciera el error. Si no sabés cuál es, renombrá toda la carpeta plugins. WordPress desactiva todos y podés entrar al admin. También podés editar wp-config.php directamente desde FTP para subir el límite de memoria.

¿Qué causa el fatal error en WordPress con más frecuencia?

La memoria insuficiente es la causa número uno. El valor por defecto de WordPress es 40MB, pero un sitio con plugins modernos (constructores de páginas, WooCommerce, caché) necesita mínimo 128MB y muchas veces 256MB. La segunda causa más frecuente es un plugin incompatible con la versión de PHP del servidor, especialmente al actualizar a PHP 8.x.

¿Cómo aumentar el límite de memoria en WordPress?

Abrí wp-config.php y antes de la línea /* That's all, stop editing! */ agregá: define( 'WP_MEMORY_LIMIT', '256M' );. Para el admin: define( 'WP_MAX_MEMORY_LIMIT', '512M' );. Si el error persiste, el límite real del servidor es más bajo y hay que ajustarlo en php.ini o pedirle al hosting que lo modifique, según la documentación de PHP.

¿Cómo activar el debug mode para ver el fatal error real?

En wp-config.php agregá 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. Buscá líneas con Fatal error: te van a dar el archivo y la línea exacta donde ocurrió el error. Desactivá el debug cuando termines.

¿Por qué aparece fatal error solo en el panel de administración y no en el front?

El admin de WordPress tiene operaciones más pesadas que el front: actualizaciones, generación de miniaturas, exportaciones. Para el admin, WordPress usa WP_MAX_MEMORY_LIMIT en vez de WP_MEMORY_LIMIT. Si solo te falla en el admin, agregá define( 'WP_MAX_MEMORY_LIMIT', '512M' ); en wp-config.php. También puede ser un plugin de administración (SEO, seguridad, backups) que consume más en el contexto del admin.

Conclusión

El fatal error en WordPress asusta porque deja el sitio caído y a veces ni siquiera podés entrar al panel. Pero la mayoría de los casos tienen solución en menos de 20 minutos si sabés por dónde empezar: aumentar la memoria en wp-config.php, desactivar plugins vía FTP, y activar el log de debug para ver el error real.

El truco es ir en orden. Primero memoria, después plugins, después el log. Si después de esos tres pasos el error sigue, ahí escalás al soporte del hosting con el mensaje exacto del log en la mano, no con «me aparece pantalla en blanco». Esa diferencia hace que el soporte pueda ayudarte en minutos en vez de mandarte a un artículo genérico de la base de conocimiento.

Y para los próximos: un entorno de staging, actualizaciones regulares y un hosting con límites de memoria razonables te sacan de la mayoría de estos aprietos antes de que lleguen a producción.

Fuentes

• WordPress.org — Debugging in WordPress (guía oficial de WP_DEBUG)
• WordPress.org — Editing wp-config.php (referencia oficial)
• PHP Manual — memory_limit (documentación oficial de PHP)