Cambiar la contraseña del único usuario activo antes de actualizar WordPress provoca una caída inmediata. Una rotación más segura crea otra cuenta con privilegios mínimos, la prueba desde el servidor de aplicación, cambia la configuración de forma atómica y revoca la anterior tras observarla.
Utiliza el procedimiento compatible de usuarios y permisos del hosting. No pegues credenciales en chats, tickets ni historial del terminal.
Inventaría todos los consumidores
Identifica la web, WP-CLI, tareas cron, copias, monitorización, staging y secretos de despliegue que usan la cuenta actual.
Registra sin valores secretos:
base, host y puerto
usuario y host permitido
consumidor y entorno
ubicación segura del secreto
responsable y orden de rotaciónUna tarea olvidada puede seguir fallando aunque la web funcione.
Prepara copia y reversión
Haz una copia actual de la base y otra protegida de wp-config.php. Confirma que conservarás acceso al panel o SSH si WordPress pierde conexión.
Registra los permisos actuales sin la contraseña. Mantén activa la cuenta anterior durante el cambio.
No rotes durante una importación, despliegue u otra operación intensa.
Crea un segundo usuario
Usa cPanel, Plesk o administración MySQL autorizada. Concede acceso solo a la base prevista y los privilegios necesarios.
Evita permisos globales *.*, privilegios administrativos y hosts comodín cuando la aplicación tiene un origen conocido. Genera una contraseña única y guárdala en un gestor aprobado.
En varios nodos, incluye los hosts reales según el diseño del proveedor.
Prueba desde el contexto de aplicación
Conecta desde la misma red, servidor o contenedor que WordPress. Verifica una lectura y una escritura segura con un valor controlado o tabla de prueba cuando la política lo permita.
No pongas la contraseña en la orden. Usa una solicitud interactiva o configuración temporal protegida que se elimine de inmediato.
Confirma TLS, autenticación y compatibilidad del driver PHP.
Coordina réplicas y pools
En clúster, actualiza credenciales en primario y réplicas permitidas según la plataforma. Workers PHP o proxies persistentes pueden conservar conexiones antiguas.
Despliega un nodo web cada vez, verifica lectura y escritura y continúa. Mantén la cuenta anterior hasta que nodos, cron y proxy usen la nueva. No la revoques por una portada correcta: revisa conexiones y registros durante todo el ciclo de los workers.
Cambia WordPress de forma atómica
Prepara una edición protegida de wp-config.php que cambie DB_USER y DB_PASSWORD juntos. Conserva propietario y sintaxis.
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'secret_from_secure_storage' );No guardes el secreto real en control de versiones. Si usas variables de entorno, actualiza el gestor y todos los nodos de forma coherente.
Verifica lecturas, escrituras y tareas
Prueba portada, acceso, guardado de borrador u opción, metadatos y WP-Cron. Busca «access denied» en PHP y MySQL.
Ejecuta WP-CLI y copias si utilizan credenciales separadas. En clúster, solicita cada nodo o inspecciona el despliegue.
Vigila conexiones con usuarios antiguo y nuevo.
Revoca la cuenta anterior
Cuando no queden conexiones legítimas durante la ventana de observación, desactívala mediante controles compatibles. Conserva un usuario de emergencia solo si lo exige la política, no indefinidamente.
Si persisten conexiones antiguas, identifica su origen. No supongas que toda conexión dormida es WordPress.
Documenta la finalización y la próxima fecha.
Gestiona una rotación urgente
Si una filtración exige actuar de inmediato, prepara primero el secreto y la configuración nuevos, usa una ventana breve y aplica ambos lados en la secuencia más corta.
Rota también copias, monitorización y staging. Revisa accesos no autorizados y sigue el proceso de incidente.
El mantenimiento recurrente debe conservar propiedad y pruebas de rotación. El cambio termina cuando todos los consumidores migran, el secreto antiguo deja de funcionar y WordPress lee y escribe sin interrupción.