Cómo solucionar la pantalla blanca de la muerte en WordPress

La pantalla blanca de la muerte de WordPress es un error fatal de PHP con la visualización de errores desactivada: el código falló antes de generar cualquier HTML, y WordPress oculta el mensaje de error para que no filtre rutas de archivos ni detalles del servidor a los visitantes.

Actualizas un plugin, recargas el sitio y obtienes una página en blanco en el front end, a menudo también en wp-admin. Sin error, sin stack trace, sin nada en lo que hacer clic. La tentación es empezar a desactivar cosas al azar, pero el mensaje ya existe; simplemente no se te está mostrando. Todos los pasos que siguen funcionan por SFTP o mediante el administrador de archivos del hosting, y hay una vía a través de la base de datos para hostings que ofrecen phpMyAdmin pero no acceso a archivos.

¿Qué es la pantalla blanca de la muerte de WordPress?

Una pantalla blanca significa que PHP encontró un error fatal antes de poder renderizar la página, y WordPress suprime deliberadamente el texto del error en sitios de producción porque puede exponer rutas, versiones y otros detalles internos. Los archivos y la base de datos del sitio están intactos; un componente hizo fallar la petición.

Antes de tocar nada, revisa la bandeja de entrada del correo de administración. Desde la versión 5.2, WordPress envía un correo al administrador cuando ocurre un error fatal, indicando el plugin o tema que falla e incluyendo un enlace que activa el modo de recuperación, un estado en el que el componente averiado queda en pausa para que puedas acceder al escritorio y desactivarlo. Ese enlace lleva una clave secreta; escribir la URL del modo de recuperación a mano no concede acceso. Si el correo nunca llega (los filtros de spam se lo comen, y el correo solo se envía cuando el error se produce en un endpoint protegido como wp-login.php o el área de administración, no en una página del front end ni en una tarea cron), continúa más abajo.

Activa el registro, no la visualización

Abre wp-config.php por SFTP o con el administrador de archivos de tu hosting y añade estas líneas encima de /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Recarga la página averiada y luego abre el log, normalmente en wp-content/debug.log. Según la documentación de depuración de WordPress, WP_DEBUG_LOG no tiene efecto a menos que WP_DEBUG sea true, y WP_DEBUG_DISPLAY es true por defecto, razón por la cual el fragmento lo establece explícitamente en false. Nunca imprimas errores en la página de un sitio en producción: cada visitante vería rutas del servidor y detalles del código. Elimina las cuatro líneas una vez que el sitio esté arreglado.

Lee el error: la ruta identifica al culpable

El log te da un archivo y un número de línea, y el directorio de esa ruta te indica qué componente falló. Una entrada realista se ve así:

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

La ruta está bajo wp-content/plugins/acme-slider/, por lo que el plugin Acme Slider es la causa, y renombrar esa única carpeta arregla el sitio de inmediato. Como regla general:

Si el log indica en cambio un error de memoria, lee la siguiente sección. Solo si el log está vacío debes recurrir a los pasos de bisección.

¿Cómo se soluciona un error de agotamiento de memoria en WordPress?

Un error que comienza con Allowed memory size of X bytes exhausted significa que PHP alcanzó su techo de memoria a mitad de la petición. Aumenta el límite de WordPress en wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress establece WP_MEMORY_LIMIT por defecto en 40M en sitios individuales y 64M en multisitio, y solo aumenta el límite de PHP, nunca lo reduce. La constante funciona solo hasta el techo que tu hosting imponga a nivel de servidor; si 256M no cambia nada, el límite lo impone el plan de hosting, no la configuración, y necesitarás que el proveedor lo aumente.

¿Cómo se desactiva un plugin defectuoso sin wp-admin?

Si el log indica un plugin, renombra únicamente la carpeta de ese plugin dentro de wp-content/plugins/. Si el log está vacío, aplica bisección: renombra wp-content/plugins a plugins.hold, carga /wp-admin/plugins.php para que WordPress marque los plugins ausentes como desactivados, vuelve a renombrar la carpeta a su nombre original y luego activa los plugins de nuevo uno a uno, recargando el sitio después de cada uno, hasta que falle. Volver a activar cada plugin a mano es el precio de esta vía, pero los ajustes que cada uno tenga almacenados quedan intactos.

¿Sin acceso a archivos, pero con phpMyAdmin disponible? Abre la tabla wp_options (tu prefijo puede no ser wp_), busca la fila donde option_name sea active_plugins y copia o exporta su option_value actual a un lugar seguro. Después reemplaza el valor por el array vacío serializado a:0:{}, lo que desactiva todos los plugins de una vez. Restaura el valor guardado más adelante si necesitas la lista original.

¿Cómo se desactiva un tema averiado?

Si el log apunta a wp-content/themes/, renombra únicamente la carpeta del tema activo, por ejemplo mytheme a mytheme.hold. WordPress recurre a un tema predeterminado incluido si hay uno instalado; si no hay ninguno, instala uno primero mediante el administrador de archivos. El culpable habitual es functions.php, y el log ya te ha indicado la línea exacta, a menudo una edición reciente con un error de sintaxis. Corrige esa línea y devuelve el nombre original a la carpeta.

¿Sigue en blanco? Cachés, permisos y versión de PHP

Antes de confiar en cualquier resultado, purga todas las cachés: la caché de páginas del plugin, cualquier caché del servidor y la de tu navegador. Una página en blanco cacheada puede hacer que un sitio ya arreglado parezca averiado, y una página correcta cacheada puede ocultar un error en producción. Después revisa los permisos de archivos, normalmente 755 para directorios y 644 para archivos en hosting compartido, y confirma tu versión de PHP: la base que WordPress recomienda es 8.3 o superior. Un sitio con 7.4 seguirá cargando, pero esa rama dejó de recibir parches de seguridad hace años.

Tres casos quedan fuera del alcance de este artículo: restaurar desde una copia de seguridad (la herramienta de backups de tu hosting, teniendo en cuenta que pierdes todo lo posterior a la instantánea), archivos del core corruptos (vuelve a copiar una descarga limpia de WordPress sobre todo excepto wp-content y wp-config.php) y malware (sigue el proceso de recuperación de sitios hackeados de tu proveedor).

Conclusión

Una página en blanco de WordPress es un mensaje de error suprimido, no un misterio, y la solución más rápida siempre consiste en leer ese mensaje en lugar de adivinar a su alrededor. Añade ahora las cuatro líneas de depuración a wp-config.php, recarga una vez y deja que la ruta en wp-content/debug.log te diga exactamente qué carpeta renombrar.

Preguntas frecuentes

¿Cuál es la diferencia entre la pantalla blanca de la muerte y el mensaje 'Ha habido un error crítico en esta web'?

Desde WordPress 5.2, un gestor de errores fatales integrado captura la mayoría de los errores fatales de PHP e imprime el mensaje de error crítico en lugar de una página en blanco. Una pantalla completamente blanca significa que PHP murió antes de que ese gestor pudiera ejecutarse, habitualmente por agotamiento de memoria o por un error muy temprano en la carga, como dentro de wp-config.php. Ambos casos proceden de errores fatales de PHP, y los pasos de depuración son idénticos.

¿Por qué wp-content/debug.log está vacío aunque WP_DEBUG esté activado?

Las causas habituales son un error que se produce antes de que las constantes de depuración surtan efecto, como un fallo de sintaxis dentro de wp-config.php, o un directorio wp-content en el que el servidor web no puede escribir, lo que impide que WordPress cree el archivo. Comprueba que las constantes estén encima del comentario de 'stop editing' y luego pide a tu proveedor el log de errores de PHP a nivel de servidor, que registra los errores fatales independientemente de la configuración de WordPress.

¿Por qué la pantalla blanca aparece en algunas páginas y en otras no?

El error fatal reside en código que solo se ejecuta en esas peticiones. Un fallo en un archivo de plantilla del tema deja el front end en blanco mientras wp-admin sigue funcionando, porque el área de administración no renderiza plantillas del front end. Un fallo en código de un plugin exclusivo del administrador produce lo contrario. Activa el registro de depuración, carga una página averiada y la ruta de archivo del error registrado identificará el componente que falla.

¿Es seguro dejar WP_DEBUG y WP_DEBUG_LOG activados después de arreglar el sitio?

No. El log se guarda por defecto en wp-content/debug.log, una ruta predecible y accesible desde la web que muchos hostings no bloquean, por lo que cualquiera que solicite esa URL puede leer rutas de archivos, detalles de errores e información interna de los plugins, y el archivo crece sin rotación. Elimina las líneas de depuración de wp-config.php una vez que el sitio funcione, o establece WP_DEBUG_LOG con una ruta de archivo personalizada fuera de la raíz web pública.