iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To change a WordPress address in MySQL, update the siteurl and home rows in the site’s options table, then replace the old URL in posts, metadata, and other stored content. The rows are the control point for WordPress itself; they are not a complete content migration.
The safest general workflow is to back up the database, record the current values, update the two options with WP-CLI, preview a serialized-data-safe search-and-replace, run it, and then test both the public site and the administrator login. Use direct SQL only when you understand that it changes the two address rows and does not repair old links elsewhere.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →
What the two WordPress URL settings control
WordPress stores its primary addresses in the wp_options table. The wp_ portion is only the default table prefix; an installation may use a different prefix, so identify the real table name before running SQL.
| Option | Purpose | Typical effect of changing it |
|---|---|---|
siteurl |
The address where the WordPress core installation is located. | Controls core-generated paths, update requests, administration URLs, and other internal references. |
home |
The public address visitors use for the site. | Controls the front-end address WordPress presents to visitors and generates for many links. |
For a normal move from one domain to another, both values usually become the new canonical address. If WordPress is installed in a subdirectory, the two values can legitimately differ: siteurl may include the installation directory while home points to the public root. Do not make them identical merely because they look similar; preserve the layout your installation is designed to use.
#1 Best Overall
Changing these rows does not rewrite URLs embedded in post content, featured-image metadata, widget settings, theme options, page-builder data, or other tables. A separate search-and-replace operation is required for those values.
Choose the method before touching the database
| Method | What it changes | Serialized-data safety | Access required | Best use |
|---|---|---|---|---|
WP-CLI option updates plus search-replace |
The two options and, separately, matching URLs throughout WordPress tables. | WP-CLI recalculates PHP serialized-string lengths. | Shell access and a working WP-CLI installation. | Preferred for a complete migration or domain change. |
| SQL update on the options table | Only the siteurl and home rows. |
Safe for these plain URL values, but it does not process serialized content elsewhere. | A database client such as MySQL access. | Emergency recovery, a controlled address-only change, or a site where no shell access exists. |
| Raw SQL replacement across all tables | Potentially every matching text value in the database. | Unsafe for PHP serialized values because byte-length prefixes are not recalculated. | Database access and a custom script or queries. | Do not use as a general migration method. |
WP_HOME and WP_SITEURL in wp-config.php |
Overrides the database values at runtime without changing them. | Does not migrate stored content. | File access to wp-config.php. |
Troubleshooting, temporarily pinning an address, or regaining control when stored values are wrong. |
The most important distinction is scope. An options-table update changes what WordPress believes its addresses are. A content search-and-replace changes old links stored throughout the site. A successful domain migration often needs both.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPrepare a safe change
1. Make a restorable database backup
Take a fresh database backup and confirm that you can restore it before editing anything. Keep the backup from before the URL change separate from later backups so it is easy to identify. If the site contains frequently edited content, put it in a maintenance window or otherwise prevent writes during the migration so new data does not continue to receive the old address.
2. Write down the exact old and new addresses
Record the current values and decide the exact form of the replacement, including protocol and any installation path. Treat http and https as different strings. Likewise, a hostname with and without www is different. Use one consistent spelling in the commands; changing only part of a URL can leave mixed links behind.
3. Confirm the table prefix and WordPress location
Look at the table_prefix setting in wp-config.php or inspect the database table list. Replace the example name wp_options in SQL with the actual prefixed options table. Run WP-CLI from the WordPress installation directory, or provide the correct path with WP-CLI’s normal path option if your site is elsewhere.
4. Check for URL constants before editing rows
Open wp-config.php and look for definitions of WP_HOME or WP_SITEURL. These constants override the corresponding database values. If they remain set to the old address, changing MySQL can appear to have no effect. Decide whether they are intentional; do not remove a deliberate configuration without understanding why it was added.
Preferred procedure: WP-CLI and a serialized-safe replacement
Step 1: Record the existing values
From the WordPress directory, run:
wp option get siteurl
wp option get homeSave this output with your backup. It gives you the exact old strings for the replacement and a reference for rollback.
Step 2: Update the two address options
Replace the example new address with the address you selected:
wp option update siteurl 'https://new.example.com'
wp option update home 'https://new.example.com'If the installation belongs in a subdirectory, include that path where it belongs rather than copying the same value into both options automatically. Confirm the result:
wp option get siteurl
wp option get homeStep 3: Preview the content replacement
Use a dry run with the old and new strings:
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --dry-runThe dry run reports what would change without saving it. Review the table and column counts, and stop if the old value or the proposed new value is wrong. The --skip-columns=guid form is used in the WP-CLI migration and reference examples; the documentation does not establish a broader reason for that exclusion, so do not infer one from the flag alone.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsStep 4: Run the live replacement
When the preview is correct, run the same command without --dry-run:
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guidWP-CLI understands WordPress tables and handles PHP serialized values while replacing the URL. That handling is the reason to prefer it over a blanket SQL text replacement: serialized strings contain byte-length prefixes, and changing their text without recalculating those lengths can break widgets, theme settings, and page-builder layouts.
Step 5: Decide whether --all-tables is necessary
By default, WP-CLI searches tables registered with WordPress’s database object. Use --all-tables only when you have a specific reason to include tables outside that set, such as a plugin or application table that stores the old URL. Preview that broader scope first. A wider search can alter unrelated data, so do not add the flag simply because it is available.
Step 6: Flush caches and test
Flush WordPress, object, page, proxy, and browser caches that may still serve the old address. Open the public home page, several internal links, an image or other media URL, and the administrator login. Confirm that the browser remains on the new host and that links do not alternate between old and new domains.
Recommended Free Tools
SQL-only procedure for changing the two rows
Use this route when you have database access but cannot run WP-CLI, or when you intentionally need to change only the address settings. It does not update old URLs stored in content.
Rank #4
1. Inspect the current rows
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');Change wp_options to the table name that matches your site’s prefix. Check the returned values before writing anything.
2. Update both values in one controlled operation
UPDATE wp_options
SET option_value = 'https://new.example.com'
WHERE option_name IN ('siteurl', 'home');This statement assumes both options should have the same value. If your installation intentionally uses different public and core addresses, update each option separately with its correct value instead of using one value for both.
3. Verify immediately
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');If your database workflow supports transactions, verify the result before committing. Keep the pre-change backup available even after the query succeeds.
4. Plan the content migration separately
After an SQL-only update, old absolute URLs can remain in posts, metadata, widget settings, theme options, and builder data. Use WP-CLI’s dry-run and live search-replace procedure when shell access becomes available. Do not attempt to compensate with an unqualified SQL replacement across every table; serialized values are the failure point.
Using wp-config.php constants for troubleshooting
Adding these definitions makes WordPress use the specified addresses at runtime:
define( 'WP_HOME', 'https://new.example.com' );
define( 'WP_SITEURL', 'https://new.example.com' );The constants override the home and siteurl rows; they do not rewrite those rows or migrate links saved elsewhere. Removing the definitions makes WordPress use the stored database values again. This makes the technique useful for testing which address WordPress should serve or for temporarily pinning a known-good URL, but it is not a substitute for a database migration.
If a redirect loop continues after changing the rows, check for conflicting constant values in wp-config.php and for cache layers serving an earlier response. The WordPress login troubleshooting guidance specifically calls out conflicting WP_HOME and WP_SITEURL definitions as a cause worth checking.
WordPress documentation also describes a RELOCATE constant that can change the stored siteurl. If you use that recovery technique, remove the constant after the address has been corrected; leaving it in place can be insecure in some configurations.
Troubleshooting by symptom
The front end still opens at the old address
- Run
wp option get siteurlandwp option get homeagain, or repeat the SQLSELECT, to confirm which values are actually stored. - Inspect
wp-config.phpforWP_HOMEandWP_SITEURL; constants take precedence over MySQL. - Flush page, object, proxy, and browser caches after correcting the source value.
- Check that your web-server or reverse-proxy redirect is not deliberately sending traffic back to the old host.
The site redirects repeatedly between two addresses
- Compare the protocol, hostname, and path in both options; a mismatch can make one layer redirect to another.
- Look for old or conflicting URL constants in
wp-config.php. - Temporarily test with the intended constants only if you need to establish a known runtime address, then remove temporary definitions once the database and content are correct.
Images, widgets, or layouts are broken
This usually indicates that the two options were changed but embedded URLs were not, or that a raw SQL replacement damaged serialized data. Stop making additional blanket replacements. Restore the pre-change backup if serialized settings are corrupted, then repeat the migration with WP-CLI’s serialized-aware search-replace.
The administrator login fails after the change
- Verify both options and the constants, paying attention to
https,www, and subdirectory spelling. - Clear cookies for the old and new hosts, then open the login URL on the intended host.
- If the database values are wrong, use a controlled SQL correction or temporary constants to regain access, then complete the content replacement and remove temporary overrides.
Some old URLs remain
A dry run can show whether matches remain in the tables WP-CLI searches. If the remaining data belongs to a table outside WordPress’s registered set, identify that table before considering --all-tables. Inspect the match rather than replacing every occurrence blindly; an old URL may be an intentional historical value or an identifier that should not be changed.
The replacement command reports unexpected counts
Stop and inspect the dry-run output. Common causes include using the wrong protocol, omitting a subdirectory, running WP-CLI from the wrong installation, or choosing --all-tables unnecessarily. Re-run the preview with the exact current value returned by wp option get and with the correct WordPress path.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Post-change verification checklist
- The database backup from immediately before the change is retained.
siteurlandhomecontain the intended values in the correctly prefixed options table.- No unintended
WP_HOMEorWP_SITEURLconstants override those values. - The public home page, representative internal pages, media, and administrator login load on the intended address.
- The old URL no longer appears where it should have been migrated, based on a reviewed dry-run result.
- Caches have been flushed, and a fresh browser session does not reveal redirects to the old host.
- Any temporary
RELOCATEor URL constants have been removed after recovery.
WP-CLI and WordPress command names can change with later releases. Before running a production migration, check the help output installed on the site, especially for search-replace options and table-scope behavior.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
