Whether you are a digital marketer or SEO, you will most likely experience a website migration project at some point in your career. It is fundamental when undertaking any site migration that it is approached with caution and is thoroughly planned out for the best possible chance of success. If the process is not managed properly, it could result in dramatic drops in your organic search rankings, leading to a significant fall in both traffic and revenue.
Whatever your reasons for conducting a website migration, it is important to ensure that it is carried out carefully. If search engine visibility does decrease, it can take months for your site to recover. This is why having a strong plan in place for SEO during any migration project should be a crucial part of your overall website migration planning.
To help you refine the website migration process, we’ve put together a helpful checklist and plan of action that outlines the pre-, day of, and post-migration tasks that will help you avoid losses in search engine rankings.
Download a free PDF version of this Website Migration Checklist to keep on hand as a useful guide throughout your site migration project.
Introduction: What is a website migration?
A website migration occurs when a website undergoes major changes relating to the website’s set-up, such as changes to URL structures or platform and site structure changes.
The different types of site migrations
There are different types of website migrations, ranging from more subtle website changes to complete restructures, and even websites disappearing and being merged into another website. The most common types of migrations we have come across over the years include:
- Domain name changes (e.g. Rebranding to a different name);
- Platform changes and CMS changes (e.g. Moving from Drupal to WordPress);
- Structural changes (e.g. Moving content under a new category);
- URL cleanups (e.g. Making URLs more user-friendly);
- HTTP protocol changes (e.g. Moving from HTTP to HTTPs);
- Merging/consolidating websites (e.g. Combining two websites into one);
- Merging/consolidating content (e.g. Combining two or more content articles together);
- TLD Migrations & ccTLDs (e.g. Changing from a .co.uk website to a .com website);
- Subdomain to subfolder move (e.g. Moving an international subdomain into an internal subfolder);
- Website redesigns (e.g. Changing the look of a website and the site’s architecture).
The 5 stages of a site migration
- Planning and scoping the migration project
- Pre-migration preparation
- Pre-migration testing
- On-the-day support
Stage 1: Planning & Scoping the Site Migration Project
1. Define your core objectives
When undertaking any website migration project, it is critical from the outset to get a clear understanding of your main objectives and what the business is hoping to achieve through the migration.
It is also useful to find out stakeholders’ reasoning around the choice to migrate the site to determine where there are other routes available that may achieve the same desired outcome.
Once your site migration objectives have been defined and agreed upon, this will help with setting up your post-migration reporting.
2. Assess the timing of your site migration
Before any migration work gets underway, it is important to assess the timing of when the migration is going to take place, as this could have an impact on the core objectives and revenue for the business. To do this, log in to your analytics platform of choice (e.g. Google Analytics) and identify if or when there are seasonal highs and lows throughout the year. We recommended going as far back as possible to make sure the seasonal changes occur yearly and are not a one-off. If you don’t have accurate data to base your decision on, Google Trends or Google Ads Planner can be a useful alternative to find seasonal search volume patterns for your priority keywords.
We always recommend migrating a website when it’s at a seasonal low; if unexpected issues arise during the migration, they will have less of an impact on revenue.
3. Create a detailed project plan
A project plan is essential for site migration success. As with most website migrations, there are likely multiple stakeholders working on different tasks related to the migration—and more often than not, these tasks have dependencies. The project plan also helps with setting milestones and deadlines, which will ensure all stakeholders are working towards the same goal and on the same schedule.
4. Determine key responsibilities and task owners
As there will be multiple people working on the migration, team and individual responsibilities need to be determined up-front so that everyone knows what they should be working on. This will help ensure no crucial tasks are missed that might delay your migration process. It is also a good time to loop in key stakeholders across your different marketing channels who might be affected by the site migration. For example, the paid media team should be aware that campaign URLs could be changing.
5. Forecast the impact of the migration
Key stakeholders and senior management will usually want to know what impact the migration could have on the website, search visibility, organic traffic, marketing channels, and sales before the migration begins. It’s worth forecasting both worst-case and best-case scenarios to be prepared.
6. Agree on a post-migration reporting plan
At the start of any migration project, it is important to define the reporting requirements that senior stakeholders are expecting to see in their post-migration reports. It is also useful to show them previous report templates that have been used on other projects, as this can help define the reporting structure.
7. Gain access to all required data at the start
Before pre-migration tasks commence, make sure that all of the required data is accessible to the team and that access has been provided to any reporting platforms.
This could include:
- Analytics access (e.g. Google Analytics, Search Console)
- Rank tracking platforms (e.g. GetStat, SEOMonitor)
- PPC accounts (e.g. Google Ads)
- Backlink data platforms (e.g. Ahrefs)
8. Consider and inform your current users
Your users and site visitors need to be considered as early on in the process as possible—especially if the website migration is a domain name change, rebrand, consolidation, or merger.
If actions need to be taken to inform users of the upcoming changes, it needs to be scoped into the project in the planning phase, before work begins on the migration. It will need to be factored into the pre-migration preparation.
User-focused tasks that might need to be factored in here include:
- Sending out an email to subscribers to inform them the site is going through a rebrand and will be under a new name in the coming months.
- Using the old brand name in metadata for the first few weeks or months post-migration.
- Setting up a “hub” page optimized for the old brand name, as this can help the new website still rank for the old branded search queries.
- Setting up PPC ads on the old brand signaling to users that it has now been renamed or has moved. PPC ads can also be run prior to the migration to give advance warning to users of any potential changes.
Stage 2: Pre-Migration Preparation
1. Review planned changes
Depending on the type of website migration you’re working on, there could be certain site changes proposed that will need to be reviewed as early on in the process as possible, as they could impact your organic search efforts or affect your pre-migration plans.
Suggested website changes that should be reviewed as early as possible include:
Navigation: Your site navigation should be reviewed to make sure that priority pages are still being linked to from the primary navigation and, if not, find out why. Not linking to priority pages that are already in the navigation could have a negative impact on your search engine rankings and will need to be accounted for in the forecasts. There may also be scenarios where navigations have been over-optimised and include too many links, which could also have a negative impact or appear overwhelming for users and would need to be reviewed.
Taxonomy: Review proposed taxonomy changes (such as removing categories or renaming categories) that will have a knock-on effect for the migration planning and redirect rules. If you are undertaking a website consolidation project, it’s important to understand the differences between the taxonomies of each site and what will be kept the same or changed.
Page templates: Changes to page templates need to be reviewed to ensure they won’t have a negative impact on SEO. These changes may include:
- Content removed from pages;
- Modules removed;
- Priority content being moved from the top of the page to the bottom;
- Internal link changes;
- Metadata, titles, and H1s.
2. Gather all website URLs
For a site migration to be successful, it is essential to identify all of the pages that need to be protected or mapped depending on the type of migration being undertaken. For example, if the migration involves changes to URL structures or consolidating URLs together, this step is important when it comes to maintaining traffic levels post-migration. The size of the website can also determine if all URLs are going to be mapped 1:1, or if only priority URLs are going to be mapped 1:1.
To identify these pages, the below data points should be gathered and used to build up a full picture of your site migration:
- Crawl the existing/legacy website: By crawling the existing website in full, you can better identify all of the URLs that will be affected as part of the website migration. It also provides useful data for later on in the process, as this crawl data will serve as a backup of how the website was structured before the migration took place. When using Lumar to crawl your website, it’s recommended to include as many data sources as possible in the initial crawl set-up, such as linking Google Analytics, Search Console, Majestic SEO, and XML sitemaps, as it will append the data automatically to each URL. However, if you don’t have the luxury of syncing different data sources, it is best to still get the data separately and merge it together at a later stage.
- Data from analytics platforms: Log in to an analytics platform, such as Google Analytics, and download all of the URLs that have received traffic within at least the past 12 months. Make sure that, when the data is being downloaded, each URL includes traffic data from different channels such as direct, organic, social, and paid. Be sure to also include conversion data and revenue data related to your pages, if available.
- Backlinks data to identify URLs that have authority: Identify all of the URLs that have received a backlink over the years by using tools such as Ahrefs or Majestic. When downloading the data, we recommend keeping the domain authority of the website linking to a URL, as you may want to only count URLs that have backlinks from a website with a domain authority over a certain amount, such as a DA of 20, for example. If you count each URL that has a backlink, it can start to get unmanageable, especially if a URL has only 1 backlink from a domain that has a low domain authority of 2.
- Traffic data from paid media accounts: If your paid media team is running campaigns to URLs on the website they need to be included in your URL list, otherwise it can negatively affect the campaigns being run as users may be taken to a dead page. To get this data you should get access to all of the paid media accounts being run, such as Google Ads and Bing Ads.
- Social share data: URLs may have generated a high number of social shares over the years and these should be catered for. Social share data can be found via tools such as Ahrefs and BuzzSumo.
- Stakeholder priority URLs: There may be URLs that have no traffic benefit but need to be protected due to the importance of the pages to internal stakeholders. To find stakeholder priority URLs, it is important to liaise with all of the relevant stakeholders early on in the project.
3. Merge all URL data & create a priority URL list
Once all data points have been collected, create a master URL document that lists all the URLs found (deduped) along with the relevant data points and status code of each URL. For URLs that do not have a status code appended, quickly run a list crawl to get the status codes.
Example column headings for your master URL document could include:
- Status code
- Datapoint columns (e.g. organic traffic, direct traffic, conversions, backlinks, social shares)
- Stakeholder priority (yes/no)
If you are required to map all URLs one-to-one, the master URL document can be used for this. However, there will be scenarios where there are too many URLs to map and it might make sense to only map the highest priority URLs on the website. To identify the priority URLs that need to be protected, we recommend creating rules.
Example rules for creating your priority URL list could include:
- Has > x organic visits (12 mo.)
- Has > x direct visits (12 mo.)
- Has > x DA20 backlinks
- Has > x social referrals (12 mo.)
- Is this URL a stakeholder priority?
- Is it a paid media priority?
4. Map required redirects
After identifying all of the URLs that need to be mapped, create a mapping document that lists the legacy URL and the new destination URL to show where each URL will be redirected.
Example columns headers for your Redirects Map could include:
- Legacy URL
- Pre-Migration Status Code
- New Destination URL
In an ideal world, all URLs should be mapped 1:1, but if this is not possible within the scope of your migration project, then focus on making sure that at least all priority pages have 1:1 mappings to an equivalent page or near-similar page.
For URLs that might not be 1:1 mapped, wildcard rules can prove useful where, if a URL runs off a certain path, all of those URLs within the path will be redirected to one destination URL.
It is important to cater to legacy redirect rules that might be in place from previous migrations. This can prevent redirect chains from occurring and could cause legacy redirects to break.
5. Determine before/after benchmarking metrics for post-migration reporting
Benchmarking metrics need to be determined before a migration has taken place, as it will help with reporting on the success of the migration and will be used to compare pre- and post-migration results.
Primary areas to benchmark include:
- Priority keyword rankings for legacy domain(s), across desktop and mobile;
- Site speed and page loading times for different page templates;
- Snapshot of branded SERPs;
- URL level metrics for priority pages, such as average conversion rates and average organic traffic.
Make sure that priority keywords are being tracked prior to the migration taking place, as it will make it easier to spot any ranking drops post-migration.
5. Prepare your paid marketing campaigns for URL updates
If URLs will be changing, it is vital to ensure that any paid marketing campaigns that are presently being run (or planned for the near future) are scheduled to be updated with the new URLs once the migration goes live.
Additionally, other marketing channels such as email campaigns must reference any new URLs structures moving forward to ensure a smooth user experience.
6. Prepare third-party extensions for URL updates
Check that any third-party extensions relating to your website (such as Hubspot, Feefo, or Mailchimp), as well as social media plugins, will work when the site is migrated. Also, verify that any code required for ads to run will work properly on the new live site.
7. Prepare new configurations for website analytics platforms
Check to ensure that any existing Google Analytics configurations will continue to monitor traffic when the site is migrated. This will be important in the short-term to monitor any immediate traffic changes post-migration, as well as in the long-term for general reporting and monitoring.
Stage 3: Pre-Migration Testing
1. Set up your staging environment
Make sure a staging environment has been set up that replicates what the site will look like once it goes live. It’s very important to make sure any staging sites are blocked from all search engines. The best way to do this is by adding authentication to the website so it can only be accessed by using a username and password. If this is not possible, add a robots.txt with one rule: “Disallow: /”.
If you manage to add an authentication layer on your staging website, make sure when crawling the environment to use crawling software that enables you to add a username and password so the crawler can get behind the authentication layer.
If you add a robots.txt file, make sure the crawling software you use has a robots.txt overwrite function.
2. Conduct a technical audit of the new site within your staging environment.
Once the staging environment has been set up, it is naturally a best practice to review the whole site to make sure there are no critical technical issues that could hinder the website migration once it goes live.
Common technical issues to look out for at this stage include:
- Page duplication
- A high number of 404 pages or broken links
- Pages not rendering correctly
- Missing metadata or on-page content
- Empty pages causing soft 404s
- Page templates not replicating initial wireframes
- Internal linking optimization
- Missing canonical tags or canonicals that are referencing the wrong URLs
- Missing schema markup or structured data
3. Create the new robots.txt file
After a technical audit has been completed, review the legacy robots.txt rules to see if they are still valid, or if new rules need to be created due to updated URL structures or changes to your site architecture.
4. Test all redirects
Within the staging environment, verify that your redirections are working by getting the developers to set up functionality where legacy URLs that are created on the staging environment will 301 redirect to the new destination staging URL.
Also, test for non-www. URLs redirecting to the www. version (or vice versa) and URLs with a trailing slash redirect to the non-trailing slash version (or vice versa).
Stage 4: Day-of Migration Tasks
1. Test legacy URLs & redirections
Once the new website has been pushed live, it is essential to test all of the redirects that were put in place and provide feedback to the developers if there are any issues. Redirection rules can sometimes be working fine in a staging environment but occasionally, when they are pushed live, redirection rules can break or be directed at the wrong URL.
As crawling all redirections will take some time, make sure to run a quick list crawl of the priority URLs to check that redirects are in place for your most important pages as soon as possible, instead of waiting for all URLs to be crawled to identify any high-priority issues.
In addition to crawling your redirects, set up a list crawl of priority pages that receive traffic to validate the server response codes.
2. Review & update robots.txt
Review the robots.txt file to make sure there is not a “Disallow: /” rule in place and validate that the correct robots.txt rules are present for the new site.
3. Complete Search Console tasks
Depending on the type of website migration undertaken, there will be tasks that need to be completed within Google Search Console.
Common Search Console tasks that may need to be done at this stage include:
- If a site has changed its domain name, set up a new property and use the “change of address” tool in the old website property;
- Upload the new XML sitemap destinations and test for any errors. If a domain change has taken place, force a sitemap crawl on the legacy property to ensure fast redirect processing;
- If a new domain change or website consolidation has taken place, upload a new Disavow file;
- Fetch as Google for every page template to help speed up the crawling of content;
- Check the URL parameter set-up to validate if it is correct and identify whether anything needs to be changed;
- Check Mobile Usability on key templates to validate that all new pages are mobile-friendly;
- Check your international set-up to make sure it is targeting the correct countries..
4. Run a full site crawl to check for technical issues
Run a full site crawl on the day of migration to check for any critical technical issues that need to be fixed as a priority. Also, review on-page elements of the site such as page titles, headings, and body content.
5. Make marketing campaign updates to reflect new URLs
Implement the relevant changes for your paid ads, email marketing, and affiliate campaigns to correctly refer to any updated URLs in order to prevent breaking the user journey or disrupting campaign tracking.
6. Check website tracking codes
Ensure that all tracking codes are present once the website has gone live to prevent any loss of traffic data. This could include reviewing analytic platform tracking codes (e.g. Google Analytics) and advertising tracking codes (e.g. Google Ads).
It’s also a best practice to annotate in your analytics platform the day that the website migration took place, as this can help with reporting going forward.
Stage 5: Post-Migration Tasks
1. Set up ongoing technical monitoring (scheduled crawls) for the new site
After launching a website migration, it’s widely recommended to set up a scheduled crawl of the website for the weeks to follow. This will help identify any new technical issues that have appeared on the website and it also checks to see if any technical issues flagged on launch day have since been resolved.
Reviewing Search Console following the migration for any indexation or usability errors should be prioritized, as any errors found will need to be fixed.
Site speed and Core Web Vitals should be monitored following the migration to check that metrics are not declining due to any website changes.
Any issues that are uncovered should be flagged along with recommended fixes.
2. Crawl priority URLs first
If you’re following along with this site migration checklist, you will have already created a priority URL list during the pre-migration phase. This list should be re-crawled regularly, especially in the first couple of weeks after migrating, to check HTTP response codes and redirect destinations and verify they are working as expected. If redirects or response codes are not correct, these should be fixed ASAP to prevent drops in website traffic. Occasionally, rules can stop working post-migration even when they were working on launch day.
3. Monitor search engine rankings & website traffic
Regular monitoring of priority keyword rankings and traffic across the website should be in place following the migration. This will provide visibility on traffic and ranking movements, whether they are positive or negative.
If drops in rankings do occur, this data can make it easier to pinpoint where there may be an issue.
4. Conduct post-launch KPI analysis & reporting
As benchmarking would have been completed in the pre-migration phase, comparisons with those earlier benchmarks should be made post-migration to see if performance has improved or declined.
Weekly KPI reports are helpful for the first two to four weeks following a migration, followed by monthly performance reports for one to three months post-migration.
The most useful metrics to compare in these reports include:
- Pre- and post-migration rankings for priority keywords;
- Site speed on key templates;
- UX metrics such as bounce rate and time on site;
- Traffic WOW, MOM and YOY;
- Number of indexed URLs over time;
- HTTP status code comparisons, such as the number of 200s, 301s, 404s.
Site migration projects can be a huge undertaking, requiring the participation and expertise of numerous team members and stakeholders. Following an organized process for website migrations can help alleviate the stress for your team and will help ensure a smooth process with minimal disruptions to your website performance and reporting efforts.
Don’t forget, you can also download our handy site migration checklist PDF to help keep things on track during your migration project.
For more advice regarding site migrations, check out Lumar’s “SEO Office Hours Notes” on Domain Migrations.