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é.
Si el equipo necesita ayuda para recuperar la vía de administración bloqueada, consulta el servicio de recuperación de acceso al administrador WordPress y su alcance. La intervención distingue cuenta y fallo del inicio de sesión, y acuerda comprobación y entrega antes de cambiar nada.
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.
Separa la recuperación del administrador de la disponibilidad pública
Prepara una comparación del mismo momento: URL pública original como visitante sin sesión, pantalla administrativa que falla y otra tarea de gestión autorizada. Registra estado, existencia de HTML y evidencia de error correspondiente en cada caso. Son comprobaciones pendientes de ejecutar; la portada visible no permite dar sus resultados por hechos.
Si la ruta pública también queda en blanco, vuelve al árbol de pantalla blanca sin mensaje de error. Si solo falla una pantalla o usuario de administración, centra el diagnóstico en sus hooks, recursos y contexto autorizado. La caché pública puede ocultar un problema que aparece al ejecutar una petición nueva.
Para cerrar, repite la tarea real: abrir el editor correspondiente, guardar un cambio de prueba autorizado o utilizar la pantalla de gestión afectada, según lo acordado. Ver solo la cabecera del escritorio deja la aceptación incompleta. Comprueba también la parte pública y registra pantallas pendientes por separado.
Para solicitar una valoración de reparación del administrador WordPress, aporta URL pública, ruta de pantalla, hora aproximada, cambios recientes y si afecta a otros usuarios autorizados. El acceso de diagnóstico se comparte después por el canal acordado; la consulta pública no necesita credenciales.