After moving a WordPress site, the browser reports a database connection error. Which checks can isolate configuration, permissions and service issues without exposing credentials?

In this hypothetical move, the message establishes that WordPress could not connect; it does not identify a damaged database. Start by confirming that the requested domain reaches the intended installation. Keep a recoverable copy of the configuration and database before making changes.

Compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php with the destination service details. A database account from the old server may not exist on the new one. The host can also require a different hostname, port or socket. Check values privately rather than posting the file, a connection string or a screenshot containing secrets.

The next useful distinction is whether the database service can be reached from the application environment. An administrator can test the same database and account through an approved client using protected credential entry. Record a sanitized error and timestamp. A connection refusal, an authentication failure and access denied to a particular database suggest different areas to investigate; none alone justifies broadening access to every database.

If authentication succeeds, verify that the intended database was imported, its expected tables exist, and the account has the permissions required for that installation. Check service availability, connection limits and relevant server logs with the operator. Avoid repeatedly resetting passwords without updating the application configuration consistently.

Once the connection works, test both the public site and administration area. Database repair is a separate action for evidence of table damage, with its own backup and recovery plan; it should not be the first response to a connection error.

Sources: Common WordPress errors and How WordPress parses DB_HOST.