Pantalla blanca en WordPress: cómo solucionar el White Screen of Death
En vez de tu web solo ves un vacío blanco, sin mensaje de error, sin acceso al escritorio. La pantalla blanca de WordPress, el famoso White Screen of Death, asusta a primera vista, pero en la inmensa mayoría de los casos se resuelve en pocos minutos siguiendo un orden claro.
Cargas tu web y no aparece nada. Ni mensaje de error, ni aviso, solo una superficie blanca vacía. El escritorio en /wp-admin suele quedarse igual de en blanco. Bienvenido a la pantalla blanca de WordPress, conocida internacionalmente como White Screen of Death o WSoD. La buena noticia: casi nunca es señal de una base de datos destruida ni de un servidor comprometido, sino de un único error de PHP que obliga a WordPress a detenerse antes de mostrar cualquier mensaje. En este artículo repasamos, paso a paso, cómo encontrar la causa y volver a poner tu web en marcha.
Qué es realmente el White Screen of Death
Técnicamente, la pantalla blanca no es un tipo de error propio, sino el síntoma visible de un error fatal de PHP: un plugin o un tema llama a una función que no existe, agota el límite de memoria o falla de alguna otra forma. En una web en producción, la salida de errores está desactivada por defecto para que los visitantes no vean rutas internas del servidor. El problema es que, sin esa salida, la página se detiene sin más y tú tampoco recibes ninguna pista de qué falló. Por eso el WSoD parece al principio tan opaco, aunque la causa casi siempre se identifica con precisión en cuanto activas la salida de errores.
Paso 1: mantén la calma y comprueba la copia de seguridad
Antes de tocar nada, un paso breve pero importante: comprueba si existe una copia de seguridad reciente de tu web y de cuándo es. La mayoría de los hostings ofrecen copias automáticas diarias, y muchos plugins de backup también. Una copia actual es tu red de seguridad: te permite, en el peor de los casos, volver sin más al último estado que funcionaba, en lugar de pasarte horas buscando. Si no existe ninguna, genera una manualmente ahora mismo, si el hosting o el plugin todavía lo permiten, antes de tocar archivos o la base de datos.
Paso 2: activa WP_DEBUG y lee el debug.log
El paso más importante de todos: conéctate por FTP o por el gestor de archivos de tu hosting, abre el archivo wp-config.php en el directorio raíz de WordPress y busca la línea define('WP_DEBUG', false);. Sustitúyela por este bloque, justo encima de la línea /* That's all, stop editing! */:
- define('WP_DEBUG', true); activa el modo depuración en general
- define('WP_DEBUG_LOG', true); guarda todos los errores en un archivo de log en lugar de solo mostrarlos
- define('WP_DEBUG_DISPLAY', false); evita que los errores aparezcan en directo en la web, visibles para cualquier visitante
Guarda el archivo, recarga la web una vez y abre después el archivo recién generado wp-content/debug.log. Ahí suele quedar registrado con precisión qué archivo, función y línea provocaron el error fatal, normalmente con un aviso del tipo "Fatal error: Uncaught Error: Call to undefined function" o "Allowed memory size exhausted". Esa única línea es la clave de la solución. Vuelve a poner WP_DEBUG en false en cuanto resuelvas el problema: dejarlo activo de forma permanente es un riesgo innecesario de seguridad y de rendimiento.
Paso 3: revisa el log de errores de tu hosting
Si ni siquiera puedes acceder a wp-config.php por FTP o gestor de archivos, o el debug.log se queda vacío, hay una segunda fuente: el log de errores del propio servidor, gestionado por tu hosting. Casi cualquier panel, ya sea Plesk, cPanel o uno propio del proveedor, ofrece un apartado de "registro de errores" que guarda los fallos de PHP con independencia de WordPress. Es especialmente útil cuando el error ocurre tan pronto que WordPress ni llega a procesar su propia configuración. Si tampoco encuentras nada ahí, pregunta al soporte de tu hosting por las últimas entradas de error de PHP en tu dominio.
Paso 4: aísla el conflicto de plugins
La gran mayoría de los casos de pantalla blanca se puede atribuir a un único plugin, a menudo justo después de una actualización. Así se procede:
- 1. Desactiva todos los plugins: conéctate por FTP y renombra la carpeta
wp-content/plugins, por ejemplo aplugins-off. Así WordPress deja de reconocer los plugins y los desactiva todos de golpe. - 2. Comprueba la web: si ahora vuelve a cargar, el causante era un plugin. Devuelve el nombre original a la carpeta,
plugins; los plugins seguirán desactivados por ahora. - 3. Reactiva uno a uno: en el escritorio, en "Plugins", activa uno tras otro y recarga la web después de cada paso. En cuanto vuelva la pantalla blanca, habrás encontrado al culpable.
- 4. Alternativa por base de datos: si tampoco tienes acceso por FTP, consigues el mismo efecto con
phpMyAdmin, poniendo en la tablawp_optionsel valora:0:{}en la entradaactive_plugins.
Una vez identificado el plugin responsable, actualízalo o revisa su foro de soporte por si otros usuarios reportan el mismo error. Si persiste, una alternativa más ligera suele ser más duradera que dejarlo desactivado de forma indefinida.
Paso 5: cambia a un tema por defecto
Si aislar los plugins no resuelve nada, el turno es para el tema activo. Aquí también ayuda el rodeo por FTP o phpMyAdmin si no puedes entrar al escritorio: renombra la carpeta de tu tema activo en wp-content/themes. WordPress recurrirá automáticamente a un tema por defecto instalado, como Twenty Twenty-Four. Si la web carga ahora, el fallo estaba en el tema, por ejemplo en su functions.php o en un child theme desactualizado. Comprueba si hay una actualización disponible o contacta con el desarrollador.
Paso 6: aumenta el límite de memoria PHP
Si en el debug.log o en el log de errores aparece un aviso del tipo "Allowed memory size of X bytes exhausted", la causa está clara: WordPress ha pedido más memoria de la que tiene asignada, a menudo por varios plugins que consumen mucha memoria a la vez. Añade en wp-config.php, justo encima de la línea /* That's all, stop editing! */, esta línea:
- define('WP_MEMORY_LIMIT', '256M'); sube el límite de memoria de WordPress a 256 megabytes
Si no es suficiente, el límite de PHP a nivel de servidor suele ser más bajo que el de WordPress y hay que subirlo también en el php.ini de tu hosting. Eso sí, subir la memoria solo corrige el síntoma: un plugin que llega habitualmente al límite suele estar, sencillamente, mal programado en cuanto a consumo de recursos.
Paso 7: comprueba la versión de PHP
No es raro que la pantalla blanca aparezca justo después de un cambio de versión de PHP por parte del hosting, porque algún plugin o tema antiguo no es compatible con la nueva versión. Revisa en el panel de tu hosting qué versión está activa y compárala con los requisitos mínimos de tus plugins. Si tienes dudas, prueba a volver temporalmente a la versión anterior para confirmarlo.
Paso 8: usa el modo de recuperación y el correo de recuperación
Desde WordPress 5.2, el núcleo trae incorporado un salvavidas: si detecta un error fatal, envía automáticamente un correo al administrador con un enlace al modo de recuperación. A través de ese enlace accedes al escritorio aunque la web siga en blanco para los visitantes, y ahí verás qué plugin o tema causó el error, con opción de desactivarlo de prueba. Revisa primero tu bandeja de entrada, incluido el spam: muchas veces la solución está a solo dos clics.
Paso 9: restablece el archivo .htaccess
Mucho menos frecuente, pero posible: un archivo .htaccess mal formado también puede provocar una pantalla blanca o un error 500, por ejemplo tras una edición manual o una actualización de plugin fallida. Renombra el archivo de prueba por FTP, por ejemplo a htaccess-backup, y recarga la web. Si funciona, WordPress genera uno nuevo y limpio en cuanto guardes una vez en "Ajustes → Enlaces permanentes". Comprueba después que ningún enlace interno apunte al vacío. Fragmentos y reglas de reescritura probados los encuentras en nuestra guía de snippets de .htaccess para WordPress.
Cuándo conviene avisar al hosting
La mayoría de los casos se resuelven con los pasos anteriores por tu cuenta. Pero hay límites claros: sin acceso por FTP ni gestor de archivos, si el log apunta a un fallo del servidor y no a código PHP, si los límites de memoria están bloqueados a nivel de servidor, o si no te sientes seguro tocando la base de datos. Un buen hosting suele revisar el log del servidor en pocos minutos y darte la causa exacta, a menudo más rápido que probar cada opción tú mismo.
La causa de fondo: por qué aparece el WSoD en primer lugar
Con toda la guía de pasos, merece la pena mirar la raíz del problema. En nuestra experiencia como proveedores de plugins, el desencadenante más habitual es casi siempre el mismo: plugins y temas mal programados, recargados de funciones o desactualizados, que se vuelven incompatibles tras una actualización de PHP o lanzan un error fatal porque las funciones internas no están bien protegidas. Cuantos más plugins tengas activos, más de ellos sean todoterrenos con un catálogo enorme de funciones, y más tiempo lleve alguno sin actualizarse, mayor es la probabilidad de la próxima pantalla blanca.
Un apunte honesto, aunque como proveedores de plugins no seamos del todo neutrales: los plugins ligeros y bien mantenidos reducen este riesgo de forma notable. Un plugin que resuelve exactamente una tarea suele ir más rápido que una lancha, mientras que un todoterreno sobrecargado arrastra cada función como un carguero, la necesites o no. Con ese principio construimos Linkjet, MemberJet y Adjet: plugins GPLv2 gratuitos, ligeros y mantenidos activamente. Nuestro tema Hafen lleva esa misma idea al terreno del tema y ya está disponible como beta gratuita para descargar. Más consejos para mantener tu web ligera y estable en el artículo WordPress lento: cómo acelerar tu web en 10 pasos, y la seguridad básica en nuestra guía para proteger WordPress de hackers.
Conclusión
La pantalla blanca de WordPress parece a primera vista un fallo total, pero casi siempre es un único error fatal, claramente identificable. Activa WP_DEBUG, lee el debug.log o el log de errores, aísla plugins y tema de forma sistemática, revisa el límite de memoria y la versión de PHP, y recurre si hace falta al modo de recuperación. Con estos nueve pasos sueles volver a poner tu web en marcha por tu cuenta, y con plugins ligeros y bien mantenidos evitas que la próxima pantalla blanca llegue a aparecer.
Una base ligera en vez del próximo error fatal
Linkjet, MemberJet y Adjet son plugins GPLv2 gratuitos y mantenidos activamente, sin lastre. Con Hafen construimos el tema a juego, rápido como una lancha en vez de pesado como un carguero. Ya disponible como beta gratuita.
Preguntas frecuentes
¿Qué significa exactamente White Screen of Death en WordPress?
El White Screen of Death, o pantalla blanca de WordPress, es una página vacía y blanca, sin ningún mensaje de error, que aparece cuando un error fatal de PHP interrumpe la ejecución antes de que se pudiera generar ninguna salida visible. En una web en producción, la salida de errores está desactivada por defecto para que los visitantes no vean rutas internas del servidor, por eso la pantalla simplemente queda en blanco en lugar de mostrar un aviso. Casi siempre hay detrás un plugin o un tema con un fallo, a menudo tras una actualización. Al activar WP_DEBUG, la causa real suele quedar visible de inmediato.
¿Pierdo datos o contenido con la pantalla blanca?
No, con el White Screen of Death normalmente no pierdes ni datos ni contenido. El WSoD afecta solo a la visualización de la web, mientras que tu base de datos, con todas las entradas, páginas y ajustes, queda intacta, porque la causa casi siempre es un único error fatal de PHP y no una base de datos destruida. Aun así, antes de intervenciones mayores como renombrar carpetas de plugins o temas, conviene comprobar que existe una copia de seguridad reciente, o crear una. Así tienes una red de seguridad por si algo sale mal al solucionarlo.
¿Cómo entro al escritorio si wp-admin también está en blanco?
Si wp-admin también se queda en blanco, igualmente puedes acceder a tu web por FTP, por el gestor de archivos de tu hosting o por phpMyAdmin. Desde ahí puedes renombrar carpetas de plugins y temas, o restablecer en la base de datos la entrada active_plugins, sin necesidad de entrar al escritorio. Además, desde WordPress 5.2, el núcleo envía automáticamente un correo de recuperación a la dirección del administrador con un enlace al modo de recuperación en cuanto detecta un error fatal. Revisa primero tu bandeja de entrada, incluido el spam: muchas veces la solución está a solo dos clics.
¿Cómo puedo evitar una pantalla blanca en el futuro?
Para evitar una pantalla blanca en el futuro, mantén WordPress, PHP, el tema y los plugins actualizados de forma constante, y prueba las actualizaciones primero en una web de pruebas siempre que sea posible. Apuesta preferiblemente por plugins ligeros y mantenidos activamente en vez de todoterrenos sobrecargados, porque cuantos más plugins tengas activos y más tiempo lleve alguno sin actualizarse, mayor es la probabilidad de un error fatal. Soluciones ligeras como Linkjet, MemberJet o Adjet reducen ese riesgo de forma notable, porque hay menos código innecesario en ejecución. Así tu web queda más estable en general, también tras un cambio de versión de PHP por parte del hosting.
¿Basta con dejar WP_DEBUG activado de forma permanente?
No, dejar WP_DEBUG activado de forma permanente no es suficiente ni recomendable. WP_DEBUG_DISPLAY debe permanecer siempre desactivado en una web en producción, para que los visitantes no vean mensajes de error internos ni rutas del servidor. Tampoco deberías dejar WP_DEBUG_LOG activo tras terminar la búsqueda del fallo, porque el debug.log crece sin necesidad y sigue siendo un riesgo de seguridad y de rendimiento. Activa el modo depuración de forma puntual para buscar el error y desactívalo de nuevo en cuanto lo hayas resuelto.