← Back to blog

How to Migrate WordPress to a New Domain, Step by Step

November 1, 2026
How to Migrate WordPress to a New Domain, Step by Step

Moving WordPress to a new domain comes down to five jobs: back up everything, copy the site to the new address, change the old URLs in the database, point DNS and HTTPS at the new domain, and redirect the old domain to the new one. Done in that order, the site keeps working and visitors follow you across. This guide covers both the plugin route and the manual route, with the exact settings and commands, so you can pick the one that fits your comfort level.

inSave Hosting
insave.hosting
Move WordPress With Less Hassle
InSave Hosting offers WordPress hosting, free migration, and staging tools for site owners preparing to move to a new domain.
Explore WordPress hosting

TL;DR

  • Back up the files and the database first, and store copies in more than one place before you touch anything.
  • Changing the domain means updating siteurl and home, then replacing the old domain in the database with a serialization-safe tool such as WP-CLI search-replace.
  • Point DNS at the new domain and get HTTPS working before you announce the move.
  • Add a site-wide 301 redirect from the old domain to the matching page on the new one, and keep the old domain registered.
  • Test links, images, forms, logins and permalinks after the cutover. If something breaks, restore the backup rather than patching blindly.

Table of Contents

Decide which kind of move you are making

People search for "change domain name WordPress" and "move WordPress to a new domain" and mean slightly different things. Sort yours first, because the steps differ.

Your situationWhat changesBest route
Same host, new domain name (rebrand)Domain and URLs onlyChange URLs in the database, add redirects
New host and new domainServer, domain and URLsPlugin migration or manual copy, then URL replacement
Old domain expired or inactiveDomain, and you can no longer log in to the old URLManual copy from backup files, then URL replacement
Test or staging site going live on the real domainDomain onlyCopy the staging site, replace URLs

If you are only changing hosts and keeping the domain, our guide to migrating WordPress to a new host is the better fit. If the new address is a folder on the same domain, see moving WordPress to a subdirectory.

Prepare the new domain before you change anything

A smooth move is mostly preparation. Before you edit a single setting:

  1. Register the new domain and confirm you control its DNS. If you are still choosing a name, you can search and register a domain with DNS management included.
  2. Create the destination. That is either a fresh hosting account or an added domain on your current account, with an empty WordPress directory or a clean install ready for the files.
  3. List your current URLs. Export a list of your pages and posts (your sitemap works) so you can check them after the move. Note the pages that bring in the most traffic.
  4. Find every place the old domain is hard-coded. Think of email links in templates, social profiles, ad campaigns, Google Business Profile, payment gateways, and any plugin that stores an API callback URL.
  5. Lower the DNS TTL on the old domain a day ahead if the old domain's DNS will change. A shorter TTL means resolvers pick up changes faster.

Then choose a quiet time. A low-traffic window gives you room to test without visitors hitting half-moved pages.

Back up files and database first

A WordPress site is two things: the files (core, themes, plugins, uploads) and the database (posts, settings, users). You need both. The WordPress handbook says to back up both the files and the database and suggests keeping several recent copies in different places, such as the hosting server, cloud storage and a local computer.

For a migration, do this:

  • Download the full site directory by SFTP or your host's file manager, or create an archive from the control panel.
  • Export the database with phpMyAdmin, your host's backup tool, or wp db export if you use WP-CLI.
  • Store one copy off the server. The handbook's lesson on moving a site makes the same point: make a backup on a device before you start.

Before you rely on the backup, check that the SQL file is not empty and that the archive opens. A backup you have never inspected is a guess. If you need a refresher on bringing one back, see how to restore WordPress from a backup, and for a longer-term routine, our SMB website backup guide covers frequency and storage.

Option 1: Move the site with a migration plugin

A migration plugin is the easiest route for most small sites. The general pattern, described in the official WordPress learning lesson, is to install a migration plugin on both the old and new sites, export a file from the old one, and import it on the new one.

A typical run looks like this:

  1. Install WordPress on the new domain (a clean install is fine).
  2. Install and activate the same migration plugin on both sites.
  3. On the old site, run the export. Most plugins let you enter the new site URL, and the plugin rewrites the old URLs inside the export for you.
  4. On the new site, import the file or paste the old site's connection details, depending on the plugin.
  5. Log in again (your old credentials will now apply on the new site), then re-save permalinks.

Before you pick a plugin, check three things:

  • Size limits. Free versions often cap upload size. A large media library may need a different method, or your host's server limits raised.
  • Serialized data handling. The plugin should handle serialized values when it rewrites URLs. Ask what it does with page builder settings and widgets.
  • Multisite and special setups. Multisite networks and sites with custom database tables sometimes need the manual route.

If you manage many sites or client sites, the plugin route is quick, but you still need the backup and the post-move test list below.

Option 2: Migrate manually

The manual route gives you full control and works when the old domain is inactive, since you only need the backup files. It follows the process in the WordPress Advanced Administration Handbook.

Step 1: Copy the files

Upload the site files to the document root of the new domain. Keep the folder structure exactly as it was, including wp-content/uploads.

Step 2: Create a new database and import the old one

Create an empty database and database user on the new hosting account. Import your SQL export into it with phpMyAdmin or the command line. If the file is too large for the browser, use your host's command-line access or ask support to import it.

Step 3: Update wp-config.php

Open wp-config.php and enter the new database name, user and password. The handbook lists this as the step between exporting and importing, because the old credentials will not exist on the new server. Leave the table prefix as it is unless you changed it in the import.

Step 4: Tell WordPress its new address

The database still holds the old domain. At minimum, set siteurl and home in the wp_options table to the new URL. You can do that in phpMyAdmin, or from Settings > General if you can still log in. The handbook describes changing both URLs in the General settings screen of the old site as one way to do this, and warns you may lose access if the old address no longer resolves.

Other database values still point to the old domain, which is the next step.

Replace the old domain throughout the database

Changing siteurl and home is not enough. Post content, image paths, widget settings, menus and plugin options can all contain the full old URL. If you leave them, you get broken images, links that bounce visitors to the old site, and layouts that look wrong.

The tool WordPress points to for this is WP-CLI. WordPress.com's restore documentation gives the pattern: run wp search-replace OLD-DOMAIN NEW-DOMAIN --skip-columns=guid, then flush the cache. A realistic example:

wp search-replace 'https://old-example.com' 'https://new-example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old-example.com' 'https://new-example.com' --skip-columns=guid
wp cache flush

Run it with --dry-run first to see how many replacements it would make. The --skip-columns=guid flag leaves post GUIDs alone, which the handbook recommends because GUIDs are meant to stay as permanent identifiers.

Why you should not run a plain text replace

WordPress stores many settings as serialized data, where each string is saved together with its character count. If you change a domain with a basic find-and-replace in a text editor and the new domain has a different length, the counts no longer match and the setting breaks. The handbook warns that careless whole-database replacement can corrupt serialized theme, widget or plugin data. WP-CLI and well-built plugins read and rewrite serialized values correctly. If you want a deeper look at why this fails and how tools avoid it, this guide to serialized data and URL replacement sits alongside the indexing tools it reviews.

Take a database backup right before the search-replace. If it goes wrong, you restore and try again.

Why you should not run a plain text replace

Don't forget the http and www variants

Run the replacement for each variant that existed: http://old, https://old, and www. Also check the protocol. If your new domain will run on HTTPS and the old one did not, replace to https:// from the start.

Point the domain at the site and turn on HTTPS

With the files and database in place, the new domain has to reach your server.

  • Nameservers or A record. Point the domain at your host's nameservers, or set an A record to the server's IP address. DNS changes can take a while to spread, so test with a temporary URL or a hosts-file entry on your computer if you need to work before it resolves.
  • Add the domain in your hosting control panel so the server knows which directory to serve for it.
  • Get an SSL certificate. Certificates can only be issued once the domain's DNS is correct. WordPress.com's documentation makes the same order explicit: the domain must be configured in DNS before a certificate can be provisioned. On inSave Hosting plans, free SSL is included, and you can also look at the SSL certificate options if you need a different type.
  • Force HTTPS. Once the certificate is live, redirect HTTP to HTTPS. Our copy-ready HTTPS redirect rules cover Apache and NGINX.

If you are moving the domain registration itself rather than just the site, read how to transfer a domain safely so you avoid downtime.

Redirect the old domain to protect traffic and rankings

This step decides whether visitors and search engines follow you. The handbook advises letting people know about a new address and considering redirect instructions in .htaccess. In practice, you want a permanent (301) redirect from every old URL to its equivalent on the new domain.

On an Apache or LiteSpeed server, put this in the .htaccess file of the old domain's document root:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

The $1 carries the path across, so /blog/my-post/ on the old domain lands on /blog/my-post/ on the new one. That one-to-one mapping is what keeps your link equity and your visitors' bookmarks working.

Some rules that save trouble:

  • Keep the same URL structure on the new domain whenever you can. Changing slugs at the same time as the domain doubles the number of things that can go wrong.
  • Do not redirect everything to the home page. Send each page to its match.
  • Keep the old domain registered and the redirect live for as long as you can. If the old domain lapses, the redirect stops and anyone using an old link is stranded.
  • Update the sitemap on the new domain and submit it in Google Search Console and Bing Webmaster Tools.
  • Update links you control: social profiles, email signatures, directory listings, ad destinations and your Google Business Profile.

For a bigger site, a written URL map and a site migration SEO plan help you track every old URL to its new home. Our own website migration checklist is a good companion for protecting traffic. After the move, you may also want to nudge search engines to recrawl the new URLs, and these indexing tools for WordPress are one way to do it.

Test everything after the move

The handbook's advice is simple: test the site after changing its address, and if you use permalinks, rewrites or redirects, reconfigure .htaccess and permalinks and test the redirects. Use this checklist:

CheckWhat to look for
Home page and top 10 pagesLoad over HTTPS, correct layout, no mixed-content warnings
Images and mediaNo broken thumbnails, correct paths in posts and galleries
PermalinksGo to Settings > Permalinks and click Save to rebuild rewrite rules
Internal linksClick through menus, footers and in-content links; none should land on the old domain
Forms and checkoutSubmit a test contact form; run a test order if you sell online
Login and adminLog in, edit a post, upload a file
RedirectsVisit old URLs and confirm one 301 hop to the right page
EmailConfirm that site email (order and contact notifications) still delivers
Analytics and tag managerUpdate the property's URL and check that tracking fires
Robots and indexingMake sure the "discourage search engines" box in Settings > Reading is not ticked

Common problems and fixes

  • Redirect loop or "too many redirects." Usually two systems fighting: a plugin forcing HTTPS while the server also redirects, or siteurl and home disagreeing about www. Make both values identical and keep a single redirect rule.
  • Pages return 404 except the home page. Resave permalinks and check that .htaccess exists and is writable.
  • Layout lost or widgets empty. A replacement likely hit serialized data. Restore the database backup and redo the replacement with WP-CLI or a migration plugin.
  • Images still load from the old domain. Run the search-replace again with the exact old URL variant you missed, and clear caching and CDN layers.
  • White screen after the move. Check the database credentials in wp-config.php first.

The handbook's fallback is to restore the database from backup if a change goes wrong, which is why the pre-change backup matters.

Our perspective

We handle a lot of WordPress moves, and the failures almost always trace back to the same two habits: skipping the backup check and doing a raw text replace on the database. A domain change looks like a settings tweak, but it touches every URL on the site, so we treat it as a small migration project with a rollback point.

Our approach is built around that. Our sites are looked after by experienced SRE and DevOps engineers in the EU and the US, and we offer free migrations, daily backups and a 30-day money-back guarantee, so you are not doing a risky cutover alone or without a way back. If you want a safe place to rehearse, our WordPress hosting is designed for exactly this, with staging tools so you can test the new domain before visitors see it.

Our advice is to move on a quiet day, keep the old domain alive with its redirect, and never announce the new address until HTTPS, redirects and forms all pass your test list.

Ihor

Let us do the heavy lifting

If you would rather not run search-replace commands yourself, we can help. inSave Hosting offers free migration, daily backups and free SSL, and our WordPress hosting plans are built around easy installation, staging and managed security. If you are just getting started or need a simpler setup, our shared hosting plans are also available.

inSave Hosting

Plans are covered by a 30-day money-back guarantee, so you can move your site over and check that everything works on the new domain. Browse the plans on the WordPress hosting page, or check the new domain name's availability on our domain page.

Security and housekeeping after the cutover

A domain change is also a good moment for a short clean-up:

  • Update your salts and credentials if the old site was ever exposed, and remove admin users you no longer need.
  • Reissue API keys and webhooks tied to the old domain, such as payment gateway callbacks and social login redirects.
  • Remove staging copies and old backups from public folders so they cannot be downloaded.
  • Review plugin licenses. Some premium plugins and themes tie a license to the domain and need to be reactivated on the new one.
  • Check security basics. Our guide to securing your WordPress site walks through the steps that matter most for small businesses.

Keep monitoring for the first few weeks. Watch your crawl errors in Search Console, your 404 logs, and your analytics for pages that suddenly lose traffic, and fix any missed redirects as they show up. If the move is part of a bigger project, our overview of website migration explains the risks and how to plan around them.

FAQ

Will changing my WordPress domain hurt my SEO?

It can cause a temporary dip, but careful planning limits it. Keep your URL structure the same, use a one-to-one 301 redirect from each old page to its new equivalent, and keep the redirect live as long as you can. Then submit the new sitemap and watch your error reports.

Can I move WordPress to a new domain if the old domain has expired?

Yes, if you still have the files and a database backup from before it expired. Use the manual route: upload the files, import the database, update wp-config.php, then replace the old domain in the database. You will not be able to redirect from the old domain unless you regain control of it.

Is a plugin or the manual method better?

For a small to medium site, a migration plugin is usually quicker and handles URL rewriting for you. The manual method suits large sites, plugin size limits, or cases where the old site no longer loads. Whichever you choose, back up first.

Do I need to reinstall WordPress on the new domain?

Not for a manual migration, since you copy the existing files and database. For some plugin methods you install a clean WordPress on the new domain first, then import the old site over it. Either way, you end up with your original content, theme and settings.

How long does a WordPress domain move take?

The copy and URL replacement for a typical small site can take an hour or two. DNS changes can take longer to reach everyone, so plan for a window in which some visitors still see the old address, and leave the redirect running.

Sources