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.
Un árbol de decisión antes de cambiar la web
- La respuesta no tiene cuerpo: registra estado HTTP y hora y correlaciónalos con evidencia del servidor y PHP. El HTML vacío no identifica por sí solo el componente que falla.
- Hay HTML, pero la página parece blanca: inspecciona marcado recibido, errores del navegador, estilos y capas superpuestas. Conserva la respuesta antes de cambiar presentación.
- Funciona la web pública, pero el administrador queda en blanco: sigue el diagnóstico de administrador en blanco. Una página pública en caché no verifica la petición del administrador.
- La petición redirige o se deniega: identifica esa respuesta y su origen antes de tratarla como un fallo de presentació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é.
Prueba HTTP propia: el estado es una pista más
El 24 de octubre de 2026 servimos cuatro respuestas sintéticas originales en un servidor HTTP temporal de bucle local y leímos sus respuestas. No intervenimos en WordPress ni en una configuración de producción. Estas fueron las observaciones controladas:
empty-success HTTP 200 0 bytes no HTML
empty-error HTTP 500 0 bytes no HTML
hidden-markup HTTP 200 90 bytes HTML present
maintenance HTTP 503 69 bytes HTML presentEl ejemplo de marcado oculto contenía un elemento main con display:none. Las respuestas vacías 200 y 500 tenían la misma longitud; cambiaba su estado. El ejercicio muestra diferencias de respuesta, no una causa de WordPress ni una reparación de cliente. Para reproducirlo, prepara esas combinaciones de estado y cuerpo en un entorno aislado e inspecciona la respuesta original.
En una incidencia real, conserva URL, hora, estado, observación del cuerpo y evidencia correspondiente del registro. La documentación de depuración de WordPress —en inglés— orienta la obtención de registros adicionales manteniendo los errores fuera de la pantalla pública.
Evidencia para cerrar la reparación de pantalla blanca
Repite la URL afectada en la condición original del visitante tras la corrección acordada. Comprueba contenido y respuesta previstos, formulario o tarea administrativa afectados y ausencia del mismo error nuevo en los registros disponibles. Anota cambio y rutas sin verificar. Para reparar una pantalla blanca de WordPress, aporta ese límite del fallo y los cambios recientes para concretar la intervención.