The Website Migration Guide You Need To Read

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:

• Crawl your website. You’ll use this as a baseline to check for changes later on. You can use Site Audit for this.
• Create a set of test pages such as those from the Top Pages report in Site Explorer. You’ll use these later to check for errors. You may want to go ahead and crawl these in a separate Site Audit project so you can easily compare them later.
• Restrict access to your staging or dev site (if you have one) to prevent it from being indexed.
• Make a backup of your site, just in case you need to go back to it.

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.

When URLs are the same…

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:

• Hosting: CDN, server
• Platform: CMS, language, JS framework
• Design: template, internal links, tags

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

What to look for

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

• Canonical tags. These should be the same.
• Title tags. Make sure these are the same or similar to what you have. New systems may have automated tag generation or some defaults that may be different than what you had.
• Meta descriptions
• Heading tags
• Hreflang
• Schema
• Meta robots. You want to make sure your pages aren’t noindexed.
• Content. This is especially important for JavaScript systems. New systems may not have all of the content loaded into the DOM by default, so search engines may not see some of the content in some cases.
• Internal links. Things like breadcrumbs, related posts, footer links, or even the main navigation may have changed.
• Speed differences

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.

• If you accidentally leave a block in place, search engines can’t crawl your pages.
• Sometimes older redirects aren’t copied over from .htaccess files or server config files, and you’ll lose some of the links that were pointing to your site. This one is tricky because it’s harder to notice and often happens when changing hosts. Keep an eye on your Best by links report in Site Explorer and filter for 404s to see pages with links that are now broken.

When URLs are different…

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:

Specific to HTTP > HTTPS

• Use a Content Security Policy of upgrade-insecure-requests to fix all mixed content issues. It’s quick to implement and works for all resources besides things like internal links, which you still need to update yourself.
• Install a security certificate
• 301 redirect HTTP > HTTPS
• Add an HSTS header

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.

Specific to domain changes

• Lower TTL temporarily (a few hours for the value). This will refresh DNS caches faster and when you make the switch your changes will be seen by more users sooner.
• Use the change of address tool in GSC.
• Check the old domain for any manual actions that might be in place in GSC

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.

All

• Update internal links and links in various tags like canonicals, hreflang, etc. You may be able to use a find and replace plugin to do this quickly for internal links.
• Setup GSC. This can include things like transferring your disavow file, setting geo-targeting, URL parameter settings, and uploading sitemaps. You’ll want to keep a sitemap with old URLs for a short period of time. This will help monitor indexing of URLs in GSC.
• Remove any crawling blocks for pages on the old and new site. Everything needs to be crawled for signals to consolidate properly.
• Make sure pages you want indexed aren’t marked noindex. You can use Site Audit for this.
• Redirect pages. You want to make sure old pages are redirected with a 301 redirect to the new versions of your pages. It’s a good idea to redirect things like images and PDFs as well, but don’t worry about things like JS, CSS, or Font files. Focus on redirecting things that get indexed by search engines and don’t worry about other file types.

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.

With Ahrefs

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:

• Canonicals
• Hreflang. This will break for a while if you change domains since it will take some time for pages to be re-crawled and connections made.
• Schema
• Meta robots

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:

1. Enter your domain into Site Explorer
2. Go to the Best by Links report
3. Add a “404 not found” filter
4. Sort by referring domains

This will show you pages with links to them that we see as 404 with our crawler. You might want to redirect these.

With GSC

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.

Misc

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.

Continue monitoring

Some problems may show up long after migration is over.

• Monitor the old domain to make sure it gets renewed, and do the same for any others you redirected to the site. If the domains expire, any signals passed through redirects from the older sites may be lost.
• If you didn’t get rid of your old hosting and still keep redirects there, be aware that they’ll break if it shuts down—and you’ll lose some links. You can solve this by redirecting via DNS and storing the redirects on your new site.
• Make sure to keep security certificates renewed or switch to a multi-domain certificate, as we talked about earlier.

Final thoughts

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.