In online marketing, site migration is usually a phrase that makes SEOs, PPCers, site owners and stakeholders wince. We’ve all heard the horror stories about sites that have migrated from one domain to another and experienced a huge drop in traffic and visibility, and those that have suffered the same fate just by changing protocol. Whether you have acquired a domain, want to roll up your M-Dot site into a responsive design or desire a move from HTTP to HTTPS, devising a solid action plan to avoid traffic and revenue loss is paramount. On this journey, we’ll cover some of the most important things to address pre, during and post migration to give your site the best chance of a smooth transition to your new destination.

Pre-pre-migration: migration types and considerations

So you are staring out into the abyss thinking what now? Before you rush off into the unknown, let’s start with the basics; migration types. There are many reasons you may want to migrate your site, but the most common reasons include:

M-Dot Roll-Up migration

The main reason for this type of migration is for a transition from a separate mobile and desktop site to a fully responsive website. Moving towards a responsive site helps to consolidate site authority and reduce development resources (due to having only one site to update).

HTTP to HTTPS migration

An HTTP to HTTPS site migration is one that is becoming more common. This type of migration is one where the domain remains unchanged but an SSL certificate becomes associated with the site. This certificate is a symbol of a safe and trustworthy site and explains Google’s push for domains to adopt the protocol. Google have recently added to this by displaying the word ‘secure’ on all HTTPS pages in the search bar, and have hinted that the phrase ‘non-secure’ may feature on HTTP pages in the near future.

ccTLD to TLD migration

This type of migration involves moving a country specific TLD (Top Level Domain) to a more internationally recognised TLD (a well-documented example of this was the Guardian moving from .co.uk to .com). A move from ccTLD to TLD can be great for users who have a much wider audience outside of their country specific location – due to reduced resources needed to manage each branch separately.

Rebranding/ consolidating multiple domains migration

Rebranding is a type of site migration which occurs due to a change of name or brand acquisition. Like ccTLD to TLD migrations, this can involve moving a single domain or migrating multiple domains into one. As expected, involving multiple sites in a migration leads to greater risk for traffic and visibility.

No matter which type of migration you are looking to do, each comes with a shared list of do’s and don’ts:

Do understand that looks aren’t everything

With the prospect of a new site comes the excitement of building something visually stunning. Do put your flair on the new site, but make sure this doesn’t come at a usability or SEO cost.

Do consider wider channels

Site migration has a big impact on multiple digital channels and is sometimes overlooked:

Social – This involves thinking about social platform bios, logos, names, trademarks and brand tone of voice. It should be relatively simple to update a social media account without interrupting ‘regular’ behaviour, but if you need users to take action, give them notice and follow up with regular ‘countdown to launch’ reminders.
PPC – If you run Adwords paid search activity then this is a biggie. Make sure you update your final URLs to reflect the URL changes you have made in the migration plan – the last thing you want is your ads sending users to broken links or being disapproved entirely. Also, don’t forget to adopt the same tracking codes/UTM parameters to ensure that there is no break in reporting.
Offline – If your migration involves a name change you may want to take out advertising on billboards, local press (and beyond depending on your offering). Also, don’t forget to look back at previous domain campaigns/products that may have been supported by vanity URLs – be sure to 301 redirect these to your new site if they are still valid/ have garnered links and social shares.
SEO – Organic traffic is likely to be impacted most adversely in the short run as Google makes sense of redirects and page changes that have been made. As a backup, it is useful to allow extra budget to invest in alternative traffic sources in this period such as email or PPC spend for keywords that you rank well for organically.

Do get the timing right

Timing is everything. In the planning stage it is vital to choose the best time to migrate by considering the following questions:

Is your site affected by seasonality? If so when are these peak periods?

Who are the core team members that will be involved in the site migration? What is their availability?

Take advantage of your analytics data to understand your business traffic patterns, and Google Trends data to understand overall user demand within the market. Plan to migrate during a quiet business period where ample staff resources are available.

Do set the tone

As hard as you try migrations don’t always go to plan, therefore it is recommended to manage expectations early:

Agree on migration objectives (why are you migrating?)

Be clear about the amount of time and effort a migration takes and the tight deadlines needed to keep the project on track

Outline what is expected from everyone involved in the migration and the impact of these expectations not being met – make sure that a migration plan is developed and communicated across all teams involved early on

Be clear about the potential impact of migration in both the short and long term and the average length of time needed for ranking recovery (this will be longer if site design, URL structure etc.. are compounded)

Share migration case studies with clients if you have them

Do agree on reporting format and frequency

Agreeing on what will be monitored and reported will provide you with accountability and makes sure that you are aware of what is important to measure; and what data is important to pull before launch. From experience, clients often request weekly ranking reports with keywords divided by category type (determined by the site), and page speed insights within the first few weeks of launch.

Although this list of dos and don’ts is important, it isn’t exhaustive. It is strongly recommended that a thorough technical audit is performed before migrating. This allows you to identify any issues that should be resolved to prevent trouble down the line. If you are aware that your site is in particularly poor technical standing or suffering from a penalty, it is advised to delay your migration plans until these issues are resolved.

Want more advice like this in your inbox? Join the monthly newsletter.

Pre-migration: fuelling the rockets

Now we’ve thought about what’s in the abyss, it’s time to arm yourselves with information before you get out there. It is vital to obtain as much URL information about the legacy site as possible, for tracking, benchmarking and URL mapping purposes. This can be gained by exporting data from the following sources:

Sites Analytics Platform – Export a list of every page that has received at least 1 visitor in the last 12 months. This ensures that all traffic driving pages are accounted for ready for the URL mapping process.

Buzzsumo – Export a list of all your most shared content. This is a great way to ensure that content that users have engaged with and continue to engage with are accounted for.

Screaming Frog/ Deepcrawl – Run and export a full crawl of the legacy site to gather a list of every URL that may need to be mapped. (If you have a separate M-Dot site or subdomains that you are looking to move, don’t forget to include these in the crawl).

Moz’s Open Site Explorer/ Majestic/ Ahrefs/ Google Search Console – from these tools, export a list of each legacy URLs that have external links pointing to them. By using each tool you can ensure that you are casting the data capture net wide as wide as possible, given that each tool collects backlink data differently.

AdWords – Export a full list of URLs you are using for your PPC campaigns. If you have PPC specific URLs, ignoring these could lead to broken links, a significant drop in quality score and even mass ad disapproval.

Once you have exported this data, it is time to combine lists, remove duplicate URLs and prioritise the most important URLs for redirection. This can be done using programmes such as GDoc and Numbers (for Mac), but for the speed of processing large volumes of data and the ability to easily group, de-dupe and order, Excel is the preferred choice. Next, create a list of URLs for the new site. When you have a list of unique legacy site URLs ordered by importance, a list of planned URLs for the new site, it’s time to create your URL redirect map.

Map each legacy URL to the new site URL on a 1:1 basis (where possible) rather than blanket mapping to the homepage or category page, and ensure that this is done via a 301 redirect – given that you want to let search engines know that the redirect is permanent. With some migrations, there are an enormous amount of URLs that need to be mapped. If this is the case look out for opportunities to use formulas and regular expressions to make the task lighter.

Once you have created your URL map for the new site, it’s time to benchmark your legacy site. This will make it easy to measure current performance against your new site. Make a record of the following on your legacy site:

Site speed of the top traffic/revenue-driving pages using tools like Pingdom, GTMetrix or Google PageSpeed Insights.

Rankings for your keywords (this does not need to be exhaustive, although it should contain your most valuable keywords and be spread across the products/services you offer). In order to effectively monitor keyword behaviour and patterns after migration, be sure to group similar keywords together in ‘category’ type groups.

Organic traffic and conversions per page.

Now that you have your most important data, and your new domain confirmed:

Create a robots.txt file to dictate which areas of your new site search engine spiders can access. Areas that you don’t want crawlers to reach should be marked with ‘disallow:/folder-on-site/’. An example of this can be found in Google’s robots.txt file.

Create an XML sitemap for the new site.

Create a useful 404 page to help users that reach a broken/ non-existent page find their desired destination on site.

Ok so now you are ready to make the journey right? Not quite yet – the abyss can be big and scary, so I would recommend performing a test run.

If you aren’t using a staging environment to test site changes it is highly recommended that you start now. A staging site is a great way to mess with settings pre-launch to understand the full effect of the changes made. Just make sure that it is either blocked in robots.txt and/or all test site pages have a noindex tag on them. Once this is done use the staging site to:

Test every 301 redirect from the legacy to the new domain.

That URLs present the expected information (e.g meta descriptions, H1 tags, title tags).

That internal links present 200 status codes and there are no broken links present.

The migration: launch

Finally, you’ve finished you rigorous testing, you’ve set up your monitoring tools and everyone and everything is in place for the big button push – launch that site!

Launch! – Publish content to the new domain and ensure that there are no internal broken links and pages are displaying as expected. Apply the 301 redirects from the legacy domain to the new domain.

Crawl Legacy URLs – Using Screaming Frog upload your legacy URLs in list mode and crawl to ensure that all pages are 301 redirecting. If this isn’t the case, review any non-200 status code pages manually.

Update robots.txt file – Remove the disavow rule in robots.txt/remove the noindex tag from pages where applicable, in order to open up the relevant pages for indexation. Remove password authentication if extra precautions were taken.

Tracking code – Check that all tracking code put on the site (analytics, retargeting, AdWords, Google Search Console etc.) are triggering and collecting data as expected.

Notify Google of site change – If the only change occurring is the protocol (from HTTP to HTTPS), or subdomain name change, this step will not need to be taken. In all other instances, it is imperative to notify Google via the existing Google Search Console domain as soon as the migration is launched.

Fetch as Googlebot – Make sure that your homepage and any other important pages are accessible to Googlebot and display content as expected. You can ‘fetch’ through the following path: Google Search Console > Fetch as Google > Enter URL > Fetch and Render > Submit to Index. Although other search engines will pick up changes from Googlebot, it is advised to follow the same process with the designated webmaster tools for each search engine that contributes a significant amount of site traffic.

Real-time – Using Google Analytics (which you should be, even if you use another analytics platform) monitor the real-time feature to view the drop in users to the legacy site and the rise in users to the new site.

Review and Upload Sitemap – Check that the new site XML sitemap is as expected and that URLs are returning a 200 response code when ran through Screaming Frog in list mode (if errors occur address each URL respectively). Once this is done, via Google Search Console, upload the legacy and new XML sitemaps through the following path Google search Console > Crawl > Sitemaps > Add. Uploading both the new and legacy sitemaps will aid crawlers to identify the new desired page and understand that legacy URLs have been redirected. As above this should be done in all webmaster consoles that contribute a significant amount of traffic to the site.

Post migration: fighting the baddies and taking it home

You’ve thought about the journey, fueled your rockets and now you are in flight. You are landing soon and you want to make sure you glide rather than fall out of the sky. Depending on the strength of your site, backlink profile and social clout, Google will begin crawling your site quite quickly, however, new pages entering the index will occur over time. Regularly check search engine caches for important pages such as the homepage and top level category pages to identify when the new URLs/page content are indexed.

Google Search Console checks

In the days after migration, Google Search Console makes it easy to monitor a site migration including; messages and crawl error reports:

Alerts and messages – Check the Google Search Console inbox daily for any alerts or error messages that need to be addressed.

Indexation – Compare the number of submitted URLs to the number of indexed URLs according to Google Search Console. These numbers may not be close together in the first few days, but if this is the case after this period, there may be errors that need to be addressed.

Crawl errors – Be sure to check the crawl error report daily for the legacy site and the new site. Within this report, it is important to pay attention to the date the error appeared and compare this to the date any changes were made. If you believe that the errors in the report have already been identified and resolved mark all errors as fixed. If they are still an issue, the error will return and it will be clear what needs to be addressed.

Screaming Frog crawl

Beyond Google Search Console, Screaming frog is a great tool to monitor status codes, redirect chains, tracking code and more. Using the tool, perform a crawl of the legacy site URLs to ensure that:

There are no temporary 302 redirects, or redirect chains present

No real pages return a 404 status code

Tags and meta descriptions have been migrated as expected

Analytics tracking code is present on all pages (use the custom extraction feature to identify this)

No pages that you want to be indexed are being blocked by robots.txt or meta robots tags

Update online properties

Make sure to update social media properties to reflect the site migration, even if redirects are already in place. It may also be beneficial to update Twitter handles and brand pages. BothSearcEngineGuideandMozprovide helpful social rebrand guides for all the major social platforms.

Update your site’s most valuable inbound links

Where possible it is strongly recommended to contact the owners of sites that link to yours where the URL has changed. Although a redirect will already be in place, a linking root domain updating their link directly to the new URL will remove undesirable redirect chains and ensure that the maximum amount of link equity is passed to the new page. More often than not, the sites will appreciate the update. Use the data pulls collected from the pre-pre-migration stage from Majestic, Ahrefs, Google Search Console and Moz’s Open Site Explorer, identify your most valuable inbound links and reach out.

Build new links to your site

It is important to build new links in order to replace some of the link equity lost from 301 redirects, and to create new paths for search engines to discover in order to crawl your site. As always, this is best done by creating content that is informative, relevant and useful. Evaluating the existing content you have via what performs well in terms of visits and engagement, and grouping these using acontent matrixcan help determine your next move.

Tracking and benchmarking

Once the new site has launched, it is time to monitor and report on the impact of your changes:

Compare site speed and usability of the legacy site vs. the new site for the legacy site’s most valuable pages based on the benchmarking data collected earlier.

Using your chosen ranking tool, monitor your pre. Vs. post-migration performance on a weekly basis. As tempting as it is; try not to draw any conclusions on positions for at least 4 weeks. It can take a while for Google to completely understand the migration that has taken place and this is compounded by the size of the site among other factors. Eventually, rankings should recover around the same positions they were previously. As it is quite common for rankings to drop before recovering, it is stressed early in this post to be transparent with clients so that there are no nasty surprises.

Final thoughts

Just to wrap up for those of you who looked at the post and thought TLDR (too long didn’t read), a site migration is a significant project which affects multiple digital channels and should, therefore, be performed with great planning and care. For the greatest chance of success, be sure to follow the processes in this migration checklist so you aren’t spending a large chunk of the post-migration period chasing your own tail.

Remember to ask questions early, pull all necessary data with plenty of time, test and retest your 301 redirects before launch and consider the impact of site migration on wider channels. Migrating a site takes a lot of effort, but if done properly, the rewards can be plentiful.

Useful tools

Crawling

Screaming Frog (Free & Paid)

Deepcrawl (Paid)

Link/ engagement intelligence

Majestic SEO (Free & Paid)

Moz’s OSE (Free & Paid)

Ahrefs (Free & Paid)

GSC (Free)

Buzzsumo (Free & Paid)

Site speed and performance

Pingdom (Free & Paid)