Pantalla blanca WordPress: guía de solución 2026

La pantalla blanca de WordPress, o White Screen of Death (WSOD), aparece cuando PHP encuentra un error fatal y no puede renderizar la página. En la mayoría de los casos, la causa es agotamiento de memoria PHP o un plugin incompatible. La solución más rápida: aumentar el límite de memoria a 256M en wp-config.php o desactivar plugins por FTP.

WordPress es un sistema de gestión de contenidos de código abierto desarrollado por Matt Mullenweg desde 2003, que permite crear y administrar sitios web y aplicaciones mediante plugins y temas personalizables. Es mantenido por la Fundación WordPress y utilizado por millones de sitios en todo el mundo.

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

Abrís tu sitio y no hay nada. Página en blanco. Sin mensaje de error, sin código HTTP visible, sin pista de qué salió mal. Eso es el WSOD (White Screen of Death), y es uno de los errores más frustrantes del ecosistema WordPress precisamente porque no te dice nada.

A diferencia de un error 404 o un «Error establishing a database connection», la pantalla blanca no te da punto de partida. El problema ocurre cuando PHP encuentra un error fatal durante la ejecución y no puede completar el renderizado. WordPress, por defecto, suprime esos mensajes en producción (para no mostrar datos sensibles), así que el resultado es la nada absoluta.

Puede afectar todo el sitio, solo el frontend, solo el backend, o una URL específica. Esa variación ya es información: si el admin carga pero el frontend no, el problema probablemente está en el tema. Si el admin también está en blanco, el problema es más profundo.

Causas principales de la pantalla blanca

Antes de empezar a tocar cosas, conviene saber contra qué estás peleando. Las causas más frecuentes, ordenadas por probabilidad:

• Memoria PHP agotada: el límite por defecto en muchos hostings es 32M o 64M, insuficiente para instaciones con varios plugins activos.
• Plugin incompatible o con error de código: un update mal aplicado, un conflicto con otro plugin, o código que asume una versión de PHP que no tenés.
• Tema con error fatal: código roto en functions.php, dependencia faltante, o un child theme apuntando a un parent que cambió su estructura.
• Error de sintaxis en wp-config.php: cualquier modificación manual mal hecha puede romper el arranque de WordPress completo.
• .htaccess corrupto: reglas de reescritura inválidas o caracteres extraños que Apache no puede procesar.
• Actualización de PHP en el servidor: el hosting actualizó de PHP 7.4 a 8.1 y hay plugins que todavía usan funciones deprecadas o eliminadas.

El 80% de los casos que vi en producción son los dos primeros. Empezá por ahí.

Paso 1: Desactivar todos los plugins

Síntomas

Si la pantalla blanca aparece justo después de instalar o actualizar un plugin, o si el sitio funcionaba bien hasta que activaste algo nuevo, la probabilidad de que el problema sea un plugin ronda el 90%.

Causa

Un plugin puede tener un error fatal de PHP (función que no existe en tu versión, clase que no carga, dependencia faltante) o conflicto con otro plugin que ya cargó sus propias funciones. Cuando PHP encuentra ese error durante la inicialización de WordPress, corta el renderizado ahí mismo.

Solución paso a paso

Si no podés entrar al admin, la vía es FTP o el administrador de archivos de tu panel de hosting. Tema relacionado: la comunidad de WordPress.

1. Conectate por FTP o el gestor de archivos del hosting.
2. Navegá a /wp-content/.
3. Renombrá la carpeta plugins a plugins_old.
4. Recargá el sitio.

Si el sitio carga, el problema está en uno de los plugins. Ahora:

1. Renombrá la carpeta de vuelta a plugins.
2. Entrá al admin (ya debería funcionar porque los plugins están desactivados).
3. Reactivá los plugins uno por uno desde Plugins > Plugins Instalados.
4. Después de cada activación, recargá el sitio y verificá que siga funcionando.
5. Cuando el sitio vuelva a romper, encontraste al culpable.

¿Y si no podés entrar al admin ni siquiera después de renombrar la carpeta? Entonces el problema no son los plugins, y pasás al siguiente paso.

Cómo prevenirlo

Antes de actualizar plugins en producción, hacé una prueba en staging. Y activá notificaciones de compatibilidad en el repositorio oficial de WordPress para los plugins que usás.

Paso 2: Cambiar a un tema predeterminado

Síntomas

El admin carga bien pero el frontend está en blanco. O el problema empezó después de cambiar de tema, editar functions.php, o instalar un child theme. También es frecuente después de actualizar WordPress cuando el tema activo no fue actualizado con la misma frecuencia.

Causa

Un error fatal en functions.php o en cualquier archivo que el tema cargue durante la inicialización mata el renderizado. Los temas con builders embebidos (Divi, OceanWP con extensiones, Astra con plugins propios) son especialmente propensos porque cargan mucho código propio.

Solución paso a paso

Si podés entrar al admin:

1. Andá a Apariencia > Temas.
2. Activá un tema predeterminado de WordPress: Twenty Twenty-Four o Twenty Twenty-Five.
3. Recargá el frontend.

Si no podés entrar al admin, otra vez FTP:

1. Navegá a /wp-content/themes/.
2. Renombrá la carpeta del tema activo (por ejemplo, de divi a divi_old).
3. WordPress va a caer automáticamente al tema predeterminado disponible.
4. Recargá el sitio.

Si el sitio vuelve, el problema es el tema. Podés reportarlo al desarrollador con los datos del error (que vas a tener una vez que actives el modo debug, ver Paso 4).

Cómo prevenirlo

Nunca editEs functions.php directamente en producción. Usá un child theme y un editor con validación de PHP antes de subir cualquier cambio.

Paso 3: Aumentar el límite de memoria PHP

Síntomas

El sitio estaba funcionando, hiciste algo (subiste imágenes grandes, activaste un plugin pesado, recibiste un pico de tráfico) y de repente: pantalla blanca. O el sitio carga a veces y otras veces no. Con debug activado, vas a ver algo así:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 20480 bytes)

Ese número al principio (67108864 bytes = 64M) es tu límite actual.

Causa

PHP tiene un límite máximo de memoria por proceso. WordPress consume parte de ese límite solo para cargar el core. Cada plugin y tema suma más. Con un límite bajo (32M o 64M), una operación que requiere un poco más de memoria mata el proceso con ese error fatal. Ya lo cubrimos antes en construir páginas en WordPress.

Según las guías de configuración que maneja Donweb y otros proveedores, los valores recomendados son: 128M para blogs con plugins básicos, 256M para sitios con WooCommerce o builders, 512M para sitios de alto tráfico con muchas operaciones simultáneas.

Solución paso a paso

La forma más directa es editar wp-config.php. Buscá la línea que dice /* That's all, stop editing! */ y antes de esa línea agregá:

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

Si necesitás también aumentar el límite para las operaciones del admin (importaciones grandes, backups):

define('WP_MAX_MEMORY_LIMIT', '512M');

Guardá el archivo y recargá el sitio. Si no cambia nada, puede que el hosting tenga un techo más bajo que lo que estás pidiendo. En ese caso, editá el php.ini (si tenés acceso) o un archivo .user.ini en la raíz:

memory_limit = 256M

O contactá al soporte del hosting para que lo suban desde el servidor. En el hosting WordPress de Donweb, el límite se puede ajustar desde el panel o pidiendo al soporte técnico.

Cómo prevenirlo

Revisá el consumo de memoria con plugins como Query Monitor antes de que llegue al límite. Y cuando elijas hosting para un sitio con WooCommerce o muchos plugins, fijate que el límite de memoria PHP sea configurable.

Paso 4: Habilitar el modo debug de WordPress

Por qué es el paso más importante

Todo lo anterior es diagnóstico a ciegas. El modo debug te da el error exacto: el tipo de error, el archivo, la línea de código. Con esa información, el 70% de los casos se resuelven solos (o con una búsqueda en Google con el mensaje exacto).

Solución paso a paso

Abrí wp-config.php y buscá esta línea:

define( 'WP_DEBUG', false );

Reemplazala por estas tres:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con WP_DEBUG_DISPLAY en false, los errores no se muestran en pantalla (que es lo que querés en producción) pero sí se escriben en un archivo. El log se guarda en:

/wp-content/debug.log

Recargá el sitio con el error, después abrí ese archivo. Vas a ver algo como:

[26-Apr-2026 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mi_funcion_custom() in /wp-content/plugins/mi-plugin/mi-plugin.php:142

Eso te dice exactamente qué falló, en qué archivo y en qué línea. A partir de ahí, el diagnóstico es directo.

Ojo: acordate de desactivar el debug una vez que resolviste el problema. El archivo debug.log puede crecer y, si lo dejás con WP_DEBUG_DISPLAY en true, podés estar mostrando errores a los visitantes. Esto se conecta con lo que analizamos en usar un staging para probar.

Cómo prevenirlo

Dejá el debug activado (con DISPLAY en false) en sitios de desarrollo siempre. En producción, activalo solo cuando estés diagnosticando y desactivalo cuando termines.

Paso 5: Revisar y regenerar el archivo .htaccess

Síntomas

El sitio muestra pantalla blanca solo en algunas URLs (por ejemplo, las entradas cargan pero las páginas no, o viceversa). O el problema apareció después de una actualización de WordPress o de haber cambiado la estructura de URLs desde Ajustes > Enlaces Permanentes.

Causa

El .htaccess controla cómo Apache procesa las URLs. Si está corrupto, tiene caracteres extraños, o las reglas de reescritura son inválidas, Apache puede fallar al intentar procesar ciertas rutas. Una actualización manual que metió un caracter raro, un plugin de seguridad que escribió reglas incompatibles, o una migración entre servidores con configuraciones diferentes son las causas más comunes.

Solución paso a paso

Lo más limpio es regenerarlo desde WordPress:

1. Entrá al admin (si podés).
2. Andá a Ajustes > Enlaces Permanentes.
3. Sin cambiar nada, hacé clic en «Guardar cambios».
4. WordPress regenera el .htaccess automáticamente.

Si no podés entrar al admin, hacelo por FTP:

1. Renombrá el .htaccess existente a .htaccess_old.
2. Creá uno nuevo con el contenido mínimo de WordPress:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Recargá el sitio. Si carga, el .htaccess viejo era el problema. Podés comparar los dos archivos para ver qué regla específica estaba rota.

Aclaración: esto aplica a servidores Apache. En servidores Nginx (o algunos setups de hosting que usan Nginx con PHP-FPM), el .htaccess no aplica y la configuración de reescritura va en el bloque server de Nginx.

Cómo prevenirlo

Guardá una copia del .htaccess funcionando antes de instalar plugins de seguridad o de caché que lo modifican. Muchos de esos plugins escriben sus propias reglas y a veces se pisan entre sí.

Acciones complementarias: caché y restauración

Antes de cualquier diagnóstico, limpiá el caché. Suena obvio pero se olvida seguido (spoiler: el 10% de los «WSOD» que me reportaron eran caché del navegador). Ctrl+Shift+Del en Chrome, vaciá todo y recargá con Ctrl+F5.

Si tenés un plugin de caché activo (WP Rocket, LiteSpeed Cache, W3 Total Cache), desactivalo temporalmente mientras diagnosticás. Un caché que sirvió una versión rota del sitio puede parecer un WSOD aunque ya hayas resuelto el problema subyacente. En reparar otros problemas técnicos profundizamos sobre esto.

Y si llegás al punto en que nada funcionó, está el backup. No es «rendirse», es pragmatismo: si tenés un backup de hace 6 horas que funcionaba, restaurarlo y después identificar qué cambio específico rompió todo es infinitamente más eficiente que seguir investigando a ciegas. La pregunta es si tenés el backup. Si no lo tenés, ese es el problema real, no el WSOD de hoy.

Tabla de diagnóstico rápido

Cuándo contactar soporte

Si hiciste todos los pasos anteriores y el sitio sigue roto, hay escenarios que están fuera del alcance de este artículo:

• El debug.log está vacío aunque activaste WP_DEBUG (puede indicar un problema al nivel de configuración del servidor, antes de que PHP empiece a ejecutar WordPress).
• El servidor está devolviendo un error 500 con un mensaje genérico de Apache o Nginx, no un error de PHP.
• El problema aparece y desaparece solo, sin que hayas cambiado nada (puede ser un problema de recursos del servidor: memoria, CPU, conexiones de base de datos).
• Tenés acceso al admin pero nada de lo que intentás cambia el comportamiento del sitio.

Antes de abrir un ticket de soporte, juntá esta información: el contenido del debug.log, los logs de error de Apache/Nginx (pedíselos al hosting si no tenés acceso directo), la versión de WordPress, PHP y del plugin o tema que crees que es el problema. Con esa info, el soporte puede ayudarte en un intercambio en vez de cinco.

Para reportar bugs en plugins, el repositorio oficial es los foros de soporte de WordPress.org. Para temas comerciales, el soporte es del desarrollador directamente. Para problemas de servidor, el soporte de tu hosting.

Si tenés quilombos con WordPress, acá te dejamos un artículo sobre Cómo solucionar la pantalla blanca en WordPress.

Para más detalles sobre esto, podés consultar nuestro artículo Cómo solucionar la pantalla blanca en WordPress.

Preguntas Frecuentes

¿Qué causa la pantalla blanca en WordPress?

En la mayoría de los casos, un plugin incompatible o agotamiento de memoria PHP. Cuando PHP encuentra un error fatal durante la inicialización de WordPress, no puede completar el renderizado y el resultado es una página vacía sin mensajes de error visibles. Activar WP_DEBUG en wp-config.php muestra el error exacto.

¿Cómo soluciono la pantalla blanca de WordPress sin acceso al admin?

Por FTP o el gestor de archivos del hosting. Renombrá la carpeta /wp-content/plugins a plugins_old para desactivar todos los plugins de golpe. Si el sitio carga, reactivá los plugins uno por uno desde el admin. Si no carga, activá WP_DEBUG editando wp-config.php directamente y revisá el debug.log para identificar el error.

¿Qué plugin causa pantalla blanca en WordPress?

No hay un plugin específico que sea el culpante universal. Cualquier plugin puede generar el problema si tiene un error de código, usa una función de PHP eliminada en tu versión actual, o entra en conflicto con otro plugin cargado antes. El diagnóstico correcto es desactivar todos y reactivar uno por uno para identificar cuál rompe el sitio.

¿Cómo habilito el modo debug en WordPress?

Editá wp-config.php y reemplazá la línea define('WP_DEBUG', false); por define('WP_DEBUG', true); más define('WP_DEBUG_LOG', true); y define('WP_DEBUG_DISPLAY', false);. Los errores se escriben en /wp-content/debug.log. Desactivalo cuando termines el diagnóstico.

¿Cuánta memoria PHP necesita WordPress?

WordPress recomienda mínimo 64M, pero según AyudaWP y la documentación oficial, 128M es el mínimo razonable para sitios con plugins. Para WooCommerce o builders como Elementor, 256M. Para sitios con alto tráfico o muchas operaciones concurrentes, 512M. El límite se configura con define('WP_MEMORY_LIMIT', '256M'); en wp-config.php.

Conclusión

La pantalla blanca en WordPress casi siempre viene de dos lugares: memoria PHP insuficiente o un plugin roto. Si el problema apareció después de instalar algo, empezá por los plugins. Si el sitio estaba funcionando y no cambiaste nada, empezá por la memoria.

El paso más valioso de todo este proceso es activar WP_DEBUG, porque convierte un diagnóstico a ciegas en uno con datos concretos. Ese archivo debug.log con el error exacto, el archivo y la línea vale más que cualquier otra suposición.

Si ninguna de estas soluciones funcionó, hay un problema más profundo a nivel servidor que requiere acceso a los logs de Apache/Nginx o revisión directa de la configuración de PHP. En ese caso, el soporte del hosting es el camino. Y si no tenés backups recientes, ese es el problema que necesitás resolver hoy, antes del próximo WSOD.

Fuentes

• WordPress.org – Documentación oficial sobre debugging en WordPress
• Donweb Guías – Solución a la pantalla blanca en WordPress
• AyudaWP – La pantalla blanca de la muerte en WordPress
• Loading.es – Pantalla blanca de la muerte en WordPress