A website migration is a term used to describe any significant changes to a website’s setup which may impact SEO, such as changes to the domain, URLs, hosting, platform, or design.
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. A 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.
If you’re thinking about updating links to your site, you may want to update links from pages you control, but I wouldn’t bother doing outreach to update links on other sites that point to you. They should consolidate properly with the 301 redirects. It’s not worth the effort to get them changed.
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:
Remember how we created that list of top pages earlier? These are your priority pages. It’s worth crawling that list in Site Audit to ensure things like redirects are in place and there haven’t been any significant changes. If you set up a separate project for that list ahead of time, you can even do a comparison crawl to see changes on these pages quickly.
You can get page traffic, keyword traffic and change history with the Top Pages and Organic Keywords reports in Site Explorer 2.0. It’s easy to make comparisons for the same domain, but if you changed domains, you might want to export this data to Excel or Google Sheets to make a combined view for different periods and see where any losses may have happened.
You can also use our crawler to make sure your redirects are working properly, and links are redirected properly.
Here’s the easiest way to do that:
This will show you pages with links to them that we see as 404 with our crawler. You might want to redirect these.
Google Search Console has a lot of data to help you with migration. For example, you can check for canonicalization issues using the URL Inspection tool. Just enter the URL, and Google will tell you what canonical they chose.
Beyond that, you can export GSC data and make a combined view of your traffic in Excel or Google Data Studio to watch the migration better. You may also want to use a combined view of the page or keyword data to troubleshoot any losses.
The Index Coverage report helps you see how your pages are indexed. If you’ve uploaded both the old and new sitemap files, you can watch the change in indexing and check for any issues here. By having the sitemap files, you can get specific coverage reports just for the pages in those sitemaps.
If you want to see an overview of Google crawl activity and any identified issues, the best place to look is the Crawl Stats report in Google Search Console. There are various reports here to help you identify changes in crawling behavior, issues with crawling, and give you more information about how Google is crawling your site.
You definitely want to look into any flagged crawl statuses like the ones shown here:
There are also timestamps of when pages were last crawled.
If you didn’t get a baseline crawl of the site and need to check for differences between the old and the new, check archive.org to see if they have a copy of any of the pages. They also usually have copies of robots.txt files from sites that can be useful to see if something went wrong and was accidentally blocked during the process.
If you don’t have access to Google Search Console for a site, you can still check canonicalization by pasting a URL in Google. Usually the first page shown will be the canonical.
And again, if you don’t have access to GSC, many other issues related to crawling can be checked in your log files.
Just a warning that the site: search operator sometimes confuses people. If you use site:, you’re asking what Google knows about a specific website. Just because you see pages there doesn’t mean that’s how they’re indexed or that there’s a problem with the migration. I’ve seen this lead to people doing things like blocking the old site to keep the pages out of the index—which causes problems.
Some problems may show up long after migration is over.
Migrating websites is no easy feat, so it’s time to celebrate if everything went well. However, as this probably won’t be the last time you do a site migration, I’d suggest getting together with those involved one more time to go over what went well, what went wrong, what you would change if you had to do it again.
Got questions? Ping me on Twitter.
Source: ahrefs.com, originally published on 2021-08-11 08:54:52