Few things can destroy a brand’s performance in the search results faster than a poorly implemented site migration.
Changing your domain name or implementing HTTPS can be a great business move, but if you fail to consider how search engines will react to this move, you are almost certain to take a major hit in organic search traffic.
Use the following SEO checklist to prepare yourself as you develop a migration game plan for your website.
1. Carefully consider if migration is the right choice
A site migration will almost always result in a temporary loss of traffic — Google needs time to process the change and update its index accordingly. A carefully executed site migration can minimize traffic fluctuations, and in a best-case scenario, Google will ultimately treat the new site as if it were the original.
Still, that is only the best-case scenario. The reality is that site migrations, in and of themselves, typically offer little to no SEO benefit and do not eliminate search engine penalties. (That is why SEOs often use site migrations as an opportunity to make SEO improvements, like streamlining the site structure, fixing broken links, consolidating redundant pages and making content improvements.)
With all of that in mind, when is a site migration worth it?
- When a strong rebranding is in order.
- When migration will generate press and links.
- When the site needs to be moved to HTTPS (one of the few cases in which migration alone offers an SEO gain).
2. Use a sandbox
Never do a site migration without first testing everything on a test server. Verify that the redirects work properly, and do all of the checks that follow in private before going public. Trying to do it all in one go without testing is bound to lead to errors, and if the mistakes are bad enough, they can set your site back by weeks.
3. Plan to migrate during a slow period
A well-planned and monitored migration shouldn’t permanently affect your traffic, but you should plan for a temporary dip. For that reason, it’s best to perform the migration during a slow part of the year, assuming that there is some seasonality to your site’s performance. A site migration during or shortly before the holidays is always a bad idea. While the goal should always be to avoid losing any traffic, it’s important to make sure that if you do lose traffic, you lose it when business is already slow.
4. Crawl your site before the migration
Crawl your site with a tool like Screaming Frog, and be sure to save the crawl for later.
You need to make sure you have a complete list of the URLs on your old site so that nothing ends up getting lost because of the transition.
Use this as an opportunity to identify any crawl errors and redirects that exist on the old site. These have a tendency to creep up over time. I rarely come across a site that doesn’t have at least some broken or redirected links.
You should absolutely remove or replace any links that point to 404 pages during the migration process. In addition, I highly recommend updating any links that point to redirected pages so that they point to the final page. You do not want to end up with redirect chains after the migration.
Remember that a site crawl may not be able to identify every single page on your site. For example, if you have pages that aren’t linked from other pages on your site, they won’t show up in a crawl. You can use your own records and databases to find these pages, of course, but if this isn’t possible, you can find these pages in your Google Analytics data, as well as through a link explorer like Ahrefs.
If you find any orphan pages, make sure to update the site, and link to these during the migration. These pages are much less likely to pick up search engine traffic if they aren’t linked to from the rest of your site.
5. Benchmark your analytics
Make a copy of your Google Analytics data; you will need this information so that you can quickly identify if any traffic is lost after the migration.
If any traffic is lost, export the Analytics data from your new site and run a side-by-side comparison with the data from your old site, so that you can identify precisely which pages lost the traffic. In many cases, a loss of traffic will be isolated to individual pages, rather than taking place across the entire site.
You may also want to identify and take note of your top linked-to pages using a tool like Ahrefs. After the migration, you will want to pay special attention to these pages and monitor them closely. If these lose traffic, it is a sign that the authority isn’t being properly transferred from your old site to the new one. These pages contribute the most to your authority, so losses here may affect the overall performance of your site.
6. Map all changed URLs from old to new
You should have a spreadsheet that lists every old URL and every new URL.
Ideally, during a site migration, all of the old pages exist on the new site. Obviously, removing a page removes its ability to capture search engine traffic. On top of that, dropping too many pages during the migration may lead Google to conclude that the new site isn’t the same as the old site, causing you to lose your rankings.
Also, ideally, the URL architecture should be identical to the old one unless you have very strong reasons to change it. If you do plan on changing it, a site migration may seem like the ideal time to do it, but you should be aware that doing so may cause Google to see it as an entirely different site. If you do both at the same time, you will not be able to determine whether any losses in traffic were the result of changing the architecture or of migrating the site.
Another reason to keep the architecture the same is that it allows you to use regex in your .htaccess file to easily redirect from your old pages to the new ones. This puts less load on your server than naming the redirects one by one, and it makes the process of setting up the redirects much less painful.
7. Update all internal links
The HTML links on your new site should point to the new site, not the old one.
This might sound obvious, but as you go through the process, you will quickly realize how tempting it might be to leave the links unchanged, since they will redirect to the new URL anyway. Do not succumb to this temptation. Apart from the server load, which slows down site performance, the redirects may dampen your PageRank.
The ideal way to rewrite the links is by performing a search and replace operation on your database. The operation should be performed so that it updates the domain name without changing the folder structure (assuming you’re keeping your site structure the same).
Write your search and replace operations carefully so that only text containing a URL is updated. You generally want to avoid updating your brand name and your URLs with the same search and replace operation.
8. Self-canonicalize all new pages
Verify that canonicalization on the new site references the new site and not the old. Canonicalizing to the old site can be disastrous, as it may prevent the new site from being indexed.
I recommend self-canonicalizing all of your pages on the new site (except, of course, for pages that should canonicalize to another page). In combination with the redirects, this tells Google that the new site is, in fact, the new location of the old site. Sitewide self-canonicalization is recommended anyway, since URL parameters create duplicate content that should always canonicalize to the parameter-free URL.
9. Resolve duplicate content issues
Various missteps during the migration process can result in duplicate content issues. Be aware of these issues, and take steps to avoid them:
- If both multiple versions of a URL are published, it results in duplicate content. If self-canonicalization is put in place properly, this should take care of the issue, but I always recommend setting up redirect rules in .htaccess so that only one version of the page is accessible. Make sure that links are consistent to avoid redirects from internal links.
- IP addresses should redirect to URLs.
- Look out for folders that lead to the same content, especially “default” folders.
- Verify that only HTTPS or HTTP is used and that only the www or non-www version of the site is accessible. The others should redirect to the proper site.
- If your site has a search function, the search result pages should be noindexed.
- I mentioned this earlier, but self-canonicalization should be in place to avoid duplicate content created by URL query strings.
10. Identify and address any removed pages
I mentioned above that you should generally avoid removing any pages during the migration. If some pages simply must be removed for branding purposes, take the following steps:
- Make a list of all the pages.
- Do not redirect the old pages to the new site.
- Remove all links from these pages.
- Remove the pages from the old site and allow them to redirect to 404.
- If there is a suitable replacement for the page, set up a redirect and change all of the links to point to the new page. You should only do this if the replacement page serves the same purpose as the old page.
- Do not redirect the removed pages to the home page (also called a “soft 404”). If there is no suitable replacement for a page, it should 404. A 404 is only an error if you link to the page.
11. Ensure that a custom 404 page is in place
A custom 404 page allows users to easily navigate your site and find something useful if they land on a page that no longer exists.
12. Manage and submit sitemaps
Keep your old sitemap in the Google Search Console, and add the sitemap for the new site as well. Requesting Google to crawl the old sitemap and discover the redirects is a good way to accelerate the process.
13. Keep analytics in place at all times
Install Google Analytics on the new domain and get it up and running well before you launch the site to the public. You do not want to have any missing data during the transition, and it’s important to watch for any changes in traffic during the migration.
14. Redirect all changed links
As mentioned above, the ideal way to set up your redirects is with a regex expression in the .htaccess file of your old site. The regex expression should simply swap out your domain name, or swap out HTTP for HTTPS if you are doing an SSL migration.
For any pages where this isn’t possible, you will need to set up an individual redirect. Make sure this doesn’t create any conflicts with your regex and that it doesn’t produce any redirect chains.
Test your redirects on a test server and verify that this doesn’t produce any 404 errors. I recommend doing this before the redirects go live on your public site.
Keep in mind that once the redirects go live, your site has effectively been migrated. The new site should be in pristine condition before setting up the redirects.
15. Keep control of the old domain
Unless the purpose of the migration was to sell the original domain, I would strongly advise against giving up control of the old domain. Ideally, the old domain should redirect to the new one, on a page-by-page basis, indefinitely. If those redirects are lost, all of the inbound links earned by the old site will also be lost.
Some industry professionals claim that you can give up control of the old domain once Google stops indexing it, but I would never advise doing this. While it’s possible that Google will attribute links pointed at the old site to the new one, even without the redirect, this is placing far more faith in the search engine then I would ever recommend.
16. Monitor traffic, performance and rankings
Keep a close eye on your search and referral traffic, checking it daily for at least a week after the migration. If there are any shifts in traffic, dive down to the page level and compare traffic on the old site to traffic on the new site to identify which pages have lost traffic. Those pages, in particular, should be inspected for crawl errors and linking issues. You may want to pursue getting any external links pointing at the old version of the page changed to the new one, if possible.
It is equally important to keep a close eye on your most linked pages, both by authority and by external link count. These pages play the biggest role in your site’s overall ability to rank, so changes in performance here are indicative of your site’s overall performance.
Use a tool like SEMrush to monitor your rankings for your target keywords. In some cases, this will tell you if something is up before a change in traffic is noticeable. This will also help you identify how quickly Google is indexing the new site and whether it is dropping the old site from the index.
17. Mark dates in Google Analytics
Use Google Analytics annotations to mark critical dates during the migration. This will help you to identify the cause of any issues you may come across during the process.
18. Ensure Google Search Console is properly set up
You will need to set up a new property in Google Search Console for the new domain. Verify that it is set up for the proper version, accounting for HTTP vs. HTTPS and www vs. non-www. Submit both the old and new sitemaps to solidify the message that the old site has been redirected to the new one.
Submit a change of address in the Google Search Console, request Google to crawl the new sitemap, and use “fetch as Google” to submit your new site to be indexed. It is incredibly important to verify that all of your redirects, canonicalizations and links are error-free before doing this.
19. Properly manage PPC
Update your PPC campaigns so that they point to the correct site. If your PPC campaigns are pointing to the old site, attribution will be lost in Analytics because of the redirect.
20. Update all other platforms
Update all of your social media profiles, bios you use as a guest publisher, other websites you own, forum signatures you use, and any other platforms you take advantage of, so that the links point to the new site and not the old.
21. Reach out for your most prominent links
Contact the most authoritative sites that link to you in order to let them know about the migration, and suggest that they update the link to point to the new website. Not all of them will do this, but those that do will help accelerate the process of Google recognizing that a site migration has occurred.
I wouldn’t recommend doing this with every single link, since this would be extremely time-consuming for most sites, but it is worth doing this for your top links.
22. Monitor your indexed page count
Google will not index all of the pages on your new site immediately, but if the indexed page count is not up to the same value as the old site after a month has passed, something has definitely gone wrong.
23. Check for 404s and redirects
Crawl the new site to verify that there are no 404s or 301s (or any other 3xx, 4xx, or 5xx codes). All of the links on the new site should point directly to a functioning page. The 404 and 501 errors are the biggest offenders and should be taken care of first. If there is a suitable replacement for a 404 page, change the link itself to point to the replacement, and verify that a 301 is in place for anybody who arrives at the missing page through other means.
The second-worst offenders are links to 301 pages that exist on the old site. Even though these redirect to the new site, the server load is bad for performance, and linking back to the old site may lead to confusion over the fact that a site migration has taken place. While all of the other efforts taken should clarify this to Google and the other search engines, these things are best never left to chance.
Any other 301s can be taken care of after this. Always update your internal links to point directly to the correct page, never through a redirect.
24. Crawl your old URLs
Use Screaming Frog or a similar tool to crawl all of your old URLs. Be sure to crawl a list of URLs that you collected before the migration, and make sure the list includes any URLs that were not discoverable by crawling. Do not attempt to crawl the site directly; the 301s will cause it to crawl only the first page.
Verify that all of the old URLs redirect to the new site. There should not be any 404s unless you removed the page during the migration process. If there are any 404s, verify that there are no links to them. If the 404s are not intended, set up a proper redirect.
Check the external URLs to verify that all of the redirects are functional. None of the external URLs should be 301s or 404s. A 301 in the external URLs is indicative of a redirect chain and is bad for performance. A redirect to a 404 will lead to a very frustrating experience for your users and may hurt your SEO in other ways.
Conclusion
If a site migration is carried out without taking SEO into account, you can almost bet on losing search engine traffic in the process. Other than clients who have approached me after being penalized by Google, the worst SEO predicaments I’ve come across were the ones caused during a site migration by professionals who didn’t consider how search engines would react to the process. Keep all of the above in mind if you are planning to migrate your site, and it should go off without a hitch.
Contributing authors are invited to create content for Search Engine Land and are chosen for their expertise and contribution to the search community. Our contributors work under the oversight of the editorial staff and contributions are checked for quality and relevance to our readers. The opinions they express are their own.
