Lots of companies update their websites each year. They change how the site is built and move to a different platform. They merge domains or move to HTTPS. And a lot of them watch their traffic take a hit right after launch. Not because Google decided to punish them. Usually, it's just that nobody sat down and actually worked through an SEO migration checklist before flipping the switch. Here's the thing about a website migration. It touches almost every signal Google uses to understand your site. URLs change. Content gets moved around. Internal links shift. Small things can break without warning, like how structured data is set up or how quickly pages respond. No one notices right away. A few weeks later, rankings start to slide. If you skip the planning step, you might throw away months of work.
A migration can go smoothly. It does not have to become a disaster. Do the prep work before the move. Pay close attention on launch day. Then leave time to fix issues and adjust after launch. When sites do this, they usually recover and stay on track. In some cases, rankings even improve. That outcome can still catch people off guard, especially those who think a migration always hurts performance. This guide walks through how to pull that off. There's a full website migration checklist below, a breakdown of the different types of migrations, a real case study, and answers to the questions we hear most from teams before they migrate.
Website migration can mean more than many people think. It is not just a simple move. It can involve changes to a site’s domain and its URL layout. The changes could also involve a platform switch, its look, or even the content. Any of that can shift how search engines find pages. How it lists the results or where they rank. Also, you do not have to change your domain for it to count. Redesigning your navigation counts. Switching from HTTP to HTTPS counts. Merging two sites into one count too.
What's actually happening under the hood is this. You're changing the address, or the presentation, of content Google has already crawled and ranked. Google now has to go rediscover that content and figure out where it fits under the new setup. Some ranking movement during that window is normal, even expected. That is why having a written SEO migration plan helps. Even when the updates look small at first.
Usually the more you change, the more risk you take. Tweaking a color scheme? Barely any SEO risk at all. Changing your domain name and switching platforms all in the same week? That's a high-risk project. It deserves real preparation not a rushed weekend before launch.
Some migrations are riskier than others. So, before you write a website migration SEO checklist, get some project details.
1. Platform Migration: Switching your content management system comes under this category. Even if the domain stays exactly the same, URL structure and technical SEO settings often shift here, sometimes more than teams expect going in.
2. Protocol Migration: moving from HTTP to HTTPS. This is usually safer than switching domains. Still, you should plan the redirects carefully and set up SSL the right way. If you miss those steps, duplicate pages can show up later as a problem.
3. Subfolder Migration: Moving from one subdomain to a subfolder means you take content from a subdomain like blog.example.com. Then you place it under a folder on the main site, like example.com/blog. Most teams do this so the value stays tied to one main root domain.
4. Site Migration: Reorganizing navigation or URL slugs without necessarily touching the domain or the platform. This tends to come up after a rebrand, or when a big content library just needs cleaning up.
5. Design Migration: It is basically a visual overhaul that keeps URLs and content mostly intact. It's the lowest risk on this list. But you still want to check for content that got dropped by accident or pages that got slower after the redesign went live.
7. Domain Migration: When content is moved from one domain to another. This comes up during rebrands. When companies merge multiple domains together. Or when switching country extensions. It's one of the riskier types out there since every URL on the site changes at once.
Most real projects, in our experience, blend two or three of these together. A rebrand often comes with a new domain, a new platform, and a new design all launching the same day. That's exactly the kind of combination where a proper SEO migration plan stops being optional.
A successful migration isn't really one SEO migration checklist. It's three of them, run one after another: before launch, on launch day, and after launch. Treat each phase like a gate. Don't move on to the next one until the current phase is finished and written down somewhere you can refer back to. The point of an SEO migration plan is pretty simple when you break it down. You can keep all the signals Google already uses for how you rank. That includes your URLs, your pages, your links from other sites, and your own internal links. You also need to carry over your technical status. Then you move to the new setup and do not lose any of it in the process. Everything in the website migration checklists below exists to protect one of those signals.
This phase decides most of the outcome, honestly. If a migration turns into a mess, it is usually because this part was rushed.
Begin by crawling your current site end to end. Use Screaming Frog or Site bulb for this step.
Pull every indexed URL along with its status code. Include title tag, meta description, H1, and canonical tag. This becomes your baseline, and trust us, you'll want it later when comparing before and after.
While you're at it, write down your current numbers too. Organic traffic along with keyword rankings and click through rates. Include conversions, page speed as well as backlink counts. Ideally, cover the past three to six months. Without this snapshot, you really can't tell how much the migration itself changed anything.
Then build your redirect map, and don't rush this part. Every old URL that's going to change needs a matching new URL, mapped by relevance and not by whatever's fastest. A thing we notice a lot is teams sending users to the homepage just because it is faster to set up. This move usually causes problems and can weaken rankings, even though the goal is to avoid risk.
Next, look for the content that already performs well. Use your top pages as the starting point. These are the URLs that drive the most visits, generate conversions, and earn links. Mark them so it is clear they are not optional. Also confirm the exact destination for each one after the new site goes live.
After that, write down what you have today on the technical side. Capture your robots.txt rules, your sitemap layout, and how canonicals are handled. If you use more than one language, include the hreflang setup. Note your schema markup too. List how your internal links are built and where they point. Do not skip this part before changes start, since you will need to copy it cleanly on the new site.
Then build the new site on staging first. Make sure search engines cannot crawl it. Use password access or a noindex tag plus a disallow rule. If a staging site gets indexed by mistake, you end up with extra work that is hard to clean up.
Move through each on page item with care. Title tags have to be copied. Meta descriptions also need to be carried over. Check header tags and make sure they stay in place. Update alt text so it still matches the images. Review internal links too. Everything should transfer to the new site, or be improved there. Do not let a site migration remove work you already built over the years without a fight.
Before you go live, run redirect tests in staging. Look at every old URL one by one. Confirm it lands on the correct new page. Each redirect must be a 301. Avoid a 302. Also avoid redirect chains that hop three or four times before the page finally loads.
Get the sitemap set up for your final URL layout. Use the structure you plan to ship. Wait to submit it until launch day.
Loop in the right people early. Stakeholders, backlink partners, anyone linking to your old URLs, a heads up goes a long way here.
And pick your launch window with some thought behind it. Pick a slower time slot. Don’t start right before a large campaign or a rush season. Leave yourself an extra couple of weeks after launch, at least two to four. Then you can see how everything levels out.
Launch day is really just executing the plan you've already built, then checking everything carefully before calling it done.
Push the new site live at your planned time, and turn on every redirect from your mapping at that same moment, not a few hours later.
Spot check a handful of redirects right away. Test some of your highest traffic pages and confirm they redirect properly, without bouncing through multiple hops before landing where they're supposed to.
Update robots.txt. After the move, remove any staging blocks that are still in place. Also make sure the live site can be crawled by search engines.
When the site launches, send the sitemap right away. Do this in Google Search Console and in Bing Webmaster Tools.
Then ask Google to index your top pages. Use the URL Inspection tool in Search Console. This helps you avoid waiting for Google to pick them up later.
Go over the canonical tags again. Each page should either reference itself or the correct preferred URL. Make sure nothing is still pointing to the old site.
Finally, test a few main page templates with Google’s Rich Results Test. Check that the structured data you added is showing up as expected.
Confirm tracking is working properly. Google Analytics, Search Console, conversion tracking, any pixels running in the background, all of it needs to fire correctly before you consider launch finished.
Watch your server for a few hours after you start it. Check the logs and the status codes often. That way you can spot 404s or crawl blocks early, before they turn into a bigger problem.
Launch day isn't really the finish line. The next four to twelve weeks are what actually decide whether the migration worked.
In the Search Console, check the Crawl Stats report. It can show if Google is reaching your new URLs as you intended.
Also watch the indexing section. The Pages report shows how fast new URLs get added and old ones get dropped.
Expect some crawl errors that first week, that's pretty normal. When you spot a missing redirect, add it to your map right away.
Check your organic traffic and rankings every day at the start. After that, move to a weekly check. Compare what you see now with the benchmark you wrote down earlier. A small drop in the first two weeks is usually not a big deal. A steady decline that just keeps going- that's the sign something needs attention.
Watch for redirect chains. Clean up anything bouncing through more than one URL before landing on its final destination.
Check internal links across the new site. Link directly to the final URLs. Do not point at old links that force another redirect later. That extra jump adds time and serves no real purpose.
For your top backlinks, contact the site owners. Ask them to swap the link so it goes to your new URL. Relying on redirects by itself is not a good long-term plan.
About day thirty, do another full technical check. Use the first baseline as your reference. Look at load times, mobile usability, and structured data.
Then send updates at day thirty, day sixty, and day ninety. Include traffic numbers, ranking changes, and conversion results. Stakeholders should see the trend as it happens, whether it is better or worse.
If you moved to a new domain, leave the old redirects on. Keep them running for at least twelve months.
Plenty of teams just leave them running indefinitely, since old backlinks and bookmarks have a way of sticking around a lot longer than anyone expects.
A few migration types need extra attention in specific spots.
For a domain migration, put most of your effort into the redirect map and into using the Change of Address tool in Search Console. Reach out to your highest value backlink sources directly if you have the bandwidth for it.
When you migrate a platform, keep an eye on what is already on the pages. Titles and meta descriptions matter a lot. Also watch the schema data. It does not always move over by itself.
If you switch from HTTP to HTTPS, check every internal link. Make sure each one goes to the HTTPS page. Also update the canonical tags to match HTTPS. Finally, confirm your sitemap lists the HTTPS URLs too. This helps avoid duplicate pages.
For a subdomain to subfolder migration, focus on consolidating duplicate content and confirming the subfolder actually inherits authority from the old subdomain instead of starting from zero.
For a redesign that keeps the same URLs, focus on page speed and on confirming nothing got quietly dropped somewhere during the rebuild.
A mid-sized B2B services company decided to merge a legacy WordPress site and a separate subdomain blog into one modern platform on a brand-new domain. That is a domain shift, a platform shift, and a design shift. All of it happening in the same window. When teams do this without extra care, things often go wrong.
Right before launch, the team wrote a redirect list for every URL that was already indexed on the site. They pulled six months of organic performance data as their baseline and ran the new site in a blocked staging environment for three weeks of testing. On launch day, every redirect went live the same moment the new domain did. The sitemap was submitted within the hour, and priority pages were manually resubmitted for indexing right away.
Traffic dropped about twelve percent over the first ten days, which the team had actually expected, since Google needed time to recrawl the new domain. Weekly technical audits caught a couple of redirect chains and a batch of internal links still pointing at old URLs, and both got fixed fast.
By day forty-five, traffic was back to its pre migration level. By day ninety, it had climbed eight percent above the original baseline, thanks mostly to faster page speed and a cleaner site structure. The takeaway is pretty simple, really. A short dip right after launch is normal. A migration succeeds or fails based on timing. It comes down to how fast the team spots issues and corrects them. This is especially true in the first weeks after the change.
Most well-planned migrations settle within two to eight weeks. Bigger projects, especially ones combining a domain change with a platform change, can take three to four months to fully stabilize. Recovery speed usually comes down to how complete and accurate the redirect map was going in.
Some short-term movement is normal, since Google needs time to recrawl and reassess your new URLs. That's not automatically a sign something went wrong. If the decline keeps going and does not stop after a couple of weeks, it often means there is a clear cause. It can be something like redirects not working anymore. Or there could be some pages that have been removed.
Pretty much, yes, for any page that changes and has traffic, backlinks, or indexing history behind it. Pages with no traffic and no backlinks can sometimes skip a redirect, but if you're unsure, just redirect it to the closest matching page anyway.
Treating the redirect map like an afterthought. A lot of teams throw it together right before launch instead of starting early on. Most migration breakages come from redirects that are missing or wrong. It is not some kind of algorithm punishment.
You can get pretty close with careful planning, but a truly risk-free migration is rare unless it's a small cosmetic tweak. A realistic goal is a short and controlled dip. It’s usually followed by full recovery, not zero change whatsoever.
When you move your blog folder first, you can cut down on the chance of trouble. If something breaks, you will likely notice it sooner. For smaller sites, one coordinated launch is usually simpler and just as safe either way.
A site migration is one of the highest stakes projects in SEO, but it's also one you can actually control. The businesses that come out ahead aren't the ones with the flashiest new design. They're the ones that treated the redirect map, the pre-launch audit, and the post launch monitoring window just as seriously as the design itself. If you're planning a migration and want a team that handles this before mapping redirects, protecting rankings, and rebuilding technical SEO from the ground up, Infinenetech's Search Engine Optimization and Web Development teams can manage the whole process for you. The goal is simple. Your rankings should come out of the transition intact, or even stronger than they went in.
