Changing the domain name of a WordPress site safely

Under Settings → General, WordPress has two fields: WordPress Address (URL) and Site Address (URL). Change them and the site answers on the new domain within seconds. The old domain is still in your post content, theme options, plugin settings, inbound links, Google’s index and, on a store, your payment connection.

So a domain change is a sequence of separate jobs, and each one can fail on its own. The order below is the one WordPress’s own migration handbook and Google’s site-move guidance support. Before you start, have a backup of files and database that you have actually restored somewhere, and keep it until the new domain has been running cleanly for weeks.

Is this a domain change, a host move, or both?

A domain-only change leaves the files and database on the same server. You point the new domain at the server and update what WordPress stores. A host move copies files and the database to a new server. The handbook notes that if you keep the same domain, you can usually move hosts without touching the site URLs at all.

Doing both at once adds problems a domain change alone never has: database credentials and $table_prefix in wp-config.php, a different PHP version, missing files. If you can, split the work. Move hosts first, confirm everything works, then change the domain. Leave the permalink structure and the design alone while you do either one. When three things change together and traffic drops, you can’t tell which one caused it.

What has to be ready before you touch WordPress

Three things, in this order.

• The new domain reaches your server. Add it at your host as an alias, add-on or primary domain, then point DNS at the server. If email runs on the domain, change only the A or CNAME records. Kinsta’s migration docs say the same: switching nameservers can drop your MX records, and the mail goes with them.
• HTTPS works on the new domain. Issue the certificate for both new-domain.com and www.new-domain.com. WooCommerce’s SSL docs warn that switching a site to HTTPS before the certificate is valid can make it inaccessible.
• The old domain keeps a valid certificate. An HTTPS visitor has to finish the secure connection before your server can send them a redirect. An expired certificate on the old domain means a browser warning in place of a redirect.

Test it by opening https://new-domain.com. If the browser accepts the certificate and you land on the old domain, that is the right result at this stage. It proves the request reached your WordPress install, which is still redirecting to the address it has stored.

How to change the domain, step by step

1. Update the two addresses. In Settings → General, set both fields to https://new-domain.com. Leave them different only if WordPress core sits in a subdirectory on purpose. Saving logs you out because login cookies belong to a domain, so log in again at new-domain.com/wp-admin. If the fields are greyed out, WP_HOME or WP_SITEURL is defined in wp-config.php. The wp-config handbook page explains that these constants override the dashboard but never update the database. Edit them too, or remove them once the database holds the new values.
2. Replace the old URLs stored in the database. See the next section. This is the step people skip most often.
3. Refresh permalinks and caches. Open Settings → Permalinks and click Save without changing anything. If you have custom rules in .htaccess, check they survived. Then clear every cache: the caching plugin, the host’s server cache, the CDN and any object cache. A homepage that loads while posts return 404 almost always means stale rewrite rules or a cache. Our guide to permalinks that stop working covers that case.
4. Redirect the old domain, page to page. See the redirects section below.
5. Tell Google. Verify both domains in Search Console. Once the redirects are live, submit Change of Address from the old property. Then submit the new sitemap and check that robots.txt and Settings → Reading are not blocking search engines.
6. Test as a visitor. In a private window, open a post, an archive, a media-heavy page and your contact form. Submit the form and confirm the email arrives. Open the browser console and look for mixed-content warnings and redirect loops.

Why a find-and-replace in phpMyAdmin breaks settings

Plugins and themes save settings as PHP-serialized data, and that format records the length of every string. Run a raw SQL REPLACE() and swap old-domain.com for a name of a different length, and the recorded lengths no longer match. PHP can’t read the value, so the widget, theme option or plugin setting silently falls back to its default.

The handbook recommends a tool that rewrites the lengths correctly. With command-line access, use WP-CLI’s search-replace:

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

Read the dry run’s table counts before you run the real thing. Repeat for http:// and www forms if your site still has them. Always include the scheme in the search string. A bare old-domain.com also rewrites info@old-domain.com in your forms and notification settings. Skip guid because WordPress says post GUIDs should never change. On multisite, WP-CLI only touches the current site’s tables unless you add --network. The handbook calls multisite domain changes “more complicated” and asks for a manual review of the network tables. Our multisite setup guide explains which domain values live where.

Without SSH, use Better Search Replace. It handles serialized data, lets you pick tables and offers a dry run. Page builders often keep their own generated CSS with absolute URLs, so regenerate those files from the builder’s tools screen afterwards. Then search the page source on the live site for the old domain. A clean report from the tool tells you what it processed, which is not the same as every URL a visitor sees.

Why redirects decide the SEO outcome

Every bookmark, backlink and search result points at the old domain. Google’s site-move documentation asks for server-side 301 or 308 redirects from each old URL to its matching new URL, in one hop. Keep them for at least a year. Sending every old URL to the homepage is the classic mistake: Google can treat those as soft 404s, and visitors lose the page they asked for.

If your paths stay the same, one rule on the old domain handles it. On Apache, put it at the top of .htaccess, above the WordPress block:

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

This keeps the path, so old-domain.com/services/ lands on new-domain.com/services/. Test the HTTP, HTTPS, www and non-www versions of a few deep URLs and check that each one takes a single hop. Update any existing redirect rules that still point at the old domain, or they will turn into chains. On Nginx or a managed host, use the host’s redirect tool. Our guides to htaccess 301 redirects and how 301s affect SEO go further.

Keep renewing the old domain after the year is up. The redirects stop working the day the registration lapses, and someone else can buy the domain and its backlinks.

What changes on a WooCommerce store

Payments notice the new URL. WooCommerce’s WooPayments Safe Mode docs say a new domain, a clone, or two URLs pointing at one install can trigger Safe Mode. Choose “Transfer your connection” to keep your account and history. “Create a fresh connection” starts over without the history. Payments can carry on in Safe Mode, but dispute and refund updates may not arrive reliably.

WooCommerce Subscriptions compares the current URL with the one stored at activation. When they differ, it switches to staging behaviour and turns off automatic payments and subscription emails. Confirm the live status after the move. If an old copy of the site is still running, shut it down. The same docs warn that a duplicate can keep processing real renewals. Then place a test order, and check refunds and renewal settings as well as checkout.

What a correct result looks like

The admin stays on the new domain after you log in again. Searching the page source of a few pages finds no internal references to the old domain. Every old deep link arrives at its matching page in one 301. The form email arrives. Search Console shows the new sitemap being read. On a store, WooPayments shows no Safe Mode notice and Subscriptions reports itself as live.

Expect search traffic to wobble anyway. Google calls temporary fluctuation normal and says a small or medium site can take a few weeks or more to settle. Search Engine Journal’s study of 892 domain migrations found an average of 523 days to win back estimated organic traffic, and 17% had not recovered after 1,000 days. Those figures come from third-party traffic estimates across all kinds of sites, so treat them as a reason to get the redirects right, not as a forecast for your site.

If something went wrong

Match the symptom to the cause before you change anything else.

• Locked out, or the site sends you to the wrong place. You probably changed the URLs before the new domain resolved. Set them back with wp option update home and wp option update siteurl, or edit the home and siteurl rows of wp_options in phpMyAdmin. Defining WP_HOME and WP_SITEURL also gets you in, as a temporary fix. Our login troubleshooting guide covers the rest.
• ERR_TOO_MANY_REDIRECTS. Usually the two URL fields disagree on http versus https or www, or .htaccess, the host and a CDN are each forcing a different version.
• Redirects back to the old domain. A constant in wp-config.php, a cached redirect, or stored URLs the replace missed.
• “Error establishing a database connection” or a white screen. This almost always means a host move happened at the same time. Check the credentials and $table_prefix in wp-config.php.
• The browser can’t find the domain at all. That is DNS, not WordPress. See our guide to DNS_PROBE_FINISHED_BAD_CONFIG.

Stop and restore the backup if the admin stays unreachable, errors appear across the site, or settings look corrupted and you can’t say why. On a store, write down every order placed since the backup before you restore over it. If you would rather hand off the WordPress side, SiteSelf can run the site changes through chat: the search-replace and redirects with hosting access, then a fetch of the changed pages to check them. The DNS, registrar and Search Console steps stay with you.

Frequently asked questions

Will changing my domain break my email?

It can. Email follows the domain’s MX records, not WordPress. If you change only the A or CNAME record that points the website at your host, mail keeps flowing. Problems start when someone moves the nameservers and the MX records don’t come across.

Can I change the domain and the URL structure at the same time?

You can, but every old URL then needs its own mapping instead of a single path-preserving rule. Diagnosing a traffic drop also gets harder. Change the domain first, let it settle, then restructure if you still need to.

Does Change of Address cover HTTPS or www changes?

No. Google’s help page says not to use the tool for moving from HTTP to HTTPS or between www and non-www on the same domain. Those changes only need redirects and correct canonical tags.

Is a traffic drop after the move proof that something failed?

Not on its own, since Google expects some fluctuation. A large or lasting drop with old URLs showing as 404 in Search Console points to missing or broken redirects. Check the redirect and indexing status of the pages that lost traffic before you rewrite their content.

Why use WP-CLI when Settings → General already changed the domain?

Those two fields only change where WordPress says the site lives. Links in posts, image URLs, widget settings and plugin options keep the old domain until a serialization-aware search-replace rewrites them.