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

Qué es la pantalla blanca de la muerte en WordPress

La pantalla blanca WordPress, más conocida como WSOD por sus siglas en inglés White Screen of Death, es ese momento helado en el que abres tu sitio y solo ves un fondo blanco sin ningún mensaje de error. Ni siquiera el panel de administración carga. La pantalla queda en blanco como si la web hubiera dejado de existir. Para quien depende del sitio para vender o atender clientes, ese silencio es peor que cualquier error con código rojo.

El problema con la WSOD es que no te dice nada. No hay número, no hay pista, no hay traza. Tu navegador simplemente recibe una respuesta vacía del servidor y te muestra esa hoja en blanco que parece eterna. La buena noticia es que detrás de ese silencio siempre hay una causa concreta y, con los pasos correctos, se puede destapar y arreglar en una o dos horas como máximo.

En el Perú, donde muchas pymes manejan su propio WordPress sin tener un desarrollador de planta, la WSOD suele aparecer después de una actualización mal calculada, de un cambio de plugin o de tocar archivos sensibles sin saber qué se está haciendo. Por eso conviene tener claro el método de diagnóstico antes de que pase, no después.

Por qué aparece la pantalla blanca de la muerte

La WSOD aparece cuando PHP encuentra un error fatal pero no tiene permiso para mostrarlo en pantalla. Es el equivalente digital a un cortocircuito silencioso. El servidor procesa la petición, choca con algo que no puede ejecutar, corta la salida y devuelve una respuesta vacía. El navegador interpreta esa respuesta vacía como una página en blanco.

Las causas más comunes son los errores de sintaxis en PHP. Cuando un plugin o un tema tiene una llave mal cerrada, un punto y coma faltante o una llamada a una función que ya no existe, todo el sistema se cae. WordPress está diseñado para procesar el código en cadena, así que un solo carácter mal puesto hace caer toda la cadena.

Otra causa frecuente es el agotamiento de memoria PHP. Cuando un plugin pesado o una operación masiva como importar miles de productos consume más memoria de la asignada, PHP se rinde y devuelve una pantalla vacía. Esto pasa mucho en tiendas WooCommerce grandes que comparten servidor con otros sitios y no tienen suficiente RAM para procesar pedidos en horarios pico.

También aparece WSOD por incompatibilidades entre plugins. Dos extensiones que intentan modificar la misma función del núcleo de WordPress pueden chocar entre sí y dejar el sitio en blanco. Lo mismo ocurre cuando un plugin no fue probado contra la versión actual de WordPress o contra la versión actual de PHP que usa el hosting.

Una causa menos obvia pero igual de común son los temas mal codificados. Un tema descargado de fuentes poco confiables puede contener código malicioso, funciones obsoletas o llamadas a archivos que ya no existen. Al activarlo, todo el frontend del sitio se queda en blanco mientras el backend a veces sigue accesible.

Activar el modo debug para ver qué pasa

El primer paso ante una pantalla blanca siempre es activar el modo de depuración. Sin esto, estás trabajando a ciegas y vas a perder tiempo probando soluciones al azar. El modo debug le dice a WordPress que muestre o registre todos los errores que normalmente esconde para no molestar al visitante.

Para activarlo hay que entrar al hosting por FTP, SFTP o por el administrador de archivos del panel. Una vez dentro, abre el archivo wp-config.php que está en la raíz del sitio. Busca la línea que dice define WP_DEBUG con valor false y cámbiala por define WP_DEBUG con valor true. Justo debajo agrega define WP_DEBUG_LOG con valor true para que los errores se guarden en un archivo. También agrega define WP_DEBUG_DISPLAY con valor false para que los errores no se muestren al visitante.

Con esto activado, los errores se registran en un archivo llamado debug.log dentro de la carpeta wp-content. Ese archivo es el santo grial del diagnóstico. Allí aparecen los mensajes exactos de PHP, las rutas de los archivos involucrados, los números de línea donde falla el código y muchas veces el nombre del plugin o del tema responsable.

Conviene refrescar el sitio una o dos veces después de activar el debug para forzar a WordPress a generar entradas en el log. Luego se descarga el archivo debug.log a la computadora local y se abre con cualquier editor de texto. Los errores fatales aparecen marcados con la etiqueta Fatal error y son los que primero hay que atacar.

Cómo desactivar todos los plugins por FTP

Cuando la WSOD impide entrar al panel de administración, no se pueden desactivar plugins desde la interfaz. La única salida es hacerlo por FTP, que es básicamente acceder a los archivos del sitio como si fueran carpetas en tu computadora.

El procedimiento es simple. Conéctate al hosting con un cliente FTP como FileZilla usando los datos que te dio tu proveedor. Navega hasta la carpeta wp-content del sitio. Dentro vas a encontrar tres carpetas principales: plugins, themes y uploads. La que interesa para este paso es plugins.

Renombra la carpeta plugins a algo como plugins-desactivados o plugins-old. Eso es todo. WordPress, al no encontrar la carpeta original, considera que no hay plugins activos y los apaga a todos de golpe. Refresca el sitio. Si carga normalmente, la WSOD venía de algún plugin.

Ahora viene la parte de identificar al culpable. Renombra la carpeta de vuelta a plugins. Vuelve a entrar al panel de administración, que ahora debería estar accesible aunque con todos los plugins desactivados. Activa los plugins uno por uno, refrescando el sitio después de cada activación. El plugin que vuelva a tumbar la página es el responsable.

Una vez identificado el plugin culpable, las opciones son borrar el plugin si no es esencial, buscar una versión actualizada en el repositorio oficial, contactar al desarrollador para reportar el bug o buscar una alternativa que cumpla la misma función sin causar el problema.

Cambiar al tema por defecto para descartar el tema

Si la desactivación de plugins no resuelve la WSOD, el siguiente sospechoso es el tema activo. Los temas también ejecutan código PHP y pueden generar errores fatales por exactamente las mismas razones que los plugins.

La forma rápida de descartar el tema es activar un tema por defecto de WordPress como Twenty Twenty Four o Twenty Twenty Five. Estos temas vienen probados y mantenidos por el equipo oficial de WordPress, así que es muy raro que causen WSOD por sí mismos. Si al activarlos el sitio vuelve a funcionar, el problema estaba en tu tema personalizado.

Cuando no se puede entrar al panel, el cambio de tema también se hace por FTP. Entra a la carpeta wp-content y luego a la subcarpeta themes. Renombra la carpeta del tema activo agregando algo al final del nombre, como tema-respaldo. WordPress, al no encontrar el tema activo, automáticamente busca el tema por defecto más reciente que tengas instalado y lo activa.

Si confirmas que el problema es del tema, no borres tu tema personalizado de inmediato. Probablemente solo necesita una corrección menor en algún archivo PHP, una actualización o un ajuste de compatibilidad. Contacta al desarrollador del tema o revisa el changelog para ver si hay una versión nueva disponible.

Usar un tema hijo para evitar perder personalizaciones

Una de las razones más frustrantes por las que aparece la WSOD es que el usuario edita el archivo functions.php del tema directamente y mete un error de sintaxis. Cuando esto pasa, el sitio cae y, peor todavía, cuando el tema se actualiza desde el repositorio, todas las personalizaciones se pierden.

Para evitar este problema existe el concepto de tema hijo o child theme. Un tema hijo es básicamente una capa que vive encima del tema padre y hereda toda su funcionalidad. Allí se hacen las personalizaciones sin tocar el código original. Si algo sale mal, basta con desactivar el tema hijo y el sitio vuelve al estado anterior usando el tema padre intacto.

Crear un tema hijo es sencillo. Se hace una carpeta dentro de wp-content slash themes con un nombre como mi-tema-hijo. Dentro se crean dos archivos mínimos: style.css con un encabezado que indique el tema padre y functions.css con las funciones personalizadas. Hay plugins gratuitos que automatizan esta creación si no te animas a hacerlo a mano.

Adoptar el hábito del tema hijo es una de las decisiones que más estabilidad da a un sitio WordPress en el largo plazo. Cualquier desarrollador con experiencia te lo va a recomendar como primera medida antes de tocar una sola línea de código personalizado.

Aumentar la memoria PHP para descartar agotamiento

Si los pasos anteriores no resuelven la WSOD, vale la pena descartar el problema de memoria. El procedimiento es agregar una línea al archivo wp-config.php que le diga a WordPress que puede usar más memoria de la que tiene asignada por defecto.

Abre wp-config.php desde el FTP o el administrador de archivos. Justo antes del comentario que indica que pares de editar, agrega la línea define WP_MEMORY_LIMIT con valor 512M entre comillas simples. Esto sube el límite a 512 megabytes, que es más que suficiente para la mayoría de sitios, incluyendo tiendas WooCommerce con varios miles de productos.

Después de guardar el cambio, refresca el sitio. Si la pantalla blanca desaparece, la causa era memoria insuficiente. En ese caso conviene investigar qué plugin o qué tarea estaba consumiendo tanto. A veces se trata de un plugin de respaldos que se queda colgado en una operación, otras veces es un importador masivo que no libera memoria correctamente.

Si tu hosting tiene un tope duro de memoria que no permite subir ese valor aunque lo definas, la solución pasa por contratar un plan superior o por migrar a un proveedor con más recursos. En el Perú hay opciones de hosting administrado especializado en WordPress que asignan memoria PHP generosa desde planes intermedios.

Revisar errores en el archivo debug.log

Una vez que el modo debug está activo y el debug.log empieza a llenarse, el siguiente paso es leerlo con atención. Este archivo es a veces extenso y puede tener cientos de líneas, pero los errores fatales son los únicos que importan para resolver la WSOD.

Busca dentro del archivo las líneas que empiezan con Fatal error o PHP Fatal. Cada una de estas líneas viene seguida de una descripción del error, la ruta del archivo que lo provocó y el número de línea exacta donde ocurrió. Esa información es suficiente para identificar el archivo problemático y, en muchos casos, para corregirlo directamente.

Los errores más comunes que aparecen en debug.log son Cannot redeclare function, que indica que dos plugins definen la misma función con el mismo nombre, Class not found, que señala que una clase PHP necesaria no existe, y Call to undefined function, que muestra que se está llamando a una función que no está disponible en la versión de PHP o de WordPress activa.

Cuando el error apunta a un plugin específico, ya sabes a quién desactivar. Cuando apunta al tema, ya sabes qué archivo revisar. Y cuando apunta al núcleo de WordPress, lo mejor es restaurar los archivos del core desde una descarga limpia del repositorio oficial.

Cómo prevenir la pantalla blanca de la muerte

La prevención de la WSOD se basa en hábitos sencillos pero rigurosos. Un sitio WordPress saludable no sufre WSOD nunca o muy rara vez, y eso no es suerte sino disciplina en el mantenimiento.

El primer hábito es nunca actualizar plugins, temas o núcleo directamente en producción sin haber probado antes en un entorno de staging. La gran mayoría de hostings serios ofrecen staging con un par de clics. Allí se prueban las actualizaciones, se confirma que todo funciona y recién se replica el cambio en producción.

El segundo hábito es mantener respaldos automáticos diarios o semanales. Cuando la WSOD aparece, un respaldo reciente te permite restaurar el sitio en minutos en lugar de pasar horas diagnosticando. Plugins gratuitos como UpdraftPlus o pagos como BackWPup hacen este trabajo sin que tengas que acordarte.

El tercer hábito es evitar editar archivos PHP directamente desde el editor de temas del panel de WordPress. Ese editor no tiene control de versiones ni capacidad de revertir cambios, así que un error de tipeo puede dejar el sitio en blanco al instante. Si necesitas editar código, hazlo por FTP con respaldos previos y usando un editor de código que detecte errores de sintaxis antes de guardar.

El cuarto hábito es mantener el sitio con la versión más reciente de PHP soportada por el hosting. WordPress y la mayoría de plugins serios prueban contra las versiones modernas, así que quedarse en PHP 7.4 o anteriores aumenta la probabilidad de incompatibilidades y WSOD futuras.

Preguntas frecuentes

Qué hago si la pantalla blanca aparece después de actualizar un plugin

Lo más probable es que ese plugin esté provocando un error fatal. Conéctate al hosting por FTP, entra a wp-content slash plugins y renombra la carpeta del plugin recién actualizado agregando algo al final como plugin-roto. Eso lo desactiva automáticamente. Refresca el sitio y debería volver a funcionar. Luego decide si esperar a una nueva versión del plugin o buscar una alternativa.

Puedo recuperar el sitio sin tener respaldo

Sí, la mayoría de veces se puede. La WSOD rara vez borra contenido. Los textos, imágenes y configuraciones siguen intactos en la base de datos y en wp-content. Con el método de desactivar plugins por FTP y volver al tema por defecto, normalmente el sitio se recupera sin perder nada. El respaldo es para casos extremos como hackeos o borrados accidentales.

La pantalla blanca afecta solo a algunas páginas

Cuando solo algunas páginas muestran pantalla blanca y otras cargan bien, casi siempre es un problema de algún shortcode, bloque personalizado o widget que se está usando solo en esas páginas. Edita las páginas afectadas y quita los elementos uno por uno hasta encontrar el que rompe la salida. Es un buen método de aislamiento.

El modo debug muestra información sensible al público

Sí, por eso siempre se debe configurar WP_DEBUG_DISPLAY en false en producción. Esa línea evita que los errores se muestren al visitante y los redirige solo al archivo debug.log. Mostrar errores con rutas y nombres de archivos al público es un riesgo de seguridad porque ayuda a posibles atacantes a entender la estructura del sitio.

Conviene usar plugins de mantenimiento ante una WSOD

No directamente, porque si el sitio está caído no podrás activar un plugin de mantenimiento desde el panel. Lo que sí conviene es configurar previamente un archivo maintenance.php o usar el modo mantenimiento de WordPress para futuros eventos. Eso muestra una página amigable al visitante mientras se resuelve el problema técnico detrás.

Es necesario contratar un desarrollador para resolver la WSOD

Para los casos más comunes no es necesario. Los pasos de desactivar plugins por FTP, cambiar al tema por defecto y aumentar memoria PHP se pueden hacer sin programación. Si después de estos pasos el sitio sigue en blanco, allí sí conviene buscar un desarrollador porque el problema puede estar en código personalizado, en la base de datos o en la configuración del servidor.

La WSOD puede ser síntoma de un hackeo

Sí, en algunos casos los hackeos inyectan código malicioso en archivos PHP que provoca errores fatales y WSOD. Si después de resolver la WSOD aparecen redirecciones extrañas, anuncios que no instalaste o archivos nuevos en el servidor que no reconoces, lo más probable es que el sitio haya sido vulnerado. En ese caso conviene una limpieza profesional con un plugin como Wordfence o un servicio especializado.

Qué tema por defecto debo usar para descartar el problema

El más reciente disponible. WordPress incluye temas oficiales llamados Twenty Twenty Cuatro, Twenty Twenty Cinco y los anteriores. Cualquiera de ellos sirve como prueba. Lo importante es que sea uno oficial de WordPress y no un tema personalizado descargado de terceros. Después de la prueba puedes volver a tu tema original o quedarte temporalmente con el oficial mientras resuelves el problema.

Cuánto tiempo toma resolver una WSOD típica

Si tienes acceso por FTP y sabes los pasos básicos, una WSOD típica se resuelve en treinta minutos a una hora. La parte más lenta suele ser identificar al plugin culpable cuando hay muchos instalados. Los casos complejos donde el problema está en la base de datos o en el servidor pueden tomar varias horas o requerir intervención del soporte del hosting.

Después de resolver la WSOD, qué debo hacer para evitar que vuelva

Implementa staging para probar actualizaciones antes de producción, activa respaldos automáticos diarios, mantén el sitio actualizado en todos sus componentes, desinstala plugins que no uses, evita temas y plugins de fuentes poco confiables y monitorea el sitio con UptimeRobot o similar. Estos cinco hábitos eliminan el noventa por ciento de las causas de WSOD futuras.