Reparar una pantalla blanca de WordPress empieza por identificar la capa que falla. Una respuesta vacía puede implicar PHP o una interrupción anticipada; una página con HTML puede estar oculta por código del navegador. Revisamos URL, condición de visita y cambios recientes para acotar la corrección y las pruebas de aceptación.
Paso 1 — Localiza dónde aparece el blanco
Anota la URL afectada y compara portada, una entrada y administrador en la condición de visita relevante. Distingue respuesta vacía, HTML presente y redirección. Estas observaciones orientan la investigación; por sí solas no demuestran que un plugin o tema concreto sea la causa.
Paso 2 — Activa el registro, no los errores en pantalla
Relaciona primero la hora de la petición con los registros existentes del servidor y PHP. Si hace falta registrar más información, acuerda una recogida controlada, mantén los errores fuera de las pantallas públicas y protege el registro. Utiliza staging cuando sea posible y conserva la configuración anterior para restaurarla al terminar.
Paso 3 — La prueba de la carpeta de plugins
Si la evidencia señala un plugin, aísla ese componente con una vía de recuperación. Si la causa no está clara, una prueba más amplia necesita una copia de staging o una interrupción acordada, el listado de plugins activos y un plan de restauración. Los mu-plugins se cargan por separado. Que la página vuelva tras un cambio es una pista, no el diagnóstico completo.
¿Tu web está afectada ahora mismo?
Envía la URL y el síntoma que ves. Jordi Ensenyat revisa el caso personalmente y define el alcance y el presupuesto antes de tocar nada. Este formulario nunca pide contraseñas.
Paso 4 — Prueba con el tema por defecto
Antes de probar otro tema, confirma que hay una alternativa compatible instalada y conserva la configuración actual. Prioriza una copia controlada. Si el cambio afecta al síntoma, revisa la plantilla o el código implicado antes de decidir la corrección permanente.
Paso 5 — Memoria y un despliegue incompleto
Ante memoria agotada, identifica la petición y el consumidor antes de valorar otro límite. Si hubo un despliegue interrumpido, compara los componentes con archivos de confianza y preserva los datos antes de sustituir nada. Subir un techo o reemplazar archivos sin evidencia puede dejar el problema original pendiente.
Preserva primero
Conserva el estado actual y una forma de volver atrás antes de editar. Restaura la configuración temporal al terminar y comprueba que los registros recogidos no sean públicos. La documentación oficial de depuración de WordPress explica los controles disponibles.
Cuándo escalar
Llama a un especialista si el administrador también está en blanco y no hay copia, si la web es una tienda, o si la pantalla blanca aparece junto a redirecciones o archivos desconocidos. Enviar la URL, qué cambió justo antes y si el administrador carga es suficiente para evaluarlo sin credenciales.
Qué debe entregar una reparación de pantalla blanca
El encargo empieza con URL, momento del fallo, cambios recientes, acceso al administrador y recorrido de negocio afectado. Una tienda, una reserva o una consulta necesitan su propia comprobación: ver la portada no resuelve por sí solo la incidencia.
Pide que el presupuesto separe diagnóstico, corrección y verificación. El cierre debe recoger la causa respaldada por evidencia, el cambio aplicado, las condiciones probadas y lo que siga sin comprobar. El plazo de atención y el alcance se acuerdan para el caso concreto.
La guía de diagnóstico de pantalla blanca en WordPress desarrolla las comprobaciones. Para solicitar una evaluación de reparación de pantalla blanca, envía la URL pública y tus observaciones. No incluyas contraseñas.
RECUPERACIÓN WORDPRESS BASADA EN EVIDENCIA
Convertir una pantalla en blanco en un diagnóstico con evidencia
En reparación urgente de webs y recuperación de WordPress, el síntoma visible puede estar lejos de la causa. recuperar el recorrido afectado sin poner en riesgo el resto de la web. Una página completamente en blanco suele significar que la salida de errores está oculta mientras la ejecución de PHP ha fallado. Activar los mensajes de depuración en público puede exponer rutas y detalles sensibles, así que la evidencia debe capturarse de forma privada mediante registros o un entorno controlado.
Qué comprobamos
- El recorrido completo, no solo la pantalla donde aparece el error
- Dependencias externas, registros y evidencias antes de cambiar configuración
- Registros de PHP y WordPress buscando errores fatales o memoria agotada
- Si la pantalla en blanco afecta a todas las rutas, al administrador o a una acción
- Cambios de tema, plugins, caché y despliegues cercanos al fallo
- La ruta original y páginas representativas tras la recuperación
Qué significa un resultado verificado
El cierre documenta la causa encontrada, el cambio aplicado y las pruebas realizadas. El resultado debe ser observable y repetible, no una impresión de que “parece funcionar”.
ANTES DE LA EVALUACIÓN
Preguntas frecuentes sobre esta incidencia
¿Cómo se comprueba que el problema está realmente resuelto?+
Se reproduce el recorrido afectado, se revisan sus dependencias y se documenta la evidencia posterior al cambio.
¿La pantalla blanca es lo mismo que el error crítico?+
Pueden compartir una causa en PHP, pero el comportamiento visible es distinto. Hacen falta registros para saber si el fallo es de memoria, código, caché o despliegue.
¿Debo activar WP_DEBUG en la web en producción?+
El registro de depuración ayuda, pero mostrar errores en público es inseguro. La salida debe escribirse en un log protegido y desactivarse después.
¿Vaciar la caché soluciona una pantalla blanca?+
A veces la caché interviene, pero vaciarla sin evidencia puede borrar señales útiles. Primero conviene identificar la capa que falla.