Need Help? Talk to Our Experts
This post was last updated by Zee Hoffmann Jones on November 2019
In online marketing, “site migration” is usually a phrase that makes SEOs, PPCers, site owners and stakeholders wince. Regardless of whether you think site migrations are real, we’ve all heard horror stories about sites that have gone through domain name changes and experienced a massive 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 are moving from HTTP to HTTPS, it’s crucial to have a solid action plan to avoid traffic and revenue loss.
On this journey, we’ll cover some of the most important things to address pre-migration, during your migration and post-migration. We’ll share a list of tools our team recommends and even give you a free site migration checklist – to give your site the best chance of a smooth transition to your new destination.
Got an upcoming site migration?Access the site migration checklist for free.
Before you rush off into the unknown, let’s start with the basics: migration types. There are many reasons you might need to migrate your site, but here are some common ones:
Two main types of mobile migrations include m-dot roll ups (e.g. m.domain.com) and responsive redesigns (e.g. redesigning your mobile experience from a pinch and zoom to one that fits various screen sizes). The main reason for these migrations is to create universal experiences of your site for all users, regardless of device type. This is especially important as Google’s index is now mobile first. Building a responsive site helps consolidate site authority and reduce development resources (due to having only one site to manage and update).
An HTTP to HTTPS site migration is getting rarer, as most sites are automatically built with secure certificates, like TLS and SSL certificates. This type of migration is one where the domain remains unchanged, but a secure certificate becomes associated with the site and changes your site’s protocol to HTTPS. This certificate is a symbol of a safe and trustworthy site and explains Google’s push for domains to adopt the protocol.
Top Level Domain (TLD) migrations refer to changing the TLD of a site (e.g. changing TLDs from .com to .org). Country Code Top Level Domain (ccTLD) migrations refer to a move from a country-specific TLD to a more internationally recognised TLD (e.g. .co.uk to .com). These moves are valuable to website owners that are trying to target a larger audience outside of a particular country’s location.
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 dos and don’ts:
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. This encompasses things like making sure your new design is accessible to special needs users and not exclusively relying on JS to load your site’s content.
If you’re changing your company’s name or branding as part of your site migration, it’s crucial that you not overlook your other digital channels:
Social – This involves thinking about social platform bios, profile pictures and logos, names, trademarks and brand tone of voice. It should be relatively simple to update a social media account without interrupting your regularly scheduled posts, but if you need users to take action (i.e. follow a new brand name account) or not to take an action (i.e. if you don’t want your devoted followers to unfollow you when your account name changes), give them notice and follow up with regular “countdown to launch” reminders.
PPC – If you run Google Ads or other paid search, 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/rebrand, you may want to take out advertising on billboards, local press and beyond (depending on your offering).
External Domains – 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 domain if they are still live or have earned links and social shares.
SEO – Organic traffic is likely to be impacted most adversely in the short term as Google makes sense of redirects and page changes that have been made. To prepare for this, plan to invest extra budget in alternative traffic sources such as increased email marketing, paid and social advertising.
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? Look to your website analytics tracking for these data (e.g. Google Analytics).
Who are the core team members that will be involved in the site migration? What is their availability? Are there concurrent company launches or releases at this time? Are any key stakeholders going to be out of the office around your launch date?
Take advantage of your analytics data to understand your business traffic patterns, and Google Trends data to understand overall user demand within your industry. Plan to migrate during quieter business periods when ample staff resources are available.
Migrations don’t always go according to plan; therefore, it is recommended to manage expectations early:
Agree on migration objectives. Why are you migrating? Is this a necessary rebrand? Is it time that you made your site secure or fully responsive?
Be clear about the amount of time and effort each step of your migration will take, and pad your timing estimates to account for delays and unforeseen blockers. Documenting firm deadlines and tight feedback turnarounds in one universal location (such as a shared work calendar, or project management tracker like Asana) will be crucial to keep the project on track.
Outline each team member’s role and responsibility in this migration and share it early on so that everyone knows what is expected of them. In addition to writing down each person’s expectations, include information around “impact” should their expectations not be met (e.g. if your SEO is unable to deliver mapped keywords by X date, what will fall by the wayside?).
Be clear about the potential impacts of migrating in both the short and long term. Ranking recovery will likely take longer if your site’s domain name, URL structures and protocols are changing (and will be compounded if happening concurrently).
Share migration case studies with your stakeholders if you have them. If you need to convince others that this migration is necessary, examples of others who did theirs well will bolster your argument.
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, we still strongly recommend you perform thorough technical audits before migrating, on your staging site, and on launch. This allows you to identify any issues that should be resolved to prevent trouble down the line.
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 one (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 Link 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 as wide as possible, given that each tool collects backlink data differently.
PPC Accounts – 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 prioritize the most important URLs for redirection. You can use Google Sheets, Excel or Numbers to do this. Next, create a list of URLs for the new site. When you have a list of unique legacy site URLs ordered by importance and a list of planned URLs for the new site, you’re ready to create your URL redirect map.
Map each legacy URL to the new site URL on a one-to-one (1:1) basis where possible, rather than blanket mapping to the homepage or a category page, and ensure that this is done via 301 redirects. With some migrations, there will be an enormous number of URLs that need to be mapped. If this is the case, look for opportunities to use formulas and regular expressions to make the task streamlined.
Once you have created your URL map for the new site, it’s time to benchmark the performance of your legacy site. This will make it possible to measure current performance against your new site. Make a record of the following:
Site speed of the top traffic/revenue-driving pages using tools like WebPageTest, Pingdom, GTMetrix or Google PageSpeed Insights.
Rankings for your site’s most valuable keywords, across the products/services you offer. In order to effectively monitor keyword behavior and patterns after migration, be sure to categorize your keywords.
Average monthly organic traffic and conversions per page. If you use Google Analytics, you can run a crawl of your site (using Screaming Frog or Sitebulb) and connect your GA account to pull these data for you.
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 are allowed to crawl. 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. You can generate one using a crawler, like Screaming Frog.
Register and set up the new domain in Google Search Console (if you’re changing domain names or protocols).
Create a useful 404 page to help users that reach a broken/ non-existent page find their desired destination on site (and make sure it returns a 404 status code).
If you aren’t using a staging environment to test site changes, stop what you’re doing and set one up now. A staging site is a great way to run through changes and settings before launch to understand the full effect of the changes made. Just make sure that it is either blocked in robots.txt and all test site pages have a noindex tag on them. Once this is done, use the staging site to:
Test every 301 redirects from the legacy URLs to their new locations;
Confirm that URLs present the expected information (e.g. meta descriptions, H1 tags, title tags; and.
Ensure all internal links return 200 status codes.
Finally, you’ve finished your 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 a crawler, upload your legacy URLs in list mode and crawl to make sure your 301 redirects are correctly in place and that they resolve to a 200 status code URL on your new site. If your legacy URLs return 200, 404 or non-301 status codes, then raise the alarm to your developers.
Update your robots.txt file – Update any necessary disallow rules in your robots.txt file, and remove noindex tags from pages where applicable in order to allow new pages to be crawled and indexed. Remove password authentication if extra precautions were taken.
Tracking code – Check that all tracking code put on the site (analytics, retargeting, PPC platforms, Google Search Console, etc.) are triggering and collecting data as expected.
Notify Google of site change – If you’re only changing your site’s protocol or subdomains, this step will not need to be taken. If your domain name is in fact changing, use Google Search Console’s Change of Address tool to notify Google of this change.
Fetch as Googlebot & Submit for Indexation – Make sure your homepage and any other important pages are accessible to Googlebot and display content as expected. Assuming your pages are functioning as they should, you can spur on indexation of these pages by requesting indexation You can “fetch” through the following path: Google Search Console > paste your URL into the Inspect URL search bar > Test Live URL > Submit to Index.
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 confirm that traffic is passing to the new site.
Review and Upload Sitemap – Check that your new site XML sitemap returns 200 response codes when run through a crawler (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 > Sitemaps > Add. Uploading both the new and legacy sitemaps will aid crawlers in identifying new pages and understand that legacy URLs have been redirected.
You’ve thought about the journey, fueled your rockets and now you are in flight. Depending on the strength of your site, backlink profile and social clout, Google will begin crawling your site quite quickly; however, there will be latency in new pages getting indexed while crawlers discover and process these site changes. Regularly check search engine caches for important pages such as the homepage and top level category pages to identify when new URLs/page content are indexed.
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 isn’t improving in the second week after launch, there may be errors that need to be addressed.
Crawl errors – Be sure to check GSC’s crawl error report daily for both the legacy and new sites. 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.
Beyond Google Search Console, software crawlers are great tools to monitor status codes, redirect chains, tracking codes and more. Using a crawler (e.g. Screaming Frog, Deep Crawl or Sitebulb), perform a crawl of the legacy site URLs to ensure that:
There are no temporary 302 redirects, or redirect chains present;
No valuable pages return 404 status codes;
Tags and meta descriptions have been migrated as planned;
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.
Make sure to update social media properties to reflect the site migration, even if redirects are already in place (e.g. update your site’s link in social bios). It may also be beneficial to update Twitter handles and brand pages. Both SearchEngineWatch and Moz provide helpful social rebrand guides for all the major social platforms.
Where possible it is strongly recommended to contact the owners of sites that link to your legacy URLs. 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 your new pages. More often than not, the sites will appreciate the update. Use the data pulls collected from Majestic, Ahrefs, Google Search Console and Moz’s Open Site Explorer to identify your most valuable inbound links and reach out.
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 relevant and useful content and promoting it to appropriate outlets. Evaluating the existing content you have via what performs well in terms of visits and engagement, and grouping these using a content matrix can help determine your next move.
Once the new site has launched, you should 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 four 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 to their previous positions. Since it is quite common for rankings to drop before recovering, make sure you communicate this transparently to your stakeholders so that there are no nasty surprises.
TL;DR (too long; didn’t read): a site migration is a significant project that 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 website 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.
Refund Policy|Terms & Condition|Blog|Sitemap