El tema público y la administración ejecutan hooks, recursos y permisos distintos. Un plugin puede fallar solo en wp-admin, o un perfil puede cargar un widget roto mientras las páginas anónimas siguen sanas en caché.
Inspecciona la respuesta administrativa antes de cambiar el tema activo o la web pública.
Comprueba estado y cuerpo
Abre Red para /wp-admin/ y anota estado, longitud, redirecciones y tipo de contenido.
Patrones:
500 y vacío -> error PHP o servidor
200 y vacío -> error oculto o salida prematura
200 con HTML -> CSS, JavaScript u overlay
403 -> seguridad, capacidad o cortafuegos
3xx -> autenticación o dominioMira el código fuente para distinguir HTML vacío de contenido oculto.
Lee los registros administrativos
Relaciona la hora con PHP y WordPress. Conserva el primer error fatal y la ruta del componente.
Activa WP_DEBUG_LOG protegido y sin mostrar solo si hace falta. No expongas errores en el navegador.
Comprueba si el fatal ocurre en admin_init, widgets, creación del menú o un aviso de actualización.
Compara rutas de administración
Prueba profile.php, edit.php, plugins.php y una página directa de plugin. Si alguna funciona, está implicado el escritorio o el hook de una pantalla.
Prueba otro administrador autorizado. Un fallo específico puede venir de opciones de pantalla, widgets, idioma o metadatos corruptos.
No crees ni compartas cuentas sin los controles habituales.
Comprueba memoria y tiempo
La administración carga más código y datos que la web pública. Conserva errores de memoria o timeout e identifica el consumidor antes de subir límites.
Un recuento sin límites o una llamada de licencia puede bloquear una pantalla. Mide consultas y APIs en staging.
Recuerda que los timeouts administrativos ocupan los mismos workers PHP.
Aísla plugins administrativos
Usa WP-CLI para desactivar el plugin señalado o renombra únicamente su directorio. Los plugins obligatorios y drop-ins se revisan aparte.
wp plugin deactivate example-pluginEjecuta como el usuario correcto y en la raíz adecuada. Conserva archivos y datos; no desinstales.
Si todavía carga parte de la interfaz, usa un modo de diagnóstico limitado a tu sesión.
Inspecciona recursos del administrador
Si existe HTML, revisa Consola y Red en busca de CSS o JS ausente, CSP y excepciones. Los plugins de optimización deberían excluir los recursos administrativos.
Un modal de bienvenida puede cubrir toda la pantalla. Inspecciona DOM y estilos antes de borrar ajustes.
Limpia la caché de recursos después de reparar, no sesiones de clientes ajenas.
Repara el estado del usuario
Los widgets y opciones de pantalla viven en metadatos de usuario. Compara la cuenta afectada con otra que funcione mediante APIs de WordPress.
No elimines todos los metadatos. Corrige solo la clave demostrada tras una copia y deja que WordPress reconstruya valores.
Revisa errores de traducción si solo falla un idioma.
Revisa menús y columnas personalizados
Los plugins crean menús, avisos y columnas solo para ciertas capacidades. Un callback puede consultar todas las entradas o llamar a un servicio antes de renderizar.
Desactiva el módulo en staging y mide esa pantalla. Carga metadatos por lotes y almacena solo referencias no personales. No retires las comprobaciones de permisos para conseguir que renderice.
Comprueba salida y compresión
Espacios, depuración o un controlador de compresión roto pueden dejar el HTML administrativo en blanco. Compara la respuesta cruda y Content-Encoding con el origen.
Revisa auto_prepend_file, búfer PHP y plugins de seguridad u optimización. Retira echo o var_dump() temporales. No desactives TLS o compresión globalmente sin pruebas.
Verifica el trabajo administrativo
Prueba escritorio, editor, guardado, páginas de plugins y temas, medios, cron y salida o entrada. Comprueba que la parte pública siga igual.
El mantenimiento recurrente debe vigilar errores fatales administrativos y tiempo de pantallas críticas. La reparación termina cuando el equipo puede realizar sus tareas, no cuando /wp-admin/ muestra una cabecera.