People type migrate wordpress site to new domain when the name on the invoice and the name in the browser have to part ways. Three objects move, and they do not share a clock. The registration, the DNS, and the strings stored inside WordPress can each change while the other two stay exactly where they were. This page is those three objects, plus the redirects from old URL to new URL.
Which tool holds the copy during a host move is WordPress migration tools compared. A rebuild that starts with no database, because the old site was Squarespace, is migrating from Squarespace to WordPress. Neither of those is a registrar transfer.
It is not a move between servers. If the machine is changing too, read what breaks after a host move succeeds before you touch the name. A plugin argument about archives is a third job, and it is already on the migration pitfalls page.
The registration is not the website
A domain is a record in a registrar’s database. The website is files and a database on a server. You can transfer wordpress domain from one registrar to another and serve the identical site the whole time, because a transfer of the registration does not, by itself, change the DNS target.
You can also leave the registrar alone and still move website to new domain wordpress by telling WordPress that its address is a name you already own. Teams lose a day because they treat those as one ticket. They are two tickets, often at two companies.
Which registrar to use, and how a transfer code actually works, is a buying decision. The comparison of those sellers on this site is in Chinese. It is here: which registrar to buy the name from.
This page will not re-rank Aliyun against GoDaddy. It only needs one fact from that decision. Know who will unlock the name, and how long an unlock takes, before you promise a cutover hour.
DNS can keep pointing at the old site on purpose
The name’s DNS is a pointer. Until you change it, visitors and Google still reach whatever host the records name. That delay is useful. Build the new URLs on a temporary hostname, or on the new name aimed only at your own office, and finish the ugly checks before the world follows.
Lower the TTL a day earlier if you can, so a mistake is a short mistake. When you do change the records, change the ones that matter. The A or AAAA record, or the CNAME, is the site.
MX is the mail. People “update the domain” and repoint mail at a web server that has never accepted a message. The site looks fine.
The inbox goes quiet, and nobody notices until a customer says so.
Leave the old name resolving until the redirects are in place and you have clicked a sample of them. Cancelling the old registration on the same afternoon as the DNS edit is how a correct new site becomes invisible. The old name has to answer, with a redirect, for as long as other sites and old emails still use it.
Export the database before you edit anything
WordPress keeps its address in the database, not in a single config line you can trust. To export wordpress database means a SQL dump of that database, taken before the replace, and stored somewhere a stranger cannot download.
On one of our own sites, a theme directory held 36 .backup copies. Every one of them was reachable from the public web. A SQL file named something helpful, dropped into public_html so a plugin can “see” it, is that incident again.
Put the dump outside the web root, or pull it to a machine that is not the server. Then prove the URL 404s.
A dump is not a polite document. It contains users, password hashes, drafts, and form entries. Email it to a client as an attachment and you have published it to every mailbox in the thread. Hand over a path and a deletion time instead.
The replace that has to know the length
Two values decide what WordPress thinks its address is: the site URL and the home URL. Changing them in the dashboard is the easy half, and only if you can still log in. The hard half is every other copy of the old name.
Post content, widget text, menu items, and plugin options all store it. Many of those values are serialized. The string carries a number that says how long it is.
Change the letters and leave the number, and PHP hands back an empty option. The site boots. Pieces of it don’t.
A desktop find-and-replace does that damage with a clean conscience. The migration pitfalls page shows why a text editor is the wrong tool for this replace. Use it. Don’t re-learn it on a production name.
Search the dump, after a proper replace, for the old host. You want leftovers you chose to keep, such as a sentence that mentions the old brand, not image URLs and not the home option. One leftover in a menu is a nuisance. A leftover in the home option sends every login back to the name you just left.
Redirects Google has already called legitimate
A redirect is not automatically a trick. Google’s spam policies list “moving your site to a new address” among the legitimate reasons to send a visitor to a different URL. The same page describes the sneaky kind: showing engines one thing and people another.
A 301 from an old product URL to the same product on the new name is the first kind. A 301 from every old URL to the new homepage is closer to throwing the catalogue away.
Map the URLs you actually had. One old path, one new path, one hop. Chains waste the crawl and they confuse a later debugger. Keep the map in a file you can open in a year, when someone asks why a printed brochure still works.
The policy text is Google’s spam policies. Read the sneaky-redirect section before you write a rule that “simplifies” the old site into a single destination.
What the new name tells Google
A new domain is also a new set of signals about who the site is for. Google’s page on multi-regional sites says a country-code top-level domain is a strong signal that the site is for that country. It says hreflang annotations, in tags, headers, or sitemaps, are how you label language and region variants.
And it says server location, taken from the IP, can be a signal but is not a definitive one, because of CDNs and hosting chosen for better infrastructure. That page is managing multi-regional and multilingual sites.
The same document says Google judges the language from the visible words on the page. It does not use the lang attribute, and it does not use the URL, as the language signal. Buying a .de name does not translate the catalogue.
It tells Google you mean Germany. If the visible pages stay in English, you have sent a mixed message, and you have done it on purpose if nobody rewrites the pages.
Google also says not to adapt the content from the visitor’s IP. The crawler will not replay your site from every country to discover those variants. If you need more than one country or language, give each version its own URL and say so with hreflang. A domain change is a bad moment to invent a geo-redirect that the old site never had.
The captcha and the mail name move with the host name
A form that worked on the old name can fail on the new one without a single mail setting being “wrong”. reCAPTCHA site keys are registered to a list of domains. The new name is not on that list until someone adds it.
The full account of a key registered on the wrong domain is on the invalid-domain site key page. Check it before you call the form plugin broken.
The address you send mail from has the same habit. A From domain that does not match the site, or that has no permission to send, will be dropped after PHP thinks it succeeded. Fix the name in the form and in the DNS that authorizes mail, in the same change window as the home URL. Otherwise the launch looks done and the enquiries are not.
Four strings, not one address
The “new domain” is at least four strings. HTTPS or not. The www host or the bare host.
The name itself. The way paths are built. WordPress will store whichever combination you saved on the day you flipped the setting.
Pick one. Redirect the other three to it in the same window.
Leaving www and the bare name both returning 200 is a duplicate you built during a project that was supposed to make the site easier to understand. The certificate has to cover the host you picked. A name that loads in the browser with a warning is not launched, whatever the homepage headline says.
Let editors work before the world follows
Use a temporary hostname, or a hosts-file override, so the people pasting content can see the new site without a public DNS change. The public cutover is the last edit. It is not the way you invite a colleague to proof a page.
When they proof it, ask them to search the rendered page for the old host. Menus, canonical tags, and the sitemap are the usual hiding places. A homepage that looks right can still ship a sitemap of old URLs. That sitemap tells Google the move is a rumour.
Submit the new sitemap after that search is boring. Add the new name as its own Search Console property. Do not assume the old verification covers a name you just bought.
Watch crawl errors on the old property for the redirects you think you wrote. The file of one-to-one paths is what you compare against those errors.
The old name also lives outside the site
Email signatures, PDF quotations, and the footer of a catalogue you printed last year still carry the old host. A redirect keeps those links from dying. It does not rewrite the PDF in a customer’s downloads folder.
If the old name is being retired for a legal reason, the redirect window has to be long enough for the paper to age out. If you cannot say how long that is, you cannot cancel the old registration yet.
Tell the people who send quotations which host to type, in one line, on the day DNS changes. A sales mailbox that keeps proposing the old URL will outrun any sitemap you submit.
About the rankings in the title
This page’s title says “without losing rankings”. That is the hope. It is not a promise anyone can sell you.
Google’s own hiring note says no one can guarantee a number-one ranking, and it says to beware of a claimed special relationship with Google. The sentence is on Do you need an SEO?
What you can do is smaller, and it is checkable. Keep the old URLs redirecting to the matching new ones. Keep the content the same page, not a thinner summary.
Keep the new name’s country and language signals consistent with the pages a person can read. Then watch Search Console for the new property, and for crawl errors on the old one, without announcing a position you do not control.
Do the registration, the DNS, the database, and the redirects as four lines on a page, with a person’s name next to each. A domain change fails when those lines are one blurred task called “the move”.
Questions before the domain changes
Does a registrar transfer move the website?
No. Transferring the registration and changing the WordPress address are different jobs. The site can stay up through a registrar transfer if DNS is left alone.
Can the new domain be guaranteed to keep its rankings?
No. Google says no one can guarantee a number-one ranking. What you can check is a one-to-one redirect, the same document at the end of it, and country or language signals that match the visible page.
Where should the database export sit?
Outside the web root, or on a machine that is not the server. A SQL file in a public folder is downloadable. 36 backup copies on one of our own sites were.
Does the new name tell Google which country the site is for?
A country-code domain is a strong signal. Hreflang labels language and region. Server location is not a definitive signal. The visible words decide the language, not the URL and not the lang attribute.