How to Change the WordPress URL in the Database (phpMyAdmin, SQL and WP-CLI)

Applies to: WordPress 7.1.2 with MariaDB 11.8 and WP-CLI 2.12.0; tested in Docker

WordPress keeps its address in two rows of the wp_options table: siteurl (where the WordPress files are) and home (the address visitors use). To change the URL in the database, update both rows, then replace the old address inside your content with WP-CLI’s search-replace. This is the way back in when a wrong URL under Settings > General has locked you out of wp-admin.

Before you start

1. Back up the database. With WP-CLI: wp db export backup.sql; in cPanel, export it in phpMyAdmin or follow backing up a database with WP-CLI.
2. Find the table prefix. It isn’t always wp_. Look for $table_prefix in wp-config.php and use your prefix in the commands below, for example abc_options.

Option 1: change siteurl and home with SQL (phpMyAdmin or the mysql client)

Check the current values first:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

option_name	option_value
home	http://127.0.0.1:18088
siteurl	http://127.0.0.1:18088

Then set the new address, without a slash at the end:

UPDATE wp_options SET option_value = 'https://www.example.com'
WHERE option_name IN ('siteurl', 'home');

In phpMyAdmin you can run this on the SQL tab of your WordPress database, or open the wp_options table with Browse, click Edit on the siteurl row, change option_value and click Go, then do the same for home. Both rows are near the top of the table. If you are new to phpMyAdmin, see editing a database table in phpMyAdmin.

Option 2: change every URL with WP-CLI search-replace

Changing siteurl and home moves the site, but links and images inside posts, widgets and theme settings still point to the old address. Replace them all with one command, from the WordPress folder (install WP-CLI first if needed: how to install WP-CLI). Always start with a dry run:

$ wp search-replace 'http://127.0.0.1:18088' 'https://www.example.com' --skip-columns=guid --dry-run
Table	Column	Replacements	Type
...
wp_options	option_value	3	PHP
wp_posts	post_content	3	SQL
wp_users	user_url	1	SQL
Success: 7 replacements to be made.

If the numbers look right, run it again without --dry-run:

$ wp search-replace 'http://127.0.0.1:18088' 'https://www.example.com' --skip-columns=guid
Success: Made 7 replacements.

This one command also updates siteurl and home, so you don’t need Option 1 when you use it. --skip-columns=guid leaves post GUIDs alone: WordPress says “It is critical that you do NOT change the contents of this field”, because feed readers use it to recognise posts they have already shown.

Why not replace URLs with a plain SQL REPLACE()?

Themes and plugins often store settings as serialized PHP data, which records the length of every text value. We tested it with a setting that held a logo URL:

a:2:{s:4:"logo";s:50:"http://127.0.0.1:18088/wp-content/uploads/logo.png";s:1:"n";i:3;}

After an SQL REPLACE() to https://www.example.com, the URL was 51 characters long but still marked s:50. WordPress could no longer read the setting at all: wp option get reported Could not get 'k09_serial' option. Does it exist?. wp search-replace handled the same row correctly and wrote s:51. Use SQL only for the two rows in Option 1, and a serialization-aware tool for everything else.

Option 3: override the URL in wp-config.php

If you can’t reach the database, add these lines to wp-config.php above the line /* That's all, stop editing! Happy publishing. */:

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

They take priority over the database values: in our test, a site whose database still held a wrong URL loaded normally again once the two lines were in place. WordPress notes that you can’t edit the two addresses under Settings > General while these lines exist. With WP-CLI you can add them with wp config set WP_HOME 'https://www.example.com' --type=constant.

After the change

• Clear any caching plugin and your browser cache, then log in again at the new address.
• Once the database holds the new URL, WordPress redirects requests that arrive on the old address: in our test the home page answered with a 301 (X-Redirect-By: WordPress) and /wp-admin/ with a 302. If the new domain doesn’t point to the server yet, the site seems to vanish: put the old address back (Option 1, or Option 3 with the old URL) until DNS is ready.
• Images still broken? See correcting image links after a WordPress migration. Moving to a new server? Follow migrating WordPress to a new host.

Official documentation: Moving WordPress and changing the site URL and wp search-replace.