Change Your WordPress Domain Without Breaking Anything

The first time I moved a WordPress site to a new domain, I did the “obvious” thing: a big search-and-replace query straight on the database. Ten minutes later the homepage loaded fine and every Elementor page was a wall of broken boxes. I’d corrupted the serialized data—and spent the evening restoring a backup I was lucky to have. A domain change is one of those jobs where the naive way quietly destroys your site and the right way takes about a minute. Here’s the right way.

The essentials

• Your domain lives in thousands of database rows, not just the siteurl and home options you see in Settings.
• Page builders (Elementor, Divi…) and WooCommerce store URLs as serialized data; a raw SQL replace corrupts it by breaking the stored character lengths.
• The Domain Changer module unserializes, replaces and re-serializes correctly, catching https://, http:// and protocol-relative //domain references.
• It previews the exact number of rows it will change, table by table, and backs up your database first (default on).
• If anything looks wrong, one click undoes the entire change—and it never rewrites the post GUID, exactly as WordPress recommends.

Why won’t a simple search-and-replace work?

Because most of your domain references aren’t plain text. Plugins like Elementor, Divi and WooCommerce store their data serialized—a PHP format where every value is prefixed with its exact character count, like s:23:"https://example.com/page". That 23 is the length of the string that follows.

Now change example.com to mynewsite.org with a raw SQL query. The text gets longer, but the stored 23 doesn’t move. PHP tries to read 23 characters, lands in the middle of your new URL, and gives up: the value is now unreadable. In practice that means shattered page-builder layouts, empty widgets, and plugin settings reset to nothing. This is the single reason domain migrations go wrong, and it’s why you need a tool that understands serialized data instead of treating the database as a text file.

Here’s everywhere your old domain is actually hiding—and what breaks if a reference is left behind:

Where the domain hides	What’s stored there	If it’s left unchanged
siteurl and home	The two options on Settings → General	Nothing—these are the only rows the Settings screen updates
Internal links and images	Your post and page content	Links and media keep pointing at the old domain and 404
Page-builder layouts	Serialized post meta (Elementor, Divi…)	A raw replace breaks the stored length and shatters the layout
Widget and plugin settings	Serialized plugin options and widget data	Empty widgets and settings reset to nothing
Protocol-relative URLs	The //domain references themes often use	Assets stay pinned to the old host
Post GUID	The guid column on every post	Leave it alone—rewriting it makes feed readers show every post as new

When would you need to change your domain?

The trigger is almost always one of these:

• Going live from a staging or development URL to production.
• Rebranding to a new domain name.
• Moving from a subdomain (blog.example.com) to the root domain, or the reverse.
• Migrating from localhost to a real server.

Switching plain HTTP to HTTPS is a related but different job—the HTTPS Redirect module handles that more cleanly than a full domain rewrite. And if you’re changing the domain, remember that old inbound links to the previous domain should get 301 redirects so you don’t lose their SEO.

How do you change a WordPress domain safely, step by step?

Activate the Domain Changer module in Blaminhor Essentials. Instead of a blind query, it walks every database table, unserializes anything that needs it, replaces the domain, recalculates the lengths, and re-serializes—so nothing corrupts.

Current domain detected for you, new domain in one field, and a preview that counts every row before a single one changes.

Step 1 — Back up first (it’s automatic)

With “backup before change” enabled—the default—the module writes a full SQL dump of your database before touching anything, and hooks into the Backup module if you have it active so the archive lands in the same place as your other backups. This is your safety net, and it’s on unless you deliberately turn it off.

Step 2 — Enter the new domain

The current domain is detected automatically from your site URL. You type the new one—without http:// or https://, just mynewsite.com. The module handles all three reference forms behind the scenes: https://, http://, and the protocol-relative //mynewsite.com that themes often use.

Step 3 — Preview the exact changes

Click preview and the module scans every table, reporting how many rows will change in each one—“142 rows in postmeta,” “38 rows in options,” and so on, with a running total. Nothing is written yet. You see the full blast radius before you commit, which is exactly the confidence a raw SQL query never gives you.

Step 4 — Apply

One click runs the replacement across the whole database: it updates the siteurl and home options, then every other table—post content, meta, widgets, plugin settings—with serialized data handled correctly throughout. Because your admin URL itself just changed, the module redirects you to the new domain’s dashboard when it’s done, so you’re not left staring at a dead page.

What if something still looks wrong?

This is where the module goes beyond “hope your backup works.” After a change, it stores the migration in its history and lights up an “Undo this change” button. Click it and the module replays the replacement in reverse—swapping the two domains back—and clears the history so it can’t fire twice. It’s a genuine one-level undo, not a manual restore.

So you have two nets, not one: the automatic pre-change backup for a full rollback, and the built-in undo for the common case of “that wasn’t right, put it back.” On a multisite install the backups are even kept per-site, so undoing one site’s move doesn’t touch the others.

The safe way to migrate is the fast way

Domain changes have an outsized reputation for pain, and it’s all because of that one serialization trap. Handle it correctly and the whole thing takes under a minute: preview, confirm, done—with a backup behind you and an undo button in front of you.

Once you’re on the new domain, set up 301 redirects from the old URLs to preserve your search rankings, and if you haven’t yet, force HTTPS site-wide to finish the move cleanly.

Domain Changer is one of the 20+ tools in Blaminhor Essentials—free and open-source on WordPress.org.

Download Blaminhor Essentials

– blaminhor