How to Fix a Wrong WordPress Site URL with phpMyAdmin

If WordPress redirects to the wrong domain or you cannot open wp-admin after changing the site address, correct the home and siteurl options directly in phpMyAdmin. Back up the database first so you can reverse an incorrect edit.

Confirm the correct URL

Decide exactly which address the site should use, including the protocol and any subdirectory:

https://example.com
https://example.com/blog

Do not add a trailing slash.

WordPress uses two related settings:

• home is the public address visitors use to reach the site.
• siteurl is the location of the WordPress core files.

They are usually identical. They can differ when WordPress is installed in a subdirectory. The WordPress migration documentation explains the distinction.

Make sure the chosen domain points to this hosting account. Use https:// only if HTTPS is configured for the domain.

Back up the database

Open phpMyAdmin from your hosting control panel, select the WordPress database, and use Export to download a database backup.

Keep this file until the site and admin area work correctly. Direct database edits take effect immediately and do not have an undo button.

If you are unsure which database belongs to the site, inspect wp-config.php and find the DB_NAME value:

define( 'DB_NAME', 'database_name' );

The same file also contains the table prefix:

$table_prefix = 'wp_';

Your prefix may be different.

Change the WordPress URL in phpMyAdmin

1. Select the WordPress database in phpMyAdmin.
2. Open the table ending in _options, commonly wp_options.
3. Use Search or Filter rows to find the row whose option_name is siteurl.
4. Edit its option_value.
5. Enter the correct URL and save the row.
6. Find the row whose option_name is home.
7. Edit it to the correct URL and save it.

Change only the option_value fields. Do not rename the options or modify their IDs.

For a standard installation, the corrected rows might look like this:

| option_name | option_value | |—|—| | siteurl | https://example.com | | home | https://example.com |

This follows WordPress’s documented procedure for changing the URL directly in the database.

Test the site

Open the corrected address in a private browser window, then test:

https://example.com/
https://example.com/wp-admin/

If both pages load, sign in and check Settings > General. Confirm that WordPress Address (URL) and Site Address (URL) contain the intended values.

Clear any WordPress, hosting, proxy, or CDN cache if requests still redirect to the old address.

If the database change has no effect

Open wp-config.php and look for these constants:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

These constants override the values stored in the database. Correct them if they contain the wrong address, or remove them if you want WordPress to use the phpMyAdmin values. Back up wp-config.php before editing it.

Also check hosting-panel redirects, CDN redirect rules, and .htaccess for rules that force the old domain.

If you have command-line access, WP-CLI’s option commands display the stored home and siteurl option values without changing them:

wp option get home
wp option get siteurl

These values may differ from the site’s actual behavior when WP_HOME or WP_SITEURL is defined in wp-config.php, or when server, hosting, proxy, or CDN rules force a redirect.

Do not replace every old URL for this repair

Correcting home and siteurl is enough when an accidental settings change locked you out. Do not run a database-wide replacement just to restore access.

A full domain migration is different because old URLs may also appear in post content, widgets, plugin settings, and serialized data. Avoid manually replacing values throughout phpMyAdmin, and do not change the guid column in the posts table.

Multisite requires a different repair

These steps are intended for a standard single-site installation. WordPress Multisite stores domain and path information in additional network and site tables, so changing only two rows may leave the network inconsistent. Restore the database backup and use a Multisite-specific migration procedure if the installation is a network.