Change WordPress Site URL and Home Settings Safely

WordPress uses two related URL settings: home is the public site address, and siteurl is the address of the WordPress installation. They are often identical, but a site that serves its homepage from a different directory can legitimately use different values.

This guide covers a standard single-site WordPress installation. Multisite, domain-mapping systems and managed deployment configurations need their own migration procedure. Changing these two values alone does not move files, configure DNS, issue a certificate or replace every old URL stored in content.

Prepare a recovery path first

• Record the currently working addresses, including HTTPS versus HTTP, the hostname and any subdirectory.
• Back up the database and configuration privately, outside the public web directory, and confirm you can restore them.
• Keep SSH, SFTP or hosting File Manager access available. A mistaken URL can make the WordPress dashboard unreachable.
• Confirm that the intended hostname reaches the correct site and has a valid certificate before switching to its HTTPS URL.
• Check whether WP_HOME, WP_SITEURL, environment configuration or a management tool already controls the values.

Choose the correct pair of addresses

Setting	Dashboard label	Purpose
siteurl / WP_SITEURL	WordPress Address (URL)	URL where the WordPress installation is located.
home / WP_HOME	Site Address (URL)	URL visitors use for the public site.

For an installation and homepage both at the domain root, both values might be https://example.com. If WordPress files are in /wordpress but the homepage is intentionally served from the root, siteurl may include /wordpress while home does not. That layout also needs the appropriate entry-point and rewrite setup; changing the values is not the complete move.

Method 1: Use Settings when the dashboard is accessible

1. Sign in with an administrator account and open Settings > General.
2. Enter the intended WordPress Address and Site Address. Include the scheme and any required subdirectory, but no trailing slash.
3. Save, then open the site and login page at the intended addresses. You may need to sign in again.

If the fields are locked, inspect the configuration rather than repeatedly trying to save them. Constants in wp-config.php override these settings and can make the fields uneditable.

Method 2: Override the addresses in wp-config.php

This can restore access after a mistaken setting when you know the correct addresses. Edit the existing wp-config.php with a plain-text editor. Update existing definitions instead of defining the same constant twice. Put the definitions before WordPress is loaded by the wp-settings.php require statement, normally before the comment that says to stop editing.

Root installation example. Replace the example domain with your own verified address; these are PHP statements inside the existing PHP file, not shell commands:

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

Alternative example for a deliberately configured root homepage with WordPress core in a subdirectory. Use only the pair matching your installation:

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

These constants override the values WordPress uses; they do not rewrite the stored home and siteurl database rows. Removing the constants later exposes the stored values again. Decide whether the constants are permanent configuration or a temporary recovery measure, and reconcile the database values before removing a temporary override.

Do not replace the whole configuration file with these two lines, add a second opening PHP tag inside it, or copy the old article’s leading --- characters. Preserve the existing database settings and secrets. Keep a private rollback copy rather than leaving wp-config.php.bak publicly downloadable.

Method 3: Correct the two database values when necessary

If you use phpMyAdmin for recovery, identify the database used by this exact installation from its private configuration. The table prefix is configurable; the options table is not always named wp_options.

1. Confirm the backup and select the correct installation’s options table.
2. Locate the rows whose option_name values are exactly home and siteurl.
3. Edit only their option_value fields to the appropriate complete URLs.
4. Check for configuration overrides and clear the relevant persistent object cache through the site’s supported mechanism if necessary.
5. Test the intended site and administrator URLs before making any broader changes.

Do not run an unrestricted database-wide text replacement to accomplish this two-setting repair. Other data may be serialized, and a plain string replacement can corrupt its stored lengths.

Review old content URLs separately

A domain or path migration can leave old image links, builder settings and embedded URLs in the database. WP-CLI’s search-replace understands serialized values and supports a dry run. The following is a preview command for an authorized operator, not a command executed during this article review:

wp --path=/path/to/wordpress search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --dry-run

Replace the path and both URLs for the actual migration. Review the selected tables and reported matches before planning a write. The default table scope may not cover every plugin’s custom table; do not widen it to unrelated sites or databases without an inventory. Preserve post GUIDs during an ordinary move of the same site. A dry run does not prove that every application-specific setting, file or external integration is covered.

Avoid leaving emergency workarounds active

The older procedure suggested RELOCATE and edits to a theme file. WordPress warns that leaving RELOCATE enabled can allow site-URL changes by an attacker in some configurations. Do not use it as a permanent setting. A theme’s file is named functions.php, not function.php; repeatedly running update_option() from a theme is not the normal configuration method. Remove temporary recovery hooks after reconciling and verifying the intended settings.

Verify the change and retain rollback access

• Check the homepage, an inner post, media files and the login/dashboard using the intended scheme, hostname and path.
• Test forms, checkout or authentication flows relevant to your site, rather than stopping at a successful homepage response.
• Inspect redirect chains for loops and check for mixed-content failures or requests to the old hostname.
• Review CDN, page and object caches individually. Purging a cache does not repair an incorrect URL.
• If access breaks, restore the recorded configuration or the two previous values through the out-of-band access prepared earlier. Do not keep guessing URLs in a locked-out dashboard.

Review scope: The configuration examples were checked for PHP syntax and exact constant values in isolated processes. The settings, override behavior and dry-run command were checked against WordPress documentation. No live site’s URLs, DNS, database content or redirects were changed to test this tutorial, and no end-to-end migration is claimed.

References: General Settings, wp-config.php constants, WordPress migration and recovery guidance and WP-CLI search-replace. For a host transfer, see the InterServer migration guide.