WordPress stores its own address in the database, in two settings called siteurl and home. Almost everything the site outputs is built from those values: links, redirects, asset paths, the login form.
Which means getting them wrong does not produce a small cosmetic problem. It produces a site you cannot log in to.
What the two settings mean
WordPress Address (siteurl) is where the WordPress files live.
Site Address (home) is what visitors type to reach the site.
They are usually identical. They differ only when WordPress is installed in a subdirectory but serves the site at the root; a deliberate arrangement that most sites do not use.
If you are not doing that, set both to exactly the same value, including the protocol and the www or lack of it.
The safe way, when you can still log in
Go to Settings → General and change both fields.
WordPress logs you out immediately, because your session belongs to the old address. That is expected. Log in again at the new one.
Do this only when the new address already works. The DNS points here and, if you are moving to HTTPS, the certificate is installed. Changing the setting to an address that does not resolve locks you out of a working site.
When the fields are greyed out
They are not broken. Somebody defined them in wp-config.php:
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');
Constants win over database values, and WordPress disables the fields to tell you that editing them would do nothing.
Edit wp-config.php instead, or remove the lines to hand control back to the settings screen. Understanding wp-config.php explains the file.
When you are already locked out
This is the common emergency: the address was changed to something wrong, and the login page now redirects to an address that does not exist.
Add the constants above to wp-config.php with the correct address. They override the database immediately, without any database access, and the site comes back on the next request.
Log in, fix the values under Settings, then remove the constants so the settings screen works normally again.
This override is the single most useful thing to know about this subject, because it turns a locked-out site into a two-minute fix using nothing but File Manager.
Changing it in the database
If you prefer to fix the source directly, both values live in the wp_options table under option_name of siteurl and home.
In phpMyAdmin, open the table, find the two rows, and edit option_value. Take a database export first. There is more in managing databases with phpMyAdmin.
Note the table prefix. It is wp_ by default and often something else, so look at the actual table names rather than assuming.
The part that catches everyone: the rest of the database
Changing those two options changes what WordPress outputs. It does not change addresses stored inside your content.
Every image inserted into a post carries a full URL. Every internal link in a page body carries a full URL. Widgets, theme options and page-builder layouts store them too. After a domain change, all of those still point at the old domain. The site looks right in places and quietly loads images from an address that may no longer exist.
Fixing that requires a search-and-replace across the database, and it cannot be a plain SQL REPLACE. Page builders and theme options store their data serialised, and serialised strings record their own length; a plain replace changes the text without updating the length, and the field becomes unreadable. The symptom is settings that revert to defaults for no visible reason.
Use a tool that understands serialised data: a search-replace plugin, or WP-CLI's search-replace, which handles it correctly. Then delete the plugin, because a tool that can rewrite the whole database should not stay installed.
The specific case of moving to HTTPS
Switching the address from http:// to https:// is the same operation, with one extra consequence.
Content still holding http:// image URLs produces mixed-content warnings: the page is secure, its images are not, and the browser reports the padlock as broken. That is the same database-wide replacement described above. Fixing mixed content warnings walks through identifying which resources are at fault.
Do the certificate first, the site address second, the content replacement third, and the redirect last. In that order nothing is ever pointing at something that does not yet work.
After the change
Save permalinks again, because the rewrite rules reference the site address. Permalinks and .htaccess goes into it.
Then redirect the old address to the new one so existing links keep working, and check a handful of real pages rather than only the homepage. Images, internal links and the login page each fail in their own way, and the homepage is the least likely to show it.
Changing addresses across a whole site is a larger job than changing the site URL, and the mapping has to exist before launch. How to Plan Redirects for a WordPress Redesign explains building it.
Pin the addresses so nothing can change them again
Once the site is on the right address, the setting can be fixed in configuration so no plugin, no import and no accidental save moves it back.
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
Placed in the configuration file, these override whatever is stored in the database and the fields become read only in the administration screen.
The trade off is worth stating. A site pinned this way cannot be moved by changing a setting, so a later migration means editing the file first. That is a reasonable price on a production site and an annoyance on one you move regularly, which is the case for keeping a staging copy unpinned.
What still holds the old address after the replacement
A search and replace covers the database. Several things live outside it and keep the previous value.
grep -rn 'old-domain' wp-content/ --include='*.php' --include='*.json' --include='*.css' | head ls -la wp-content/uploads/*/ | head -3 grep -rn 'old-domain' .htaccess wp-config.php 2>/dev/null
The usual holdouts are hard coded addresses in a theme, a cached configuration file written by a plugin, rewrite rules, and any content delivery setting that names the old host.
Object caches and page caches also keep pages built with the previous address, so a site that still shows it after a correct replacement may simply be serving stored copies. Clear those before concluding the replacement failed.
Confirm from outside rather than from the dashboard
The administration screen reports the setting. What matters is what the site actually emits to a visitor.
curl -s https://example.com/ | grep -oE '(href|src)="https?://[^"]+"' | sed 's|.*//||; s|/.*||' | sort | uniq -c | sort -rn | head curl -s https://example.com/ | grep -o 'rel="canonical" href="[^"]*"' curl -sI https://example.com/wp-json/ | head -1
The first lists which hostnames the page references, which is the fastest way to see leftovers. The canonical should name the new address. The interface endpoint should answer rather than redirect, since a redirect there breaks anything that talks to the site programmatically.
Check a deep page and an image as well as the home page. Home pages are the ones people fix and the ones least likely to reveal the problem.