Introduction

Moving a WordPress site — to a new host, a new domain, or from HTTP to HTTPS — touches every signal Google uses to evaluate a page: its URL, its speed, its internal links, and its authority. Done carefully, a migration costs you a few weeks of wobble and then settles. Done carelessly, it costs you rankings that take months to win back.

The difference is almost never luck. It is a checklist, worked through in order, with a rollback plan for the day something goes wrong. This guide is that checklist, split into three phases: before launch, launch day, and the first month after. It covers the three kinds of move you are most likely to make — a host change on the same domain, a domain change, and an HTTP-to-HTTPS switch — and it flags which steps matter most for each.

Know which kind of move you are making

Not all migrations carry the same risk, and the checklist below applies differently to each:

• Host change, same domain. The lowest-risk move. URLs do not change, so no redirects are needed. The risks are downtime, a slower server, and a broken copy of the site.
• Domain change. The highest-risk move. Every URL changes, which means every backlink, every cached search result, and every internal link points to a dead address until redirects are in place. This is the move where the redirect map and the Search Console Change of Address tool matter most.
• HTTP to HTTPS. A medium-risk move. Every URL changes its protocol, so redirects are needed, but the structure stays the same and the move is well understood.
• Platform change (away from WordPress, or to WordPress from another CMS). The most complex move. URL structures, templates, and structured data often change at the same time. If you are doing this, treat every URL as a potential redirect and budget extra time for testing.

Whatever the type, the principle is the same: change one thing at a time. Do not combine a domain change with a redesign and a host change on the same day. If the rankings drop, you will not know which change caused it.

Phase 1: Before launch — the pre-migration checklist

Do all of this while the old site is still live and healthy. Rushing the preparation is how migrations fail.

1. Take a full backup. Files plus database, stored somewhere other than the server you are moving away from. Test that the backup can actually be restored — a backup you have never restored is a hope, not a safety net. Note the backup’s date and location.

2. Record your current rankings and traffic. Export your top pages from Google Search Console — impressions, clicks, and average position for the past three months. Note your total organic traffic and your top ten pages by clicks. These numbers are your baseline; without them, you cannot tell after launch whether the migration hurt you or whether traffic was already falling.

3. Crawl the site and list every URL. Use a crawler such as Screaming Frog or your Search Console data to produce a complete list of every indexed URL, its status code, and its internal links. This list becomes your redirect map. Include pages that no longer have internal links but still receive traffic or backlinks — the Search Console Links report (top linked pages) and the Page indexing report will surface those.

4. Build the redirect map. For a domain change or a URL-structure change, map every old URL to its new equivalent in a spreadsheet: old URL, new URL, redirect type (301). The rule is strict: every URL that has ever received a backlink or appeared in search results needs a 301 redirect to the most relevant equivalent page. Redirecting everything to the homepage is not a substitute — Google treats a homepage redirect for a non-homepage URL as a soft 404. Use permanent redirects (301, or 308, which Google treats the same way), one hop each: if page A went to B and B now goes to C, point A straight to C. Redirect chains pass less value and slow crawling down.

5. Save your SEO titles, descriptions, and settings. Export your SEO plugin’s settings and note your title and meta description templates, your canonical settings, and any custom robots rules. A migration is a bad time to discover that the new install has different defaults.

6. Set up staging and test the copy. Move a copy of the site to the new host or domain on a staging URL first. Test it thoroughly: do the pages load, do the forms work, do the images load, do the internal links point to the right place? Check the site on a phone as well as a desktop. Block search engines from the staging copy with a password or a noindex setting so Google does not index a duplicate.

7. Lower the DNS TTL. At least 24 hours before the move, lower your domain’s DNS time-to-live to 300 seconds (5 minutes). This means that when you switch the DNS records on launch day, the change spreads quickly instead of taking a day to reach every visitor.

8. Decide what happens to retired pages. Every old URL gets one of three outcomes: it moves to the same address on the new site, it moves to a new address (and gets a redirect), or it is retired. Retired pages with a close match get a redirect to that match; retired pages with no match return a proper 404. Decide this now, not on launch day.

Phase 2: Launch day — the migration control sheet

Work through this list in order, and tick each item off as you go. If any step fails, stop and fix it before moving to the next — do not press on and hope the later steps cover it.

#	Step	Done?
1	Confirm the backup from Phase 1 is current and restorable	☐
2	Put the old site in maintenance mode if the host move involves downtime	☐
3	Move the files and database to the new host, or point the domain at the new install	☐
4	Update the WordPress Address and Site Address in Settings → General (domain change)	☐
5	Run a search-and-replace on the database for the old domain (use a migration plugin or WP-CLI’s search-replace with a dry run first; never edit the database by hand in a text editor)	☐
6	Activate the 301 redirect map on the old domain/host	☐
7	Test the new site: homepage, five top pages, a post, the contact form, and the checkout or sign-up flow if there is one	☐
8	Check that the new site is not accidentally blocking search engines (Settings → Reading → “Discourage search engines” must be off; remove any staging noindex)	☐
9	Submit the new XML sitemap in Search Console under the new property	☐
10	For a domain change, submit a Change of Address request in Search Console (see below)	☐
11	Test the old URLs: each one should return a 301 to the correct new URL, in one hop	☐
12	Announce the move to your audience if the domain changed (email, social media)	☐

The Change of Address tool. In Google Search Console, this tool formally notifies Google of a domain move. It has conditions worth knowing: you must own both the old and new properties in Search Console, it works only on domain-level properties, and it requires that 301 redirects from the old pages to the new ones are already in place — it checks that a few pages return 301s before it accepts the request. To use it, add and verify the new domain as a property, open the old property, go to Settings, choose Change of Address, and select the new property. The tool is not needed for an HTTP-to-HTTPS move, for switching between www and non-www on the same domain, or for path changes within one domain.

Keep the old domain and hosting alive. Do not cancel the old domain or the old hosting yet. The old site is where your redirects live, and Google needs them. Keep the redirects in place for at least a year — Google’s own guidance asks for at least 180 days and recommends longer if you still see traffic arriving at the old URLs — and keep the old domain registered for at least a year so nobody else can buy it.

Phase 3: The first month — monitoring and fixes

A migration is not finished on launch day. Rankings typically wobble for two to four weeks after a domain change while Google recrawls and consolidates signals, and a same-domain host move usually stabilizes within a few days. What matters is watching the right numbers and fixing what breaks.

Week 1 — daily checks:

• Crawl the old domain and confirm every redirect still returns a 301 with the correct destination, in one hop.
• Check Search Console’s Page indexing report daily for new errors — especially 404s on URLs that should have redirected, and redirect errors.
• Check that the new sitemap was accepted and that Google is indexing the new URLs. If new pages are not appearing, our guide on getting your website indexed by Google covers the checks to run, and if pages show up as crawled but not indexed, see our guide on fixing crawled — currently not indexed.
• Watch for a spike in 404 errors and fix the redirect map for any URL you missed.

Weeks 2–4 — weekly checks:

• Compare organic traffic and rankings against the baseline you recorded in Phase 1. Expect a dip for a domain change; a sharp, sustained drop beyond the first two weeks is a signal to investigate, not to panic.
• Update internal links across the site to point directly at the new URLs. Redirects handle the transition, but internal links should not rely on redirects permanently — they slow crawling and leak value. The same applies to your most important external links: contact the sites that link to your top pages and ask them to update the link.
• Check that canonical tags, structured data, and your XML sitemap all reference the new domain. A sitemap that still lists old URLs, or canonical tags pointing at the old domain, will confuse Google. Our guide on creating an XML sitemap and submitting it to Google covers the sitemap side in detail.
• Monitor site speed on the new host. A slower server after a host change can quietly cost rankings; measure it the way our loading-speed guide describes and fix the bottleneck before it becomes a trend.

Rollback criteria — when to reverse the move:

• The new site is down or broken for more than a few hours and the host cannot fix it: restore the backup on the old host and re-point DNS.
• Search Console shows that a large share of your top pages are returning errors after a week, with no clear fix: pause, restore the redirect map, and investigate before the damage compounds.
• Traffic falls by more than half and keeps falling after two weeks with no recovery pattern: treat this as a migration fault, not a normal wobble, and audit the redirects, the sitemap, and the canonical tags before doing anything else.

A rollback is not a failure. It is the reason you made a backup and kept the old hosting alive.

Common migration mistakes

• Skipping the redirect map. The number-one cause of lost rankings. Every indexed URL needs a destination.
• Redirecting everything to the homepage. Google treats these as soft 404s. Redirect to the closest relevant page, or let the page 404 properly.
• Forgetting the staging noindex. A staging copy that gets indexed creates duplicate content and splits your rankings.
• Cancelling the old hosting too soon. The redirects die with it, and the rankings die with the redirects.
• Changing the URL structure at the same time as the domain. Two changes at once make it impossible to tell which one caused a problem. Keep the URL structure identical across a domain change if you possibly can.
• Not telling Google. A domain change without a Change of Address request and a new sitemap leaves Google to discover the move on its own, slowly.

The bottom line

A WordPress migration without losing SEO is a planning exercise, not a technical trick. Back up, record your baseline, map every URL, test on staging, redirect every old URL to its matching new one in a single 301 hop, tell Google through Search Console, and keep the old domain and redirects alive for at least a year. Expect a few weeks of wobble after a domain change; investigate a sustained drop. And if anything goes badly wrong on launch day, the backup and the rollback plan you prepared in advance are what save the site — which is why they come first, not last.

Frequently asked questions

How long does it take for rankings to recover after a migration?
A same-domain host move usually stabilizes within a few days. A domain change typically takes two to four weeks of fluctuation while Google recrawls the redirects and consolidates signals. A longer, deeper drop usually means something in the redirect map, sitemap, or canonical tags is wrong.

Do I need a plugin to migrate WordPress?
Not necessarily — you can move files and the database manually — but a reputable migration plugin reduces the risk of a broken copy, especially for the database search-and-replace step. Whichever route you take, test the copy on staging before launch day.

What happens if I forget a redirect?
The old URL returns a 404, visitors and Google hit a dead end, and any ranking value that URL carried is lost. Check Search Console’s Page indexing report in the first week after launch and add redirects for every missed URL.

Can I migrate without any downtime?
For a host change, usually yes: set up the copy on the new host, test it, then switch DNS with a low TTL. For a domain change, there is a short window while DNS propagates, but with the TTL lowered in advance it is typically minutes, not hours.