Tried And True: Our Website Migration Checklist
Migrating website content is quite possibly the most challenging thing someone in charge of SEO can do. It requires good planning, clear communication, and the right people. If you don’t have all of those things working together, you’re going to feel like you’re a cat herder, not a SEO consultant.
I have overseen the migration of at least eight websites in the past 12 months with varying degrees of success. I found that the following list, when implemented properly, gave each domain the best chance at surviving its transformation.
Pre-Migration Checklist
- Archive all old URLs
- Export top linked-to pages from Moz (top 500)
- Export top linked-to pages from Google Search Console (top 500)
- Reporting: Set up custom all traffic report in GA
- Reporting: Set up custom organic traffic report in GA
- Reporting: Set up custom referral traffic report in GA
- Reporting: Set up custom 404 page traffic in GA
- Create a sitemap of all old URLs
- Create a sitemap of all new URLs
- Prepare new robots.txt file
- Check that tracking has been added to every page
Launch Checklist
- Launch new robots.txt file
- Check redirects are working properly
- Check proper self-referring canonicals
- Check home page and sitemaps are okay with Google Search Console Fetch and Render
- Crawl list of OLD URLs
- Handle any pages that are not properly redirecting (302 or 404)
- Submit Old XML sitemap
- Submit New XML sitemap
- Resubmit the site to Google index
Post-Launch
- Monitor 404s and fix crawl errors
- Monitor index status
- Monitor organic traffic
- Monitor referral traffic
- Re-link Google Search Console in Google Analytics if domain name changed
“Oh Sh*t!” List
- Check for sitemap errors & fix them
- Recrawl all old and new URLs to check that they are working properly. Prioritize these.
- Check traffic channels in analytics to identify where traffic has dropped
- Look at the custom 404 report in GA to identify landing pages that have a high number of 404 errors
- Check top linked-to pages, compare stats to post-launch data
- When errors are fixed, resubmit sitemaps and then resubmit the site to be indexed
Pre-Migration
Proper preparation and planning is key to any project. Website migrations are no exception. My pre-migration checklist covers all of your bases. You will also want to check out one of my earlier blog posts, 3 Keys to Auditing or Migrating Any Website. That post will walk you through a proper interview so that you know what’s changing and where things are moving.
This checklist is all about making sure your ducks are aligned before you flip the switch. The following tasks can and should be done while the development team is finishing up the development of the new website. That will help with a smooth transition into launch.
Collect the Pre-Launch Data
To-Do:
- Archive all old URLs
- Export top linked-to pages from Moz (top 500)
- Export top linked-to pages from Google Search Console (top 500)
Data collection is important. If things go sideways you’re going to be really happy you have something to reference from before you flipped the switch. It’s easy to go overboard with what you should archive before you launch, and there are plenty of blog posts about what data you should look at during a migration. My rule of thumb is if you can reference the historical data later, don’t archive it, it’ll only take time away from other things. I focus here on links to the domain and all old URLs because those are the things you’ll need to check to see if things have been implemented properly.
Crawl Stats in Google Search Console is a good example of when to archive data. Google gives you the high, low, and average crawl stats. Archiving the high and low stats are really a waste of time, you’ll be able to use Googles graph to see those later. But that average may change and is something you’re unable to calculate. Note it for later.
Create Custom Reports
To-Do:
- Set up custom all traffic report in GA
- Set up custom organic traffic report in GA
- Set up custom referral traffic report in GA
- Set up custom 404 page traffic in GA
These reports may seem redundant because all of this data is available through GA already. But I find that it’s really helpful to know that you and your team are looking at the same report day in and day out. Custom reports eliminate any doubt that what you’re looking at today is what you were looking at yesterday.
I have created these report templates for you already. Each report has tabs that allow you to see referrals, landing page, device, and time of day. Feel free to customize the reports as you see fit. Make sure you update the 404 page title.
Prepare Essential Website Files
To-Do:
- Create a sitemap of all old URLs
- Create a sitemap of all new URLs
- Prepare new robots.txt file
- Check that tracking has been added to every page
I have found the cornerstone of a successful migration is having both the old and new sitemap in Google Search Console. An old sitemap paired with self-referring canonicals on the new URLs is a one-two punch for showing Google what has changed on your site.
Before you launch make sure you have the old sitemap ready and that it is free of errors. Do the same with the new sitemap. With these two sitemaps in the Google Search Console you’ll be able to request Google crawl your old sitemap, which contains a list of URLs that are all redirecting (with 301’s) to new URLs. Hammering Google with this request allows you to reinforce the changes that have been made. Do not underestimate the power of combining a 301 redirect with a self-referring canonical.
Launch Day
Direct and Test
To-Do:
- Launch new robots.txt file
- Check redirects are working properly
- Check self-referring canonicals
- Handle any pages that are not properly redirecting (302 or 404)
- Check home page and sitemaps are okay with Google Search Console Fetch and Render
Robots.txt
One of the first things you should do when launching the site is ensuring the new robots.txt file is not limiting a search engine’s ability to crawl the website. You’ll want to restrict some directories, like all administration docs, other than that search engine should have free reign over the site. You want them to be able to understand the new structure of the site and how the old content fits into that structure. Restricting access to important directories can hinder that process and possibly hurt your migration.
Redirects
Before launch you should have used the development site to check that redirects were working properly and that self-referring canonicals were correct. Now make sure all of those things made it live.
Take that list of old URLs that you used to create the old sitemap and recrawl all of them using a tool like Screaming Frog. If something is fundamentally wrong, like the site using 302 redirects instead of 301, you’ll be able to spot and fix those quickly. All URLs in the old sitemap, which you will be submitting to Google Search Console, should be returning a 301 redirect response code.
Canonicals
After you’ve checked redirects you need to check that all self-referring canonicals are correct. I’ve made this mistake once and I’ll never make it again. Using a self-referring canonical on the destination page of 301 redirects is a one-two combo for successfully transferring a page. Google will follow the 301 to the new destination, when it gets there the self-referring canonicals acts as a confirmation that the page they have landed on is indeed the new location of the old page. It is of utmost importance that these two are correct and are working together.
Check Your Sitemaps
Once you’ve confirmed that everything looks okay on the new live site, then you can begin the process of informing Google it needs to update its index.
Use Google Search Console to test both the new and the old sitemap for errors. I have found that sometimes sitemap syntax will not throw any errors when checked by a third party website like xml-sitemaps.com, but when you test the sitemap in Google Search Console the sitemap throws an error. This is especially true for specialty sitemaps like Google News sitemaps. Don’t make any assumptions, test before submitting them.
Check Home Page with Fetch and Render
Lastly, test the home page and make sure that Google can properly fetch and render your website. The Fetch and Render tool in Google Search Console makes this easy. Just plug in the URL of your home page and click fetch and render. Fix any problems it may flag before moving on.
Submit For Indexation
After you give your site a clean bill of health, it’s time to let Google do its thing. First remove the old sitemaps left over from the old site. Then submit your two sitemaps for the new site. The first will be the sitemap that contains all old URLs (I like to name it /sitemap-old.xml). Then submit the sitemap that contains a list of new URLs (this one should be located at the standard /sitemap.xml). When you’ve done that successfully go to Fetch as Google and submit your site to be indexed. This will prompt Google to crawl the entire website.
I cannot stress the importance of making sure all redirects, self-referring canonicals, and sitemap are error free before submitting your site, and its sitemaps, to be crawled and indexed. The old sitemap, new sitemap, and resubmission for index work together to show Google how it should be updating its index. If you do not fix errors before submission it will results in an underperforming migration.
Post-Launch
To-Do:
- Monitor 404s and fix crawl errors
- Monitor index status
- Monitor organic traffic
- Monitor referral traffic
- Re-link Google Search Console in Google Analytics if domain name changed
In the days following the transition you will want to monitor site performance with those custom reports you set up before launch. These reports allow you to quickly reference how the site is performing across all channels, especially organic search. Additionally you’ll want to keep an eye on the Index Status report in Google Search Console and check in on the health of your sitemaps. I also like to resubmit sitemaps once a day for several days following the migration, just to be sure Google is crawling those old URLs and updating its index accordingly.
“Oh Sh*t!” List
To-Do:
- Check for sitemap errors & fix them
- Recrawl all old and new URLs to check that they are working properly. Prioritize these.
- Check traffic channels in Google Analytics to identify where traffic has dropped
- Look at the custom 404 report in GA to identify landing pages that have a high number of 404 errors
- Check top linked-to pages, compare stats to post-launch data
- When errors are fixed, resubmit sitemaps and then resubmit the site to be indexed
Sometimes you do everything right and something still goes wrong. Typically I find that these things were out of my control, i.e. a server goes down post launch or a code update breaks part of the site. These things happen and there’s really no way to avoid them. But the preparation you did before site launch can help you pinpoint the issue and resolve it.
When things hit the fan I follow this list to quickly check on all of the most obvious issues. Your Google Analytics should be the first place you check. Using the channels report tab in the Custom All Traffic report will allow you to see what part of your inbound traffic has taken a hit. It may not be organic traffic at all that is causing a lagging post-launch performance, it could be that you didn’t update your URLs in AdWords. The point is, before you freak out and start wasting time checking anything and everything related to SEO, find where it hurts.
As a final note I would like to remind you that launching a website is not like launching a new product. The public is not anticipating the migration or redesign of your website, so do not let that false deadline get between you and a successful migration. Who cares if you launched your site on time if 50% of the traffic you were getting is no longer visiting the site to enjoy it?
Stick to your guns, follow the process, and enjoy the rewards.
