A brand new website launching for the first time has nothing to lose. A website that’s replacing an existing one does - real rankings, real traffic, real backlinks that took months or years to earn. Get the switch wrong and you don’t just start from zero, you go backwards while Google works out what happened to a site it already trusted.
This checklist is for that second situation: you already have a live website, and you’re about to change something significant about it - the host, the domain, the platform, or the entire design - and you want to come out the other side with your rankings intact, not rebuilt from scratch.
If you’re launching a website for the very first time, use our 27-point website launch checklist instead - the concerns are different when there’s nothing yet to preserve.
Migration, Relaunch, or Rebuild? It Doesn’t Matter Which One You Call It
Strictly speaking, “website migration” means moving an existing site to a new host or server without changing the site itself. That’s not what most people mean when they search for a migration checklist, and it’s not really what this article is about either.
In practice, the same core risk shows up whenever you change any of the following: your hosting provider, your domain name, your CMS or platform, or your entire design and structure. Each of these can break the signals Google uses to recognise your site, sever the paper trail your existing backlinks rely on, or simply remove pages that other sites and search results still point to. Whether you call it a migration, a relaunch, or a rebuild, the checklist for protecting what you’ve already earned is the same one.
Who Actually Works Through This List: You, or Your SEO Professional?
Every item below is written so a business owner can do it without specialist help. But if you already pay someone to handle SEO on your current site, most of it is exactly the kind of work that should already be their job, not yours - the baseline recording, the content audit, the redirect mapping and its execution. Your job in that case is narrower: tell them the rebuild is happening early enough for it to matter (see #5), then check the boxes off together rather than quietly redoing their work yourself. If nobody currently handles SEO for you, the list is written so you can work through every step on your own.
Phase 1: Before You Touch Anything
1. Understand What You’re Actually Protecting, Not Just What You’re Changing
Most people commissioning a rebuild aren’t thinking about rankings at all - they’re sick of looking at a design that feels dated, and a fresh look is the entire brief. That’s a completely valid reason to rebuild. But the tired old site you can’t wait to replace has quietly been doing real work in the background, particularly if you’ve ever spent money on SEO, however long ago - rankings for the searches that bring in people who’ve never heard of your business by name.
Here’s the honest problem: if you’ve never actually checked what you rank for, “don’t lose your rankings” isn’t something you can measure against your own experience - you have no baseline to notice it’s gone. What you will check after launch is whether the new site is live and whether searching your own business name finds it. Neither tells you whether the generic searches that used to bring in strangers - “electrician Brisbane,” not your business name - still do. That’s what this checklist actually protects, even if it’s never once been on your radar.
2. Record Your Current Rankings and Traffic as a Real Baseline
Do this even if you’ve never looked at either of these numbers before - it takes ten minutes. First, make sure you can actually get in: a previous developer or an SEO agency may have set up Google Analytics and Search Console on your behalf without ever handing you access, so confirm you can log in and see your own site’s real data before you rely on either one. This matters more than usual around a migration: if the new site ends up with a fresh Analytics property instead of reusing the existing one, or the domain changes and Search Console needs a new property for it, your old data doesn’t get deleted - but it can end up stranded in an account you’ve lost access to or forgotten exists. Once you’re in, export your current organic traffic from Analytics and your current keyword positions from Search Console, both for the last 90 days, so you have a real number to compare against later rather than a vague feeling that “it seems slower now.”
3. Export a Complete List of Every Live URL
Pull every indexed URL from Google Search Console, your current XML sitemap, and your CMS’s own page list - these three sources rarely match exactly, and the gaps matter. Every URL on this list either needs an equivalent on the new site or a deliberate decision to redirect or retire it. Nothing should disappear by accident.
4. Audit What’s Actually Worth Keeping Before You Rebuild It
Not every page on your current site deserves to survive the move. Check which pages actually earn traffic, rankings, or backlinks in Search Console, and which ones are genuinely dead weight. While you’re in there, open the Pages report under Indexing and look at anything sitting in “Crawled - currently not indexed” - Google won’t tell you exactly why a page landed there, but stale content is a common pattern worth checking for: an old blog post citing “current” industry best practices or safety standards that have since changed can read as outdated, even if it was accurate when written. That doesn’t automatically mean the page is worthless - if it still has real traffic or backlinks, updating it with current information and carrying it forward is usually the better call than losing it. Keep a running note of which pages fall into which camp as you go - solid, stale-but-worth-updating, or genuinely dead weight - because that’s exactly what decides what gets redirected and what doesn’t (see #11).
5. Tell Your SEO Professional and New Developer About Each Other
A new agency or developer was hired to build and deliver a new website - not to safeguard the value built into the one it’s replacing. Unless migrating your existing rankings and redirects is specifically part of what you’re paying them for, don’t assume it’s happening by default; for most agencies, it isn’t in scope unless you ask. If you’ve separately been paying an SEO professional to work on your current site, tell them a rebuild is happening before it starts, not after - and where possible, get them talking directly to the new developer so the reasoning behind your existing URL structure and keyword targeting actually makes it into the new build instead of being quietly lost in the handover.
6. Set a Realistic Timeline, and Get Sign-Off From the Person Who Can See What You Can’t
Most business owners think about a new website the way they’d think about any other major purchase - a product they’re spending real money on, and nobody wants a rushed version of that. That instinct is correct, and it applies under the hood as much as it does to the design: a rushed migration is where redirects get skipped and testing gets shortened, not from carelessness, but because there simply wasn’t time to do it properly.
Loving the design is not the same as the project being finished. The design is the part you can actually judge for yourself - the redirects, the indexing, and the tracking setup are not, which is exactly why they’re easy to approve without really checking. Before you give the final go-ahead to go live, make sure your SEO professional has signed off on what’s under the hood, the same way you’ve already signed off on what you can see.
Phase 2: Building the New Site Safely
7. Build on Staging, Block It From Search Engines, and Keep Your Analytics Clean
The new site gets built and tested somewhere the public - and Google - can’t see it, not by editing the live site in place. Most hosts and platforms offer a staging environment as standard; if yours doesn’t, a password-protected subdomain works.
A staging site that gets crawled and indexed by Google creates duplicate content competing with your real site - and once indexed, it’s genuinely difficult to fully remove. Password-protecting the staging environment solves this at the source: a login wall stops search engines from ever reaching the content, so there’s nothing to crawl or index in the first place.
One more thing worth getting right early: don’t install your live Google Analytics property on staging “just to check it’s working.” Every test pageview and QA click gets recorded into your real numbers, quietly polluting the traffic and conversion data you’re trying to keep clean - right when #2 asked you to record a genuine baseline. Use a separate property, or none at all, until the site is actually live.
8. Don’t Assume Forms Still Work Just Because the System Didn’t Change
A new site built on the same platform, theme, or form plugin as your old one can still arrive with broken forms - a notification email pointing to the wrong address, a plugin update that quietly changes default behaviour, or settings that simply never got carried across. Test every form on staging before launch, confirming two separate things: the person submitting sees a proper thank-you message, and you actually receive the lead notification in your inbox. Passing this test on staging is necessary, but it isn’t the finish line - see #17.
9. Map Every Old URL to Its New Equivalent Before Launch
Using the URL list from #3, build a spreadsheet mapping every existing URL to where its content lives on the new site. This redirect map is the single most important document in the entire migration - it’s what stands between your existing rankings and a site full of dead links the moment you switch over.
10. Point Internal Links at Their Final URLs While You Build
As you populate the new site, watch for internal links that still point at your old URL structure - the most common example is a blog article linking to one of your own other articles using its old address. Left alone, the link still works because your redirect map catches it, but it’s not quite as good as it could be: every redirect adds a small delay and passes across slightly less ranking value than a link straight to the final page would. Point these links at the new URLs directly as you build the content, rather than leaning on the redirect to get visitors there.
11. Decide What Gets Redirected and What Gets Genuinely Retired
This is where the audit from #4 earns its keep. Anything you flagged as solid or worth updating gets a new home; anything that was genuinely dead weight - no real content, no traffic, no backlinks - can be allowed to return a proper 404 or 410 instead of being redirected somewhere unrelated just to avoid an error. Redirecting everything to your homepage “just in case” is a common mistake - Google treats a pattern of irrelevant redirects as a signal the site isn’t being maintained properly.
Phase 3: Launch Day - The Cutover
12. Schedule the Switch for Your Lowest-Traffic Window
Pick a day and time when the fewest real visitors are likely to be affected if something goes wrong - early morning or a weekend for most local businesses. That window gives you room to fix problems before they cost you real enquiries.
13. Implement Every Planned Redirect Before You Touch DNS
Every redirect from your map in #9 needs to be live and tested on the new site before it goes live to the public, not added afterwards as you notice gaps. A 301 redirect (permanent) is what passes ranking value through to the new URL - a 302 (temporary) doesn’t do this the same way, so check your platform is actually creating 301s by default.
14. Remove Every Staging Block the Moment You Go Live
The password protection from #7 needs to come off as soon as the site is genuinely public - forgetting this step is one of the most common launch-day mistakes, and it silently blocks Google from indexing your new pages while you wonder why nothing’s showing up. On WordPress, check Settings > Reading and make sure “Discourage search engines from indexing this site” is unticked - it’s routinely switched on during the build to keep staging private, and just as routinely forgotten once the site actually goes live.
15. Update and Resubmit Your XML Sitemap
Generate a fresh sitemap reflecting the new site’s actual URL structure and submit it through Google Search Console immediately after launch. This is what tells Google to prioritise crawling your new pages rather than waiting to stumble across them naturally.
16. Confirm HTTPS Is Active on the New Site, Not Just the Old One
A new website often comes with new hosting as part of the package. Don’t assume your SSL certificate carried across automatically just because it worked fine on the old site - check the padlock shows on every page of the new live site, and that nothing is still loading over HTTP. A mixed-content warning can quietly undermine visitor trust on launch day.
Phase 4: The First 48 Hours
17. Test Every Form Again, Now That It’s Genuinely Live
The staging test from #8 doesn’t guarantee the live site behaves the same way - moving to production can quietly break form handlers, SMTP settings, or notification routing that worked fine beforehand. Submit every form again on the live site, confirming once more that both the visitor’s confirmation and your own lead notification actually arrive.
18. Watch Search Console for Crawl Errors as They Come In
Check the Coverage report daily for the first week. New crawl errors in this window almost always trace back to a missed redirect or a page that didn’t survive the move intact - the earlier you catch these, the less ranking damage they do.
19. Spot-Check Your Redirects Manually, Not Just on Paper
Pick 15 to 20 of your highest-traffic old URLs and actually visit them in a browser, rather than trusting the redirect map was implemented correctly. A redirect that works in testing can still fail in production due to a caching issue, a rule that only partially matched, or a typo in the destination URL.
20. Confirm Analytics Is Actually Recording on the New Site
Check that Google Analytics is firing correctly on the new domain or platform, including on your thank-you and confirmation pages. A migration is exactly when tracking codes get lost, duplicated, or left pointing at the wrong property - and you need this data working from day one to judge how the migration actually performed.
Phase 5: The First Month - Recovery and Monitoring
21. Expect a Temporary Dip, and Know the Difference Between Normal and a Problem
Some fluctuation in rankings and traffic in the first two to four weeks is normal, even for a well-executed migration - Google needs time to recrawl, process your redirects, and re-establish trust in the new URLs. A genuine problem looks different: rankings that keep falling rather than recovering, or specific pages missing from the index entirely with no redirect explaining why.
22. Compare Rankings and Traffic Against Your Baseline Every Week
Go back to the numbers you recorded in #2 and compare them weekly, not just once. A steady week-on-week recovery toward your baseline is the sign of a migration going to plan. A number that’s flat or still dropping after three to four weeks is worth investigating properly rather than waiting it out.
23. Fix Broken Redirects and 404s as Search Console Surfaces Them
New crawl errors don’t stop appearing after the first 48 hours - Google continues discovering old URLs from external links, bookmarks, and its own historical index for weeks after launch. Keep checking Search Console and patching gaps in your redirect map as they turn up.
24. Update Your Google Business Profile and Key External Listings
If your domain or business name changed as part of the move, update your Google Business Profile, social media profiles, and any directory listings to point at the new URL. Inconsistent URLs across these platforms send confusing signals about which site is actually current.
25. Only Let the Old Domain Go If a Domain Change Made It Necessary
This one only applies if your migration included a domain change - if you rebuilt on new infrastructure but kept the same domain, there’s no old domain to let go of. There’s only ever been one, and once it’s confirmed serving your new site correctly, there’s nothing left to manage.
If you did change domains, keep the old one active and redirecting - even once everyone’s moved on to using the new domain day to day - until Search Console shows your new pages are indexed and the redirects are confirmed working. Letting it go too early can pull the plug on redirects that are still doing real work, sending both visitors and search engines into dead ends.
Before you let it go for good, check the Links report in Search Console for genuine backlinks still pointing at the old domain. Say you’d acquired a business that had spent years building up a genuinely well-read blog, cited and linked to from all over the internet - you’ve recreated that same content on your new site under new URLs, just as good if not better. None of that matters to the sites already linking to the original articles: those links point at the old domain specifically, and they only keep working today because that domain is still active and redirecting. The moment you stop owning it, every one of those links breaks outright - there’s no automatic handover to your new domain, no matter how faithfully you rebuilt the content. Where backlinks like that exist, it’s usually worth keeping the old domain going indefinitely rather than only until reindexing settles, so the sites that once considered that content worth linking to keep landing somewhere real.
A migration done properly is genuinely invisible to your customers and, within a month or two, invisible to your rankings as well - the whole point is that nothing looks like it changed except the parts you wanted to improve. If you’re weighing up whether your site needs a full rebuild in the first place, here’s how to tell; if you’ve already decided and just need the technical foundations done right, that’s what we build on.
Frequently Asked Questions
How long does a website migration usually take to complete?
The technical cutover itself can happen in a single day. Full recovery - rankings and traffic returning to baseline - typically takes two to six weeks, depending on how many pages changed URLs and how quickly Google recrawls the site.
Will my rankings definitely drop after a migration?
Some short-term fluctuation is normal even with a perfect migration, since Google needs time to reprocess the change. A properly mapped and tested redirect strategy is what keeps that fluctuation temporary rather than permanent.
Do I need 301 redirects for every single old URL?
Only for URLs worth preserving - pages with real traffic, rankings, or backlinks. Genuinely low-value pages can be allowed to 404 or 410 rather than redirected somewhere unrelated, which Google reads as a stronger signal than a pattern of irrelevant redirects.
Is a website migration different from a website redesign?
Not in practice. A redesign that keeps the same domain and hosting still carries migration risk if URLs, structure, or content change - the same checklist applies regardless of what triggered the change.
What’s the single most common migration mistake?
Forgetting to remove the staging site’s noindex tag and password protection at launch. It silently blocks the new site from being indexed, and it’s often not noticed for days because the site looks and works fine to visitors - it just isn’t showing up in search.
If you’re planning a migration, redesign, or platform switch and want it handled without losing the rankings you’ve already earned, get in touch to find out how YourStuff can help - or see how we approach website design from the ground up.
Photo by Taylor Vick on Unsplash
