Recuperación de WordPress: Pantalla blanca de la muerte — La solución de 5 pasos que funciona

Guía de diagnóstico rápido (qué comprobar primero)

Si estás de guardia, cansado y tu Slack se está convirtiendo en una escena del crimen, usa esto. Está optimizado para tiempo-hasta-señal. El objetivo es identificar la capa que causa el bloqueo: edge/caché, servidor web, runtime PHP, base de datos o código de WordPress (plugins/temas).

Primero: ¿es realmente el origen?

• Comprueba desde tu portátil con evitación de caché. Si un CDN o proxy inverso sirve una respuesta en caché en blanco, perseguirás fantasmas en el servidor.
• Pegunta directamente al origen (archivo hosts, IP directa con cabecera Host, o DNS del balanceador interno) para aislar problemas de edge.

Segundo: ¿es un problema HTTP o un problema PHP?

• Mira el código de estado y las cabeceras HTTP. Un 200 con un cuerpo de 0 bytes suele ser PHP muriendo después de enviar cabeceras, rarezas de buffer de salida o una caché devolviendo un objeto vacío.
• Sigue los logs del web + PHP. Quieres una línea de error fatal con una marca temporal que coincida con la petición en blanco.

Tercero: obliga a WordPress a incriminarse

• Activa WP_DEBUG + debug.log (con cuidado) y reproduce una vez.
• Desactiva plugins en bloque (renombrando el directorio o con WP-CLI) y vuelve a probar.
• Cambia a un tema por defecto y vuelve a probar.

Cuarto: lo poco glamuroso

• Memoria/límites: memory_limit de PHP, max_execution_time, opcache, permisos de archivos, disco lleno.
• Cambios recientes: actualizaciones, plugin nuevo, tema nuevo, cambio de versión de PHP, ejecución de gestión de configuración, cambio en política de purga de caché.

Ese es el plan. Ahora hagamos el trabajo con una secuencia de cinco pasos que produce respuestas, no sensaciones.

Qué es realmente WSOD (y por qué miente)

WSOD no es un bug único. Es un síntoma: tu petición se completó sin renderizar salida visible. Eso puede ocurrir por múltiples razones:

• Error fatal de PHP antes de la salida (o la salida está suprimida). A menudo causado por código incompatible de un plugin/tema, clases faltantes o llamar a una función eliminada en una versión más reciente de PHP.
• Agotamiento de memoria (clásico): “Allowed memory size exhausted”. A veces no lo verás en el navegador porque display_errors está desactivado.
• Rarezas de buffer de salida/caché: una capa de caché almacena una respuesta vacía y la sirve como “exitosa”.
• Fallos de permisos o sistema de archivos: WordPress no puede leer archivos del tema, no puede escribir caché, no puede autoload; el runtime muere.
• Problemas de opcode cache (menos comunes ahora, pero reales): opcache obsoleto tras despliegues o patrones de invalidación rotos.
• Problemas en el Edge/CDN: no es WordPress en absoluto. La “página en blanco” es un marcador intermedio.

WSOD miente porque los navegadores son educados. No gritan sobre el cuerpo vacío; simplemente no muestran nada. Tu servidor, sin embargo, sí gritó: en logs, en stderr, en el journal de systemd—en alguna parte. Tu trabajo es encontrar dónde fue a parar ese grito.

Una cita para tener en la cabeza durante incidentes:

“La esperanza no es una estrategia.” — Gene Kranz

Eso es operaciones en cinco palabras: deja de esperar que “sea solo un problema de caché” y empieza a probar qué capa está fallando.

Broma #1: La Pantalla Blanca de la Muerte es la única vez que una página en blanco cuenta como “transparencia total”.

La solución de 5 pasos que funciona

Paso 1: Confirma el modo de fallo (código, tamaño del cuerpo, implicación de caché)

Antes de tocar WordPress, confirma qué reciben realmente los clientes. Si el edge está sirviendo una respuesta en caché vacía, arreglar el origen no quitará la blancura hasta que la caché expire.

Haz: captura cabeceras, código de estado, longitud de contenido y cabeceras de caché. Compara origen vs CDN.

Evita: editar wp-config.php por presentimiento. En producción, los presentimientos son cómo creas un segundo incidente.

Paso 2: Lee los logs como si importara (web + PHP-FPM + journal del sistema)

WSOD suele ser un error fatal de PHP. Los errores fatales terminan en logs de PHP-FPM, logs de error del servidor web o en el journal del sistema dependiendo de cómo esté montada tu pila.

Haz: sigue los logs mientras reproduces el problema una vez. La correlación temporal vence a la arqueología.

Evita: leer logs de hace tres días mientras tu balanceador está comprobando la salud y está martillando nuevas fallas cada segundo.

Paso 3: Activa el registro de depuración de WordPress (sin convertir tu sitio en un confesionario)

WordPress puede registrar notices/warnings/fatales de PHP en wp-content/debug.log. A menudo es la fuente de verdad más limpia para fallos de plugins/temas.

Haz: activa el registro, desactiva la visualización en el navegador, reproduce, y luego apágalo.

Evita: activar display_errors en un sitio público. Los equipos de seguridad también tienen sentimientos.

Paso 4: Elimina la complejidad rápido (desactiva todos los plugins, cambia de tema)

La mayoría de los WSODs son autoinfligidos por código que se ejecuta dentro de WordPress. Los plugins y temas son código no confiable con una bonita UI. Trátalos en consecuencia.

Haz: desactiva plugins en bloque (renombra el directorio de plugins o usa WP-CLI). Luego cambia a un tema por defecto (Twenty Twenty-*). Vuelve a probar después de cada cambio.

Evita: desactivar plugins uno por uno vía wp-admin cuando wp-admin también está en blanco. Eso no es resolución de problemas; es arte performático.

Paso 5: Arregla la restricción subyacente (memoria, versión PHP, permisos, almacenamiento, BD)

Una vez que conozcas el disparador—incompatibilidad de plugin, extensión PHP faltante, agotamiento de memoria, despliegue defectuoso—aplica la solución real. Si es memoria, auméntala correctamente y confirma; si es un despliegue malo, revierte; si es disco, libera espacio y evita recurrencias. Recuperación no es lo mismo que prevención.

Ahora vamos a ser concretos con comandos. Nada de “prueba apagar y volver a encender”. Tareas reales, salidas reales, decisiones reales.

Tareas prácticas: comandos, salidas y decisiones (12+)

Supuestos para los ejemplos siguientes:

• Servidor Linux con Nginx + PHP-FPM (también mencionaremos Apache).
• WordPress vive en /var/www/wordpress.
• Tienes SSH y sudo.

Tarea 1: Comprueba estado HTTP, cabeceras y tamaño del cuerpo (desde shell)

cr0x@server:~$ curl -sS -D - -o /dev/null -w "status=%{http_code} bytes=%{size_download} time=%{time_total}\n" https://example.com/
HTTP/2 200 
date: Tue, 04 Feb 2026 10:12:01 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=0, must-revalidate
cf-cache-status: HIT
status=200 bytes=0 time=0.092

Qué significa: HTTP 200 pero bytes=0. También una cabecera de caché indica que el CDN lo sirvió (HIT).

Decisión: Evita la caché / pega al origen directamente. No toques WordPress todavía; podrías estar viendo una respuesta en caché vacía.

Tarea 2: Evita la caché y compara la respuesta

cr0x@server:~$ curl -sS -H "Cache-Control: no-cache" -D - -o /dev/null -w "status=%{http_code} bytes=%{size_download}\n" https://example.com/
HTTP/2 500 
date: Tue, 04 Feb 2026 10:12:11 GMT
content-type: text/html; charset=UTF-8
status=500 bytes=0

Qué significa: Evitar la caché revela un 500 en el origen (o al menos que no está cacheado). Bien: ahora persigues un error real.

Decisión: Ve a los logs inmediatamente y reproduce una vez.

Tarea 3: Sigue el log de error de Nginx mientras reproduces

cr0x@server:~$ sudo tail -n 50 -f /var/log/nginx/error.log
2026/02/04 10:12:11 [error] 13219#13219: *918 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211" while reading response header from upstream, client: 203.0.113.15, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Qué significa: El tema llama a get_field() (Advanced Custom Fields) pero la función no existe—plugin faltante/desactivado, o cargado demasiado tarde.

Decisión: Desactiva el tema o restaura el plugin faltante. Esto no es un problema de base de datos. Es código.

Tarea 4: Sigue el log de PHP-FPM (o journal) buscando fatales

cr0x@server:~$ sudo tail -n 50 -f /var/log/php8.2-fpm.log
[04-Feb-2026 10:12:11] WARNING: [pool www] child 22109 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211"

Qué significa: Confirma que el fatal se origina en el runtime PHP. Ahora tienes el archivo y el número de línea.

Decisión: Procede con la aislamiento de tema/plugin (Paso 4) y/o revierte el cambio de tema.

Tarea 5: Comprueba el espacio en disco (las páginas en blanco a veces significan “disco lleno”)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   79G  200M 100% /
tmpfs           3.8G  2.0M  3.8G   1% /run

Qué significa: El filesystem raíz está lleno. PHP puede fallar al escribir sesiones, archivos de caché o logs; WordPress puede fallar al actualizar opciones autoloaded; todo se vuelve extraño.

Decisión: Libera espacio ahora (logs, releases antiguos, caché), luego implementa rotación/monitoreo. No “aumentes memoria” por un problema de disco.

Tarea 6: Encuentra qué consume espacio rápidamente

cr0x@server:~$ sudo du -xhd1 /var | sort -h
120M	/var/cache
1.8G	/var/lib
6.5G	/var/log
14G	/var/www

Qué significa: Los logs son enormes. Eso es tráfico alto, un bucle de logging o rotación faltante.

Decisión: Inspecciona /var/log y rota/trunca de forma segura (y arregla la causa raíz).

Tarea 7: Identifica los logs que más ocupan

cr0x@server:~$ sudo find /var/log -type f -printf "%s %p\n" | sort -n | tail -n 10
2147483648 /var/log/nginx/access.log
1073741824 /var/log/nginx/error.log
536870912 /var/log/php8.2-fpm.log

Qué significa: Tus logs han crecido desmesuradamente. Tal vez una tormenta de bots, un bucle de redirección o logging de depuración activado.

Decisión: Trunca para recuperar espacio (a corto plazo), luego arregla logrotate y errores ruidosos (a largo plazo).

Tarea 8: Truncado relativamente seguro para recuperar espacio rápido

cr0x@server:~$ sudo sh -c ': > /var/log/nginx/error.log; : > /var/log/php8.2-fpm.log'

Qué significa: Los archivos se truncan en el lugar (los procesos mantienen los file handles). Esto da margen sin reiniciar servicios.

Decisión: Revisa inmediatamente df -h. Luego implementa rotación. Y considera por qué error.log tenía 1GB: eso no es “normal”.

Tarea 9: Activa el registro de depuración de WordPress (controlado)

Edite wp-config.php y establezca estos valores cerca del final, por encima de “That’s all”:

cr0x@server:~$ sudo sed -n '1,120p' /var/www/wordpress/wp-config.php
<?php
/* ...existing config... */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
/* That's all, stop editing! Happy publishing. */

Qué significa: Los errores van a wp-content/debug.log, no al navegador.

Decisión: Reproduce la WSOD una vez, luego lee el debug.log. Desactiva esto después de capturar la evidencia.

Tarea 10: Lee el log de depuración de WordPress

cr0x@server:~$ sudo tail -n 60 /var/www/wordpress/wp-content/debug.log
[04-Feb-2026 10:12:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211
Stack trace:
#0 /var/www/wordpress/wp-settings.php(595): include()
#1 /var/www/wordpress/wp-config.php(95): require_once('...')
#2 /var/www/wordpress/wp-load.php(50): require_once('...')
#3 /var/www/wordpress/wp-blog-header.php(13): require_once('...')
#4 /var/www/wordpress/index.php(17): require('...')
#5 {main}
  thrown in /var/www/wordpress/wp-content/themes/custom/functions.php on line 211

Qué significa: Confirma un fatal a nivel de tema, falta la función del plugin. La traza muestra que muere durante el bootstrap.

Decisión: Arregla la dependencia del tema o restaura el plugin requerido. Recuperación más rápida: cambia a un tema por defecto.

Tarea 11: Desactiva todos los plugins vía renombrado del sistema de archivos (funciona incluso cuando wp-admin está muerto)

cr0x@server:~$ cd /var/www/wordpress/wp-content
cr0x@server:~$ sudo mv plugins plugins.disabled
cr0x@server:~$ ls -l
drwxr-xr-x  2 www-data www-data 4096 Feb  4 10:13 plugins.disabled
drwxr-xr-x 10 www-data www-data 4096 Feb  4 09:50 themes

Qué significa: WordPress no encontrará plugins; los tratará como desactivados.

Decisión: Vuelve a probar el sitio. Si vuelve, has probado que la falla está relacionada con un plugin. Luego reactiva selectivamente (renombra de nuevo, o usa WP-CLI para activar uno por uno).

Tarea 12: Cambia el tema sin wp-admin (renombra la carpeta del tema activo)

cr0x@server:~$ cd /var/www/wordpress/wp-content/themes
cr0x@server:~$ sudo mv custom custom.disabled
cr0x@server:~$ ls -1
custom.disabled
twentytwentyfour
twentytwentythree

Qué significa: WordPress caerá al tema por defecto disponible.

Decisión: Si el sitio carga ahora, tu tema es el culpable. Mantén el tema por defecto temporalmente; arregla el tema personalizado fuera de producción.

Tarea 13: Usa WP-CLI para desactivar plugins en masa (más limpio cuando está disponible)

cr0x@server:~$ cd /var/www/wordpress
cr0x@server:~$ sudo -u www-data wp plugin deactivate --all
Plugin 'akismet' deactivated.
Plugin 'advanced-custom-fields' deactivated.
Success: Deactivated 12 of 12 plugins.

Qué significa: Los plugins quedan desactivados a nivel de WordPress (estado en la base de datos), no solo ocultos vía sistema de archivos.

Decisión: Si desactivar arregla la WSOD, reactiva plugins de uno en uno hasta que vuelva a fallar. Entonces tendrás al culpable.

Tarea 14: Comprueba el límite de memoria PHP y la versión actual de PHP

cr0x@server:~$ php -v
PHP 8.2.14 (cli) (built: Jan 15 2026 10:20:41) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies
cr0x@server:~$ php -i | egrep -i "memory_limit|opcache.enable|max_execution_time" | head
memory_limit => 128M => 128M
max_execution_time => 30 => 30
opcache.enable => On => On

Qué significa: 128M suele ser justo para stacks modernos de WordPress con page builders, plugins pesados o opciones autoloaded grandes.

Decisión: Si los logs muestran agotamiento de memoria, aumenta el límite de memoria en la pool de PHP-FPM o en php.ini (no solo en wp-config) y vuelve a probar.

Tarea 15: Detecta un fatal por agotamiento de memoria en los logs

cr0x@server:~$ sudo grep -R "Allowed memory size" -n /var/log/nginx/error.log | tail -n 3
/var/log/nginx/error.log:9921:FastCGI sent in stderr: "PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/wordpress/wp-includes/class-wpdb.php on line 2345"

Qué significa: No es un bug del tema; es memoria. WordPress murió en código de la base de datos porque PHP se quedó sin memoria.

Decisión: Aumenta el límite de memoria PHP e investiga qué consume memoria (bucles de plugin, opciones autoloaded enormes, consultas gigantes).

Tarea 16: Comprueba la conectividad de la base de datos rápidamente (no des por hecho, verifica)

cr0x@server:~$ mysqladmin -u wpuser -p ping
Enter password: 
mysqld is alive

Qué significa: La BD es accesible con las credenciales proporcionadas (al menos desde este host). WSOD probablemente no sea “BD caída”.

Decisión: Pasa al camino de código PHP/WordPress, a menos que los logs muestren errores o timeouts de BD.

Tarea 17: Verifica que PHP-FPM esté activo y escuchando donde Nginx espera

cr0x@server:~$ systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Tue 2026-02-04 09:01:22 UTC; 1h 13min ago
cr0x@server:~$ sudo ss -lxn | grep php8.2-fpm.sock
u_str LISTEN 0      4096   /run/php/php8.2-fpm.sock 12345678            * 0

Qué significa: El servicio está en ejecución, el socket escucha. Si todavía obtienes páginas en blanco, probablemente sea a nivel de aplicación o permisos en el socket.

Decisión: Si falta el socket, reinicia PHP-FPM; si los permisos son incorrectos, arregla la propiedad/modo. De lo contrario, sigue investigando en los logs.

Tarea 18: Revisa cambios recientes (paquetes, despliegues) sin historias

cr0x@server:~$ grep -E "upgrade|install" /var/log/dpkg.log | tail -n 8
2026-02-04 08:55:10 upgrade php8.2-fpm:amd64 8.2.13-1 8.2.14-1
2026-02-04 08:55:12 upgrade php8.2-cli:amd64 8.2.13-1 8.2.14-1
2026-02-04 08:55:15 upgrade nginx:amd64 1.24.0-1 1.24.0-2

Qué significa: PHP y Nginx cambiaron recientemente. Incompatibilidades de plugins/temas con versiones de PHP son un desencadenante frecuente de WSOD.

Decisión: Si esto coincide con el inicio del incidente, considera revertir la actualización de PHP o parchear el plugin/tema incompatible.

Tres micro-historias corporativas en producción

Micro-historia 1: El corte causado por una suposición equivocada

En una compañía mediana con la actitud “WordPress es solo marketing”, el equipo de plataforma migró el sitio detrás de un CDN con caché agresiva. Hicieron una prueba rápida: la página de inicio cargó, un par de páginas internas cargaron, terminado. Asumieron que una respuesta 200 siempre significaba “saludable”.

Dos días después, una actualización de plugin introdujo un error fatal de PHP en una plantilla específica usada por páginas de campaña. El origen empezó a devolver un 500 con cuerpo vacío para esas páginas. El CDN, configurado para cachear “respuestas exitosas” solo por código de estado, tenía un bug en una regla: cacheaba la respuesta incluso cuando el cuerpo estaba vacío debido a una condición mal especificada. Los visitantes recibieron un 200 limpio y una página en blanco. El monitoreo no alertó porque comprobaba el código de estado, no la longitud del contenido ni una palabra clave.

El ingeniero de guardia pasó una hora reiniciando servicios porque “es WordPress, volverá”. No volvió. El error era determinístico. Una vez que evitaron el CDN y comprobaron el origen directamente, vieron el 500 y el fatal de PHP en menos de un minuto.

Lo arreglaron cambiando las comprobaciones de salud para validar contenido (un marcador HTML simple), ajustando reglas de caché para evitar cachear cuerpos vacíos y haciendo que “prueba de bypass al origen” sea el paso cero en el runbook de incidentes.

Micro-historia 2: La optimización que salió mal

Una gran organización decidió reducir la latencia de PHP subiendo las configuraciones de OPCache y habilitando preloading agresivo. El cambio se desplegó durante una ventana de mantenimiento rutinaria. Pareció genial: TTFB más rápido, CPU más baja. Todos celebraron.

Luego empezaron las pantallas blancas—intermitentes. No en todas las peticiones, solo las suficientes para arruinar el día. El problema subyacente no era WordPress; era la mecánica del despliegue. Su proceso de despliegue reemplazaba archivos PHP en el lugar, y a veces actualizaba directorios de plugins mientras los workers de PHP-FPM estaban en mitad de una petición. Con preloading y opcache que redujo las comprobaciones de stat, algunos workers ejecutaban una mezcla de rutas de código antiguas y nuevas. Cuando una clase se movía, el autoload fallaba, produciendo errores fatales que se manifestaban como páginas en blanco.

La solución fue aburrida: dejar de reemplazar archivos en el lugar. Desplegar en un directorio de release nuevo, y luego cambiar un symlink de forma atómica. Además, ajustar la validación de OPCache para su patrón de despliegue en vez de copiar “las mejores configuraciones” de un post de benchmarking.

Las mejoras de rendimiento son reales, pero “rápido” que falla ocasionalmente es solo otro tipo de caída.

Micro-historia 3: La práctica aburrida que salvó el día

Una compañía de servicios financieros ejecutaba WordPress para documentación y onboarding de clientes. Nada glamuroso, pero con impacto real. Tenían una regla estricta: todo cambio que pudiera afectar el runtime tenía una ruta de reversión fácil, y cada host tenía suficiente logging para depurar sin acrobacias SSH.

Cuando WSOD ocurrió tras una actualización de tema, el ingeniero de guardia no entró en pánico. Miró el panel: quema del presupuesto de errores, picos en fatales de PHP-FPM y una línea de log clara apuntando a una función faltante. Revirtieron al directorio de release anterior en segundos cambiando un symlink y recargando PHP-FPM. El sitio volvió de inmediato.

Luego, en horario laboral, reprodujeron en staging con la misma versión de PHP y conjunto de plugins, arreglaron las comprobaciones de dependencia del tema (protegieron llamadas a funciones de plugins con comprobaciones) y redeplegaron correctamente. El postmortem fue corto porque los hechos ya estaban capturados por logs y la línea de tiempo de cambios.

No fue heroísmo. Fue la competencia silenciosa de tener backups, rollbacks y telemetría que no desaparece cuando la necesitas.

Errores comunes: síntoma → causa raíz → solución

La resolución de WSOD falla de formas previsibles. Aquí están las trampas habituales, con remediaciones concretas.

1) Síntoma: La página de inicio está en blanco, pero algunas URL internas funcionan

Causa raíz: Plantilla del tema o hook del front-page que desencadena un error fatal; a veces un shortcode de page builder en la página de inicio.

Solución: Revisa logs buscando fatales vinculados a la petición de la página de inicio. Cambia a un tema por defecto para restaurar el servicio, luego arregla la plantilla.

2) Síntoma: wp-admin está en blanco, el front-end está bien (o viceversa)

Causa raíz: Plugin solo para admin, mu-plugin o hook de admin que causa fatal. O un plugin de capacidades que rompe la inicialización del admin.

Solución: Desactiva todos los plugins y prueba wp-admin específicamente. Revisa wp-content/mu-plugins por plugins de uso obligatorio; no se desactivan como los normales.

3) Síntoma: HTTP 200 con cuerpo vacío, solo a través del CDN

Causa raíz: Respuesta vacía cacheada, regla de edge mal configurada o el origen devolviendo respuesta chunked que se maneja mal.

Solución: Evita el CDN y compara. Purga la caché para las rutas afectadas. Actualiza reglas de caché para evitar cachear cuerpos vacíos y valida respuestas del origen.

4) Síntoma: Pantalla blanca después de actualizar la versión de PHP

Causa raíz: Plugin/tema usa funciones obsoletas/eliminadas, problemas de tipado estricto o dependencias incompatibles.

Solución: Identifica la línea fatal; actualiza o reemplaza plugin/tema; si es necesario, revierte la versión de PHP temporalmente. No “simplemente subas la memoria”.

5) Síntoma: WSOD aparece bajo carga, desaparece cuando baja el tráfico

Causa raíz: Agotamiento de workers de PHP-FPM, consultas DB lentas, deadlocks o timeouts de APIs externas causando peticiones largas y fallo en cascada.

Solución: Revisa settings del pool PHP-FPM y slow logs; revisa el log de consultas lentas de la BD; añade timeouts; cachea llamadas externas. Escala solo después de entender la saturación.

6) Síntoma: WSOD empezó después de habilitar un plugin de caché/minify

Causa raíz: JS/CSS minificado roto no causa WSOD (rompe el layout). Pero plugins de caché pueden generar HTML en caché vacío, o la caché de objetos puede envenenar resultados.

Solución: Limpia caches del plugin, desactiva el plugin de caché y elimina directorios de caché generados. Confirma bytes de respuesta y contenido HTML, no solo que “parece estar bien a veces”.

7) Síntoma: Solo los usuarios autenticados ven WSOD

Causa raíz: Hooks específicos de usuario, admin bar, conflicto de caché personalizado o fallo en manejo de sesiones (disco lleno, permisos).

Solución: Prueba con una sesión de navegador limpia. Revisa el path de guardado de sesiones y permisos; revisa espacio en disco; desactiva plugins que modifican flujo de autenticación/sesión.

8) Síntoma: WSOD tras “pequeño cambio de configuración” en wp-config.php

Causa raíz: Error de sintaxis (comilla/punto y coma faltante), encoding/espacios en blanco antes de <?php, o definiciones duplicadas de constantes.

Solución: Ejecuta un lint de PHP en wp-config.php, restaura desde una copia conocida buena y usa plantillas de gestión de configuración en vez de ediciones manuales.

Broma #2: Nada dice “empresa” como un outage en producción causado por un punto y coma faltante en un archivo llamado wp-config.php.

Listas de comprobación / plan paso a paso

Checklist de incidente: restaura el servicio primero, luego arregla bien

1. Captura evidencia: código de estado + cabeceras + tamaño del cuerpo desde cliente y desde origen. Guárdalo en las notas del incidente.
2. Sigue logs mientras reproduces una vez: servidor web + PHP-FPM. Consigue la línea fatal.
3. Activa WP_DEBUG_LOG temporalmente si los logs no muestran suficiente detalle.
4. Desactiva plugins en bloque (renombra el directorio plugins o usa WP-CLI). Vuelve a probar.
5. Cambia a tema por defecto (renombra el directorio del tema custom). Vuelve a probar.
6. Arregla la restricción: memoria/disco/permisos/incompatibilidad de versión PHP/etc.
7. Reversa si es necesario: revierte el último deploy o restaura la última copia conocida buena.
8. Apaga el registro de depuración y limpia cualquier cambio temporal.
9. Escribe la causa raíz y la barrera para prevenir recurrencia (monitoreo, tests, cambio de despliegue).

Checklist de aislamiento de plugins (la forma rápida y segura)

1. Desactiva todos los plugins.
2. Verifica que el sitio cargue (front-end y wp-admin).
3. Vuelve a activar plugins uno por uno, probando después de cada uno.
4. Cuando se rompa, encontraste el disparador. Déjalo desactivado.
5. Busca una actualización compatible; si no, reemplázalo.

Checklist de aislamiento de tema

1. Cambia a un tema por defecto.
2. Si el sitio carga, el tema personalizado es culpable hasta que se demuestre lo contrario.
3. Busca en el código del tema llamadas directas a funciones de plugins; protégelas con function_exists().
4. Arregla en staging con la misma versión de PHP y conjunto de plugins.

Checklist de prevención permanente (cosas SRE que la gente omite)

1. Las comprobaciones de salud validan contenido, no solo HTTP 200.
2. Se prueban backups (drills de restauración), no solo “están habilitados”.
3. Los despliegues son atómicos (symlink releases), no swaps de archivos in-place.
4. Existe rotación de logs y alertas de disco antes del 95% de uso.
5. Staging coincide con producción en versión de PHP y extensiones críticas.
6. Se fijan actualizaciones de plugins o al menos se agrupan con notas de rollback.

Datos e historia interesantes (porque esto no empezó ayer)

• WordPress empezó en 2003 como fork de b2/cafelog; el ecosistema de plugins creció rápido, y también el radio de impacto del código PHP de terceros.
• El término “Pantalla Blanca de la Muerte” es anterior a WordPress y se popularizó en otros ecosistemas (notablemente errores tempranos de Windows y crashes de consolas), pero el desarrollo web lo adoptó para páginas en blanco sin errores.
• En los primeros tiempos WordPress a menudo corría con display_errors activado en hosting compartido; las pilas modernas suelen ocultar errores en el navegador, lo cual es más seguro pero hace que WSOD se sienta “silencioso”.
• El lanzamiento de PHP 7 (2015) fue un gran cambio de rendimiento; también expuso problemas de compatibilidad en plugins/temas antiguos, un desencadenante recurrente de WSOD durante upgrades.
• PHP 8 introdujo más estricticidad y cambió comportamientos de error; código que “funcionaba por accidente” puede empezar a fallar fatally, especialmente en temas antiguos.
• El orden de carga de plugins de WordPress importa: mu-plugins se cargan antes que los plugins normales, y los temas pueden ejecutar código temprano vía functions.php—genial para flexibilidad, malo para outages.
• La caché puede hacer las fallas persistentes: una vez que una respuesta vacía se cachea en el edge, puedes “arreglar” el origen y aún así servir páginas en blanco hasta purgar/expirar.
• Los incidentes por disco lleno son desproporcionadamente comunes en entornos WordPress por uploads de medios, backups locales y logs verbosos cuando algo falla.
• WSOD no es siempre WordPress: sockets mal configurados de PHP-FPM, parámetros fastcgi incorrectos o denegaciones de SELinux/AppArmor pueden manifestarse como una página en blanco.

Preguntas frecuentes

1) ¿Por qué mi página de WordPress está completamente en blanco sin error?

Porque los errores no se muestran por defecto en producción. Probablemente PHP tuvo un error fatal o se quedó sin memoria, y la salida no se renderizó. Revisa logs web/PHP o activa brevemente WP_DEBUG_LOG.

2) ¿WSOD siempre es problema de un plugin?

No. Los plugins son comunes, pero temas, mu-plugins, upgrades de PHP, disco lleno y capas de caché pueden producir el mismo síntoma: nada.

3) ¿Cuál es la forma más rápida de recuperar cuando wp-admin también está en blanco?

Desactiva plugins renombrando wp-content/plugins, luego cambia el tema renombrando la carpeta del tema activo. Esto evita wp-admin por completo.

4) ¿Debo activar WP_DEBUG en producción?

Temporalmente, con WP_DEBUG_DISPLAY en false y WP_DEBUG_LOG en true. Captura el error y luego apágalo. Dejar debug activado a largo plazo puede filtrar rutas sensibles y llenar discos.

5) Obtengo HTTP 200 pero la página está en blanco. ¿Cómo puede ser?

Los códigos de estado pueden mentir por omisión. Un proxy reverso puede devolver 200 con un cuerpo vacío desde caché, o PHP puede haber enviado cabeceras antes de crashear. Revisa tamaño del cuerpo y cabeceras de caché, luego compara origen vs edge.

6) Aumenté la memoria en wp-config.php pero WSOD persiste. ¿Por qué?

Porque el límite efectivo suele establecerse en la configuración de la pool PHP-FPM o en php.ini. Además, no todos los WSOD son por memoria. Confirma con logs que muestren “Allowed memory size exhausted” antes de cambiar límites.

7) ¿Un problema de base de datos podría causar WSOD en lugar de “Error establishing a database connection”?

Sí. Consultas lentas, tablas bloqueadas o timeouts pueden desencadenar saturación de PHP-FPM, llevando a respuestas vacías. Pero deberías ver timeouts en los logs. Verifica salud de la BD y revisa logs de consultas lentas si está relacionado con carga.

8) ¿Y si desactivar plugins y cambiar tema no lo soluciona?

Entonces probablemente está por debajo de WordPress: PHP-FPM caído, socket mal, denegación de permisos/SELinux, extensiones PHP faltantes, disco lleno o regresión en configuración del servidor web. Vuelve al estado de servicios y logs.

9) ¿Cómo sé si es Cloudflare (u otro CDN) versus mi servidor?

Compara peticiones con cabeceras para evitar caché y pega al origen directamente si es posible. Si el origen devuelve HTML normal y el CDN devuelve vacío, el problema es el edge—purga o arregla reglas de caché.

10) Después de la recuperación, ¿cuál es el paso de prevención con mejor ROI?

Comprobaciones de salud que validen contenido más un proceso de despliegue con rollback. Esas dos cosas convierten la “misteriosa página blanca” en un incidente rápido y acotado.

Siguientes pasos que deberías hacer realmente

WSOD parece que WordPress hace drama. En realidad es tu stack diciéndote: “Me caí, y no conectaste la salida de errores a un sitio conveniente.” La solución no es un flag mágico; es una secuencia repetible.

1. Ahora mismo: ejecuta la guía de diagnóstico rápido. Captura estado/bytes, evita caché, sigue logs, reproduce una vez.
2. Recupera el servicio: desactiva plugins en bloque, cambia a un tema por defecto o revierte el último deploy.
3. Arregla la causa raíz: parchea/reemplaza el plugin/tema problemático, corrige incompatibilidades de versión PHP, aumenta memoria solo cuando esté demostrado y resuelve restricciones de disco/permisos.
4. Prevén recurrencias: añade comprobaciones de salud basadas en contenido, asegura rotación de logs + alertas de disco y adopta despliegues atómicos con rollback fácil.

No necesitas heroísmos. Necesitas evidencia, aislamiento y la disciplina para dejar de “optimizar” cosas que no has medido.