In digital marketing, “site migration” is usually a phrase that makes SEOs, PPCers, site owners & 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 & experienced a massive drop in traffic & visibility, & 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 & revenue loss.
On this journey, we’ll cover some of the most important things to address pre-migration, during your migration & post-migration. We’ll share a list of tools our team recommends & even give you a free site migration checklist – to give your site the best chance of a smooth transition to your new destination.
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:
Mobile Migrations: M-Dot & Responsive Redesigns
Two main types of mobile migrations include m-dot roll ups (e.g. m.domain.com) & responsive redesigns (e.g. redesigning your mobile experience from a pinch & 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 & reduce development resources (due to having only one site to manage & update).
HTTP to HTTPS migrations
An HTTP to HTTPS site migration is getting rarer, as most sites are automatically built with secure certificates, like TLS & SSL certificates. This type of migration is one where the domain remains unchanged, but a secure certificate becomes associated with the site & changes your site’s protocol to HTTPS. This certificate is a symbol of a safe & trustworthy site & explains Google’s push for domains to adopt the protocol.
TLD Migrations & ccTLDs
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/Consolidating Domains migrations
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 & visibility.
No matter which type of migration you are looking to do, each comes with a shared list of dos & 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. This encompasses things like making sure your new design is accessible to special needs users & not exclusively relying on JS to load your site’s content.
Do consider wider channels
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 & logos, names, trademarks & 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 & 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 & 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 & social shares.
SEO – Organic traffic is likely to be impacted most adversely in the short term as Google makes sense of redirects & 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 & social advertising.
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? 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, & Google Trends data to understand overall user demand within your industry. Plan to migrate during quieter business periods when ample staff resources are available.
Do manage expectations
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 & effort each step of your migration will take, & pad your timing estimates to account for delays & unforeseen blockers. Documenting firm deadlines & 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 & responsibility in this migration & 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 & long term. Ranking recovery will likely take longer if your site’s domain name, URL structures & 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.
Do agree on reporting format & frequency
Agreeing on what will be monitored & reported will provide you with accountability & makes sure that you are aware of what is important to measure; & 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), & page speed insights within the first few weeks of launch.
Although this list of dos & don’ts is important, we still strongly recommend you perform thorough technical audits before migrating, on your staging site, & 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 & 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 & continue to engage with are accounted for.
Screaming Frog/ Deepcrawl – Run & 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 & even mass ad disapproval.
Once you have exported this data, it is time to combine lists, remove duplicate URLs & prioritise 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 & 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, & 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 & 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 behaviour & patterns after migration, be sure to categorise your keywords.
Average monthly organic traffic & conversions per page. If you use Google Analytics, you can run a crawl of your site (using Screaming Frog or Sitebulb) & connect your GA account to pull this data for you.
Now that you have your most important data, & 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 & 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 (& 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 & set one up now. A staging site is a great way to run through changes & settings before launch to understand the full effect of the changes made. Just make sure that it is either blocked in robots.txt & 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; &
Ensure all internal links return 200 status codes.
Finally, you’ve finished your rigorous testing, you’ve set up your monitoring tools, & everyone & everything is in place for the big button push – launch that site!
Launch – Publish content to the new domain & ensure that there are no internal broken links & 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 & crawl to make sure your 301 redirects are correctly in place & 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, & remove noindex tags from pages where applicable in order to allow new pages to be crawled & 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 & 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 & any other important pages are accessible to Googlebot & 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 & confirm that traffic is passing to the new site.
Review & 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 & new XML sitemaps through the following path Google search Console > Sitemaps > Add. Uploading both the new & legacy sitemaps will aid crawlers in identifying new pages & understand that legacy URLs have been redirected.
You’ve thought about the journey, fueled your rockets & now you are in flight. Depending on the strength of your site, backlink profile & social clout, Google will begin crawling your site quite quickly; however, there will be latency in new pages getting indexed while crawlers discover & process these site changes. Regularly check search engine caches for important pages such as the homepage & top level category pages to identify when 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 & crawl error reports:
Alerts & 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 & new sites. Within this report, it is important to pay attention to the date the error appeared & compare this to the date any changes were made. If you believe that the errors in the report have already been identified & resolved, mark all errors as fixed. If they are still an issue, the error will return, & 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 & 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 & 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.
Update online properties
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 & brand pages. Both SearchEngineWatch & Moz provide 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 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 & 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 & Moz’s Open Site Explorer to identify your most valuable inbound links & 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, & to create new paths for search engines to discover in order to crawl your site. As always, this is best done by creating relevant & useful content & promoting it to appropriate outlets. Evaluating the existing content you have via what performs well in terms of visits & engagement, & grouping these using a content matrix can help determine your next move.
Tracking & benchmarking
Once the new site has launched, you should monitor & report on the impact of your changes:
Compare site speed & 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, & 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 & should, therefore, be performed with great planning & 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 & retest your 301 redirects before launch & 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.