How to complete a website shutdown with a split migration

I was recently asked by a major global brand to support a website shutdown project. The company was not making enough to support itself and make a profit. The same global brand also owns several other similar companies in the niche.

Shutting down a website is easy, but if you need to do it along with redirects, what and how do you do it?

One of the requirements was to make the shutdown smooth, redirecting half the traffic to one website and half to another. The type of product was decisive.

Why is it called “split migration”?

A website migration is a detailed, procedural process that often involves changing domain and URLs, redesigning, or changing platforms. Though it’s tedious even on a small site, the problems you may encounter only increase with each additional page on a site.

Now imagine a website with thousands of pages or products that you need to include in the migration. Add to this the complexity of having to migrate parts of a single site between two other sites.

How do you deal with thousands of pages and products when you need to move them to two different and existing websites?

Before this point I had never done a split migration, but I had a general idea of ​​where to start and how to begin the process.

Unfortunately, migrations are more than a simple redirect. Every migration comes with its difficulties, but this particular one was a bit easier as it only involved URL redirects from the source to the destination pages.

However, the process would be more tedious for a normal migration or platform change that involves:

• metadata
• contents
• headlines
• 404 error
• Existing redirects
• pictures
• Etc.

In terms of Quality Assurance (QA), a simple URL redirect is easier to test and verify that everything is working properly. Still, we went through several stages to make the process run smoothly, starting with “discovery”.

discovery phase

I knew my biggest challenge was identifying the existing pages on all three sites. Let’s call them Source, Target1, and Target2 for privacy, intellectual property, and other legal reasons.

I started with a screaming frog crawl that went through the source site and identified all indexable pages. And for an easier decision-making process, I needed to pull Google Analytics and Google Search Console data using the APIs.

But I was missing another piece of data. I didn’t have access to the Semrush API, so I had to get the backlink data separately. Once you have the list of URLs to work with, make sure to pull backlink data as well.

You can change this to Ahrefs or another preferred source. The point here is to know how important a URL is in terms of backlinks.

---

---

construction phase

Now that I’ve collected all my URLs from the source page I needed to work with, I needed a few things to make the process smoother:

• Clean the list to exclude URL parameters or other duplicates.
• Identify the owners of the page (which site should it go to – Target1 or Target2).
• What is the priority of the page? (Does it have direct traffic? Does it rank in Google? Does it have backlinks?)
• What is the status code of the page? (Is it a 200 or a 301 or a 404?)

I put my ScreamingFrog data and Semrush data into separate sheets and created a Google Sheets file:

First, I shared the file with all contributors and owners so they could choose the URLs that belong to each destination. Remember that each URL on each of these websites can have its counterpart.

For example, a specific product existed on both the source and target websites, so the final redirect should be to the target URL and the same page.

You can also pass parameters. So make sure the goal is filled in correctly.

In my assignment, I worked with 18,000 URLs, and after some filtering and removing unimportant URLs, I ended up with 11,000.

Testing

In most cases you would need to test this on a temporary server. For example, this may or may not have a setup of your actual source URLs dev.source.com Instead of source.com.

You can easily temporarily replace your source URLs or use a duplicate of the file.

When testing, make sure to use the same configuration that you used during discovery.

Update ScreamingFrog export in SF internal ALL sheet adjusts the data in automatically URLs sheet and show you the ones that have failed destination url.

But what went wrong?

Every migration is a learning experience. If you’ve ever performed a migration, you know that a single mistake can result in 404 errors, images not loading, or other issues. Luckily, the biggest issue we had was a global server-side cache that affected the testing process.

This migration QA was based on two things:

• alignment.
• Checking 301 redirects.

We spent more time on the discovery phase than on the migration itself.

One thing we take away from this particular migration is that you really need to learn the ins and outs of a website. It takes a lot of time to work with large teams and learn who owns each site and how to manage it (sites or site owners).

Nothing in particular hindered the migration, but we attribute this to the enormous time investment in the discovery phase. If we hadn’t devoted a lot of time to this phase, it could have ended badly.

Discovery allowed us to be prepared for issues during the migration, so we could bring in the right people and fix the error immediately.

Using the template helped us a lot.

template

This shared migration template will be updated as new and similar projects come my way. Please make your own copy rather than requesting access. Improve or suggest improvements as you work on it.

Conclusion

Our migration was a success, it took us 5 minutes to go live (including clearing the entire global cache) and only 15 minutes to do a list crawl to see that all redirects were working properly.

The definition of “success” is something that every migration requires. With most migrations, something always seems to go wrong. Even if you spend extra time in the setup phase, there’s always a small detail that gets overlooked.

Admittedly, the success of this migration was easier than others done in the past, as the only real quality assurance required was to make sure the redirects were working. Automation helped here to verify that all redirects were successful.

However, that is only part of the story. We also waited for the following before considering the project won:

• The source website pages were slowly deindexed.
• Landing page rankings started to increase.

We encountered an issue with a server-side cache that was affecting the verification process and had to be cleared a few times. Global caches always seem to cause problems with migrations, so you should definitely take this into account when working on a regular or shared migration in the future.

Within a day we started seeing updates in Google’s search results and many of the landing pages were increasing due to targeted redirects.

---

The opinions expressed in this article are those of the guest author and not necessarily those of Search Engine Land. Staff authors are listed here.

---