Website Migration SEO: A Checklist to Move Your Site Without Losing Rankings

Moving a site to a new domain, platform or server is one of the riskiest jobs in SEO. In this guide I break website migration down by type and give you a separate checklist for each one. I have worked in digital marketing since 2012, so I will also share the mistakes I keep seeing in the field.

What is a website migration in SEO?

A website migration is any planned change to a site's domain, protocol, platform, URL structure or hosting that can affect how search engines crawl, index and rank it. The SEO goal is simple: pass the signals your old URLs have earned to the new ones and keep the traffic dip short.

In other words, a migration is not a copy and paste job. Google has known your old URLs for years. Links, clicks and index entries also point to them. During the move, then, you decide how that memory transfers to the new addresses. With a solid plan, the turbulence lasts a short while. Without one, the loss can drag on for months.

Google itself says as much in its documentation, too, because the risk is real. Its guide to site moves with URL changes warns that any significant change can cause ranking fluctuations while Google recrawls and reindexes the site. So the target is not zero movement. Instead, the target is a dip that stays short and under control.

I suggest you use this article as a working checklist. First, identify which type of move you face. Then work through the shared preparation steps and the section for your type. If one project combines several types, put all the relevant sections into a single timeline.

How is a website migration different from a redesign?

A redesign usually keeps you on the same domain. The look, the templates and sometimes the content layout change. I also covered that scenario in detail in how to protect SEO during a website redesign. A migration is the broader category: the address itself, the platform or the server changes.

In practice, the two often overlap. For example, an online store may launch a new design and switch platforms at the same time. In that case, then, you need both checklists. The distinction still matters, because the risks come from different places:

• In a redesign, the usual risks are lost content, broken heading structure and missing internal links.
• In a migration, the usual risks are missing redirects, wrong canonical tags, crawl blocks and lost signals.
• In a combined project, both groups hit at once. That is why splitting the timeline into phases is safer.

My advice: if you can, do not launch the new design and the new URLs on the same day. Keep them apart instead. Then, when traffic drops, you can find the cause much faster.

Which migration types exist and how risky is each?

Not every website migration carries the same weight. The table below sums up the six types I meet most often and their relative risk. Specifically, treat the risk column as a starting estimate from field experience, not a guarantee. Your site size and technical debt can also shift it.

The order gives you a rough sense of priority. However, risks stack when you combine types. Switching domain and platform on the same day, for instance, squeezes two high risk jobs into one launch.

What data should you back up before you start?

If something breaks after launch and you have no "before" snapshot, you cannot prove what changed. So my first step is always a thorough baseline.

• Search Console performance data for the last 16 months, exported by page, query and country.
• A full crawl: every URL, status code, title, meta description, canonical tag and H1.
• Analytics data: organic landing pages and the pages that drive conversions.
• A list of the pages with the strongest backlinks. These get top priority in the redirect plan.
• Copies of the current robots.txt, XML sitemap and any hreflang setup.
• Samples of your schema markup: product, article, FAQ and local business.

In addition, I record rankings for the top traffic pages. That way, after the move, you see exactly which page lost ground on which query. The prep takes a few hours. It also saves you days of guesswork later.

Store these files in a shared project folder with a date in the file name. Months from now, someone will ask how much traffic a page used to get. Then you will have the answer in seconds. Search Console keeps a limited history, so this backup may become your only source for long term comparisons.

How do you build a URL redirect map?

A redirect map is a simple list that pairs every old URL with its new destination. In every website migration, this is the step that takes the most effort. That said, it also pays back the most. Google lists preparing a mapping of old to new URLs as one of the first steps in its site move guide.

Here is the order I follow:

1. Merge all old URLs from your crawl, sitemaps, Search Console and analytics into one list.
2. For each old URL, find the closest new page by content. A one to one match always comes first.
3. Decide what happens to pages with no match. Either send them to a similar page or return a 404 or 410.
4. List parameter, pagination, trailing slash and letter case variants separately.
5. Test the full map in staging and confirm each row reaches its target in a single hop.

The shortcut I see most is redirecting every old URL to the homepage. Google does not treat mass redirects to an irrelevant page as helpful. As a result, you can lose the signals of the pages involved. To keep new URLs short and readable, try the slug generator.

What is the difference between 301, 302 and 308 redirects?

A permanent move calls for a permanent redirect. According to Google's documentation on redirects and Google Search, 301 and 308 are permanent. Google reads them as a strong signal that the target should become canonical. On the other hand, 302, 303 and 307 are temporary, so the source page may stay in search results.

The same page also adds a few details worth knowing:

• Server side redirects have the best chance that Google interprets them correctly.
• Google treats an instant meta refresh as permanent and a delayed one as temporary.
• Use JavaScript redirects only as a last resort. If rendering fails, Google may never see the redirect.

The site move guide also warns about redirect chains. Googlebot can follow up to ten hops, yet Google recommends fewer than three, because each extra hop slows users down. Before launch, run sample URLs through the redirect checker. Then confirm that each one lands on its target in one hop with the right status code.

What should you check when you change your domain?

Domain changes come from rebrands, mergers or a move from a country domain to a generic one. This is the highest risk type of website migration because every signal has to travel to a different domain. My checklist:

1. First, check the history of the new domain. A domain with a spam past can carry problems.
2. Verify both domains in Search Console as an owner, using the same Google account.
3. Redirect every old URL to its matching new URL with a page level 301.
4. Make sure canonical tags, hreflang and the sitemap on the new site all point to the new domain.
5. Once redirects work, start the Change of Address tool in Search Console.

The Change of Address help page explains that the tool only works for domain level properties. It expects a 301 from the old homepage to the new homepage, and its effect lasts 180 days. During that window, Google prioritises crawling the new site and forwards signals to it. Therefore, never let the old domain lapse inside those 180 days. Better still, follow Google's advice and keep redirects for at least a year, or indefinitely if you can.

What does an HTTP to HTTPS migration need?

Technically, HTTPS is a URL change, because the protocol is part of the address. Still, you stay on the same domain, so you do not need the Change of Address tool. Google's site move guide says so directly, in fact, so you can skip that step. My checklist:

• Confirm the certificate covers every hostname variant, with and without www.
• Redirect every HTTP URL to its HTTPS twin with a single 301 that keeps the path.
• Switch image, script and stylesheet calls in your templates to HTTPS to clear mixed content warnings.
• Update canonical tags, internal links and the XML sitemap to HTTPS addresses.
• Add the HTTPS property in Search Console, or check coverage if you use a domain property.

The mistake I see most often is two separate rules for www and HTTPS. As a result, http://site.com jumps to https://site.com and then to https://www.site.com. That two hop chain is not a disaster. Still, it is pointless. Instead, write one rule that sends every variant straight to the final address.

What tends to break during a CMS or platform switch?

Moving from WordPress to a custom build, from one ecommerce platform to another, or from a static site to a CMS tends to break things in places you do not look. The new platform shows the same pages, but it behaves differently underneath. In practice, I compare these areas one by one:

• Titles and meta descriptions. Bulk imports often leave them empty or reset them to a template default.
• Canonical tags. Some platforms force their own canonical logic on filter and sort pages.
• Schema markup. Price, stock and review markup may be missing in the new theme.
• Pagination and filters. A new parameter format can create thousands of new URLs.
• Image URLs and alt text. These affect traffic from image search.
• Page speed. A heavy theme drags down your Core Web Vitals.

Ecommerce platforms use very different URL patterns for categories and products. So before you choose a platform, ask how much control you will have over URLs. For large catalogues, also see category structure for large websites. I also support platform moves through ecommerce consulting.

Which mistakes should you avoid when changing URL structure?

Sometimes the domain and platform stay the same and only the URLs change. For example, you might drop dates from blog URLs, remove category folders or strip file extensions. This kind of website migration looks small, but its effect spreads across the whole site. Avoid these mistakes:

1. Changing URLs only because they will "look nicer". Without a clear gain, you take the risk for nothing.
2. Leaving internal links untouched. Even with working redirects, links to old URLs waste crawl budget and slow users down.
3. Forgetting trailing slash, letter case and extension variants.
4. Reusing an old URL for different content soon after the move.
5. Keeping both old and new URLs in the sitemap.

My rule is simple, so it is easy to remember. The new structure should be clean enough to last for years. Sites that change URLs every two years have to move their signals again each time. Before launch, build the new sitemap with the XML sitemap generator, and include only canonical URLs that return 200.

Does a hosting or server move affect rankings?

If URLs stay the same, a server move is the lowest risk type. Low risk is not zero risk, though. Google's guide to site moves without URL changes says you may see a temporary drop in Googlebot's crawl rate right after launch, followed by a steady rise over the next few days. Put simply, a brief crawl dip is normal.

Here is my checklist, based on that guide and my own practice:

• Lower your DNS TTL at least a week before the move so the change spreads faster.
• Make sure the new server has no robots.txt or noindex blocks left over.
• If you verify Search Console with an HTML file, copy that file to the new server.
• Use the URL Inspection tool to confirm Googlebot can reach the new server.
• Keep the old hosting live until traffic to it drops to zero.

You can check whether DNS records point to the new address with the DNS lookup tool. Also, watch the new server's response time. A slow server lowers crawl rate and hurts visibility indirectly.

Which pages should you keep when you merge two sites?

Mergers happen when two brands join forces or when a campaign microsite folds into the main site. This type needs the most judgement because moving every page one to one rarely makes sense. I sort each piece of content into one of three groups:

• Keep and move: pages with traffic, links or conversions whose topic the main site does not cover.
• Consolidate: if the main site already has a similar page, combine the strongest parts of both into one page and redirect the old one there.
• Remove: thin, outdated pages with no signals should return a 410 or 404.

Next, there is one more trap. When both sites competed for the same queries, their rankings do not simply add up after the merge. Google needs time to assess the new page, and fluctuation during that period is normal. The site move guide also notes that larger sites take longer to settle. For that reason, set realistic expectations from day one.

How do you protect hreflang on a multilingual site?

For sites that publish in several languages, a migration also means rebuilding the hreflang network. Every language version must reference all other versions at their new URLs. If one version still lists an old URL, the return link breaks and Google may ignore the annotations.

Specifically, here is what I check during the move:

• Hreflang tags should point to the final URL that returns 200, not to a redirecting one.
• Each version should list itself, and x-default should point to the right page.
• If language folders change, build a separate redirect map for each language.

I explain the basics in what is the hreflang tag. To generate tags for the new URLs quickly, use the hreflang generator. That also rules out the typos that creep in when you write tags by hand.

If you move language versions from separate country domains into folders on one domain, each old domain needs its own plan. For example, if the German version moves from a .de domain to a /de/ folder, you must redirect every page on that domain to its /de/ match and monitor the old domain in Search Console as well.

What should you test in staging before launch?

In practice, staging is your insurance policy. Protect the new site with a password or an IP allowlist, because you do not want the test copy in Google's index. That said, put the removal of that protection on your launch list as a separate item.

These are the checks I run in staging:

• Crawl every row of the redirect map in bulk. Each old URL should reach a 200 target in one hop.
• Compare titles, meta descriptions, H1s and canonicals of key templates side by side with the old site.
• Check mobile layout and page speed. Fix a heavy theme before launch, not after.
• Test forms, cart, checkout and thank you pages from start to finish.

Share this list with the team and give every item an owner. Then launch day becomes a verification exercise rather than a surprise. When you review meta tags in bulk, the Google SERP preview shows how each title will look in search results.

What should you do on launch day, step by step?

First, pick a low traffic day and hour. Avoid sale weeks in retail and quarter ends in B2B. My launch day list runs in this order:

1. Remove staging noindex tags and robots.txt blocks. Forgetting this is one of the most expensive mistakes I see.
2. Push the redirect rules live and test random samples from the map straight away.
3. Submit the new XML sitemap in Search Console.
4. For a domain change, start the Change of Address tool.
5. Check your most valuable pages with URL Inspection and request indexing.
6. Confirm that analytics and conversion tags fire on the new pages.

Google's guide notes that a sitemap with new URLs may show zero indexed pages at first. That is normal, so do not panic. If you need to rewrite robots.txt for the new structure, the robots.txt generator gives you a clean file. Finally, agree in advance who owns which kind of problem. Knowing whom to call saves minutes when something goes wrong.

What should you monitor in the first 30 days?

Launch is, in other words, only half the job. The real problems tend to surface later, as Google recrawls your old URLs. In the first 30 days I check these every day or two:

• Search Console crawl stats: spikes in 404, 5xx and redirect errors.
• The page indexing report: how fast new URLs enter the index and how many pages sit under "page with redirect".
• The performance report: the point where old and new URLs cross over in impressions and clicks.
• Server logs: which old URLs Googlebot still requests.
• Conversions: traffic can hold while a form or checkout flow quietly fails.

Next, compare everything with your baseline. Then you can tell quickly whether a drop is sitewide or tied to one template. For example, if only product pages fall, the product template is the likely cause. After week three you can check less often, but keep a monthly comparison going for at least six months. For the wider technical picture, read technical SEO after AI.

How long does it take to recover traffic after a website migration?

There is no single answer, because every site differs. Google's site move guide says that for a medium sized site, it can take a few weeks or more before Google shows the new URLs instead of the old ones. Larger sites can take longer still. That is the most solid official reference you have for setting expectations.

Here is a rough frame from my own work. Read it as a starting range from field experience, not a guarantee:

• Server moves and clean HTTPS switches usually settle within days to a few weeks.
• URL structure and platform changes can fluctuate for a few weeks to a few months.
• Domain changes and mergers can take several months. Some projects never fully return to the old level.

What stretches recovery most is slow fixing of errors found after launch. So your first 30 days of monitoring directly shape how fast you recover.

One more point, which people often ignore: avoid big content changes right before and after the move. Deleting pages, rewriting titles in bulk or opening new categories blurs the cause of any dip. Let the migration settle first, then start improving.

What are the most common website migration mistakes?

Over the years I have worked on migrations of many sizes, and I have also joined projects to rescue them after launch. Most failures come from poor planning and communication, not from a lack of technical skill. The ones I meet most:

1. The staging noindex tag goes live with the new site.
2. Every old page redirects to the homepage.
3. The site uses temporary instead of permanent redirects, because the software default is 302.
4. Nobody renews the old domain a few months later, and it lapses.
5. Canonical tags on the new site still point to the old domain.
6. Links in ads, emails and social profiles never get updated.

The last item does not look like an SEO issue, yet it matters. If nobody updates Google Ads final URLs, every paid click passes through a redirect and tracking can get messy. If you want to handle the paid side together, see my Google Ads management page.

Almost all of these mistakes share one root: the team treats the migration as a developer task only. Marketing, paid media and content teams need to know the timeline too. A short meeting and a shared checklist prevent most of these errors.

Should you run the migration yourself or get help?

For a small business site, the checklists above usually cover a server move or an HTTPS switch. However, if you are changing the domain or platform of an ecommerce site with thousands of URLs, the cost of a mistake easily exceeds the cost of help. Ask yourself:

• How much of your revenue comes from organic traffic?
• Does anyone on your team write and test redirect rules?
• Do you have time to monitor the site daily for 30 days after launch?

If you answer "no" to even one of these, a second pair of eyes makes sense. Through my SEO consulting service, I handle the pre-launch audit, the redirect map review and the post-launch monitoring. You can reach me directly through the contact page. There is no middleman, and we shape the plan together.

Whichever route you take, adapt these lists to your own project and tick off each step as you go. A migration rarely fails because of one big move. It fails because of small details that someone forgot.