You move a WordPress site from your computer to a live server, open the domain, and see: “Error establishing a database connection.” The message is alarming, but it usually means WordPress cannot reach or log in to its database. It does not automatically mean your content is lost.
Start with the fastest reversible checks. Don’t reinstall WordPress, delete the database, or install troubleshooting plugins while the site is down. First record what you see, protect the current files and database, then check the migration’s database details one item at a time.
First, Triage the Outage
Before changing anything, write down the exact error and when it appeared. Keep a short incident scratchpad so you can compare symptoms and undo changes accurately.
- Exact message: Copy the browser error, including any additional details. Time: Record the time and time zone when you first noticed the problem. Scope: Check whether the homepage, /wp-admin/, and other sites on the same hosting account are affected. Recent changes: Note the migration time, database import, DNS change, or edits to wp-config.php.
Then make a backup before editing configuration or database content. Save a copy of the live site’s files, especially wp-config.php, and export the live database if it exists. If the site has never worked on the live server, preserve the imported database and the original local copy. A backup gives you a way back if a correction makes matters worse.
Fast, Reversible Checks
Reload the page once in a private browser window. Rule out a stale browser response without changing the site. Check the hosting provider’s status page or control panel for a database outage or maintenance notice. Confirm that the domain points to the intended live server. If DNS was changed recently, check that you are not viewing an old server or a cached destination. Compare the live site’s database settings with the values shown in the hosting control panel.If the host reports a database outage, save the notice and its timestamp. Don’t change WordPress credentials to compensate for a service that is temporarily unavailable.
How WordPress Connects to the Database
WordPress reads its database connection details from wp-config.php, usually in the site’s document root. The relevant entries look like this:
define( 'DB_NAME', 'database_name' ); define( 'DB_USER', 'database_user' ); define( 'DB_PASSWORD', 'database_password' ); define( 'DB_HOST', 'localhost' );The values must match the database and database user created on the live hosting account. Local development values such as root, an empty password, or localhost may not be correct on the new server. A migration copies site files and database content, but it does not necessarily create a live database, create a user, or grant that user permission to connect.
Check Database Credentials Carefully
Open the hosting control panel’s database section and verify each value. Depending on the host, this may be labelled MySQL, MariaDB, or Databases. Don’t assume that the database name or user is the same as it was on your computer.
Setting What to verify Common migration issue DB_NAME The exact live database name in the hosting panel The local database name was copied into the live configuration DB_USER The exact database user assigned to that database A local username, or an incomplete account name, was used DB_PASSWORD The current password for that database user The password changed during setup or contains an unescaped quote DB_HOST The database hostname specified by the host localhost was assumed instead of checking the server’s required valueCreate a New Database User if Needed
If there is no suitable live database user, create a new database user in the hosting control panel, assign it to the intended database, and grant the permissions required for WordPress to operate. On many shared hosts, the panel provides a specific “add user to database” step. Creating a user alone may not give it access.
Use a strong, unique password and copy it carefully into wp-config.php. Avoid sending database passwords in public support tickets, screenshots, or chat messages. If you suspect the password has been exposed, rotate it in the panel and update the configuration to match.
What changed: A live database user was created or assigned, and the connection values in wp-config.php were corrected. How to roll back: Restore the saved configuration file and, if necessary, remove or disable the newly created user in the hosting panel. Don’t remove a user until you have confirmed that no other live site depends on it.
Check Whether the Database Was Imported
A correctly configured username cannot connect WordPress to content that was never transferred. Confirm that the live database contains the site’s tables. In the hosting database manager, look for familiar WordPress tables, such as wp_options, wp_posts, and wp_users. The prefix may differ from wp_, so use the actual prefix shown in the site’s configuration or table list.
If the live database is empty or missing the expected tables, import the local database backup into the correct live database. Use the hosting control panel’s database import tool or the host’s documented method. Before importing, verify the target database name and make a copy of any existing live database: an import can add, replace, or conflict with existing tables depending on the method and options selected.
After You Import the Database
- Confirm the import completed without errors or file-size limits. Check that the tables are in the database named by DB_NAME. Make sure the database user is assigned to that database with appropriate permissions. Check whether the site uses a custom table prefix. The $table_prefix value in wp-config.php must match the imported tables.
What changed: The site’s database backup was imported into the live database. How to roll back: Restore the pre-import database backup using the control panel or your host’s documented restore process. Don’t import repeatedly without checking what the previous attempt did.
Verify the DB_HOST Change
The right DB_HOST value depends on the hosting environment. Some hosts use localhost; others provide a hostname such as a database server address, and some require a port or socket detail. A local development setup may also use a container name or custom address that does not exist on the live server.
Find the required value in the hosting database panel or its setup instructions. If none is shown, ask support this specific question: “What exact hostname, port, or socket should I use for DB_HOST for database [database name] on account [account identifier]?” Do not guess repeatedly, and never put a control-panel login password into DB_HOST.
What changed: Only the DB_HOST value was updated to the hostname supplied by the host. How to roll back: Restore the previous value from your saved wp-config.php copy. Change one setting at a time so you know which adjustment affected the result.
Check the Configuration File Itself
Make sure you edited the live site’s active wp-config.php, not a local copy or a duplicate in the wrong directory. Use the hosting file manager or SFTP, and verify that the file is in the WordPress installation incorrect db user wordpress directory. A migration can leave multiple folders, such as a staging directory and a public web root.
Check for accidental syntax problems around the database settings. Keep the quotes and semicolons intact. A password containing a single quote can break a PHP string if it is pasted without proper escaping. If you are unsure, set a new strong password using characters supported by the panel, then update the file carefully.
Do not paste the entire configuration file into a public forum or support request. It can contain database credentials and security keys. Share only the relevant error and non-sensitive details.
Check Hosting and Server Health
If the credentials, database, and host value appear correct, the problem may be on the server side. Check whether the database service is running, whether the account has reached a storage or connection limit, and whether the hosting account is suspended or restricted. On managed hosting, these checks may be visible in the control panel; on other plans, the provider may need to inspect the service.
When contacting support, give them useful evidence instead of a vague “my site is broken” message:
- Your domain and hosting account identifier. The exact error message and the time it began, including the time zone. Whether the WordPress dashboard and other sites on the account are affected. Confirmation that you checked the database name, user assignment, password, and required DB_HOST. The approximate time of the database import or migration.
Ask support to confirm whether the database server is reachable from the web server, whether the database user has access, and whether recent logs show connection refusals, limits, or an outage. Never send your database password unless the provider has a secure, approved method—and usually they do not need it.
Common Migration Mistakes to Avoid
- Using local credentials on the live server: Local database accounts are not automatically created on hosting. Forgetting the user assignment: The user exists but has no access to the selected database. Importing into the wrong database: The import succeeds, but WordPress is configured to connect to another database. Assuming every host uses localhost: Verify the required DB_HOST value. Making several changes at once: This makes it difficult to identify the cause and roll back safely. Reinstalling WordPress or deleting tables: These actions can make recovery harder and may destroy data.
Confirm the Fix and Keep a Record
After correcting one setting, reload the site and test both the homepage and /wp-admin/. If the error remains, record the new result and move to the next check rather than changing unrelated files. Once https://smoothdecorator.com/how-to-test-database-credentials-without-wordpress-loading/ the site loads, verify several pages, confirm that recent content is present, and check that the correct domain appears in WordPress settings.
Keep the backup and scratchpad until you have confirmed the site is stable. Note the final working database name, username, and host privately, but do not store the password in an unsecured document. If the site is live for customers, also check key forms, contact details, and any time-sensitive pages.
Quick Recovery Checklist
Record the exact error and timestamp; confirm which parts of the site are affected. Back up the live files and database before making changes. Verify DB_NAME, DB_USER, and DB_PASSWORD against the hosting panel. Create or assign a new database user if needed, with appropriate permissions. Confirm the database was imported into the database WordPress actually uses. Check the host’s required DB_HOST value instead of assuming it is localhost. Test the site after each change and keep a clear rollback copy. If the settings match, send hosting support the exact error, timestamp, and checks completed.In most post-migration cases, the cause is a mismatch between live database credentials, an incomplete import, or an incorrect host value. Careful checks—and a backup before edits—can restore the connection without risking the site’s content.