La pantalla blanca de la muerte en WordPress, explicada

La pantalla blanca de la muerte es un error fatal de PHP que no puedes ver. WordPress sufrió un error irrecuperable a mitad del renderizado, PHP se detuvo y, como la visualización de errores está desactivada en los servidores de producción, la página volvió en blanco en lugar de mostrar el motivo. La solución casi nunca es cuestión de adivinar: activa el debug log, abre wp-content/debug.log y lee la última línea fatal. Ahí aparece el nombre del archivo exacto — casi siempre un plugin o un tema — y esa única línea es toda la reparación.

Por qué la pantalla está en blanco

PHP tiene un ajuste llamado display_errors. En una máquina de desarrollo normalmente está activado, así que un error fatal imprime un stack trace en la pantalla. En un hosting real está desactivado por defecto, porque filtrar rutas de archivos y errores a los visitantes es un problema de seguridad. Así que cuando algo lanza un error fatal — una llamada a una función que ya no existe, una clase que no está cargada, un error de sintaxis en la actualización de un plugin — PHP muere y no envía nada. Tu navegador renderiza un documento vacío. Eso es la “pantalla blanca”.

Desde WordPress 5.2 existe un manejador de errores fatales (WP_Fatal_Error_Handler) que intenta capturarlos. Cuando funciona, no obtienes una página en blanco, sino “Ha habido un error crítico en esta web”, además de un correo a la dirección del administrador que a menudo contiene el error real y un enlace al Modo de recuperación. Una pantalla realmente en blanco suele significar que el error se disparó antes de que ese manejador pudiera ejecutarse: un error de parseo/sintaxis (capturado en tiempo de compilación), un must-use plugin roto o un error fatal en el functions.php del tema activo. En cualquier caso, la causa está escrita en algún sitio. Solo tienes que activar esa escritura.

Soluciónalo, en orden

1. Activa el log. Edita wp-config.php por SFTP y añade esto encima de la línea /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY en false mantiene los errores fuera de la página pública mientras WP_DEBUG_LOG los escribe en wp-content/debug.log. Recarga la página rota una vez para generar una entrada nueva.

2. Lee el último error fatal. Abre wp-content/debug.log y mira el final:

tail -n 30 wp-content/debug.log

Buscas una línea como esta:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

La ruta señala al culpable: plugins/some-addon. Esa es tu respuesta. Si el trace es largo o el mensaje es críptico (Allowed memory size exhausted, Cannot redeclare, un nombre de clase que no reconoces), pégalo en nuestro descifrador de logs de errores: elimina el ruido, te dice a qué plugin o tema apunta la ruta y explica qué significa ese tipo de error concreto.

3. Desactiva el componente señalado. No puedes acceder a /wp-admin, así que hazlo por SFTP. Renombra la carpeta del plugin problemático, por ejemplo some-addon → some-addon.off. WordPress no puede cargar una carpeta que no encuentra, así que desactiva el plugin y el sitio vuelve. Si el log apunta a tu tema, cambia a un tema por defecto renombrando la carpeta del tema activo — WordPress recurre a un twentytwentysomething incluido.

4. Si el log no se escribe, es que wp-content no tiene permisos de escritura, o el error está a nivel de servidor. Revisa en su lugar el log de errores de PHP del hosting:

find . -name "error_log" -newermt "-1 hour"

La misma información, en un archivo distinto. Los stacks de cPanel/Apache suelen dejar un error_log en la raíz del sitio o en el directorio que falla.

Qué no hacer

No te limites a subir el límite de memoria. El consejo más repetido en internet es aumentar WP_MEMORY_LIMIT a 256M o 512M. Eso solo arregla la pantalla blanca si el log dice realmente Allowed memory size of N bytes exhausted. Si el error es Call to undefined function, más memoria no hace nada — has cambiado un ajuste al azar y la pantalla sigue en blanco. Lee el log primero y luego sube la memoria solo si la memoria es el problema declarado.

No vacíes la caché y lo llames diagnóstico. La pantalla blanca es PHP muriendo en el servidor antes de que exista ningún HTML. Un recurso cacheado obsoleto no puede provocar un documento en blanco. (Un plugin de caché roto sí puede — pero el log lo nombrará, que es de lo que se trata.)

No edites ni reinstales el core de WordPress. El error fatal casi nunca está en wp-includes ni en wp-admin; está en el plugin o el tema al que apunta el log. Reinstalar el core es lento, arriesgado y trata un síntoma que no has confirmado.

No desactives todos los plugins para reactivarlos uno a uno a ciegas. El bisecado funciona, pero es el camino lento. El log te dice la carpeta exacta en un solo paso. Recurre al método de “apagarlo todo” solo cuando no haya ningún error legible en absoluto.

No dejes display_errors activado en producción. Una vez que el sitio esté de vuelta, elimina las definiciones de debug (o vuelve a poner WP_DEBUG en false). Los errores mostrados a los visitantes exponen tus rutas.

¿Sigues atascado?

Si el log nombra un plugin pero desactivarlo no despeja la pantalla, hay un segundo error fatal por debajo del primero — vuelve a activar el log y lee la nueva última línea; los errores fatales se apilan. Si el mensaje en sí es el muro, suéltalo en el descifrador de logs de errores y deja que te traduzca el tipo de error y la ruta del archivo. La pantalla blanca solo sigue siendo un misterio mientras el log está apagado.