There are a number of very good reasons to migrate your website:
- For some businesses, it’s a matter of security. A good example would be an http domain that needs to move to an https one.
- For others, it’s a matter of cleaning up while changing things like content management systems. If you’re moving from, say, Joomla to Drupal, it might also be a good time to just migrate the content that still matters, and plan for just that.
- For some organizations, it’s a matter of acquisitions. A company that gets purchased will sometimes need to get folded into the “mother” domain.
- For some companies, it’s just time for a rebrand, and the domain name is one of the things to change.
Whatever your reason for the migration, you need to understand that all domain migrations carry some risks, some of them benign, others website-traffic-breaking.
A carefully planned migration mitigates those risks. It also gives website owners a better shot at retaining already existing search engine referrals, or actually improving on overall website traffic.
Benchmarking before the move
Before planning for the more technical aspects of the migration, there are a number of things you need to dig for using different tools. This is akin to kicking your tires before a long drive. It’s better to go into a migration project prepared.
Every website is different, but you’ll likely want some variation of the items below:
- From Google Search Console, export a year’s worth of Google impressions, click-throughs, and positions. This will establish the baseline for search engine presence that you will need to meet after the move.
- From a website analytics tool (like WebTrends or Google Analytics), export the monthly stats for organic traffic, total visits, average number of 404 errors, the bounce rate, and conversions. Get this for at least one year as well. If your tool has a real time function, get a feel for the concurrent traffic on a weekday, so you can also compare this against the new domain after launch.
- If you have a survey tool (like ForeSee or Qualaroo) export the satisfaction rate, and the percentage of people who can find what they need.
- If your conversions are form submissions rather than purchases, export this from your marketing automation tool and/or customer relationship management (CRM).
Those stats will give you a mix of qualitative and quantitative stats to compare against. One of the advantages of collecting a range of stats for the migration is that if something goes wrong, you’ll be able to triangulate, and isolate what the issue is fairly quickly.
Some migrations can have a ton of moving parts, and most teams will likely be very busy during the move. You’ll want to optimize the time it takes to identify and isolate issues, so that doesn’t add too much of a strain to already busy teams. This way the data crunch is during the preparation phase, rather on the launch day, where all teams are likely to be stretched.
Collecting baseline stats to isolate issues down the line is something all marketers should do if they’re planning for a website migration.
Planning for the different types of website migration
Depending on what kind of migration you’re going to do, there will be different tasks you need to plan for. There are a few things you need to determine:
- Domain only changes versus URL path changes
- Same content or different content
- New content management system (CMS) or same CMS
- New tools or same tools
Let’s get to what you need to plan for given the differences.
Domain only changes versus URL path changes
A domain only move doesn’t change any of the strings after the top level domain. (These are the “paths” or “URL paths”.)
For instance, if all your strings like /products/product1 or /about/company will not change, but your domain will change from domain.com to new-domain.com, then you have a domain only change.
Domain changes
- www.domain.com/path1 to www.new-domain.com/path1
- www.domain.com/path2 to www.new-domain.com/path2
- www.domain.com/path3 to www.new-domain.com/path3
An http to https redirect will also qualify as a domain only move.
By contrast, a migration with URL path changes will mean changes to the strings after the domain.
Domain and URL path changes
- www.domain.com/path1 to www.new-domain.com/new-path1
- www.domain.com/path2 to www.new-domain.com/new-path2
- www.domain.com/path3 to www.new-domain.com/newfolder/newstringsfornewpath3
For migrations where the URL paths don’t change, there are usually technical ways to automatically change the domain string for redirects without writing one redirect for every page on the website.
For migrations where the URL paths actually change, there will be a need to write some page level 301 redirects. This is definitely more cumbersome.
If there will be information architecture changes to a site with thousands and thousands of pages, it may not be feasible to write page-level redirects for everything. You may need to decide on a traffic threshold. For instance, you might like only redirect the top 5,000 pages instead of all 175,000 pages, based on search engine and total traffic rankings.
Same content or different content
If you’ll effectively have the same content on the new domain as you do on the old one, there’s not a ton of things to consider as far as internal linking, ensuring the content groups still make sense, etc.
However, if you’ll add or remove significant chunks of content, you’ll need to carefully map that out.
- Are there any categories that you’ll change, and will you “orphan” pages in the process? Those pages might need to find a new home or get folded into other pages. That needs to be part of your plan.
- Will the main menu still make sense given your new content? If there are sections that are important pages that will be tougher to get to after the move, consider providing additional pathways to them after the content changes have been made.
New CMS or same CMS
If you’re moving from www.example.com to www.new-example.com and you’re not changing the CMS, then the actual migration of the content should be dead simple.
If you’re switching from one CMS to another, that same move may not be a straightforward task. You’ll need to …
- Make sure that the layouts and templates on the old site will be reasonably supported by the new system.
- Determine if there’s a way to export your CMS content into something that the new content management system will accept (even if this isn’t 100%, partial automation of the content migration can help).
- Carve out time for the pieces of the content migration that will be manual due to the CMS change.
New tools or same tools
Your actual tools and the way you deploy tools may be different between the old domain and the new domain.
You need to think of a few things:
- On the new system, is there a master page or something similar to plug-in the scripts you need for tools, either independently or as part of a tag management tool? Or do you need to plug in the scripts multiple times across the site? If it’s the latter, ensure you have ample time for that.
- If you’re switching from a tool-by-tool implementation to a tag management tool like Google Tag Manager, ensure you have enough time to test this scenario out. Tag management tools are useful, but they can take time to get used to, and that should be factored into your timeline for the domain switch.
- If you’re adding tools, ensure you have time for regression testing. Your new tool may not play well with the older tools immediately, and you’ll need time to debug.
Completing the site migration plan
Once you have a handle on the different types of site migration, it’s time to set up the site migration plan.
Let’s build an example for a fairly complex scenario, so you can just strip out the parts you don’t need.
Let’s say you’re migrating from an old CMS to a new CMS. And your information architecture on the new site will be slightly different – some URL paths will be moved to a new location.
Here are a few things you need to do early on from a redirect standpoint:
1. Ensure that you have a way to handle page-level 301 redirects
There are a number of ways to set up “manual” page-level redirects. Some of them involve editing a configuration file, others involve dropping an XML into a module, and others still have a basic CMS function that handles this (assuming you’ll still have access to the old CMS). Determine which path you’re going to take early on, so you can avoid headaches down the line.
2. Check if you can handle wildcard or conditional redirects
If you have the ability to tweak the .htaccess file or a similar configuration file, you can manage some of the redirects via conditions rather than setting up each redirect individually. This will save you some time.
3. Export the top pages on the old site
Choose between total traffic and organic traffic as your determining factor for the rank. (Organic traffic is pretty good for this, so you know you’ll redirect the pages that actually drive search engine referrals before the migration.)
- Choose a threshold that makes sense given the size of the site. The top 100 pages can be optimal for a site that has 500 URLs or so where most of the traffic is for the top 80 pages. However, you may need the top 5,000 pages for a site that has tens of thousands of URLs.
4. Map the top pages to their new location
This is a manual step that you can do to save time down the line. Line up the list of the top pages on a spreadsheet and mark them as old URLs, and then add the new URLs next to them. When you know what to build (like an XML file) you’ll have the file you can start with.
Benefits of 301 Redirects
Adding 301 (or “permanent”) page-level redirects to your most valuable pages as you move to a new domain gets two things done:
- It sends users to the correct page, for user experience (UX) benefits
- It tells search engine spiders about the move, for SEO benefits
When only part of your site has had an information architecture change, you can usually do conditional or wildcard redirects on the parts of the site that still have the same URL path, and only use one-by-one page-level redirects for the smaller number of use cases where they are absolutely necessary.
For example, maybe everything under /product/ just gets changed to /products/ on the new site. You can handle that part of the move using a wildcard replace. But let’s also say that everything under /about/ gets a new “path,” so the actual strings after /about/ will change. For everything under /about/, you need to map the old URL to the new URL, and add a 301 page-level redirect.
This way you get the benefits of link equity transfer from the old domain, without overwhelming the team managing the redirects.
Avoiding common pitfalls
There are a lot of ways a domain migration can fail.
Here are just a few of the common ones that you need to watch out for:
1. The redirect tools you have at your disposal are not robust enough for the switch.
- Some redirect tools only manage http URLs, and can’t handle https ones. So, you’ll need to find other ways to deal with your https URLs.
- Some redirect tools are native parts of a CMS and take a boatload of time to set up. That ends up problematic when you have hundreds or thousands of URLs.
- Some redirect tools can’t handle wildcards, so you’ll need to plan for manual redirects. And you’ll need to account for the extra time needed.
Successful website migrations rely on marketers fully understanding the redirect tools at their disposal, and planning for only what’s possible.
Start clarifying what’s available to you with your devs early on, using clarifications like the ones listed above.
Note the limitations you’ll have well before launch day. If there are a lot of manual steps, reserve enough time to tackle those steps.
This ensures that when the day of the switch comes, there are no surprises in this area.
2. The team can’t assess success or failure properly.
If the team has not established benchmarks to meet – search terms the site ranks for, total organic traffic, total visits, satisfaction and success rates on the site, etc. – it can be very tough to tell whether the migration went smoothly.
Maybe overall traffic is about the same, but the success rates started to tank. Maybe the satisfaction scores are the same, but there are fewer search terms that the site ranks for and organic traffic has dropped.
If you don’t have a range of figures you’re looking at, it may look like the domain switch went smoothly while the website is actually taking a hit. Performing badly and recognizing it is preferable to performing poorly and thinking you’re doing well.
Ensure that you have benchmarks for multiple aspects of the site to avoid this issue.
3. The team misses important pages to migrate.
For domains with information architecture changes, it can be easy to lose pages that either rank on search engines or get a significant amount of traffic from multiple sources.
If nobody has done an export of the top pages to ensure all of those get migrated, the team will usually see a dip in traffic after the move.
If this happens, the team needs to scramble a report together and check if the old content is still on a file somewhere so it can be brought over to the new domain, or live with the traffic loss. This type of failure in planning can really hurt overall traffic.
You need to ensure that you’ve looked at your analytics tool and exported the top pages, and that the content plan is in good shape before you pull the redirect trigger.
4. The volume of tasks becomes too much for the team to handle
There are a number of things that can change the volume of tasks required for a domain migration.
The site may have absolute rather than relative links, and you’ll need to do a lot more internal link tweaking than you originally anticipated.
The redirect tool may not have the capability to support wildcards, and you’ll need to manage more manual redirection than you planned for.
There may be non-page-content items that you need to move over to the new CMS, like featured results for on-site search, and you’ll need to devote time to it after the launch.
It’s usually best to assign some extra resources to the site as the switch happens, so you have wiggle room when things do not go exactly according to plan.
Managing the tasks on the day of the switch
Let’s say all the redirects work exactly as expected.
All the content that you wanted to move over has been moved over. You don’t get 404 error spikes, all your tools are firing just like before, all of the non-page-content configurations move over properly.
That’s a great start, but it still leaves some tasks for SEO tasks on launch day:
1. Getting your disallow conditions right on robots.txt
The robots.txt file tells search engine spiders what they should and should not crawl on a site.
Check with your devs and SEOs that you have a configured robots.txt file, and move that over. If you don’t have one, at least ensure that your robots.txt file will not read like this:
- User-agent: *
- Disallow: /
That combination will tell Google and other search engines not to index anything on your website. It’s a scenario you should try to avoid.
2. Creating and validating new Google Search Console accounts
Once the new domain is established, you need to register it to Google Search Console, and prove that you own the domain. You can do this using a number of methods, from dropping a file Google will recognize at the root to using Google Tag Manager.
- Setting up Google Search Console accounts for folders. Once you have the domain validated, you can add the sections of your site as additional properties. This will allow you to do things like look at the searches leading to just your “products” section or just your “about us” section, if you have those. This will get you an extra layer to check if your organic traffic survived the domain migration.
3. Submitting site maps
Depending on your content management system, you can either generate a site map with URL listings from your CMS, from crawling tools, or manually via Notepad.
One thing you can do here is generate a separate site map for each section of your site (one site map for your “products” section, one site map for “about us,” etc.) If Google indexes 90% of your products pages but only 5% of your about pages, you’ll know to fix just the poorly indexed section. You’ll only see that issue if you have separate site maps per section of the website.
Once you have generated site maps for the different website sections, you should submit them to Google via Search Console.
4. Telling Google about the domain switch
This is a step even some seasoned marketers miss. Google Search Console has a tool that allows you to declare a “change of address”. To use it, you need to validate the Google Search Console property for the old and new domains, then follow the steps listed by Google Search Console.
Monitoring the stats after launch
If you have followed the advice on this post so far, you’ll have quantitative and qualitative benchmarks to compare against.
- Survey tool data. A significant dip in satisfaction and people’s ability to find what they need can mean the new structure of the site may be confusing to visitors. You’ll need to rethink the new architecture.
- Google Search Console and analytics tool data. A spike in 404 errors combined with some ranking losses and organic traffic dips will usually mean at least some redirects are failing. You’ll need to investigate the redirect methodology.
- Analytics tool data. A significant drop in total and referral traffic without as large a dip in search engine traffic can mean you didn’t move over content that other websites link to. You’ll need to revisit that content.
Real time monitoring of traffic can also help here. If the concurrent number of visitors on your site is significantly below pre-launch figures (say, less than half of what it was), then you’ll know something is off and you need to dig deeper.
No such thing as over-preparation in domain migration
Moving domains can be a painful process.
There are a lot of ways the process can go poorly for your site. And there are very few paths to complete success.
All that said, if you need to change your domain, it’s best to over-prepare. If you …
- learn what your redirect tools can do for you early on,
- obsess over the content plan until you see no holes left, and
- use data to manage the transition
… you stand a better chance at seamlessly moving to a new domain.
For certain types of moves, if you obsess about the plan, you might even increase traffic and conversions after the switch.
