
A practical, step-by-step website migration SEO checklist for protecting rankings, traffic, URLs, analytics and conversions before, during and after launch.
This website migration SEO checklist is for anyone changing hosts, platforms, domains or URL structures without wanting to sacrifice the traffic they have already earned. A website can look perfect on launch day and still lose enquiries two weeks later.
The pages load. The new design works. Nothing appears broken. But Google starts dropping old URLs from its index, valuable backlinks lead to error pages, and organic traffic quietly falls.
This usually happens because the migration was treated as a file transfer. In reality, moving a website means transferring years of search history from one set of pages, URLs and technical signals to another.
Whether you are changing hosting, moving from WordPress to Shopify, switching domains or rebuilding the whole site, this website migration SEO checklist will help you protect what the old website has already earned.
What counts as a website migration?
A website migration is any significant change that affects how visitors or search engines access your site. Common examples include:
- Moving to a new hosting provider
- Changing your domain name
- Moving from HTTP to HTTPS
- Switching platforms, such as Magento to Shopify
- Rebuilding a WordPress website
- Changing the URL structure
- Combining two websites
- Redesigning a website while moving or removing pages
Not every migration carries the same risk. Moving to another host while keeping every public URL unchanged is usually straightforward. Changing the domain, platform, content and URL structure at the same time is far more complicated.
Where possible, change one major thing at a time. It makes problems easier to identify and reduces the number of variables affecting traffic.
Website Migration SEO Checklist: Before the Move
1. Create a complete list of existing URLs
Start by recording every useful URL on the current website. Do not rely only on the XML sitemap. It may exclude old landing pages, images, PDFs or pages that still receive traffic.
Build the inventory from several sources:
- The website's XML sitemap
- Google Search Console
- Google Analytics
- A complete website crawl
- Server logs
- The content management system
- Pages receiving external backlinks
- Advertising and email campaign landing pages
Record each page's title, status code, canonical URL, organic traffic and proposed destination. This becomes the working document for the migration.
2. Benchmark current performance
You need a clear picture of the site before it moves. Otherwise, you will not know whether the migration caused a problem.
Record organic traffic, conversions, indexed pages, important rankings, top landing pages, Core Web Vitals, crawl errors and backlinks to valuable pages. Take particular care with pages that generate enquiries or sales. A page receiving modest traffic may still be commercially important.
3. Decide which pages will stay, change or disappear
A migration is a useful time to remove genuinely outdated content, but deleting pages without checking their value is risky.
For every existing URL, choose one outcome:
- Keep the same URL
- Move it to a new equivalent URL
- Combine it with another relevant page
- Remove it because it has no useful replacement
Do not redirect every removed page to the homepage. Visitors expect to reach something relevant, and Google may treat unrelated redirects as soft 404 errors.
4. Build a one-to-one redirect map
Your redirect map connects every old URL to its most relevant new destination. Use server-side permanent redirects, normally 301 or 308, when a page has permanently moved.
Avoid chains such as old URL to temporary URL to final URL. Send the old address directly to its final destination. This is faster for visitors and easier for search engines to process.
Google's site migration guidance recommends permanent server-side redirects and says migration redirects should generally remain in place for at least one year. Keeping useful redirects longer is often better for people using old bookmarks or external links.
5. Preserve important on-page SEO
A new design should not accidentally remove the information search engines use to understand each page.
Transfer and review:
- Page titles and meta descriptions
- H1 and supporting headings
- Main page content
- Image alt text
- Canonical tags
- Structured data
- Internal links
- Images and downloadable files
Do not rewrite every successful page during the same migration unless there is a clear business reason. If traffic changes, you need to know whether the cause was the move, the new content or both.
6. Build and test on staging
Prepare the new website in a private staging environment while the current site remains live. The staging site should not appear in search results. Protect it with authentication or appropriate indexing controls, then make sure those controls will not carry over to production.
Test more than the design. Check forms, confirmation emails, checkout, user accounts, search, analytics events, cookie consent, mobile layouts, downloads, canonical tags, structured data, internal links and page speed.
A good migration also has a written rollback plan. If a critical function fails after launch, the team should know exactly how to restore the previous site.
During launch
7. Choose a sensible launch window
Launch when traffic and sales are normally lower, not simply when the development work happens to finish. For an ecommerce site, avoid promotional campaigns and seasonal peaks. For an international business, check traffic by customer time zone first.
Keep the old hosting available during the changeover. Do not cancel it immediately after updating DNS.
8. Activate and test every redirect
Once the new site is live, crawl the old URL list and verify that:
- Every old URL reaches the correct destination
- Redirects lead to relevant pages
- There are no loops or unnecessary chains
- Destination pages return a successful 200 status
- HTTP, HTTPS, www and non-www versions behave correctly
Test the URLs receiving the most traffic and backlinks manually as well. These pages deserve more than an automated green check.
9. Remove accidental indexing blocks
One line left over from staging can make an otherwise successful migration disappear from search.
Confirm that the live site does not contain a site-wide noindex directive, robots.txt rules blocking important sections, canonical tags pointing to staging, password protection or links that still use the staging hostname. Use Google Search Console's URL Inspection tool to test several important pages.
10. Update analytics and Search Console
Make sure analytics starts recording traffic immediately after launch. Check the tracking code, conversions, advertising pixels, consent settings, Search Console ownership, XML sitemap and reporting filters.
If the domain changed, use Search Console's Change of Address tool where applicable. Monitor both the old and new properties while search engines process the move.
After the migration
11. Crawl the new website again
Run another complete crawl after launch and compare it with the original URL inventory. Look for broken internal links, unexpected 404 pages, redirect chains, missing titles, incorrect canonicals, orphan pages, missing images, duplicate content and pages blocked from indexing.
Every important page needs to be accounted for. A working homepage does not prove that the rest of the migration succeeded. If ongoing checks are not handled in-house, a structured website maintenance plan can cover broken-link monitoring, backups and technical checks after launch.
12. Monitor traffic without panicking
Some ranking fluctuation is normal while Google crawls the redirects and processes the new URLs. Google notes that moving a small or medium-sized site can take several weeks, while larger migrations may take longer.
Watch the direction of travel rather than reacting to one day of data. Monitor organic clicks and impressions, indexed URLs, crawl errors, important rankings, conversions, server errors and Googlebot activity in server logs.
Traffic on the old URLs should gradually decline while traffic to the new URLs rises. A continuing decline deserves investigation. Common causes include missing redirects, removed content, indexing blocks, incorrect canonical tags and internal links that still point to old pages. If the cause is unclear, an evidence-led SEO audit should start with Search Console and crawl data rather than assumptions.
13. Update links you control
Redirects work, but direct links are better. Update internal links, navigation menus, social profiles, Google Business Profile, email templates, paid advertising, directory listings and important external backlinks where possible.
This reduces unnecessary redirects and helps people reach the correct destination immediately.
Website migration mistakes that cause lasting damage
The most expensive migration mistakes are usually ordinary details that nobody checked:
- Launching with noindex still enabled
- Redirecting every old page to the homepage
- Forgetting valuable URLs that were absent from the sitemap
- Deleting useful content during a redesign
- Changing the domain, platform, design and copy simultaneously
- Allowing redirect chains to accumulate
- Losing analytics at launch
- Cancelling the old hosting too early
- Stopping monitoring after the first day
None of these problems requires a mysterious SEO trick to prevent. They require an accurate inventory, a tested redirect map and someone responsible for checking the site after launch.
Will a website migration hurt your rankings?
A well-planned migration can still cause temporary movement while search engines recrawl and reprocess the site. No honest provider should promise that rankings will remain completely unchanged.
Permanent losses are more likely when search engines cannot connect old pages with their new equivalents or when valuable content disappears during the move.
Google states that permanent redirects do not inherently cause a loss of PageRank. The important part is sending each old URL to a genuinely relevant destination and keeping the redirects active long enough for the move to be processed.
The safest migration is planned before development starts
SEO should not be added after the new website is finished. By then, URLs may already have changed, pages may have been removed and important technical decisions may be expensive to reverse.
The migration plan should explain what is moving, which URLs will change, where each old page will redirect, how the new site will be tested, when the launch will happen, how performance will be monitored and who is responsible if something goes wrong.
That is what turns a risky website move into a controlled project.
If you are planning a host, platform or domain change, eDeskCloud's website migration services include a full URL inventory, one-to-one redirect mapping, staging checks and post-launch monitoring. You receive the plan in writing before anything moves.



