How to Move WordPress to a New Domain Without Breaking Links

You've decided to move WordPress to a new domain — a rebrand, a .io to .com move, or a project that finally earned its own name. The files copy over fine. The problem is everything inside your database still points at the old domain: post content, page builder data, widget options, image URLs, even settings buried in serialized arrays. Miss one and you get broken links, mixed content warnings, and images that 404.

This guide walks the full, safe process to change your domain in WordPress and update every reference at once — with a dry run before anything is written, and a one-click undo if a value comes out wrong.

Why a domain move needs a full search-and-replace

WordPress doesn't store your URLs in one tidy place. It hardcodes the absolute domain across your whole install:

Post and page content — every internal link and embedded image uses the full https://old-domain.com/... URL.
wp_options — siteurl, home, and dozens of theme and plugin settings.
wp_postmeta and wp_termmeta — page builders (Elementor, Divi, Beaver Builder), SEO plugins, and custom fields store full URLs here.
Serialized data — many of those options aren't plain strings. They're PHP arrays serialized into a single field with byte-length prefixes, so a naive find-and-replace corrupts them.

So changing siteurl and home under Settings → General is not enough. Those two values control where WordPress thinks it lives, but they don't touch the thousands of old-domain URLs already baked into your content. That's what a proper search-and-replace is for — and it's the core of a clean move. For the full conceptual background, see the pillar guide on a safe WordPress search and replace.

The safe end-to-end process

Here's the whole move at a glance. The detail follows.

Back up the database (and files) before you touch anything.
Move the files and database to the new domain — or do a fresh install and import the content.
Run Update URLs to replace old-domain.com with new-domain.com everywhere.
Dry run first to preview every match before writing.
Selectively apply the changes you've confirmed.
Verify the new site end to end.
Undo instantly if a replacement was wrong.

The key idea: you never run a blind, irreversible replace across a production database. You preview, you apply, and you keep a rollback in your pocket.

Step 1 — Back up first

Before any replace, take a database backup. Update URLs has a built-in one-click database backup and restore so you don't have to leave WordPress or wrestle with phpMyAdmin. Create a snapshot, confirm it's saved, then proceed. See one-click database import and export.

This backup is your floor. Even with dry runs and undo available, a full snapshot before a migration is non-negotiable.

Step 2 — Get the site onto the new domain

You have two common paths:

Move files + database. Copy your wp-content and database to the new host/domain. The site will load but render half-broken until URLs are updated — that's expected.
Fresh install + import. Install WordPress on the new domain and import an export of your content.

Either way, update siteurl and home to the new domain so WordPress loads on it. If you can reach Settings → General, change them there; if you're locked out, set them via wp-config.php or the database directly. The detailed approach is in change the WordPress URL in the database.

At this point the site loads on the new domain but is still full of old-domain links. Now the real work.

Step 3 — Run Update URLs: old domain → new domain

Install and activate Update URLs (see installation), then open the search-and-replace screen.

Search for: https://old-domain.com
Replace with: https://new-domain.com

Use the full URL including the protocol, not just the bare domain. Replacing the protocol-and-domain string together gives you cleaner, more predictable matches and lets you fix http vs https in the same pass (more on that below).

If you only want to touch specific tables — say wp_posts and wp_postmeta — use the table picker to scope the run instead of hitting every table. That's covered in run search and replace on selected tables. For a domain move, though, you generally do want to cover all tables, because old URLs hide in options and meta as well as content.

The full mechanics of the search-and-replace screen are in how to do search and replace text in WordPress.

Step 4 — Dry run before you write anything

This is the step that separates a calm migration from a stressful one. Run the replace as a dry run first. Update URLs scans every selected table and shows you exactly how many matches it found and what would change — without modifying a single row.

Read the preview:

Does the match count look sane for the size of your site?
Are the replacements hitting content and meta, not something unexpected?
Any table you didn't expect to be touched?

If anything looks off, adjust the search string or table scope and dry-run again. See how to do a dry run before search and replace.

Step 5 — Selectively apply

Once the dry run looks right, apply it. You don't have to run everything at once — you can apply selectively, table by table or change set by change set, so a large migration stays under control. Each applied run is recorded so you have a clear trail of what changed and when.

Step 6 — Handle http/https and www/non-www

A domain move is the perfect moment to normalise these, because you're already rewriting URLs:

HTTP → HTTPS. If the old site served http:// anywhere, run a second pass replacing http://new-domain.com with https://new-domain.com to clear lingering insecure URLs. This is exactly the cause of mixed-content padlock warnings — the dedicated walkthrough is fix mixed content (HTTP→HTTPS).
www vs non-www. Pick one canonical form and replace the other (https://www.new-domain.com → https://new-domain.com, or vice versa) so you don't split links and SEO signals across two hostnames.

Run each as its own search-and-replace with its own dry run. Small, explicit passes are easier to verify than one giant regex.

Step 7 — The serialized data caveat

This is the one that bites people who use raw SQL or a manual find-and-replace. Serialized PHP data stores the length of each string alongside it. When you change a domain — say from a 15-character host to a 20-character one — the stored length no longer matches the new string, and WordPress can't unserialize it. The result is broken widgets, blank page-builder layouts, or lost settings.

Update URLs handles serialized data correctly: it unserializes, replaces, and re-serializes with corrected lengths, so Elementor data, theme options, and plugin settings survive the move intact. You don't need to do anything special — but you should understand why it matters, especially if you were tempted to run the replace in phpMyAdmin instead. Read how to update serialized data effectively and the deeper search & replace without breaking serialized data.

Step 8 — Verify the new site

Now confirm the move actually worked:

Open the homepage and a few inner pages on the new domain. Check links and images load over the new domain.
View page source and search for the old domain — you want zero hits.
Click through your main navigation and a couple of posts with embedded images.
Open the browser console and confirm there are no mixed-content or 404 errors.

If anything still references the old domain, it usually means a table was skipped or a URL variant (www, http) wasn't covered. Dry-run that variant and apply.

Step 9 — Undo if something's wrong

If a replacement went too far — you matched a string you shouldn't have, or a value came out wrong — you don't have to restore a backup and start over. Update URLs keeps a history of every run with one-click Undo/Rollback, so you can revert a specific search-and-replace instantly and try again with a tighter search string. (A plain find-and-replace tool can't do this — once it writes, it's written.)

See view search and replace history and undo changes. And if a run somehow left the database in a bad state, the one-click database restore from Step 1 is your hard reset.

Post-move checklist

After the URLs are updated and verified, finish the move:

Re-save permalinks. Go to Settings → Permalinks and click Save once to flush rewrite rules on the new domain.
Set up redirects. Add 301 redirects from the old domain to the new one (at DNS/host or via .htaccess) so existing inbound links and bookmarks land on the right pages and link equity transfers.
Clear all caches. Page cache, object cache, and CDN — stale caches will keep serving old-domain URLs and make it look like the replace failed.
Check internal links and images. Spot-check a few posts and the media library; confirm featured images and embeds resolve on the new domain.
Update search engines. Add the new domain as a property in Google Search Console, submit your sitemap, and use the change-of-address tool if you're moving a verified property.
Update external references. Analytics, ad platforms, email signatures, social profiles, and any hardcoded links you control.

Conclusion

Moving WordPress to a new domain breaks links only when the database still points at the old one. The fix is a complete search-and-replace — back up, run old-domain → new-domain across all tables, normalise http/https and www, handle serialized data safely, then verify. Do it with a dry run first and a one-click undo ready, and a domain move stops being scary: it becomes a preview, an apply, and a quick check. Update URLs gives you the backup, the dry run, the serialized-data handling, and the rollback in one place — see the installation guide to get started, or the troubleshooting page if you hit a snag.

FAQs

Will my links break when I move to a new domain?

Only if the database still references the old domain. Run a full search-and-replace from old-domain.com to new-domain.com across all tables and your internal links, images, and settings keep working. Dry-run first so you can confirm the matches before anything is written.

Do I update the database directly?

You can, but it's risky — a raw SQL find-and-replace corrupts serialized data and gives you no preview or undo. Use Update URLs instead: it runs inside WordPress, previews matches with a dry run, handles serialized data correctly, and lets you roll back. See change the WordPress URL in the database.

What about serialized data?

Serialized PHP arrays store each string's length, so a plain replace breaks them and your page-builder layouts and plugin settings disappear. Update URLs unserializes, replaces, and re-serializes with correct lengths automatically. More in search & replace without breaking serialized data.

Do I need a redirect after moving domains?

Yes. Set up 301 redirects from the old domain to the new one so existing inbound links, bookmarks, and search rankings carry over. The search-and-replace fixes internal URLs; redirects handle external links pointing at the old domain.

Can I undo a search and replace if I get it wrong?

Yes. Update URLs keeps a history of every run with one-click Undo/Rollback, so you can revert a specific replace instantly and retry with a tighter search string — no full backup restore needed. See undo a search and replace.