What you should never ignore during a migration

There are a number of reasons you may decide to migrate your site; a rebrand, consolidation of multiple brand domains, moving to a new CMS, or even a substantial change in URL structure across your current domain.

Whatever the reason, it is important to have a plan in place to mitigate any potential loss of organic traffic performance once the migration has been executed, with contingencies ready to benchmark, monitor, and identify issues should the migration be seen negatively.

What is a Site Migration?

Making major technological, structural, design, or domain adjustments to a website is called “migrating” a website.

A site migration is a serious undertaking and shouldn’t be taken lightly, poorly executed migrations can result in a significant loss of traffic almost overnight which may not be recoverable in the short term.

Types of website migrations include;

• TLD (Top Level Domain) Migration – This involves migrating your website domain from a .com, a .co.uk, .net, or any other number of available TLDs.
• CMS (Content Management System) Migration – A CMS migration involves migrating your site to use different content management technologies. For instance; moving from WordPress to Umbraco.
• URL Structure Changes – Significant changes to your site URL subfolder architecture require careful planning and strategy before execution.
• Subdomain Migration – Similar to URL structure migrations, you may decide to consolidate subdomains into subfolders. For instance; migrating a subdomain such as https://blog.yourdomain.com/ to a subfolder like https://yourdomain.com/blog/
• Protocol Migration – Moving from an HTTP to an HTTPS protocol.

Depending on your situation, you may be doing a combination of any of the above migration types.

Site Migration Risks

There are several risks involved with a site migration; in many instances, a period of ranking turbulence can be noted following site migration. Resulting in diminished traffic.

In these instances, traffic will likely recover if the migration has been correctly implemented as Google requires time to crawl/recrawl your site, process the information and make updates to their index as necessary. However, this is not a guarantee and if a robust site migration strategy isn’t implemented traffic loss can be severe and long-lasting.

Common site migration risks include;

• Loss of traffic
• Analytics & tracking issues if this has not been implemented correctly.
• Difficulty indexing the new domain.
• Disruption for users in the case of site redesigns changing the UX, with the potential to lower conversions.
• Load speed increases if migrating to new servers, or introducing excessive load times through new technologies used in a new site build.

It is not unheard of for migrations to go completely wrong, resulting in the decimation of traffic, rankings, and more importantly revenue. Because of the associated risks, migrations should only be undertaken if there is a logical need, or business case to support the decision – with a full understanding of the potential downsides.

So, what can we do to avoid negative migration outcomes?

Site Migration Checklist

Below is a list of actions that should be taken before any site migration takes place, in order to mitigate traffic loss and ranking volatility.

Do We Really Need To Migrate?

First thing’s first, migrations can be time-consuming and tricky to navigate. If things go wrong organic performance can tank, traffic is lost and revenue dries up. Migrating to a new domain, consolidating domains, significant URL structure changes, or changes to the technology used to serve the site should only be done if reasonably necessary.

This may include a rebrand or acquisition of another business that is being consolidated within your current business. The technology used to build the site no longer has the features required to grow your site, or, is no longer supported with updates.

If migration has been deemed necessary to improve search performance in the long term, it is time to set out a realistic project plan to work against.

Set a Timeframe

Setting up a reasonable timeframe and liaising with the necessary departments can help a migration run smoothly. If expectations and deadlines are set then we can get our house in order effectively and efficiently.

Crawl the Original Site

Once a timeframe has been agreed upon, a crawl of the original site should be done. A number of tools can be used to achieve this, but I prefer to use the industry-standard Screaming Frog web crawler.

Once crawled, we will have all the data we need including page titles, metadata, header responses (identifying internal redirects and 404 pages,) canonical tags, NOINDEX/NOFOLLOW directives, and a list of all URLs on the site.

We will use this data to not only map out our redirect strategy but use the opportunity to make internal fixes to broken links and excessive internal redirects.

Benchmarking Old Domain Performance

Benchmarking site performance is essential to any successful migration strategy. If we don’t measure our current organic performance there will be no way for us to tell if our migration has been successful or not. Moreover, if we do encounter problems post-migration, benchmarking our previous performance should help us diagnose issues on the new site.

Benchmarking organic performance includes;

• Identify Top Performing Pages

Once we have our site crawl saved and can identify all the indexable pages, we need to determine which are the most important to focus on within our migration strategy. These are the pages that drive conversions, traffic, and referring domains.

If you have a large website, redirecting every single page may be unrealistic if there are restrictions on available time, available skilled resources, or other technical limitations.

In these instances, we need to prioritise our top-performing pages using data from Google Analytics, Google Search Console, and third-party SEO tools like aHrefs, SEMRush, Moz, etc.

With our list of indexable pages, we need to source organic visits, pageviews, conversions, conversion rates, and revenue over the past year.

All this data can be found within Google Analytics.

Further to this, we will want to get click and impression data from Google Search Console.

Lastly, we want to find our top backlinked pages. For this, we will need to use SEO tools (my preference is aHrefs; but a number of tools such as SEMRush, Moz, and Majestic can perform the same function).

Pages that drive traffic, and conversions, or contribute to revenue within the user’s site journey should be prioritised during a site migration. These pages should exist within the new site and have redirects in place to ensure any external link equity is correctly passed to the new pages.

• Keyword Rank Tracking

Keyword tracking should form part of any solid SEO strategy however we will need to have a solid idea of our keyword ranking performance before implementing our migration strategy.

When keyword benchmarking we need to take a reasonable approach, your site may be ranking for thousands of keywords and it would be a large task to monitor each middle and long-tail variation.

Instead, we should place importance on and identify the top traffic-driving keywords and export a list of their rankings around a week before migration goes live.

This will give us a list of keyword rankings that we can reasonably, and effectively, monitor to make decisions post-migration.

• Site Speed Performance

Site speed should be measured before a migration. If migrating to a new server, or if the migration includes a redesign, site speed can be affected – we want to ensure this isn’t negatively impacted and that we can diagnose issues if necessary.

While site speed isn’t the largest ranking factor (we can consider it a ‘last-mile’ ranking factor) it can have other effects on the user experience when browsing your site. Furthermore some studies have shown a correlation between site speed and conversion rate.

Using tools like Google Pagespeed Insights, Lighthouse Dev Tools, or third-party tools like SpeedVitals we can collect the data necessary to benchmark our page speed performance.

Setting Up A Staging Environment

Setting up a staging environment is crucial to the migration process, allowing us to test redirects, and ensure site health (no broken links and assets are loading correctly). Critically, the final URL structure of our new site needs to be set within the staging environment before we begin preparing our redirect strategy.

If we spend time mapping out our redirects only to have the URL structure change down the line, this can lead to delays in the migration going live, wasted time, or worse if unnoticed.

Reminder; search engine user agents should not be able to access the staging environment through password protection, disallow rules in the robots.txt file, or whitelisting only specific IP addresses.

Redirects For Migration

Correctly mapping out redirects is probably the most important task for migrations, once the URLs on the old domain no longer exist we need to send not only potential visitors somewhere but search engine user agents.

For SEO, a redirect strategy is used to help search engine user agents find, crawl, and index the new site’s URLs. Moreover, they are used to associate the old URL with the new URL, passing over any link equity, or ‘juice’, passing ranking signals between domains.

This should lead to minimal disruption to traffic and rankings once the migration has gone live.

Should a redirect strategy not be put in place, or poorly implemented, rankings and traffic will completely tank as users land on 404 pages, irrelevant pages, or wind up in a redirect loop. The consequences of this may prove to be difficult to recover from, at least in the short term.

• Mapping Site Migration Redirects

Ideally, the URL structure won’t be changing between domains. In these instances, a regex rule can be implemented to redirect URLs on a 1-to-1 basis.

As we all know, this isn’t always going to be the reality when migrating a site, particularly if we are consolidating domains.

Depending on the size of the site, this may require some manual action. Or, in the case of large sites with tens or hundreds of thousands of pages some automation will be required as a manual process will be unreasonably time intensive.

The most important pages (as identified earlier) should be given priority and mapped first to ensure this is correct.

In cases where we have tens to hundreds of thousands of URLs, manually mapping redirects sits somewhere between extremely impractical to impossible. In these instances, some automation will need to be relied on.

We can use unique, common, identifiers between pages from the old site and the new site. These can be page titles, H1 tags, product codes, etc. Of course, if the chosen attribute is repeated across several pages this may result in incorrect redirect mapping between domains.
Reminder; URL structure should be finalised on the staging server before redirect mapping is started.

• Previous Redirects

When starting our redirect mapping process, we need to consider if our old domain has existing redirects from previous domains in place.

In these instances we will also need to map out redirects from the previous domains, avoiding redirect chains where possible.

• Internal Redirects

Finally, internal links should be updated to avoid internal redirects. Search engine user agents can and do follow internal redirects, but they can add additional unnecessary load times to your site.

• Testing Redirects

Before going live, redirects should be tested in the staging environment. Once redirects have been confirmed as live within the testing server we should crawl our list of redirects and check for the following;

1. Redirects into 4xx responses
2. Redirects into 5xx server errors
3. Redirect loops & chains
4. Canonical loops & chains
5. HTTP/HTTPS inconsistencies

Importantly, we also need to check that the page being redirected to is the correct one. This can sometimes be missed by assuming that all redirects correctly point to their intended destination.

Create XML Sitemap & Robots.txt File

Once the URL structure has been finalised within the staging environment, an XML sitemap should be created ready for submission in Google Search Console once the migration has gone live. Further to this, the robots.txt file should be created and uploaded disallowing appropriate subfolders & URL parameters as necessary.

The robots.txt file should also contain a reference to the XML sitemap.

Post-Migration Activities

So, our new site is built, the URL structure is finalised, and redirects have been mapped and tested. What’s next?

Once the migration has been pushed live there are a number of things we need to check;

• Redirects

Firstly, redirects should be checked. We can use the list of URLs from the crawl we saved from the beginning of the migration process. Are any redirects not working, or returning 4xx or 5xx responses? If so, these will need to be addressed as soon as possible.
If you have hundreds of thousands of URLs to check, it may be more practical in the first instance to check on our identified top-performing pages first. Ensuring these are correctly implemented will give the best chance for a positive result following migration.

• Analytics

We also need to ensure that analytics is correctly tracking the new domain and that all goals, eCommerce & enhanced eCommerce tracking are correctly implemented, enabled, and working. This is important as we will be using Google Analytics to monitor the success of the migration against our benchmark going forward.

Reminder; the domain will need to be updated within analytics.

• Google Search Console

There are a couple of actions we need to take with Google Search Console – we should use the Change of Address tool to inform Google we are switching domains. Not only that but once we have tested our XML sitemap(s) to ensure there are no errors, we need to upload and submit it/them to Google Search Console.

Further to this, we need to keep an eye on our crawl stats. Typically, when Googlebot finds new pages, we should see a noticeable spike in the number of pages crawled per day. If we can’t observe a spike in crawl activity following site migration there may be an issue with Googlebot’s ability to crawl the new site.

In these instances, a log file analysis may need to be done to identify problem areas.

Measuring Performance Post-Migration

When and how should we measure our performance following a site migration? There is no set answer, but the longer we wait the more data we will have collected.

Measuring too soon (excluding the possibility that migration has gone wrong and your traffic has completely tanked) can provide inaccurate results as there will likely be some ranking and traffic volatility immediately following migration.

In general, we can start to measure our performance against benchmarks for small to mid-sized sites from around 4-8 weeks post-migration. This will require some monitoring, looking for traffic & ranking stabilisation before making comparisons.

For large enterprise websites we may have to wait between 2-4 months before we can fully realise the effects that our migration has had on performance.

How to Measure

There are many factors to take into consideration when measuring performance, has the site design changed affecting repeat users’ experience, is the purchasing experience different – this could affect conversion rates, is there a seasonal trend that may affect the traffic?

Most likely, the two metrics that will concern the business owners are going to be traffic and revenue and whether each has been affected following migration or not.

However, that may not provide us with a full picture of what is going on. To gain more insight we also need to look into;

• Visibility – Both for mobile and desktop devices (third-party tools such as Sistrix and SearchMetrics can be used here)
• Rankings – Again, for mobile and desktop. Is there a significant shift for one device over the other?
• Engagement metrics – Bounce rate, time on page.
• Conversion rate – Are our product pages converting at the same rate? Not only this but have conversions wildly changed based on device type (mobile/desktop)?

Conversion metric decline may be an indicator of UX decline following site redesign, making the buying process more clunky for the user. Disparity between devices can also indicate that design considerations may need to be adjusted for only a single device, ensuring that not only is UX thought of – but that content can be crawled and rendered correctly by search engine user agents for both devices.

Technical Measurements

It is also prudent to look at the number of indexed pages in Google Search Console, particularly XML sitemap submissions vs indexed pages.

Site Speed Measurement

As before migration, we want to measure site speed on the new site to compare against our benchmark. If page speed performance has decreased significantly on-page speed optimization may be required. This could require the input of specialist web developers with speed optimization experience.

Conclusion

Site migrations can be tricky, risky, and if not overseen by competent individuals, downright disastrous for online businesses.