What changes for Google when a WordPress site changes domain?
Everything Google knows about your site is filed under its hostname. The pages, the links from other sites, the record of which URL answered which search: all of it points at the old domain. When you're moving a WordPress site to a new domain, Google sees a new site turn up with content it's already seen somewhere else. The only thing joining the two is a trail of redirects, and building that trail is the core of my website migration SEO services.
Can you change the domain of an existing WordPress website? Yes, and the content, design and plugins come with it. This post is for self-hosted WordPress; on a WordPress.com plan, you register or connect the new name and make it the site's primary address in its domain settings. I don't build or redesign sites. I do the search side and the database work that decides it.
Google files a domain change under site moves with URL changes: server-side permanent redirects, updated internal links and canonicals, and a new sitemap. It also warns that rankings may fluctuate while it recrawls and reindexes the site. Nobody can switch that off, and I won't put a date on it. What I control is whether every old URL tells Google where it went.
Why can't I just edit the Site Address in Settings?
Because changing the WordPress site URL in that field changes two rows in the database and nothing else. Settings, General holds the WordPress Address and the Site Address, stored as the siteurl and home options. Change them and WordPress builds its own links from the new domain, but it doesn't move files or DNS, and it doesn't touch the places the old domain is written into content.
WordPress's own migration notes say that after changing the URLs in Settings, General you should expect to see a 404 page, and they carry a whole section on recovering from a site URL changed by accident.
| Where it's stored | What it holds | What I do |
|---|---|---|
| siteurl and home in wp_options | The two addresses from Settings, General | Change them as part of the full replace, or set them in wp-config.php during the move |
| Post and page content | Links and image URLs typed into the editor | Replace old with new across every post, page and revision |
| Serialized options and widgets | Theme settings, widget text and plugin options stored with a length count | Use a tool that reads serialized data, so the counts get rewritten too |
| Page builder data in post meta | Layouts that carry full URLs for images, buttons and links | Run the builder's own replace as well, if it has one |
| The guid column in wp_posts | A permanent ID for each post, used by feed readers | Leave it alone. WordPress says never to change it |
The serialized row is the one that bites. Some themes and widgets store a value with its length written in front of it. A plain SQL REPLACE swaps the domain but leaves the old count, and when the new domain is a different length, PHP can't read the value back. The widget empties, often with no error. WP-CLI's search-replace command handles serialized data properly, which is why it's the tool I use.
If WP-CLI isn't available: phpMyAdmin. WordPress's migration notes walk through editing the siteurl and home rows of wp_options in phpMyAdmin, and that's fine for those two rows. It isn't a way to change the domain in the database everywhere else, because the serialized values still need a tool that rewrites their counts. On hosts without WP-CLI, I run a search and replace plugin that handles serialized data, on a staging copy first.
How I change a WordPress site's domain, step by step
Most answers to how to change a domain name in WordPress stop at the database. My list runs on to the redirects and Search Console. The first four steps happen before anything goes live, and the Change of Address waits until the redirects pass.
- Step 01
Back up, then pull the full URL list
A full backup of files and database, then a list of old URLs from a crawl, the XML sitemap, the Search Console Performance export by page and a backlink export. The redirects get tested against that list later.
- Step 02
Verify the new domain in Search Console
I add the new domain as a Domain property verified with a DNS record before it carries any pages. Google's help says the DNS record has to stay in place for the property to stay verified.
- Step 03
Put a copy of the site on the new domain
If the host is changing, files and database move first. The old domain keeps serving the live site until the switch.
- Step 04
Run the search and replace, dry run first
wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-runreports every table and row it would change without saving anything. When the counts look right, I run it for real, then again for the http and www forms of the old domain. - Step 05
Replace inside the page builder too
Elementor ships a
wp elementor replace-urlscommand for its own data, and other builders need their own tool or a check by hand. Then every cache layer gets cleared: plugin, host and CDN. - Step 06
Check what lives outside WordPress
The CDN zone, the SSL certificate on the new domain, SMTP settings, and any URL hardcoded in wp-config.php or a child theme.
- Step 07
Switch on the redirects at server level
One rule on the old domain sends every path to the same path on the new one with a 301 rather than a 302. On Apache:
RewriteCond %{HTTP_HOST} ^(www\.)?old\.example$ [NC]andRewriteRule ^ https://new.example%{REQUEST_URI} [R=301,L]. On Nginx, a server block for the old names withreturn 301 https://new.example$request_uri;. A plugin can't do this, because WordPress no longer answers for the old domain. - Step 08
Test the whole URL list against the old domain
Every URL from step one should answer with one 301 and land on a page returning 200. Anything that chains, loops, 404s or lands on the homepage gets fixed before Search Console hears about the move.
- Step 09
Tell Search Console, then submit the new sitemap
Only after the redirects pass. The Change of Address tool runs its own checks, and the new sitemap goes into the new property the same day.
Never run a plain SQL REPLACE over the whole database, and never let any tool rewrite the guid column. A GUID is an ID, not a link, so one that still names the old domain is correct.
Rather have me do this? One person, whole job.
Book a call on UpworkHow do the redirects need to be set up for a domain move?
Path for path, at server level, in one hop. A domain change is the simplest redirect map there is, because WordPress keeps the paths. /services/roof-repair/ on the old domain becomes /services/roof-repair/ on the new one, so one pattern rule covers the whole site.
The usual mistake is sending everything to the new homepage. It throws the history away, because a homepage doesn't answer the searches the inner pages did. In one of my case studies, a WooCommerce catalogue's new URLs shipped without redirects and daily clicks fell from 162 to 49 in three days. That wasn't a domain change, but the cause was the same: old addresses that didn't lead to their replacement.
| Request | Answer | Why |
|---|---|---|
| https://old.example/page/ | 301 to https://new.example/page/ | The main rule: same path, new host |
| http://old.example/page/ | 301 to https://new.example/page/ | One hop, not an http to https hop on the old domain first |
| http://www.old.example/page/ | 301 to https://new.example/page/ | The www form has links and history of its own |
| https://www.old.example/page/ | 301 to https://new.example/page/ | Same rule, same destination |
| https://old.example/page/?ref=x | 301 to https://new.example/page/?ref=x | Query strings come across, so tracked links still work |
Google counts 301 and 308 as permanent and prefers them server-side, not a JavaScript hop or a meta refresh. Wherever the rule lives, I check the real status code with a header request, because the setting and the response don't always agree.
What do I tell Search Console, and when?
Search Console hears about a domain change in four stages, and each one waits for the stage before it.
- i.
Before the move: both properties verified
The Change of Address tool needs the same Google account to own the old and the new property, and the old property has to sit at domain level, with no folder in its address.
- ii.
After the redirects pass: the Change of Address
It's filed from the old property, only for a move from one domain or subdomain to another, and Google keeps the forwarding signal for 180 days. Subdomains don't move with it, so a shop subdomain gets its own request.
- iii.
Same day: the new sitemap
The new domain's sitemap goes into the new property, and it should list only new URLs that return 200. If a plugin still prints old domain URLs into it, the sitemap and robots.txt get fixed before it's submitted.
- iv.
The weeks after: the Pages report on both sides
On the old property, URLs moving to Page with redirect is the healthy sign. On the new one, pages stuck at Discovered, currently not indexed for weeks have a diagnosis of their own.
The Change of Address tool isn't for an http to https switch, a www change or a new folder on the same domain. Those only need the redirects and an updated sitemap.
How long should the old domain stay registered?
Longer than Google asks, and I'd say for good. Google's site move guide says to keep the redirects as long as possible, generally at least a year. The Change of Address help asks for at least 180 days and recommends paying for the old domain for at least a year, so nobody else can buy it and use it for something malicious.
Links from other sites don't update themselves because you moved. An old directory listing or forum thread points at the old domain for as long as it exists, and every click on it needs the redirect.
Email is the other reason. If inboxes or old invoices still use the old domain, its MX records have to keep working until every one has moved. Letting it lapse loses the redirects and the mail in one go.
If you're changing a WordPress site's domain and you'd like one person to own the search side, from the URL list and the replace to the redirects, Search Console and the weeks after, that's the migration work I do. Your host and your developer keep their parts.
Book a call on Upwork
