"Migration" covers three very different jobs. Moving host is low risk and mostly mechanical. Moving to HTTPS is low risk if the redirects are right. Changing domain or URL structure is where rankings actually get lost.
This covers all three, with the steps in the order I do them. The single most important rule applies to all of them: never change two variables at once.
Quick Info
Host change
Low risk. Nothing visible to search engines if done properly
HTTPS change
Low risk with correct redirects
Domain or URL change
Real risk. Requires a complete redirect map
Golden rule
One change at a time, settled before the next
Expected dip on a domain change
Two to six weeks
Keep the old host running
At least two weeks after
Before any migration: benchmark
01Crawl the site and export every URL.
02Export your top 100 pages by organic traffic and impressions.
03Export your top 200 queries with positions.
04Export your backlink profile so you know which URLs have earned links.
05Record current Core Web Vitals.
06Take a full backup of files and database and keep it somewhere off the server.
Do this even for a simple host move. It costs twenty minutes and it is the only way to answer the question "was it always like that?" afterwards.
Migration type one: changing host
URLs stay identical, so search engines have nothing to re-evaluate. Risk comes from downtime and from missing something in the copy.
01Ask the new host to do the migration. Most managed hosts do it free and do it well.
02If doing it yourself, use a migration plugin or copy files and database manually, then import.
03Test thoroughly on a temporary URL or by editing your local hosts file, before touching DNS.
04Lower your DNS TTL to 300 seconds a day beforehand so the switch propagates quickly.
05Change the nameservers or A record. Both hosts serve the site during propagation, which is why you keep the old one running.
06Verify SSL is active on the new host before the switch, so there is no window without it.
07Test forms and email delivery. Email is the thing that breaks and nobody checks.
08Keep the old hosting live for at least two weeks.
Do not cancel the old account the same day. The one thing you forgot to copy will surface in week two.
Migration type two: HTTP to HTTPS
Still occasionally needed on older sites. Mechanically simple and easy to leave half-finished.
01Install the certificate. Most hosts provide it free and automatically.
02Update the WordPress and site address settings to https.
03Run a search-and-replace across the database for http://yourdomain to https://yourdomain, to fix hard-coded links and images.
04Redirect all http URLs to their https equivalents, permanently, at server level.
05Fix mixed content warnings. Usually an image or a script still called over http.
06Update canonical tags and your sitemap.
07Add the https property in Search Console and submit the new sitemap.
08Update your analytics property settings.
The common failure is a half-migrated site: https available but http not redirected, so both versions exist and split your signals.
Migration type three: changing domain or URL structure
This is the one that costs rankings when done carelessly. Everything depends on the redirect map.
01Build a spreadsheet of every old URL and its new equivalent. Every row filled, no blanks.
02Map like to like. A service page goes to the equivalent service page, never to the homepage.
03Never bulk-redirect everything to the homepage. Search engines treat that as a soft 404 and discard the value.
04Implement as permanent 301 redirects, ideally at server level rather than through a plugin.
05Update internal links in your content to point directly at the new URLs, rather than relying on the redirects.
06Test every redirect before launch, on staging, and test the top twenty by hand after launch.
07Add the new domain in Search Console and use the change of address tool if the whole domain is moving.
08Update your sitemap and submit it.
09Reach out to the sites linking to you most valuably and ask them to update. Not all will, and the ones that do are worth the emails.
Every redirect that points somewhere generic is a page's history thrown away. The map is the migration.
The things people forget
—Email. If it was hosted with the website, it moves separately and it breaks quietly.
—Cron jobs and scheduled tasks. Backups, newsletters and imports all silently stop.
—Third-party integrations with the old domain hard-coded: payment webhooks, booking systems, CRM forms.
—Analytics and tag manager configuration.
—Search Console verification on the new setup.
—Any hard-coded absolute URLs in theme files or custom code.
—Robots.txt, which is often copied from staging complete with a blanket disallow.
The staging noindex tag surviving into production is the most common self-inflicted migration disaster, and it takes weeks to notice.
Launch day sequence
01Full backup of the old site, kept for six months.
02Deploy or switch.
03Implement redirects.
04Remove any noindex and confirm robots.txt allows crawling.
05Submit the sitemap in Search Console.
06Crawl the live site and check for 404s and redirect chains.
07Hand-test the top twenty old URLs.
08Confirm analytics is recording and forms are arriving.
Tuesday morning, not Friday afternoon. The problems appear within six hours.
The four weeks after
—Check Search Console coverage daily for the first week, watching for 404 spikes.
—Watch impressions rather than sessions. A short dip is normal on a domain change; a continuing decline after three weeks is a problem.
—Collapse redirect chains where A points to B points to C.
—Compare your benchmarked top pages against current positions and investigate specific losers rather than the average.
—Expect full recovery on a well-executed domain change within four to eight weeks.
If a specific page has lost position while the rest held, check its redirect and whether its content actually survived. Those two explain nearly every individual case.
Frequently Asked Questions
Will changing host affect my SEO?
No, if URLs stay the same and downtime is minimal. Search engines see the same site at the same addresses.
How long do I keep redirects?
Permanently, or a year at absolute minimum. Old links and bookmarks persist for years and the redirect is what preserves their value.
Can I redesign and change domain at the same time?
You can and you should not. Combining them makes it impossible to tell which change caused any problem. Do one, wait a month, do the other.
How long until rankings recover after a domain change?
Usually two to eight weeks with a complete redirect map. Longer or never if the mapping was incomplete.
Should I use a migration plugin or my host?
Let a managed host do it if they offer it. Migration plugins are good and hosts do this daily and fix their own mistakes.
What if I already migrated and lost traffic?
Crawl your benchmarked old URL list against the live site to find 404s, check for a leftover noindex, and compare content on the pages that fell. Those three checks find most causes.
Before You Go
Host moves are routine, HTTPS is routine, and domain changes require a spreadsheet with no blank rows. The migrations that go wrong are almost never technically difficult; they are ones where nobody owned the redirect map.
Benchmark first, change one thing, keep the old host running. If the migration is part of a redesign, the redesign checklist covers the content parity side.
One change at a time. Fill every row of the map.
WRITTEN BY TARIQ SALLAM
Marketing Consultant. Entrepreneur. Content Creator.
I'm a marketing consultant, entrepreneur and content creator. I help businesses grow through practical marketing, websites, SEO, content and AI.
More About Tariq →
Keep reading