How to Change Your WordPress URL in the Database (Safely)

You changed your domain, switched from HTTP to HTTPS, or moved from localhost to a live host — and now WordPress is half-broken. Maybe the admin redirects you in a loop, the homepage loads but every internal link points to the old address, or images 404 because their URLs still say http://old-domain.com. The fix usually starts with one phrase people search for in a panic: change WordPress URL in the database.

This guide explains the safe way to do it. We'll cover the two URL settings WordPress actually uses, the normal ways to change them, when you're forced into the database, and — most importantly — why a naive SQL UPDATE can corrupt your site, and how to avoid it.

First: siteurl vs home — they're not the same

WordPress stores two URLs in the wp_options table, and confusing them causes most "I changed it and now it's worse" situations.

WordPress Address (siteurl) — where your WordPress core files live. This is the URL WordPress uses to load admin, includes, and core assets. In Settings → General it's labelled WordPress Address (URL).
Site Address (home) — the address visitors type to reach your site. This is your public homepage URL. In Settings → General it's labelled Site Address (URL).

For most installs these are identical (https://example.com). They differ only when WordPress lives in a subdirectory but is served from the root — e.g. core files in /wp/ (siteurl = https://example.com/wp) while visitors use https://example.com (home). If you set them wrong, you get redirect loops or a dashboard you can't reach. So before you change anything, know which value you actually need to change.

The normal ways to change your WordPress URL

If you can still log in, you usually don't need to touch the database at all. Try these first, in order.

1. Settings → General (the easy case)

Go to Settings → General, update WordPress Address (URL) and Site Address (URL), and save. This is the right method when you're only switching protocol on the same domain (HTTP → HTTPS) or making a small correction, and you can still reach the admin.

It does not rewrite URLs that are hardcoded inside your posts, pages, widgets, or theme options — more on that below. It only updates the two wp_options rows.

2. wp-config.php constants (when settings are greyed out)

If those two fields are greyed out, someone has hardcoded them. Add (or edit) these lines in wp-config.php, above the /* That's all, stop editing! */ line:

define( 'WP_HOME', 'https://new-domain.com' );
define( 'WP_SITEURL', 'https://new-domain.com' );

These constants override the database values at runtime. They're handy to break a redirect loop and regain admin access — but they're a runtime override, not a real database change. The old values still sit in wp_options, and every hardcoded URL across your content is untouched.

3. WP-CLI (clean, if you have shell access)

If you can run WP-CLI, this is the cleanest non-plugin route because it understands serialized data:

wp option update home 'https://new-domain.com'
wp option update siteurl 'https://new-domain.com'
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --dry-run

wp search-replace is serialization-aware (the --dry-run flag shows what would change before you commit). The catch: many people on shared hosting don't have shell access, and a typo in --all-tables with no rollback is a long night. Which is exactly the scenario where you end up in the database directly.

When you're forced into the database

You go straight to the database when you've lost the front door:

The admin redirects in an endless loop after a domain move, so Settings → General is unreachable.
The login page itself points to the old domain and won't load.
You can't edit wp-config.php (locked-down host, no SFTP), or constants didn't help.
You're migrating a full site and need every old URL replaced, not just the two settings rows.

In phpMyAdmin or Adminer, the minimum fix is to update two rows in wp_options:

UPDATE wp_options SET option_value = 'https://new-domain.com' WHERE option_name = 'home';
UPDATE wp_options SET option_value = 'https://new-domain.com' WHERE option_name = 'siteurl';

(Your table prefix may not be wp_.) This gets you back into the admin. But it does not fix your content — and that's where most people get burned.

Why editing wp_options alone isn't enough

Your old URL isn't only in wp_options. After any real install it's baked into content all over the database:

wp_posts — every internal link, embedded image (<img src="http://old-domain.com/...">), and absolute URL you ever pasted into a post or page.
wp_postmeta — page-builder content (Elementor, Divi, Beaver Builder), custom fields, attachment metadata, and more.
wp_options — widget contents, theme settings, and plugin configuration, much of it serialized.

So even after fixing siteurl and home, your site is littered with the old domain. The obvious next move — a site-wide UPDATE ... REPLACE() across every table — is also the move that quietly corrupts your site.

The serialized-data trap

WordPress stores a lot of settings as serialized PHP arrays, which embed the length of each string. A serialized value looks like this:

s:21:"https://old-domain.com";

That 21 is the character count of https://old-domain.com. If you run a blind SQL find-and-replace and change it to https://new-domain.com (which is shorter), the string is now 21 characters but the header still says 21... or the length no longer matches at all. PHP can't unserialize a value whose declared length is wrong, so the whole option silently fails to load: a widget vanishes, a page builder shows a blank layout, or a plugin reverts to defaults.

This is the single biggest reason "I did a search and replace in SQL and my site broke." A raw REPLACE() in phpMyAdmin does not recalculate serialized string lengths. You need a tool that unserializes each value, swaps the URL, and re-serializes with corrected lengths. We go deeper on this in How to update serialized data effectively and Search and replace serialized data safely.

The safe way: a serialization-aware search and replace

The reliable approach is a tool that handles serialization for you, lets you preview, and lets you undo. That's exactly what Update URLs is built for. Here's the workflow.

1. Back up first — always

Before any database write, take a backup. Update URLs has a built-in one-click database backup & restore, so you don't need a separate plugin or a manual mysqldump — see One-click database import and export. If anything looks wrong afterward, you restore in one click. This step is non-negotiable for database changes.

2. Enter the old and new URL

Search for your old URL and set the replacement — typically https://old-domain.com → https://new-domain.com. Keep both consistent on protocol (https:// to https://) and on trailing slashes so you don't half-replace. The general method is covered in How to do search and replace text in WordPress.

3. Pick the tables (don't sledgehammer everything)

You rarely need every table. Use the table picker to target the ones that hold URLs — wp_posts, wp_postmeta, and wp_options — and leave audit logs, session tables, or large transient stores alone. Selective replacement is faster and lowers blast radius. See How to run search and replace on selected tables.

4. Dry run before you commit

Run a dry run first. It reports exactly how many rows in which tables would change — without writing anything. This is your chance to catch a mistake (wrong protocol, a stray match in a table you didn't mean to touch) before it happens. Walkthrough: How to do a dry run before search and replace.

5. Apply

Happy with the dry-run preview? Apply it. Because the engine is serialization-aware, those s:21:"..." values get unserialized, swapped, and re-serialized with correct lengths — so widgets, page-builder layouts, and plugin settings survive the move intact.

6. Undo if it's wrong

This is the part raw SQL and most search-replace tools don't give you: one-click Undo / Rollback. If you replaced the wrong string or picked the wrong tables, you roll the change back from the history — no restoring a full backup, no redoing your last hour of work. Update URLs also keeps a history of past operations and lets you save profiles for moves you repeat (like staging → production). Details: Undo a search and replace in WordPress.

Note on the GUID column: don't bulk-rewrite post.guid. It's a permanent identifier for feed readers, not a live URL, and changing it can mark old posts as "new" in feeds. See What is GUID and how to replace before you touch it.

If you're moving the whole site to a different domain, the end-to-end process — DNS, files, database, and the URL replacement above — is in Move WordPress to a new domain. For the broader theory behind doing any of this safely, see the pillar guide: WordPress search and replace: the safe guide. If something still looks off after a replace, start with troubleshooting.

Conclusion

Changing your WordPress URL in the database is straightforward once you separate two things: getting back into the admin, and fixing your content. Updating siteurl and home in wp_options (or via wp-config.php constants) gets you in. But the old URL is also hardcoded across wp_posts, wp_postmeta, and serialized wp_options values — and a blind SQL REPLACE() corrupts those serialized values.

The safe path is always the same: back up, search the old URL, set the new one, pick the relevant tables, dry-run, apply, and keep an Undo in your pocket. A serialization-aware tool like Update URLs does that for you and lets you roll back in one click if something looks off — which, when you're rewriting a live database, is the feature you'll be glad you had.

FAQs

What's the difference between siteurl and home?

siteurl (WordPress Address) is where your core WordPress files live; home (Site Address) is the public URL visitors use. They're usually identical, and only differ when WordPress is installed in a subdirectory but served from the root. Setting them inconsistently causes redirect loops.

Can I just edit wp_options directly with SQL?

Yes for the two rows siteurl and home — that's safe and gets you back into admin. But do not run a site-wide SQL REPLACE() to fix the rest of your content: it breaks serialized data. Use a serialization-aware tool for everything beyond those two rows.

Why does a SQL search and replace break my site?

WordPress stores many settings as serialized PHP arrays that include each string's character length. A raw SQL replace changes the text but not the stored length, so PHP can't unserialize the value and the option silently fails — widgets, page-builder layouts, and plugin settings disappear. A serialization-aware replace recalculates those lengths.

I'm locked out of admin after a domain move — what now?

Open phpMyAdmin (or Adminer) and update the siteurl and home rows in wp_options to your new URL, or add WP_HOME and WP_SITEURL constants in wp-config.php. That restores admin access. Then run a proper, serialization-aware search and replace to fix the hardcoded URLs in your content.

Can I undo a URL change if I get it wrong?

With raw SQL, only by restoring a backup. With Update URLs, yes — every replace is logged and reversible with one-click Undo / Rollback, so you don't have to restore the whole database to recover from one bad replace.