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:
- Domain: changing domain, merging into another site, splitting a site
- Protocol: HTTP > HTTPS
- Path: subdomain/subfolder, changing site architecture
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.
