El sitio funcionaba hace un segundo, usted estaba terminando un artículo o configurando WooCommerce y, de repente, nada. Una pantalla blanca en lugar del panel de administración. O la página de inicio desapareció, aunque el escritorio aún abre. ¿Le suena familiar? Bienvenido al club, ha conocido la Pantalla Blanca de la Muerte, también conocida como WSOD, también conocida como la «pantalla blanca de la muerte» de WordPress.

El pánico aquí es el primer enemigo. La WSOD casi nunca significa que el sitio esté muerto para siempre. La mayoría de las veces la causa es mundana: un conflicto de plugins tras una actualización, código mal insertado en functions.php o simple falta de memoria para el proceso PHP. En esta guía, cuatro formas comprobadas de devolver el sitio a la vida y una quinta integrada en el núcleo de WordPress que incluso los usuarios experimentados olvidan.

💡 Resumen rápido:

• Desactive el plugin problemático mediante FTP (renombre la carpeta) o en bloque renombrando el directorio plugins
• Desactive el tema conflictivo usando el mismo método: carpeta themes → renombre el directorio del tema activo
• Aumente el límite de memoria PHP con la línea WP_MEMORY_LIMIT en wp-config.php a 128M o 256M
• Active WP_DEBUG y WP_DEBUG_LOG para diagnóstico, conozca la causa exacta del error desde el archivo debug.log
• Use el Modo de Recuperación (WordPress 5.2+), un mecanismo integrado que envía un enlace para acceder al panel de administración incluso durante un error fatal
• Restaure el sitio desde una copia de seguridad si los otros métodos no funcionaron

1. Desactivar el plugin problemático

Los plugins son la causa más común de la WSOD. Usted acaba de actualizar su plugin de caché favorito, la pantalla se volvió oscura. Instaló un nuevo slider, el sitio dejó de abrir. La mecánica es simple: el código PHP del plugin causa un error fatal y WordPress detiene la carga de toda la página.

El problema es que usted no puede iniciar sesión en el panel de administración y hacer clic en «Desactivar», el panel de administración también se va a una pantalla blanca. La solución: desactive el plugin directamente a través del sistema de archivos.

Cómo desactivar un plugin mediante FTP:

• Conéctese al servidor vía FTP (FileZilla, WinSCP) o a través del administrador de archivos del hosting (cPanel → Administrador de archivos).
• Navegue al directorio raíz de WordPress.
• Abra wp-content/plugins.
• Encuentre la carpeta del plugin problemático, el nombre coincide con el título (por ejemplo, akismet, woocommerce o elementor).
• Renombre la carpeta: añada un guion bajo o sufijo, _akismet o akismet_disabled. WordPress percibirá el cambio de nombre como la ausencia del plugin y lo desactivará.

Inmediatamente después de renombrar, abra el sitio en su navegador. Si funciona, el culpable está encontrado. Ahora puede restaurar el nombre original de la carpeta y, tras iniciar sesión en el panel de administración, actualizar el plugin a una versión compatible, o eliminarlo y buscar una alternativa.

Desactivación masiva de todos los plugins a la vez. Si no está claro qué plugin exacto causó la falla, desactive todo en bloque. Renombre la carpeta wp-content/plugins a plugins_old y cree un nuevo directorio plugins vacío junto a ella. Todos los plugins quedan desactivados. Luego tráigalos de vuelta uno por uno: mueva la carpeta del plugin de plugins_old de vuelta a plugins, inicie sesión en el panel de administración, actívelo y revise el sitio. Repita hasta encontrar al culpable.

Alternativa para quienes tienen WP-CLI. Un comando en la terminal reemplaza el baile de FTP con pandereta:

1
wp plugin deactivate --all

Y luego active uno por uno: wp plugin activate <slug>. Rápido, limpio, sin administrador de archivos.

2. Desactivar el tema conflictivo

El segundo culpable más frecuente es el tema. Los escenarios son los mismos: actualizó el tema a una nueva versión mayor, instaló un tema con un functions.php mal escrito o un plugin entró en conflicto con el tema actual tras una actualización de WordPress.

El mecanismo de solución es casi idéntico al de los plugins:

• Inicie sesión vía FTP en wp-content/themes.
• Encuentre la carpeta del tema activo (el que está actualmente instalado en el sitio).
• Renómbrela, por ejemplo, añada _disabled al final del nombre.

WordPress, al no encontrar el tema activo, cambiará automáticamente al tema predeterminado Twenty Twenty-Five (o Twenty Twenty-Four, dependiendo de la versión de WP). El sitio cargará con el diseño predeterminado, pero todo su contenido permanecerá en su lugar. Importante: no elimine el tema predeterminado, de lo contrario no habrá a qué cambiar y obtendrá otra ronda de WSOD.

Temas mal codificados y actualizaciones de WordPress. Tras un lanzamiento mayor de WordPress, los temas antiguos que usan funciones u hooks obsoletos pueden romperse. Los temas de calidad de desarrolladores verificados se actualizan a los pocos días del lanzamiento del núcleo. Si su tema no se ha actualizado durante seis meses o más, esa es una señal de alerta: cambie a uno que reciba mantenimiento activo.

Editar functions.php y otros archivos del tema. Un error tipográfico en functions.php, un corchete extra, una llamada a hook incorrecta y el sitio se cae. Si editó archivos del tema inmediatamente antes de que apareciera la WSOD, reemplace el archivo modificado con la versión original de una copia de seguridad o de la distribución del tema. Sin copia de seguridad, descargue el tema nuevamente desde la fuente y suba el archivo limpio.

3. Exceder el límite de memoria PHP

El sitio creció, los plugins se multiplicaron, el tráfico subió y, de repente, WSOD. Un síntoma clásico de que el proceso PHP se quedó sin RAM. Especialmente relevante en hosting barato, donde un servidor atiende cientos de sitios y el límite por cliente se reduce al mínimo.

WordPress recomienda oficialmente un mínimo de 64 MB de memoria, pero esta recomendación data de la era de PHP 5.6 y cinco plugins por sitio. En 2026, un mínimo realista para un sitio funcional es 128 MB, y para construcciones con Elementor, WooCommerce y varias docenas de plugins, 256 MB.

Cómo aumentar el límite de memoria:

Abra el archivo wp-config.php (ubicado en la raíz de la instalación de WordPress) y añada una línea antes del comentario /* That's all, stop editing! */:

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

Si el proveedor limita estrictamente la memoria PHP a nivel de servidor, esta directiva no funcionará, entonces solo hay una salida: cambiar el plan o el hosting. El hosting WordPress gestionado (SiteGround, WP Engine, Kinsta) configura los límites adecuadamente de fábrica y el problema de memoria prácticamente nunca se encuentra allí.

4. Diagnóstico mediante WP_DEBUG

A veces ni los plugins, ni el tema, ni la memoria son culpables, la causa de la WSOD se escapa. Entonces necesita hacer que WordPress le diga qué salió mal exactamente.

WordPress ha llevado un depurador integrado WP_DEBUG durante décadas. Por defecto está desactivado (pantalla blanca en lugar de errores, la idea es no exponer las interioridades del sitio a los visitantes). Pero para el administrador, este modo es invaluable.

Añada a wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Qué sucede:

• WP_DEBUG activa el modo de depuración;
• WP_DEBUG_LOG escribe los errores en el archivo wp-content/debug.log, conveniente para leer sin mostrarlos a los visitantes;
• WP_DEBUG_DISPLAY con valor false oculta los errores de la pantalla (usted ve una pantalla blanca, pero los registros se escriben).

Después de activarlo, abra el sitio, reproduzca el problema y mire en wp-content/debug.log. Allí habrá una línea con el archivo, número de línea y tipo de error, por ejemplo, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Esta es la dirección exacta del problema.

Importante: no deje WP_DEBUG activado en producción después del diagnóstico, los registros crecen rápidamente y pueden llenar el espacio en disco.

5. Modo de Recuperación, el salvador integrado de WordPress 5.2+

Desde la versión 5.2, WordPress puede detectar errores fatales por sí mismo y ofrecer una ruta alternativa. El Modo de Recuperación (recovery mode) es una función que muchos administradores aún no usan simplemente porque no la conocen.

Cómo funciona. Cuando el código PHP en un plugin o tema causa un error fatal, WordPress lo intercepta, detiene la extensión problemática y envía un correo electrónico al correo del administrador. El correo contiene un enlace que abre el acceso al panel de administración sin pasar por el código problemático. Usted inicia sesión, ve el plugin caído marcado como «causó error», lo desactiva y el sitio vuelve a estar vivo. Sin FTP, sin renombrar carpetas.

Limitaciones del Modo de Recuperación:

• El enlace es válido por un tiempo limitado (aproximadamente un día) y está vinculado a una dirección IP;
• Requiere envío de correo configurado desde el sitio (plugin SMTP o correo del hosting);
• No salva de errores a nivel de servidor (falta de memoria, .htaccess roto).

Y sin embargo, si el correo llegó, usted se ahorra una docena de minutos de nervios y movimientos de FTP.

Vea una guía breve sobre cómo arreglar la WSOD, todos los métodos descritos con demostración en vivo:

⁉️🤔 Preguntas frecuentes

¿Por qué aparece la pantalla blanca solo en el panel de administración, pero el sitio abre normalmente?

El error está localizado en código que se ejecuta solo en el panel de control: un metabox de plugin, página de configuración del tema, widget de administración personalizado. Desactive los plugins instalados recientemente uno por uno, el culpable se encontrará rápidamente. Si no ayuda, active WP_DEBUG_LOG y revise el registro después de intentar iniciar sesión en el panel de administración.

Pantalla blanca solo en una entrada o página de artículo, ¿qué es?

Lo más probable es que el problema esté en el contenido de la entrada específica: un shortcode de un plugin inexistente, HTML roto en el texto, conflicto con campos personalizados. Abra la entrada mediante Edición rápida en el panel de administración y cambie temporalmente el estado a «Borrador». ¿Carga la página? Entonces indague dentro del contenido.

¿Se puede evitar la WSOD por completo en el futuro?

Eliminarla por completo, no, pero minimizar el riesgo es realista. Tres reglas: (1) siempre pruebe las actualizaciones de plugins y temas en una copia de staging del sitio antes de implementar en producción; (2) mantenga copias de seguridad diarias de archivos y base de datos; (3) no instale plugins y temas de fuentes dudosas, especialmente versiones nulled.

El Modo de Recuperación no envió un correo, ¿qué hacer?

El correo desde un sitio WordPress sin un plugin SMTP configurado funciona de manera inestable. Configure SMTP (Post SMTP, FluentSMTP o WP Mail SMTP) como medida preventiva. Si el correo ya no llegó, vuelva al método FTP de la sección 1, siempre funciona.

¿Cuánto dura el enlace del Modo de Recuperación?

El enlace es válido por 24 horas (más precisamente, hasta que expire el token nonce). Después de eso necesita reproducir el error nuevamente, WordPress enviará el correo de nuevo.

¿Qué hacer si nada ayudó?

Si los cuatro métodos anteriores y el Modo de Recuperación no devolvieron el sitio, el problema es más profundo. Quizás el archivo .htaccess está dañado (renómbrelo e inicie sesión en el panel de administración, WordPress creará uno nuevo a través de «Ajustes → Enlaces permanentes → Guardar»). O incompatibilidad de versión de PHP: WordPress moderno requiere PHP 7.4+, pero el host podría tener aún PHP 5.6.

Otra herramienta de diagnóstico es el plugin Health Check & Troubleshooting del equipo de WordPress.org. Puede lanzar una sesión de modo seguro: desactiva todos los plugins y cambia al tema predeterminado, pero solo para su navegador (los visitantes ven el sitio normal). Con él puede activar plugins de forma segura uno por uno y atrapar al culpable sin tocar producción.

¿No hay tiempo para investigar, pero el sitio necesita estar en línea ya mismo? Restaure la copia de seguridad. Si no hay copia de seguridad, una lección para el futuro: las copias de seguridad automáticas diarias cuestan unos pocos dólares al mes y se pagan solas el primer día de un desastre. Prácticamente todo hosting ofrece esta función en el panel de control.

Y lo más importante, no le tema a la WSOD. Es desagradable, pero tiene solución. Ahora usted tiene un algoritmo de acción paso a paso, no pánico y una pantalla vacía.