Moving a WordPress site to a new domain (rebrand, cheaper TLD, moving from .io to .com) is a common task that goes wrong in specific, predictable ways. This guide walks through the practical steps that preserve SEO and prevent broken links.

Before you start

• Register the new domain.
• Point its DNS at your existing WordPress hosting.
• Add SSL for the new domain (usually one command with Certbot).
• Take a full backup of your site. Non-negotiable.

The three approaches

1. WP-CLI search-replace. Recommended. Free. Handles serialized data correctly.

2. Database SQL update. Works but breaks serialized data unless you're careful.

3. A migration plugin. Convenient but a paid subscription.

The WP-CLI approach (recommended)

Install WP-CLI on your VPS if not already:

```bash

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

chmod +x wp-cli.phar

mv wp-cli.phar /usr/local/bin/wp

```

Run search-replace to update every URL in the database:

```bash

cd /var/www/yourdomain.com

Dry run first to see what would change

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --dry-run

If the count looks right, run for real

wp search-replace 'https://olddomain.com' 'https://newdomain.com'

```

WP-CLI's search-replace correctly handles serialized data in WordPress options, post meta, and widget settings — which is why it's the recommended path over a raw SQL UPDATE.

Update the siteurl and home options explicitly if for some reason search-replace didn't catch them:

```bash

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

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

```

Clear the WP object cache:

```bash

wp cache flush

```

Test the new domain. All internal links should now point at newdomain.com.

Update wp-config.php

Some sites hardcode the URL in wp-config.php:

```php

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

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

```

If these are present, update them.

Update Nginx / Apache config

Update your web server's server_name (Nginx) or ServerName (Apache) to include the new domain:

```nginx

server_name olddomain.com www.olddomain.com newdomain.com www.newdomain.com;

```

nginx -t && systemctl reload nginx.

Or if you're moving decisively:

```nginx

server_name newdomain.com www.newdomain.com;

```

And add a separate redirect server block for the old domain (see next section).

Set up 301 redirects (critical for SEO)

You must redirect every URL on the old domain to the same URL on the new domain. This preserves link equity and prevents broken external links.

In Nginx:

```nginx

server {

listen 80;

listen 443 ssl;

server_name olddomain.com www.olddomain.com;

# Include the old SSL cert config here if you had HTTPS

ssl_certificate /etc/letsencrypt/live/olddomain.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/olddomain.com/privkey.pem;

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

}

```

$request_uri preserves the full path. /blog/how-to-x/ on old domain redirects to /blog/how-to-x/ on new domain.

Test with curl -I https://olddomain.com/some-old-url — should return 301 Moved Permanently with the new domain in the Location header.

Update Cloudflare or CDN

If you use Cloudflare in front:

• Add the new domain to Cloudflare.
• Configure the same DNS records.
• Turn on the same page rules.
• If you had cache-everything rules, apply the same to the new domain.

Update external services

Every place your site's URL appears externally needs updating:

• Google Search Console. Add the new domain property. Submit updated sitemap. Use the Change of Address tool (Legacy tools & reports → Change of address) to notify Google.
• Google Analytics / Umami / Plausible. Update the tracked domain.
• Google Business Profile. Update the website URL.
• Facebook Page. Update the website field.
• Twitter / X profile. Update the linked URL.
• LinkedIn Company Page. Update.
• Email signatures. Everyone's.
• Third-party integrations (webhook targets, OAuth redirect URIs, payment gateway webhooks).
• Ads. Update every landing page URL in Google Ads, Facebook Ads, etc.

Common gotchas

Redirect chains. A URL redirecting through 2-3 hops before reaching the final page burns some SEO value and looks bad in Google Search Console. Test with a tool like httpstatus.io to verify direct 301s.

Mixed content warnings. If you had http://olddomain.com/wp-content/uploads/... in database rows, they'll still be HTTP after the domain change. Run another search-replace: wp search-replace 'http://newdomain.com' 'https://newdomain.com'.

Serialized data breakage. This is why WP-CLI search-replace is safer than raw SQL. If you did use raw SQL and things break, restore from backup and try WP-CLI instead.

Cached URLs. Clear all caches: WordPress caching plugin, Cloudflare (Purge Everything), object cache, page cache. If URLs still look wrong, cache is the culprit.

Search engines not updating. Google respects 301s but takes 4-12 weeks to fully re-attribute the old domain's authority. Be patient.

Broken email deliverability. If you had SPF/DKIM/DMARC records set up for the old domain and use wp_mail from your site, set them up on the new domain too.

SEO expectations after the move

• First week: Google Search Console shows both old and new domain indexed.
• Weeks 2-4: rankings for the new domain grow; old domain rankings decline.
• Month 2-3: most of the SEO value transferred (assuming 301s are working and no broken links).
• Month 4-6: old domain is essentially deindexed.

Any short-term traffic dip is normal. Long-term impact depends on how well you preserved link equity via 301s.

Related guides

• Best hosting for a WordPress site — hosting options.
• Shared hosting to plain VPS migration — includes WordPress moves.
• How to speed up WordPress on any VPS — post-migration optimization.