Síntoma y contexto
La pantalla blanca de WordPress, también llamada WSOD, aparece cuando el sitio deja de renderizar contenido y el navegador muestra una página vacía. Puede afectar solo a la portada, a una sección concreta, al área de administración en /wp-admin o a todo el dominio. A veces no hay texto de error visible porque PHP está configurado para ocultar fallos en producción. Otras veces el servidor devuelve un 500, un 503 o una respuesta 200 con el cuerpo vacío.
El objetivo no es tocar todo a la vez. Una pantalla blanca suele indicar un error fatal en PHP, una incompatibilidad de plugin o tema, falta de memoria, caché corrupta o una actualización incompleta. Si se mezclan cambios en plugins, tema, versión PHP y caché sin anotar el orden, el sitio puede empeorar y el diagnóstico se vuelve más lento.
Esta guía está pensada para recuperar visibilidad sin pedir contraseñas ni pegar archivos sensibles. Si puedes entrar al panel de hosting, SFTP, administrador de archivos o WP-CLI, se puede aislar la causa con pasos reversibles. Para una caída general del servidor, revisa también la web no carga. Si el síntoma viene acompañado de bucles, mira demasiadas redirecciones.
Causas probables
- Plugin incompatible o actualizado a medias. Un plugin puede lanzar un fatal error al cargar una función que ya no existe, al exigir una versión PHP distinta o al quedar con archivos incompletos tras una actualización.
- Tema activo con error PHP. Un cambio en
functions.php, un tema antiguo o una plantilla personalizada puede romper la carga antes de que WordPress pinte la página. - Límite de memoria agotado. El log suele mostrar
Allowed memory size exhausted. Ocurre con plugins pesados, importaciones, builders visuales o tráfico que dispara procesos simultáneos. - Versión PHP incompatible. Al subir de PHP 7.4 a 8.x, código antiguo puede fallar por funciones retiradas, tipos más estrictos o avisos convertidos en errores fatales.
- Actualización de WordPress incompleta. Si la actualización del core se interrumpió, pueden quedar archivos mezclados de dos versiones o un modo mantenimiento atascado.
- Caché de plugin, hosting o CDN corrupta. Una página en blanco puede quedar servida desde caché aunque el origen ya esté reparado, o al revés.
- Error de base de datos distinto a la pantalla blanca. Si aparece mensaje de conexión a base de datos, usa la guía de error de base de datos en WordPress en lugar de tratarlo como WSOD.
- Reglas del servidor o permisos incorrectos. Un
.htaccessroto, permisos cambiados o archivos propiedad de otro usuario pueden impedir que PHP cargue recursos necesarios.
Checklist copiable
WORDPRESS PANTALLA BLANCA - [URL] Fecha: ___________ Hora (zona): ___________ 1. ALCANCE DEL FALLO [ ] Portada en blanco [ ] Todo el sitio en blanco [ ] Solo /wp-admin [ ] Solo una ruta: ___________ Código HTTP si se ve: ___________ 2. CAMBIOS RECIENTES [ ] Actualización de plugin [ ] Actualización de tema [ ] Cambio de versión PHP [ ] Migración de hosting [ ] Limpieza o cambio de caché Detalle y hora: ___________ 3. ACCESO DISPONIBLE [ ] wp-admin [ ] SFTP [ ] Panel de archivos del hosting [ ] WP-CLI [ ] Logs de errores PHP 4. PRUEBAS SEGURAS [ ] Renombré wp-content/plugins a plugins.off [ ] Probé tema por defecto [ ] Revisé error_log o debug.log [ ] Probé en incógnito sin caché 5. LOG RELEVANTE Pega solo la línea del error fatal, sin rutas con usuarios si no quieres: ___________ 6. NO ENVIAR [ ] Sin contraseñas de wp-admin [ ] Sin contenido completo de wp-config.php [ ] Sin claves de base de datos ni salts
Qué capturar antes de escribir
La información más útil es la URL exacta, el alcance del fallo y qué cambió justo antes. Indica si puedes entrar a /wp-admin o si también queda en blanco. Una captura de la pantalla ayuda, pero en este caso el dato clave suele estar en los logs del hosting: error_log, registros PHP-FPM, visor de errores de cPanel o archivo wp-content/debug.log si lo activaste.
Si editas wp-config.php, haz copia antes. Para registrar errores, basta con activar temporalmente constantes como WP_DEBUG y WP_DEBUG_LOG, preferiblemente sin mostrar errores al visitante. No pegues el archivo completo en el formulario. Ese archivo puede contener nombre de base de datos, usuario, contraseña, salts y rutas internas. Copia solo la línea de error que mencione el plugin, tema o archivo afectado.
Anota cada paso reversible: carpeta renombrada, hora de la prueba y resultado. Si desactivas plugins por SFTP renombrando carpetas, no borres nada. Cambia plugins a plugins.off, prueba, y vuelve a nombrar cuando tengas el resultado. Ese registro evita perder configuración o activar extensiones en un orden peligroso.
Comandos y paneles útiles
En hosting con panel, revisa Administrador de archivos, registros de errores, selector de PHP, copias de seguridad y herramientas de WordPress si existen. En cPanel suele aparecer un apartado de Errors o MultiPHP Manager. En Plesk, busca Logs, PHP Settings y WordPress Toolkit.
# Ver cabeceras para saber si hay 500, 503 o cuerpo vacío curl -I https://tudominio.com # Si tienes WP-CLI y el sitio carga suficiente para ejecutarlo wp plugin list wp theme list wp option get siteurl # Desactivar todos los plugins con WP-CLI wp plugin deactivate --all # Ver versión PHP en servidor php -v
Si solo tienes SFTP o panel de archivos, la prueba segura más habitual es renombrar wp-content/plugins. WordPress no encuentra los plugins y los desactiva para esa carga. Si el sitio vuelve, restaura el nombre y renombra plugins uno a uno hasta encontrar el culpable. Hazlo con calma y sin borrar carpetas.
Pasos por escenario
La pantalla blanca apareció tras actualizar un plugin
Renombra la carpeta del plugin sospechoso dentro de wp-content/plugins. Si no sabes cuál fue, renombra la carpeta plugins completa. Cuando el sitio vuelva, restaura el nombre y desactiva desde el admin los plugins no imprescindibles antes de probar uno a uno. Revisa el log: muchas veces dirá el nombre exacto del plugin y la función que falla.
No puedes entrar a wp-admin
No pidas ni envíes contraseñas por mensajes. Usa el panel de hosting o SFTP para aislar plugins y tema. Si tienes WP-CLI, desactiva plugins con wp plugin deactivate --all. Si no, renombra carpetas. Para tema, puedes mover temporalmente el tema activo o cambiar la opción desde base de datos solo si sabes identificar template y stylesheet. Antes de tocar base de datos, haz copia.
El log muestra falta de memoria
Busca Allowed memory size exhausted. Puedes subir el límite desde el panel PHP del hosting o mediante configuración permitida por el proveedor. En WordPress, WP_MEMORY_LIMIT puede ayudar si el hosting no lo bloquea, pero no compensa un plugin que consume demasiado. Si el fallo empezó al activar un builder, importador o plugin de copias, desactívalo y revisa si hay procesos atascados.
El fallo empezó al cambiar PHP
Vuelve temporalmente a la versión anterior desde el panel si el proveedor lo permite y documenta el resultado. Después actualiza plugins y tema en un entorno controlado. No mantengas una versión PHP antigua indefinidamente, pero usarla unos minutos para recuperar acceso puede ser razonable mientras localizas el código incompatible.
Hay Cloudflare, caché o reglas de redirección
Primero confirma si el origen responde con curl -I. Purga caché solo después de aislar plugins y revisar el código HTTP. Si además ves bucles entre http y https, sigue la guía de redirección infinita. Si el servidor directamente no responde, vuelve a web caída.
Cuándo escalar
Escala usando el formulario con categoría Web o despliegue si el sitio sigue en blanco tras desactivar plugins, si el log muestra un fatal error que no sabes interpretar, si no tienes acceso al panel de archivos o si necesitas tocar base de datos con seguridad. Incluye la checklist, URL, proveedor de hosting, versión PHP si la conoces y la línea exacta del error. No incluyas contraseñas, claves de base de datos, salts ni el contenido completo de wp-config.php.
Enlaces relacionados: La web no carga, Formulario que no envía, WordPress error de base de datos, Demasiadas redirecciones.