Changing the password on the only active database user before WordPress is updated creates an immediate outage. A safer rotation creates a second least-privileged account, proves it from the application server, switches WordPress atomically and revokes the old user after observation.
Use the hosting platform’s supported user/grant workflow. Never paste credentials into chat, tickets or shell history.
Inventory every credential consumer
Identify the WordPress site, WP-CLI, cron jobs, backup tools, monitoring, staging copies and deployment secrets that use the current account.
Record without secret values:
database name/host/port
username and allowed host
consumer/environment
secret storage location
owner and rotation orderA forgotten cron or backup can continue failing after the website works.
Back up and prepare rollback
Take a current database backup and protected copy of wp-config.php. Confirm panel/SSH access remains available if WordPress loses connection.
Record current user grants without the password. Keep the old account active through the cutover window.
Do not rotate during an import, deployment or other database-heavy change.
Create a second database user
Use cPanel, Plesk or authorised MySQL administration. Grant only the intended WordPress database and required privileges.
Avoid global *.*, administrative privileges and wildcard hosts when the application has a known source. Use a long unique password stored in an approved password/secret manager.
For multi-node hosting, include the actual application hosts according to the provider design.
Test from the application context
Connect from the same server/container/network as WordPress. Verify both a read and a safe write against a controlled staging value or dedicated test table where policy permits.
Do not put the password on the command line. Use an interactive prompt or protected temporary client configuration removed immediately.
Confirm TLS/authentication requirements and PHP driver compatibility.
Coordinate replicas and connection pools
In a clustered setup, update the credential on the primary and permitted replicas according to the platform design. Long-lived PHP workers or proxies may retain old pooled connections temporarily.
Roll configuration through one web node at a time, verify reads/writes, then continue. Keep the old account valid until every node, cron runner and database proxy reports the new user. Do not revoke it based on one successful homepage request; inspect active connections and logs across the full worker lifetime.
Switch WordPress atomically
Prepare a protected wp-config.php update changing DB_USER and DB_PASSWORD together. Preserve file ownership and syntax.
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'secret_from_secure_storage' );Never commit the real secret to version control. For environment-based deployments, update the secret manager and roll out all web nodes consistently.
Verify reads, writes and background work
Test homepage, login, saving a controlled draft/option, media metadata and WP-Cron. Check PHP/MySQL logs for access denied messages.
Run WP-CLI and backup jobs explicitly if they use separate credentials. In a cluster, request each node or inspect its configuration rollout.
Monitor active connections under old and new users.
Revoke the old account
After the observation window shows no legitimate old-user connections, disable/revoke it through supported controls. Keep an emergency rollback user only according to security policy, not indefinitely.
If old connections persist, identify their source before revocation. Do not assume every sleeping connection is WordPress; use host/process evidence.
Document completion and next rotation date.
Handle an emergency single-user rotation
If compromise requires immediate password change, prepare the new secret/config update first, use a brief maintenance window and apply both sides in the shortest sequence possible.
Rotate backups, monitoring and staging secrets too. Review logs for unauthorised access and follow the incident-response process.
Recurring care should maintain credential ownership and rotation tests. A clean rotation proves every consumer moved, the old secret is unusable and WordPress can both read and write without interruption.