How to change your WordPress domain name

Changing the domain on a WordPress site requires updating the database, the configuration file, and your DNS records. If you skip any of these steps, the site either breaks or silently serves the wrong URLs. This guide covers the full process for both a complete domain swap and a simpler www/non-www change, with the exact commands and settings you need at each step.

This is not the same as migrating WordPress to a new host – that involves moving files and the database to a different server. Here, the site stays on the same server, but the domain it responds to changes.

Before you start#

Back up everything. Take a full copy of your WordPress files and export the database before making any changes. If something goes wrong during the domain switch, you need a clean copy to restore from.

Specifically:

• Database export. Run mysqldump -u your_user -p your_database > backup.sql via SSH or export through phpMyAdmin. This is the critical backup – the database is where most of the changes happen.
• Files. Copy the entire WordPress directory. If you have SSH access, tar -czf wordpress-backup.tar.gz /path/to/wordpress/ creates a compressed archive. If you are using a hosting panel, use the file manager or backup tool.
• Note your current URLs. Check Settings > General in wp-admin and write down both the WordPress Address (URL) and the Site Address (URL). You will need these if you have to roll back.

Make sure the new domain is already pointing to your server’s IP address. DNS propagation can take anywhere from a few minutes to 48 hours, so set this up before starting the domain change. You can verify propagation with dig newdomain.com or an online DNS checker. If you are unfamiliar with how domain names and DNS work, read up on that first – understanding A records and propagation will save you confusion during this process.

Changing the domain completely#

This is the most common scenario. You have a WordPress site running on olddomain.com and you want it to run on newdomain.com instead. Every URL in the database, every image path, and every internal link needs to change.

Step 1 – update the site URL in the database

WordPress stores its own URL in two places in the wp_options table: siteurl and home . These control where WordPress looks for its core files and what URL it uses for the front end.

The fastest way to update them is through WP-CLI:

wp option update siteurl 'https://newdomain.com'
wp option update home 'https://newdomain.com'

If you do not have WP-CLI, you can update these directly in the database:

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

Replace wp_options with your actual table prefix if you changed it from the default.

After this change, your wp-admin login page moves to https://newdomain.com/wp-login.php . If you lose access at this point, you can force the URLs in wp-config.php as a fallback:

define('WP_HOME', 'https://newdomain.com');
define('WP_SITEURL', 'https://newdomain.com');

These constants override whatever is in the database. Remove them once you have confirmed the database values are correct.

Step 2 – search and replace across the entire database

Updating siteurl and home fixes the main site URL, but the old domain is embedded throughout the database – in post content, widget settings, theme options, plugin configurations, and serialized data. A simple SQL REPLACE() query will corrupt serialized data because it changes string lengths without updating the serialization headers. You need a tool that handles serialized data properly.

WP-CLI (recommended):

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --skip-columns=guid --dry-run

Run with --dry-run first to see what will change without modifying anything. Once you are satisfied with the preview:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --skip-columns=guid

The --skip-columns=guid flag is important. The GUID column in wp_posts is a unique identifier that should not change – WordPress uses it for RSS feeds and internal tracking, not as a URL. Changing it can cause feed readers to republish every post as new.

Also run the replacement for the non-HTTPS variant if your old site ever used HTTP:

wp search-replace 'http://olddomain.com' 'https://newdomain.com' --skip-columns=guid

Better Search Replace plugin (if no SSH access):

Install the Better Search Replace plugin from the WordPress plugin repository. It handles serialized data correctly and shows a preview before making changes. Enter the old domain as the search term and the new domain as the replacement, select all tables, and run it.

Step 3 – update wp-config.php if needed

Check your wp-config.php for any hardcoded references to the old domain. Some setups define WP_HOME and WP_SITEURL directly in the config file, and some caching or CDN plugins add domain-specific constants. Open the file and search for the old domain name – replace any instances with the new one.

If your site uses HTTPS (and it should), verify that the WP_HOME and WP_SITEURL values use https:// and not http:// . A mismatch here causes redirect loops that make the site inaccessible.

Step 4 – set up 301 redirects from the old domain

If the old domain had any search engine authority, incoming links, or bookmarks, you need to redirect it to the new domain. A 301 redirect tells search engines that the move is permanent and that they should transfer ranking signals to the new URL.

In Nginx (add to the old domain’s server block):

server {
    listen 80;
    listen 443 ssl;
    server_name olddomain.com www.olddomain.com;

    # SSL certificate for the old domain
    ssl_certificate     /path/to/olddomain-cert.pem;
    ssl_certificate_key /path/to/olddomain-key.pem;

    return 301 https://newdomain.com$request_uri;
}

This preserves the URL path, so olddomain.com/blog/my-post redirects to newdomain.com/blog/my-post .

In Apache (add to .htaccess on the old domain):

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

Keep these redirects running for at least a year. Search engines need time to recrawl and update their indexes, and old links from other websites may never get updated.

Step 5 – update your SSL certificate

Your new domain needs a valid SSL certificate. If your hosting uses Let’s Encrypt with automatic renewal (as Hostney does), the certificate is provisioned automatically once the domain resolves to the server. Otherwise, you will need to install an SSL certificate for the new domain manually.

Keep the SSL certificate active on the old domain too, at least while the 301 redirect is running. Without it, visitors arriving at https://olddomain.com will see a certificate error before the redirect even fires.

Step 6 – clear all caches

After completing the domain change, clear every cache layer:

• WordPress object cache. WP-CLI: wp cache flush . Or clear it from your caching plugin’s settings.
• Page cache. If you use a caching plugin (WP Super Cache, W3 Total Cache, LiteSpeed Cache), purge all cached pages.
• Server cache. If your hosting uses Nginx FastCGI cache or Varnish, purge that too. On Hostney, cache is purged automatically when content changes.
• CDN cache. If you use a CDN, purge the entire cache so it fetches content with the correct domain.
• Browser cache. Hard refresh with Ctrl+Shift+R and test in an incognito window to avoid stale cached pages.

Adding or removing www#

If you just want to switch between example.com and www.example.com (or the other way around), the process is simpler. Both variants point to the same site – it is a preference, not a structural change.

Update the WordPress URLs

In wp-admin, go to Settings > General and change both the WordPress Address and Site Address to your preferred format – either with www. or without. Or via WP-CLI:

wp option update siteurl 'https://www.example.com'
wp option update home 'https://www.example.com'

Then run a search-replace for any hardcoded URLs in the database:

wp search-replace 'https://example.com' 'https://www.example.com' --skip-columns=guid

Set up the redirect

You want one canonical version. If you chose www.example.com , redirect the non-www variant:

Nginx:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

Apache (.htaccess):

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

Update DNS

Make sure both example.com and www.example.com resolve to your server. The bare domain needs an A record pointing to your server’s IP. The www subdomain needs either a CNAME pointing to example.com or its own A record. If you are not sure how DNS records work, the DNS errors guide explains the fundamentals.

Common mistakes after changing a domain#

Forgetting serialized data

WordPress plugins and themes store complex settings as serialized PHP arrays in the database. Serialized data includes string length counts – for example, s:22:"https://olddomain.com" means “a string of 22 characters.” If you use a naive SQL REPLACE() to swap domains, the URL changes but the length count does not, and PHP cannot unserialize the data. Settings break silently. This is why WP-CLI’s wp search-replace or the Better Search Replace plugin are necessary – they recalculate serialized string lengths automatically.

Not updating Google Search Console

Google treats olddomain.com and newdomain.com as completely separate properties. After changing the domain:

1. Add and verify newdomain.com as a new property in Google Search Console.
2. Use the Change of Address tool in the old domain’s property to tell Google about the move.
3. Submit the new sitemap ( https://newdomain.com/sitemap.xml ).
4. Keep the old property active so you can monitor the redirect for crawl errors.

Without this step, Google continues trying to index the old domain and treats the new one as a brand-new site with no history.

Broken image paths

Images in WordPress are stored with absolute URLs in the database. If the search-replace missed any tables or if you have images referenced in custom CSS, theme files, or hardcoded HTML, those images will break. After the domain change, check your site for broken images by opening the browser console (F12 > Console) and looking for 404 errors on image URLs that still reference the old domain.

If you find stray references in theme files, update them manually. If they are in the database, run the search-replace again targeting the specific tables.

Mixed content after switching protocols

If the domain change also involves switching from HTTP to HTTPS (or if some URLs were stored with http:// ), you may see mixed content errors. The browser loads the page over HTTPS but finds resources loaded over HTTP, triggering security warnings. Running the search-replace for both http://olddomain.com and https://olddomain.com pointing to https://newdomain.com prevents this.

Redirect loops

If your old domain and new domain are both configured in Nginx or Apache with conflicting redirect rules, the browser gets caught in a loop between them. The too many redirects error means one rule sends the browser from A to B while another sends it from B back to A. Check that only the old domain redirects to the new one, and that the new domain’s configuration does not redirect anywhere else.

What to do with the old domain#

After the domain change is complete and the 301 redirects are running, you have three options for the old domain:

Keep it and redirect (recommended). Maintain the domain registration and keep the 301 redirect active. This preserves any backlinks and SEO authority that pointed to the old domain, and prevents someone else from registering it and intercepting your old traffic. The annual registration cost is minimal compared to the SEO value.

Park it. If you do not want to maintain a server configuration for the old domain, some registrars let you park the domain – it stays registered to you but does not point anywhere. You lose the redirect benefit but keep ownership.

Let it expire. If the old domain has no backlinks, no brand value, and no traffic, letting it expire is fine. But be aware that expired domains with any history can be picked up by domain squatters who may use them for spam or phishing. If the domain was associated with your brand, keeping it registered is worth the small cost.

Quick reference checklist#

1. Back up the database and files
2. Point the new domain’s DNS to your server and wait for propagation
3. Update siteurl and home in wp_options
4. Run wp search-replace for all URL variants (HTTP and HTTPS), skipping the GUID column
5. Check wp-config.php for hardcoded domain references
6. Set up 301 redirects from the old domain to the new domain
7. Install or verify SSL certificate on the new domain
8. Clear all caches (object cache, page cache, server cache, CDN, browser)
9. Update Google Search Console with the Change of Address tool
10. Test the site thoroughly – check pages, images, forms, and plugin functionality
11. Keep the old domain redirecting for at least 12 months

How Hostney handles domain changes#

On Hostney, the hosting infrastructure handles several of these steps automatically. SSL certificates are provisioned via Let’s Encrypt as soon as the domain resolves to the server – no manual certificate installation needed. Nginx caching is purged automatically when WordPress content changes, so you do not need to manually clear the server cache after updating URLs.

For the database search-replace, Hostney’s managed WordPress control panel includes a Search & Replace tab that handles serialized data correctly – no SSH or WP-CLI required. Enter the old domain, enter the new domain, and the tool runs the replacement across all tables while preserving serialized data integrity. If you prefer the command line, you can also connect via SSH and use WP-CLI directly – each site runs in its own isolated container with WP-CLI pre-installed.

If you are also migrating from another host at the same time (new domain and new server), the WordPress migration guide covers the full file and database transfer process. The domain change steps in this article apply after the migration is complete.