WordPress Address and Site Address: the two settings that can lock you out, and the wp-config fix

What do the WordPress Address and Site Address settings do?

When you change the WordPress site URL, you are editing two settings that tell WordPress where it lives. Both sit under Settings, General, and the WordPress handbook says they “control where WordPress is located” and are “used throughout the WordPress code”.

Site Address (URL) is the address you want people to type to reach your site. WordPress Address (URL) is where the core files are, such as wp-admin and wp-includes. On most sites the two are the same.

The handbook also describes how people end up stuck. They “change one or both and discover that their site no longer works properly”, which can leave them “with no easily discoverable way to correct the problem.”

Why can’t you log in after changing the site URL?

Because the login page now lives at the address you typed. On a WordPress 7.1 copy of our test store, on 11 Oct 2026, we typed an address that does not exist into each field in turn, the way a typo would.

Wrong Site Address. Save worked and the dashboard stayed open. The home page still loaded, but 16 of its links (Shop, Cart, Checkout, the posts) now pointed at the dead domain. A visitor clicking anything would hit an error page.

Wrong WordPress Address. This is the lockout. The moment we clicked Save Changes, Chrome showed “This site can’t be reached” with DNS_PROBE_FINISHED_NXDOMAIN. Opening /wp-admin/ redirected to the login page on the dead domain, and the login form on the real address posted to the dead domain too. There was no screen left to undo it from.

How do you get back in with wp-config.php?

Add two lines to wp-config.php. It sits in your WordPress folder, or one folder above it. Put them above the line that says “That’s all, stop editing”:

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

Use your own address. The handbook says it “should include the https:// part and should not have a slash / at the end”. WP_HOME sets the Site Address and WP_SITEURL the WordPress Address. Both override what the database holds.

Open it in your host’s file manager or over SFTP, and keep a copy first.

On our lab, the next request to /wp-admin/ redirected to the right login page, the form posted to the right address, and we logged in.

Why does the wp-config fix not finish the job?

Because the constants hide the problem rather than repair it. The handbook says so plainly: “This is not necessarily the best fix, it’s just hard-coding the values into the site itself.”

We checked the database after logging back in. The siteurl row still held the dead address. The wp-config.php page in the handbook warns about exactly this: the constant “will not change the database stored value”, and the URL “will revert to the old database value if this line is ever removed”.

We removed the two lines to test it. The next visit to /wp-admin/ sent us straight back to the dead domain.

Why are the address fields greyed out now?

That is the constants at work. With WP_HOME and WP_SITEURL defined, Settings, General shows both fields greyed out with your wp-config values in them. WordPress’s documentation for that screen says you “will not be able to make changes to it from the WordPress administration screen”.

Some setups define these constants for you. The WordPress Playground we test on does, so its fields were greyed out before we touched anything.

How do you fix the stored value for good?

Pick one of the other methods in the same handbook section, then decide whether the constants stay:

1. phpMyAdmin. Back up the database first. In the wp_options table, edit the siteurl and home rows. Your table prefix may not be wp_.
2. RELOCATE. Add define('RELOCATE',true); to wp-config.php and load wp-login.php at the correct address. WordPress then saves the address you used as siteurl. Remove the line straight after: the handbook says leaving it in place “is insecure”, because in some setups it lets an attacker change your site URL.
3. functions.php. Two update_option() lines in the active theme’s functions.php. Load the login or admin page “a couple of times”, then remove them. The handbook says: “Do not leave this code in the functions.php file.”

On multisite, the handbook says to edit the database by hand.

What should you check before anyone edits these fields?

Check that you, or your host, can open wp-config.php today. That file is the way back.

Changes like this are part of our WordPress maintenance plan: we make them on a copy first.

If your site is locked out now, tell us the address you typed and we will reply with the steps for your host.