Una página en blanco puede ser una respuesta vacía con estado correcto, un error fatal de PHP oculto, una salida prematura, memoria agotada o HTML escondido por el código del frontal. El color que muestra el navegador no identifica por sí solo la capa que falla.
Inspecciona el estado, las cabeceras y el cuerpo antes de hacer visibles los errores. Los visitantes de producción nunca deberían ver rutas del servidor ni trazas de ejecución.
Comprueba la respuesta HTTP real
Abre la pestaña Red de las herramientas del navegador o utiliza un cliente HTTP autorizado. Registra el código de estado, tipo de contenido, longitud de respuesta, cadena de redirecciones y cabeceras de caché.
Patrones de una respuesta en blanco:
500 con cuerpo vacío -> fallo del servidor o PHP
200 con cero bytes -> salida prematura o error oculto
200 con HTML -> problema de CSS, JavaScript o visualización
bucle 3xx -> problema de URL, HTTPS o cookiesPrueba también un CSS o una imagen y wp-login.php para delimitar el alcance.
Mira la respuesta sin interpretar
Utiliza «Ver código fuente» o inspecciona el cuerpo recibido. Si existe marcado HTML, desactiva extensiones del navegador y busca CSS como texto blanco, contenedores ocultos o una capa a pantalla completa.
Si el cuerpo termina bruscamente, anota la última sección de plantilla renderizada. Puede señalar el hook o shortcode que se ejecutaba cuando PHP se detuvo.
No modifiques el diseño antes de demostrar que el servidor devolvió el HTML completo.
Lee los registros de PHP y del servidor
Relaciona la hora de la petición con los registros de PHP-FPM, Apache o Nginx y WordPress. Busca errores fatales, memoria agotada y excepciones no controladas.
Activa WP_DEBUG_LOG con WP_DEBUG_DISPLAY desactivado solo si no hay registros suficientes:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Desactiva el registro temporal al terminar y evita que el archivo pueda descargarse públicamente.
Comprueba memoria y tiempos de ejecución
La memoria agotada puede producir una respuesta blanca cuando los errores están ocultos. Registra el límite, la asignación solicitada, el archivo y la línea.
No aumentes el límite sin investigar qué consume la memoria. Un bucle o una consulta sin límites agotará también el nuevo máximo.
En los timeouts, compara el tiempo máximo de PHP con el del proxy inverso e identifica la tarea que se bloqueó.
Aísla plugin y tema de forma precisa
Si el error fatal menciona un plugin, renombra solo su directorio. Si no hay registros, prueba en staging o renombra el directorio de plugins siguiendo un orden documentado de reactivación.
Recuerda que los plugins obligatorios cargan aparte del directorio normal y pueden seguir provocando la pantalla blanca.
Si el problema está en el tema, confirma que existe un tema predeterminado compatible. Sin alternativa, WordPress puede quedarse sin nada que renderizar.
No edites el tema padre ni los archivos del plugin como solución permanente.
Localiza salidas prematuras y búferes
Busca en el código propio exit, die, limpieza del búfer de salida y lógica de mantenimiento alrededor de la ruta afectada. Un control de seguridad o staging puede devolver deliberadamente un cuerpo vacío.
if ( ! defined( 'ABSPATH' ) ) {
exit;
}Esta protección es normal al abrir un archivo directamente; el defecto aparece si una condición similar se activa durante una petición válida de WordPress.
Comprueba archivos incompletos o incorrectos
Una actualización interrumpida, una restauración fallida o el límite de disco o inodos pueden dejar archivos PHP ausentes o de cero bytes. Compara checksums de paquetes fiables y fechas de modificación.
Tras hacer copia, reinstala exactamente el componente oficial. Conserva subidas y configuración, y verifica el propietario de los archivos antes de actualizar otra vez.
Limpia OPcache para que PHP no conserve código compilado antiguo.
Verifica todas las rutas afectadas
Prueba portada, entradas, acceso, administración, editor, medios y la URL original. Revisa si aparecen nuevos errores y prueba como usuario anónimo y conectado.
El mantenimiento recurrente debería alertar también de respuestas HTML vacías, no solo de estados distintos de 200. La pantalla blanca está resuelta cuando la petición subyacente termina de forma predecible, no cuando aparece temporalmente una página guardada en caché.