A Website Migration Takes More Than A Checklist To Be Successful

There are many different kinds of migrations, but the basic steps for planning and troubleshooting are similar. Migrations can be highly complex as they often involve many people and moving parts. Don't panic if everything doesn't go as planned; you can fix almost anything that goes wrong.

In this guide, we'll cover:

You need to know what is changing and who needs to be involved for it to happen. In other words, you need a plan and a place to track all the moving parts. You'll need to know all of the people involved, their role, deadlines, and have a process in place to track everything. An SEO project manager and project management system helps with this. Trying to do it all in email and Slack can get out of control fast.

You also want to have a rollback plan, just in case something goes horribly wrong. You should always have a way to get back to the original state, even if you only plan to use it in extreme situations.

You'll want to know the impact of a move, so make sure you have access to GSC and Analytics on the old and new sites (make a combined view if needed to see both). Some changes may take a few weeks or even months where you may see flux, but others may not see any changes at all. For instance, if you're migrating a mid-size site to a new domain, I'd expect a few weeks of flux. But if you're combining into an existing site, you may not see any traffic disruptions at all.

You also want to do a bit of prep work. I suggest a few steps:

Precisely what's involved in a website migration depends on whether the URLs will remain the same or not. Below we'll discuss both scenarios.

This is typically a more straightforward move—at least SEO-wise—since fewer things are changing. It still may be a complex move, but many of the tasks involved with these moves are typically more the work of infrastructure/DevOps or developers and not SEOs.

These migrations may include:

If you are using a staging or dev site, it’s best to get access to check for issues before you launch it live.

For this, you're essentially looking for any changes, including things like:

Use the comparison function of Site Audit to see changes since your last crawl:

There are a couple more issues that may create more significant problems.

These migrations will usually be more complex. The exception is moving from HTTP to HTTPS—which is pretty easy these days.

These migrations may include:

I wouldn’t worry about things like a redirect chain on the root path or updating links to the site. Fixing the chain and updating links won't provide any benefits since signals consolidate because of the redirects.

Here's a quick tip for Site Audit users: if you change the scope of your crawl in the project settings to a different domain, your new crawl will be on the new domain and you'll be able to compare it to the crawl on the old domain.

You want to catch changes as early as possible so if you have a dev or staging site, you should crawl this to make sure everything's okay before pushing changes to a live site. Remember that if an old site was using HTTPS and the certificate expires, bots are passed but users will receive an error message and won’t be redirected. There are multi-domain certificates that cover multiple sites that can help prevent this issue.

If you see a drop, it’s likely related to redirects, something not being able to be crawled, something noindexed, changes to the content or removing content, changes to internal links, or something that changed related to technical SEO.

There are various ways to watch the progress of the migration and make sure everything is progressing as it should.

There are several various ways to look for changes. As I mentioned earlier, you can change the scope of your crawl in Site Audit and get a comparison that shows you what changed. You'll want to look out for changes to things like: