Split migrations are not something you’ll need to do often, but when handling a site migration for a large, global brand, it’s a very beneficial process. Recently, a major brand needed help with their shut-down project for one of their websites.
However, the brand didn’t want to waste all of the resources and SEO value they already had on the website.
It’s not uncommon for brands to spin off multiple niche sites or projects, realize that they’re not profitable and shut down these services. For example, Google has shut down many projects:
Google Video (led to purchasing YouTube)
So many others
The brand I was working with had multiple similar projects in a similar niche that were profitable. They wanted to shut down one project, let’s call it Source, and redirect to two sites: Destination 1 and Destination 2.
However, the site had over 18,000 pages, and the brand wanted help making the migration go smoothly and without any redirect mistakes impeding the process.
Let’s see what I did to go through the split migration from start to finish.
The Goal of Split Migration
Clients have goals, and my client’s goal was as follows:
Shut down the Source website smoothly
Redirect half of the site to Destination 1
Redirect half of the site to Destination 2
Since these were all product websites, breaking pages down into product types helped with choosing which redirects would go to which domain.
While I’ve done a lot of site migrations over the years, I’ve never done what I call “split migration.” However, it was a great success, but it required quite a bit of preparation to execute properly.
Phase 1: Discovery
First, if you’re going to be doing a split migration, you need to have a discovery phase. There is a lot going on here, and you need to identify all of the pages on:
You can use many tools to crawl your site, but for the sake of this project, we relied on ScreamingFrog.
The tool allows you to connect to different platforms using APIs. In this case, I wanted to gather data from:
Google Search Console
Once all of the APIs are connected, be sure to save the configuration file because it will be needed in the future. If you don’t save the config, you’ll have to redo everything when entering in the test phase or will have to deal with some wildly inaccurate data.
You’re going to be doing this for all three sites in the split migration process.
However, one main issue with this approach is that I couldn’t connect to SemRush’s API to collect backlink data. This shouldn’t be a problem if you’re using Moz, Majestic, or Ahrefs. What you would do here if no API exists is collect all of the backlink data separately and add them to a spreadsheet so that you know which pages on all sites have the best link portfolios.
Once you’ve done that, it’s time to move into the setup phase.
Phase 2: Setup
If the sites involved in the migration are massive, you’ll be overwhelmed with URLs to look through. What I did was start with the Source site and started to clean up the list of URLs:
Exclude some URLs based on parameters
Identify the priority of each page based on:
During the setup, it was easier to identify the owners of the page based on where the page would be redirected.
Since I was working with both ScreamingFrog and SemRush data, I decided to create a Google Sheets file that would help me make sense of all of the data collected. I made a template from this file, download the split migration template.
Enterprise sites of this size have many stakeholders and parties involved, so once your file is created, bring them in on the migration process. What worked best during this particular project was to:
Share the file with all parties and owners
Allow these stakeholders to select and identify where each URL should point to after the migration
Since these sites had similar or the same products for sale, most redirects went from: Source product to Destination product.
Of course, you can also pass parameters if you want to track the process.
In total, before the setup phase, I was dealing with 18,000 pages, which I was able to cut down to 11,000. Of course, migrating 11,000 pages is still a major undertaking, but it’s much easier than before the filtering process.
You’ll find your own filtering parameters during the discovery phase of the split migration. The key to success here is to bring in all stakeholders during the decision-making process to determine where URLs should be redirected. Taking this approach ensures there are no disagreements when the migration is executed.
Phase 3: Test and Retest
Once you have all of your URLs and their respective redirects mapped out properly, it’s time to test out everything. You can perform one redirect at a time and test everything, but you’re going to spend weeks doing this for 11,000 pages.
Instead, testing on a temporary server is safer and more efficient.
You’ll want to create a test server for Source with:
All pages to be redirected
Images / other files not redirected won’t matter if they don’t have any traffic or rankings
Using a backup file or just creating a duplicate file on the test site will more than suffice. Your goal is to test the mass redirects that you plan on putting in place.
Once the redirects are in place, it’s time to:
Open up ScreamingFrog
Scan the site
Update the export in the template provided on sheet SF-Internal ALL
You’ll want to compare the most recent scan from ScreamingFrog to find any failed redirects. Work through the failed list, take corrective action and then rerun your test. You’ll need to repeat this process until all of the redirects work flawlessly.
Then, when there are no failed URLs to worry about, you’ll move to execute the final migration.
Once the final migration is done, you’ll want to run a final test and take any necessary corrective action.
Using the same process above, it took about 5 minutes for the final site migration to go through. Of course, the three phases together took a lot of time to complete. However, the client wanted to have a smooth shut-down for their project, and a 5-minute split migration was considered a success.
It took another 15 minutes to run a list crawl to verify that all of the destination URLs were correct.
SEO value indeed flowed from the Source site to the destination sites. It took just one day to see the impact of the migration, with many of the targeted redirects seeing an immediate bump in the SERPs.
Over the next few weeks, the Destination sites saw a significant jump in organic traffic.
For major brands that are closing down massive projects like this one, it makes more sense to perform a split migration than just close the project with all of the resources put into the site being lost.