Setting the WordPress Site and Home URLs

These two constants outrank the database, which makes them both the recovery tool and the trap. WP_SITEURL tells WordPress where its files live. WP_HOME is the address visitors type. Defining them in wp-config.php overrides whatever is stored in the options table and greys out the fields in Settings, because editing something that is being ignored would be misleading.

The two values

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

On the overwhelming majority of sites they are identical. They differ in exactly one arrangement: WordPress installed in a subdirectory but served from the root.

Two formatting rules matter. No trailing slash, because WordPress appends paths and a double slash breaks some of them. And include the scheme — a value starting with // or with no scheme at all produces links that work on one protocol and fail on the other.

Using them to recover a locked-out site

This is where the constants earn their reputation. A site whose stored URL is wrong is unreachable in a specific and frustrating way: the login page redirects to the wrong domain, so you cannot log in to fix the setting that is causing the redirect.

Because wp-config.php is a file, it does not need a working login. Adding both constants with the correct values makes the site reachable immediately, and the admin becomes usable again. That is the same class of problem as a login redirect loop, and the same fix applies when the loop is caused by an address mismatch.

Once the site is reachable, there is a choice: leave the constants in place, or set the database values through Settings and remove them. Leaving them is the more predictable option for a site with any deployment process, because the address then travels with the code rather than with a database that gets copied between environments.

What they do not do

This is where the recovery tool starts creating new problems:

• They do not rewrite content. An image inserted with an absolute URL still points at the old domain. A link written into a post still points at the old domain. The constants change where WordPress thinks it is, not what editors typed.
• They do not move files. Changing WP_SITEURL does not relocate core; it tells WordPress where to expect it. Pointing it somewhere the files are not produces a site with no stylesheets, because every asset URL is built from it.
• They do not update the options table. Remove the constants later and the site reverts to whatever was stored, which may be the broken value you were working around.

Content URLs need a search and replace across the database, handled in a way that understands serialised data — a plain SQL replace corrupts serialised strings by leaving their length prefixes wrong. That is the same operation that makes a migration to a staging site safe.

The mixed content case

Moving a site to HTTPS and setting these constants to https:// while content still contains http:// references produces a page served securely that loads insecure resources. Browsers block or flag those, and the padlock disappears.

The constants are a necessary part of that migration and not a sufficient one. The rest is the content replace above, and the symptoms if it is skipped are covered in fixing mixed content warnings and the not secure warning.

Getting them wrong

A wrong value here takes the site down more completely than most mistakes, because every URL WordPress generates is built from it. The recovery is the same file you broke: edit wp-config.php, correct the value or remove the lines, and reload.

That is worth remembering before making the change, because a site pointing at a domain you do not control cannot be fixed from the dashboard — the dashboard is at the wrong address too.

Verify on four surfaces

Load the front page, load the admin, view source and confirm asset URLs use the expected domain, and open a post to confirm links behave. Then check Settings and confirm the fields are greyed out, which is how you know the constants are being read rather than silently ignored because they sit below the stop-editing comment.

If pages load but permalinks 404, the address is now right and the rewrite rules are stale, which is a separate repair covered in permalinks not working.