Website Migration Checklist: SEO and Risk Management Guide

A website migration is one of the highest-risk technical projects a business can undertake. Done without a structured plan, it can wipe out years of accumulated search rankings within days. Done well, it is an opportunity to consolidate authority, fix long-standing technical debt, and set the site up for stronger performance.

This checklist covers every phase of a migration, from the discovery work you need to complete weeks before launch through to post-migration monitoring and disaster recovery. It is written specifically for UK marketing managers, developers, and business owners who need a clear operational framework, not just a list of technical steps.

You will find guidance on assembling the right team, navigating UK GDPR considerations when moving hosting environments, and what to do if traffic drops after go-live.

Assembling Your Migration Team: Roles and Responsibilities

Most migration guides focus entirely on the technical steps and say nothing about who should be doing them. This is a significant gap. A migration that lacks clearly assigned roles becomes a project where critical tasks are assumed to be someone else’s responsibility, until something breaks.

The Core Team You Need

A well-structured migration team typically includes three distinct functions. Each one owns a separate layer of the project, and all three need to communicate throughout.

The SEO lead is responsible for the URL mapping document, redirect logic, benchmarking current rankings, and monitoring performance after go-live. This person should be involved from the first planning meeting, not brought in on launch day to sign off on a redirect list someone else built.

The developer or technical lead handles server configuration, DNS management, staging environment setup, robots.txt management, and the actual redirect implementation. They also own the go-live sequence and should be available for at least 48 hours after launch.

The project manager or stakeholder lead owns internal communication. Before the migration goes live, key stakeholders need to understand that a temporary traffic dip is a normal part of the settling period, not a sign of failure. Setting this expectation in advance prevents panicked rollback decisions based on one bad day of data.

Defining the Decision-Making Chain

Before any work begins, agree on who has the authority to approve a rollback. This sounds administrative, but migrations often go wrong not because of technical errors, but because decisions are made in a crisis without a clear chain of command.

Document the answer to three questions: who can approve the go-live, who can approve a delay, and who can approve a full rollback. Get sign-off from everyone involved before the project starts.

B2B versus E-commerce Migrations

The risk profile differs significantly depending on the type of site you are moving. A lead-generation site with 50 key landing pages and a handful of high-value backlinks is a very different migration challenge from an e-commerce store with thousands of product SKUs, category pages, faceted navigation URLs, and transactional pages that carry significant link equity.

For e-commerce migrations, the URL mapping exercise alone can take weeks. Product SKUs need to map to new URLs, category structures need to be preserved or carefully consolidated, and filtered or parameterised URLs need specific handling to avoid creating thousands of duplicate redirect chains. Build this complexity into your project timeline from the outset.

For SMEs managing their own website transitions, working with a digital agency for migration projects of this scale is often the most cost-effective approach.

Phase 1: The Pre-Migration Discovery and Benchmarking

The pre-migration phase is where the majority of the work happens. Rushing or compressing this phase is the single most common reason migrations fail. Plan for a minimum of four to six weeks for a standard site, and considerably longer for large or complex properties.

Technical Site Audit and Crawl

Before you move anything, you need an accurate picture of what you have. Crawl the existing site using a tool such as Screaming Frog and export a complete list of all indexable URLs. This becomes the foundation of your redirect mapping document.

At the same time, pull your benchmarking data from Google Search Console. Record the following for every page that matters: organic clicks over the last three months, impressions, average position for primary queries, and click-through rate. This snapshot is what you will compare against in the weeks after launch to determine whether the migration has performed within acceptable tolerances or whether something has gone wrong.

You should also run a full content audit at this stage. Identify which pages are worth migrating in full, which should be consolidated, and which should be removed or noindexed on the new site. Do not carry low-quality, thin, or duplicate content into a new environment; a migration is the correct moment to prune, not after go-live when you are introducing multiple variables at once.

The URL Mapping Document

The URL mapping document is the most important deliverable in the pre-migration phase. It is a complete record of every old URL and the exact new URL it will redirect to. Every page that will change its address needs a row in this document, including subpages, tag pages, category archives, and any URL that has backlinks or significant organic traffic.

The 80/20 principle applies here: concentrate the most time on the 20% of pages that carry the most link equity and organic traffic. These are the pages where a missing or incorrectly configured redirect will do the most damage. For the remaining long tail of low-traffic URLs, bulk redirect rules based on URL patterns can handle the work efficiently.

Understanding how search engines process domain redirects is important before you begin mapping, particularly if the migration involves a domain change as well as a platform change.

UK GDPR and Data Privacy Considerations

This is the section most migration guides ignore entirely, and for UK businesses, it is not optional. When a website migration involves changing hosting providers, there is a real possibility that user data, including form submissions, CRM integrations, analytics data, and email lists, is transferred between servers in different jurisdictions.

If you are moving from a UK-based server to a US-based hosting provider, or vice versa, you need to review your current Privacy Policy and confirm that your data transfer mechanisms comply with UK GDPR requirements. This is not a post-migration task; it needs to be resolved before go-live.

At a minimum, review and update your Privacy Policy, Cookie Policy, and Terms of Service to reflect the new hosting environment and any changes to how data is collected, stored, or processed on the new platform. If your current CMS stores user data in a database that will be exported and re-imported during the migration, confirm that this transfer is documented and compliant.

If you are uncertain about your obligations, consult the ICO’s guidance on data transfers or take legal advice before proceeding.

Phase 2: Staging Environment and Safety Checks

Never test a migration on a live site. A staging environment is a private, non-indexed copy of the new site where you can run every check, identify every error, and resolve every issue before a single real user or search engine crawler touches the production environment. Skipping this step is not an acceptable shortcut on any project.

Blocking Search Engines from Staging

The first thing you must confirm before doing anything else on the staging environment is that search engines are blocked from indexing it. There are two mechanisms for this: a noindex meta tag in the site’s head section, and a Disallow: / rule in the staging site’s robots.txt file. Use both. If the staging environment is accidentally crawled and indexed, you risk creating duplicate content issues that persist even after go-live.

Confirm the block is working by checking the staging URL in a tool such as Google’s URL Inspection tool on a test basis, or by reviewing the robots.txt file directly in a browser. Do not assume the CMS setting is sufficient without verifying it in the file itself.

Testing Redirects in a Sandbox

With the staging environment live, begin redirect testing. Work through the URL-mapping document and verify each redirect on your list. Check that each old URL resolves to the correct new URL, that it returns a 301 status code (not a 302 or a meta refresh), and that there are no redirect chains where the old URL redirects to an intermediate URL which then redirects again to the final destination.

Redirect chains eat crawl budget and dilute link equity. Every chain should be flattened to a single hop from old to new. Use a tool that can crawl all redirect responses simultaneously rather than testing URLs one by one.

Understanding how search engine crawling and indexing work will help you prioritise which redirect failures carry the most risk to your rankings.

Performance Benchmarking: Core Web Vitals

Run a Core Web Vitals assessment on the staging environment before go-live. Record your Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) scores. Compare these against the scores from the current live site.

If the new platform or theme scores worse on any metric than the existing site, identify the cause and address it before launch. A migration that improves content structure but degrades page performance is a net negative for search rankings. Common causes include unoptimised images, render-blocking scripts, and uncached resources on a new hosting environment that has not yet been properly configured.

The staging phase is also the correct time to test the site across multiple browsers and devices, verify that all forms submit correctly, and confirm that any third-party integrations such as analytics, CRM connectors, and chat tools are functioning in the new environment.

Phase 3: Launch Day Execution Protocol

Launch day is not when the hard work begins; it is when the work you have already completed is executed in a precise sequence. If the pre-migration and staging phases have been completed properly, launch day should be methodical rather than stressful. The goal is to follow the protocol, not improvise.

The DNS Switch and Propagation

Never launch a migration on a Friday. If something goes wrong, your development team needs to be available to respond, and that availability is far lower over a weekend. Mid-week launches give you two full working days of support coverage in the critical post-launch window.

When you update your DNS records to point to the new hosting environment, propagation can take anywhere from a few minutes to 48 hours, depending on TTL settings and your DNS provider. Before you make the switch, lower your DNS TTL to the minimum your registrar allows, ideally to 300 seconds, at least 24 hours before go-live. This reduces the propagation window significantly. Once the migration is confirmed stable, you can raise the TTL back to a normal value.

Keep your old hosting environment active and do not cancel it for at least 30 days after the migration. Your 301 redirects on the old server need to remain live to pass link equity correctly during the crawl and re-indexing period.

Removing Noindex Tags and Updating Robots.txt

Once the DNS has propagated and the new site is confirmed live, remove the noindex meta tags and update the robots.txt file to allow crawling. This step is critical and needs to happen in the right order: confirm the new site is live before opening it to search engines, not before.

After removing the blocks, do a final check of the live site’s robots.txt file in a browser. Confirm it does not contain any accidental Disallow rules that would prevent crawling of important sections. Check also that your canonical tags are pointing to the correct URLs on the new domain or structure.

Submitting the Change of Address in Google Search Console

If the migration involves a domain change, you must submit a Change of Address notification in Google Search Console. This is done under Settings within the relevant property and requires you to have both the old and new domains verified in GSC.

Immediately after the Change of Address submission, upload your new XML sitemap in the new GSC property. This gives Googlebot a complete map of your new URL structure and accelerates the re-crawl and re-indexing process. Do not wait for Google to discover the new URLs organically; submit the sitemap on launch day.

For sites built on WordPress, managing your WordPress sitemap correctly before and after migration is a step that is easy to overlook but significant for indexing speed.

Phase 4: Post-Launch Monitoring and Indexing

The 72 hours after a migration goes live are the most information-dense period of the entire project. Issues that were invisible in staging will surface in production, and the faster you identify them, the less damage they cause. Monitoring in this window needs to be active and structured, not a passive check of your analytics dashboard each morning.

The 72-Hour Critical Watchlist

Within the first three hours of go-live, verify the following: the new site is accessible, the old URLs are redirecting correctly, the sitemap has been submitted and accepted in GSC, and your analytics tracking is firing correctly on the new environment. A common oversight is that analytics code fails to carry over cleanly, leaving you with a gap in your post-migration data at the exact moment you need it most.

Over the first 72 hours, monitor Google Search Console crawl reports closely. An increase in 404 errors indicates URLs that are returning not-found responses rather than redirecting, which means pages in your mapping document have not been correctly implemented. Address 404s as they appear rather than batching them for review at the end of the week.

Expect some ranking volatility in the first two to four weeks. This is a normal part of the re-indexing period and does not constitute a failed migration on its own. A failed migration is one where rankings decline and do not recover after six to eight weeks, or where large volumes of pages are not being re-indexed within the expected timeframe.

Monitoring Log Files and 404 Errors

If you have access to server log files, reviewing them during the post-launch period gives you a direct view of how Googlebot is crawling the new site. You can see which URLs are being requested, what status codes they are returning, and whether the crawler is spending time on low-value pages rather than your important content.

Set up a filtered view in Google Search Console that surfaces any pages returning 404 or 301 chain errors. Review this daily for the first two weeks, then weekly for the following month. You should also run a fresh crawl of the live site using your crawler tool and compare it against the original crawl from the pre-migration phase to confirm that no pages have been accidentally dropped.

For ongoing site health after the migration has settled, running regular SEO risk assessments will help you catch issues before they develop into ranking problems.

Disaster Recovery: What to Do if Traffic Drops

Every migration should have a documented recovery plan before launch day. Not because failure is inevitable, but because decisions made in a crisis without a framework are rarely good decisions. If traffic drops significantly after go-live, the first step is to diagnose before you act.

Identifying the Leak: Redirects, Content, or Technical

A traffic drop after migration typically falls into one of three categories, and the fix differs for each. The first is a redirect failure, where pages that carried significant organic traffic are returning 404s or incorrect redirect destinations. Check your GSC coverage report and compare the list of 404 errors against your URL mapping document.

The second category is a content issue. If pages were consolidated, pruned, or significantly rewritten during the migration, their rankings may decline as Google re-evaluates the content. This type of drop tends to be gradual rather than immediate and affects specific query clusters rather than the whole site.

The third category is a technical issue: noindex tags left in place, robots.txt blocking crawling, canonical tags pointing to incorrect URLs, or Core Web Vitals scores that have deteriorated on the new platform. These can cause broad de-indexing or ranking suppression across the whole site rather than on specific pages.

An AI-assisted SEO audit can speed up the diagnostic process when you need to identify technical issues at scale quickly.

When to Trigger a Rollback

A rollback should be considered a last resort, not a first response to a difficult post-migration week. It introduces its own disruption and can compound the ranking volatility rather than resolve it. That said, there are specific conditions where a rollback is the correct decision.

Trigger a rollback if: more than 30% of your previously indexed pages are returning 404 errors after 48 hours and cannot be resolved quickly; if a critical technical failure, such as a broken checkout or broken contact forms, is causing direct commercial damage; or if a compliance issue, such as the accidental exposure of user data, has been identified on the new platform.

Before triggering a rollback, confirm that your old hosting environment is still active and that the old site files are intact. This is why the recommendation to keep old hosting live for 30 days is not advisory; it is a direct insurance policy against exactly this scenario.

The Stakeholder Communication Template

When traffic drops after a migration, the pressure to act can come from within the business rather than from the data. Stakeholders who were not briefed on the expected settling period will interpret a 15% drop in week one as a crisis rather than as normal post-migration behaviour.

Before launch, send a brief to all relevant stakeholders that covers three things: what to expect in the first four weeks, what constitutes normal volatility versus a genuine problem, and who is responsible for monitoring and decision-making. This briefing prevents reactive decisions and gives the migration the four-to-eight-week window it needs to settle before any conclusions are drawn.

Northern Ireland and Irish businesses undertaking migrations as part of a wider digital transformation can find relevant regional context and examples through resources such as Connolly Cove’s guide to Northern Ireland, which covers the local business landscape ProfileTree operates within.

For businesses at any stage of a site migration project, ProfileTree’s approach to maximising digital marketing ROI puts the technical work in the context of commercial outcomes, which is where it belongs.

Migration Risk Matrix: Types and Recovery Timelines

Not all migrations carry the same level of SEO risk. The table below provides a reference guide to the four main migration types, their risk profile, and typical recovery timescales.

Conclusion

A website migration handled with this level of preparation is not a gamble; it is a managed transition with clear checkpoints and a recovery path if anything goes wrong. The businesses that come through migrations without ranking damage are the ones that treat the pre-migration phase as seriously as the launch itself.

If you are planning a migration and want a technical team that has managed this process for SMEs across the UK and Ireland, get in touch with ProfileTree‘s web development team to discuss your project.

FAQs