La pantalla blanca que no mostraba el error · WordPin 009

Era un microsite montado para una sola cosa: captar leads durante una campaña con fecha de cierre. Cuatro páginas, formulario principal, píxel de seguimiento y poco más. El sitio había estado funcionando sin problema durante semanas. Nada especial, nada pesado, nada fuera de lo común. Un día, al abrir la URL principal, el navegador devolvió una página completamente vacía. Sin texto, sin cabecera, sin footer. Solo el fondo blanco del navegador como si no hubiera nada detrás.

La campaña llevaba semanas activa sin ningún cambio reciente. Nadie había tocado el tema, ni actualizado plugins, ni modificado archivos. Eso hacía todo más raro. Si nada había cambiado, ¿por qué dejaba de responder ahora?

Lo que dejó la pantalla blanca antes de callar del todo

Lo primero que pensé fue en un fallo puntual del servidor, algo temporal. Pero recargué varias veces y la pantalla blanca seguía ahí, siempre igual. Sin mensaje de error, sin aviso, sin código HTTP visible que indicara qué pasaba. El HTML que llegaba al navegador estaba literalmente vacío. No era una página rota con partes cargando a medias: era una respuesta que no contenía nada.

Después de confirmar que no se trataba de un problema de red ni de DNS. Abrí el sitio desde otro dispositivo y otra conexión: mismo resultado. Página en blanco, respuesta vacía. El servidor respondía con un HTTP 200, lo cual significaba que técnicamente la petición llegaba y WordPress intentaba procesarla. Pero el cuerpo de la respuesta estaba vacío.

Accedí por FTP y edité el archivo wp-config.php para activar el modo de depuración. Quería que WordPress me dijera qué estaba pasando por dentro.

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

Recargué la página esperando ver algún warning, un notice, un fatal error en pantalla. Pero no. La pantalla blanca seguía exactamente igual. Ni una línea de texto. Eso significaba que el proceso moría antes de que PHP pudiera mostrar nada, o que la salida de error no estaba llegando al navegador por algún motivo de configuración del servidor. Demasiado silencio para ser un error menor.

Revisé el archivo debug.log dentro de wp-content. Existía, pero las últimas entradas eran de días anteriores, notices sin importancia. No había registro nuevo del fallo actual. El log de WordPress no estaba capturando lo que fuera que mataba la carga.

Primer sospechoso: el plugin de formularios

El microsite tenía un plugin de formularios de captación como pieza central de la campaña. Era el componente más activo de todo el sitio: procesaba envíos, conectaba con una API externa y generaba registros internos. Si algo iba a fallar en un sitio así, ese plugin era el candidato más obvio.

Renombré la carpeta del plugin por FTP para desactivarlo de golpe. Recargué la página. Y el sitio cargó. El front apareció completo, con su cabecera, su contenido, su footer. Todo menos el formulario, claro.

Parecía un caso cerrado. Pero antes de culpar al plugin, quise hacer una segunda prueba. Restauré el plugin de formularios y, en su lugar, desactivé el plugin de seguimiento de campaña, un componente de tracking ligero que insertaba scripts de medición. Recargué. Y el sitio también cargó.

Esto no encajaba. Desactivar uno u otro parecía resolver el problema, pero ambos habían estado conviviendo sin conflicto durante semanas. Si fuera una incompatibilidad directa entre ellos, habría fallado antes. El patrón no era de conflicto entre plugins, sino de algo más general. Con todos activos, se caía. Con cualquiera fuera, funcionaba.

Segundo sospechoso: edición reciente en el tema

Comprobé si alguien había tocado los archivos del tema. El functions.php tenía un bloque añadido manualmente que insertaba un snippet de seguimiento adicional para la campaña. Era código limpio, sintácticamente correcto, sin errores de escritura.

Aun así, lo comenté por precaución y recargué. La pantalla blanca desapareció de nuevo. El sitio cargaba. Pero también cargaba al restaurar ese código y quitar cualquiera de los dos plugins. Otra vez el mismo patrón: reducir carga total resolvía el síntoma. No importaba qué quitaras.

WordPress no suele fallar porque haya demasiadas cosas. Falla cuando algo concreto se rompe. Pero aquí no había nada roto. Todo funcionaba por separado. El problema aparecía solo cuando todo estaba activo a la vez. El síntoma apuntaba a una cosa, pero los datos decían otra.

Dónde se cortaba la respuesta realmente

Dejé de buscar en WordPress y fui al servidor. Si el log de depuración de WordPress no capturaba nada, tenía que haber un registro en otro sitio. Accedí al error log de PHP desde el panel del hosting y busqué las entradas recientes.

Ahí estaba. Una línea repetida varias veces en los últimos días, siempre en el mismo momento de la carga:

[error] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 4194304 bytes) in
/home/site/public_html/wp-includes/plugin.php on line 205

El valor 67108864 bytes corresponde a 64 MB de memoria PHP. Eso era lo que tenía asignado el servidor para cada proceso. WordPress, con su core, el tema y los plugins activos, estaba intentando usar más de lo que el servidor permitía. Cuando la carga combinada superaba ese límite, PHP moría sin completar la respuesta. Sin output, sin error en pantalla, sin rastro visible para el usuario. Solo una pantalla blanca y un log del servidor que nadie estaba mirando.

Eso explicaba por qué desactivar cualquier componente resolvía el problema. No era que un plugin concreto estuviera roto: era que la suma de todos superaba los 64 MB disponibles por muy poco. Quitar uno cualquiera bajaba el consumo justo lo suficiente para que la carga terminara. Pero el problema de fondo seguía ahí.

La pantalla blanca no era un error de código. Era un límite de infraestructura que WordPress no podía comunicar porque PHP moría antes de llegar a hacerlo. Un error fatal que ocurría tan pronto que ni WP_DEBUG_DISPLAY tenía oportunidad de actuar. La depuración de WordPress escribe en su log cuando puede, pero si el proceso se corta por memoria antes de que el handler de errores intervenga, no queda registro interno. En este caso, el fallo solo quedó registrado en el log del servidor.

Un sitio puede parecer sano y estar funcionando al borde de su capacidad. Mientras no se añada nada, aguanta. Pero cualquier pico —un plugin que cargue un array grande, una petición que acumule más hooks de lo habitual— lo empuja al límite.

Lo que la pantalla blanca escondía bajo la superficie

El impacto no era solo visual. Mientras el sitio devolvía una respuesta vacía con HTTP 200, los bots de rastreo recibían lo mismo: una página sin contenido. Si el problema se prolongaba, Google podía empezar a desindexar las pocas URLs del microsite. En un sitio de captación con campaña activa, perder visibilidad durante horas significaba perder registros directamente.

Además, el Recovery Mode de WordPress, activo desde la versión 5.2, no siempre se dispara con errores de memoria. Está diseñado para ayudar a gestionar determinados errores fatales de PHP, pero un proceso que muere por límite de RAM puede saltarse ese mecanismo dependiendo de cómo se produzca el error fatal y de si WordPress llega a ejecutar su mecanismo de recuperación. En este caso, no se activó.

Restaurar la carga sin esconder el problema

La primera tentación era directa: subir el límite de memoria en wp-config.php y seguir adelante. Es una línea, se aplica de inmediato y el síntoma desaparece.

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

Pero hacer eso sin más era tapar el problema. Si el consumo real del sitio estaba rozando los 64 MB con solo cuatro páginas y tres plugins, algo estaba usando más memoria de la razonable. Subir el límite a 128 MB daría margen, pero si el componente responsable seguía creciendo, el fallo volvería más adelante con un techo más alto.

Ajustar el margen sin dejar el consumo a ciegas

Antes de tocar el límite, necesitaba saber cuánta memoria consumía cada parte. Instalé Query Monitor en el entorno y revisé los datos de consumo por componente. El plugin de formularios cargaba correctamente, con un consumo moderado. El snippet de tracking insertado en el tema era insignificante. Pero el plugin de seguimiento de campaña, el que parecía más ligero, estaba cargando en cada petición un array completo de eventos históricos de la campaña para calcular métricas internas. Ese array crecía con cada visita registrada, y después de semanas de campaña activa, su consumo había escalado hasta superar los 20 MB por carga.

Ese era el componente que disparaba el uso. No estaba roto, no tenía un error de código, simplemente acumulaba datos en memoria de una forma que no escalaba. Con una campaña corta, nadie lo habría notado. Pero con semanas de tráfico acumulado, cada nueva carga pesaba más.

La solución fue doble. Primero, ajusté la directiva de memoria en wp-config.php para dar margen operativo real mientras se resolvía el fondo. Segundo, desactivé la funcionalidad de métricas en tiempo real del plugin de tracking y purgué los registros históricos acumulados. Con eso, el consumo bajó a niveles normales. También confirmé con Health Check & Troubleshooting que el entorno quedaba estable y que la pantalla blanca no volvía bajo carga normal.

Después de aplicar los cambios, monitoricé el sitio durante 48 horas. Las cargas se completaban, el consumo de memoria se mantenía por debajo de los 80 MB incluso con todos los componentes activos, y el error log del servidor dejó de registrar fatales de memoria. El sitio volvía a responder como lo había hecho al principio de la campaña.

Aquí había una pista que no estaba mirando bien. El hecho de que el sitio hubiera funcionado antes no significaba que la configuración fuera correcta. Significaba que el consumo aún no había cruzado el límite. La diferencia entre un sitio que carga y uno que muestra una pantalla blanca puede ser un solo megabyte.