Hello I’m Adam // General Manager
Drive quality traffic to your site
Talk to me todayHello I’m Faye // Marketing Director
Drive quality traffic to your site
Talk to me todayA website migration can affect existing rankings, traffic and enquiries if URLs, pages or important settings aren’t handled carefully during launch.
Adarsh Jose Benny
Nov 2, 2026
With careful planning and testing, those risks can be managed. This website migration checklist explains what to check before launch, what needs to happen on the day and how to monitor the site afterwards.
A website migration is a significant change to a website’s domain, platform, structure, hosting, content or design that could affect how visitors and search engines access it.
This could involve:
Not every migration changes the website’s URLs. A redesign could keep the same addresses while altering the content, navigation, page templates, internal links or technical setup. Those changes can still affect how search engines understand the website and how well its pages perform.
If your project involves moving to another platform, our guide to switching content management systems covers some of the wider decisions involved.
Turn the checklist into a working plan by giving each task a named owner, deadline and status. This makes it clear who is responsible for completing and approving the work, rather than allowing important checks to fall between different teams.
Start by recording exactly what the migration involves and what the finished website needs to achieve.
Confirm:
Bring your SEO team or specialist into the project before the website structure, URLs and content decisions have been finalised. It is much easier to protect valuable pages and influence the new structure while those decisions are still open.
Before anything changes, record how the existing website performs. This gives you a reliable baseline for measuring the migration and diagnosing any problems afterwards.
Useful information includes:
Save the reports and exports rather than relying on being able to find the same information later. Use a comparison period that accounts for seasonal changes where possible.
Take a complete backup of the website too, including its files and database. This gives your team something to restore if a serious problem occurs during the migration.
Create a master list of the existing website’s URLs using:
Combine the results and remove duplicates. Don’t rely entirely on the XML sitemap because it may exclude orphan pages, old campaign landing pages or other URLs that still receive traffic or links.
Include valuable PDFs, images and downloadable files too. Then give every URL a clear action:
Base each decision on the page’s purpose, accuracy, traffic, conversions, rankings and backlinks. Protect pages that already perform an important role, even if they aren’t prominent within the current navigation.
Avoid rewriting every successful page during the migration. Changing its URL, content and design simultaneously makes any later performance changes much harder to explain. Preserve the essential content and search targeting where practical, then make further improvements once the migration has settled.
A useful URL doesn’t need to change simply because the website is being redesigned. Keeping it avoids creating an additional step for visitors and search engines.
Where a URL must change, record its new destination in a redirect map. This tells the developer where each old address should send visitors after launch.
Redirect map example
| Old URL | New URL | Action | Status |
| /old-service | /services/new-service | Permanent redirect | Ready |
| /outdated-offer | No suitable replacement | Remove | Review |
| /contact-us | /contact | Permanent redirect | Ready |
Follow these basic rules:
Blanket homepage redirects can confuse visitors and may be treated as soft 404s by Google. If several old pages have genuinely been combined into one useful resource, they can all redirect to that page.
Google’s official site-move guidance provides further information about URL mapping and permanent redirects.
A staging website is a private working version of the new site used for testing before it replaces the live one.
Protect it from public access and search indexing during development. Password protection is generally the clearest option while still allowing authorised people and testing tools to review it.
Before launch, check that the new website preserves or correctly updates:
Crawl the staging website and compare its important pages and templates with the current site. Look for missing content, broken links, incorrect status codes and pages that search engines may struggle to access or understand.
Our technical SEO guide explains these checks in more detail.
Any password protection, noindex instructions or crawl restrictions used during development must be removed from the live website. Add this as a specific launch task rather than assuming it will happen automatically.
A successful migration also needs to preserve the actions customers and staff rely on.
Test:
Complete realistic journeys rather than checking whether each feature merely appears on the page. Submit a test enquiry, place an order where appropriate and confirm that the information reaches the right system or person.
Record who tested each function and the result. These checks should be repeated on the live website immediately after launch.
The launch plan should explain what will happen, who will complete each task and how the team will respond if something goes wrong.
Confirm:
Choose a time when the necessary people are available and potential disruption to customers is manageable. Avoid launching immediately before a busy trading period or an unattended weekend.
The checks completed on staging need to be repeated once the website is live. Changes to the domain, hosting or server configuration can introduce problems that weren’t present in the test environment.
Confirm that important live pages aren’t blocked by password protection, noindex instructions or an incorrect robots.txt file.
Keep the separate staging website protected or take it offline after launch.
Test the complete redirect map on the live website rather than checking only the homepage and a few important pages.
Confirm that each old URL uses the intended permanent status, reaches the correct live page and doesn’t pass through a chain or create a loop. Prioritise any problems affecting pages that previously generated traffic, conversions or backlinks.
Crawl the website as soon as it is available and check for:
Compare the results with the staging crawl and original URL inventory to identify anything that changed or disappeared during launch.
Repeat the important customer journeys on the live website. Submit an enquiry, place a test order where appropriate and check any account or download functions.
Confirm that the information reaches the right systems and that Analytics records the relevant visits and conversions.
Once the website is live:
The Change of Address tool isn’t required for a redesign, CMS change, URL changes within the same domain, a move from HTTP to HTTPS or a change between www and non-www.
Continue monitoring the website while search engines crawl the new pages and process the changes.
Review:
Compare the results with the baseline recorded before the migration. Use equivalent periods and account for seasonality, marketing campaigns and other events that could affect demand.
If traffic falls, check:
Compare individual landing pages rather than looking only at the website-wide total. This will show whether the problem affects the whole website, one section or a small number of important pages.
Some short-term movement may occur while Google processes the migration. A large or sustained decline should still be investigated rather than dismissed as something that will resolve itself.
Use the original URL inventory to confirm that:
Some old URLs may no longer be discoverable through a normal crawl of the new website, which is why the original inventory remains important.
Replace old URLs in:
This sends visitors directly to the correct page and reduces unnecessary reliance on redirects.
Google recommends keeping migration redirects in place for at least one year. Keeping useful redirects for longer can also help visitors following old bookmarks, emails or links from other websites.
If the migration involved a domain change, keep control of the old domain and maintain its security certificate so the redirects continue to work properly.
Planning and completing a migration may take several weeks or months. The timeframe depends on the number of pages, systems involved, scale of the changes and how many people need to review and approve the work.
After launch, Google needs time to crawl the redirects, discover the new URLs and process the updated website. Google advises that this can take a few weeks or longer, with larger websites generally taking more time.
There is no universal recovery date. Some migrations cause very little disruption, while others experience more noticeable movement. Continue comparing performance with the original baseline and investigate anything that remains significantly below expectations.
Professional support may be useful when:
Statuo can help plan the SEO requirements, record what the existing website has earned and coordinate the technical checks with your wider project team.
We can also prepare redirect maps, review the staging website and monitor performance after launch so problems are identified and addressed quickly.
