SEO Migration Checklist – How To Not Lose traffic

We’ve covered how to migrate and get the best SEO results, and we’ve also covered factors which are overlooked during migrations, but this blog aims to be a go-to resource for anyone going through a website migration.

This is a complex task and there are far more moving parts than what can be covered here, but with this list in hand you should be in a great position to make the most of your website migration and to ensure that any traffic losses are kept to a minimum.

There are several stages of migrations, and SEO should be a consideration throughout. It’s often the case that SEO considerations will only be made from stage 2 onwards, but you should endeavour to be involved as soon as possible.

Stage One: Initial Considerations

via GIPHY

At this stage the ideas of migrating will be up in the air, and you might not get any further. It’s important to be involved from day one though, as SEO-wise it might be more beneficial to rebrand, simply change domains or redesign existing assets.

• Stakeholder Discussions – Involving everyone from the start is the best strategy to raise concerns and find potential issues.
• Benchmarking – Through Google Analytics and Google Search Console (and any other tracking), make sure you know how the existing site performs in terms of traffic as well as page speed.
• Identify The Needs – Make sure that you are migrating for a reason. As mentioned above, a full migration may not be needed.
• Discuss KPIs – How will these fit into or change the plan around migration?
• Set Timelines – These will change, but getting a rough outline for design and development will help plan the SEO tasks.

Stage Two: Preparing On Staging

via GIPHY

This is the meatiest task for SEO, as it will be the basis of optimisations on the pages across your site, helping the pages get indexed, ranked and maintain existing traffic.

• Site Structure – Make sure you discuss the extra or removed areas on the site so that you can make allowances for redirects, changes in traffic, etc.
• SEO & Design Considerations – We often see designs happening in their own silo, but it’s important to get SEO considerations in early. Form over function may sway those making decisions, but they can drastically change the performance of a site. Unless you are a household name, you will need this organic performance rather than a flashy and uncrawlable site.
• Sitemaps – These need to be created and updated regularly. Ideally they will be dynamic and follow your site structure. Most CMSs allow this and are built in, but custom projects need to add these in.
• Robots.txt – This will need to be in place to block your staging site and make sure that only the right pages are crawled. You can remove query strings from being crawled, but make sure this doesn’t affect other pages you want to rank. On staging sites it is best to use Screaming Frogs custom robots.txt facility to see how it will act once live.
• Redirects – If you are migrating there will at least be redirects from your current to next iteration. More likely there will be previous ones too, so make sure you obtain these an plan redirects so they don’t clash or use needless steps. Rather than URL 1 to 2 to 3, you can just go 1 to 3 in most cases.
• URLs – Similar to the site structure, you need to make sure the different sections follow logical paths and are both user friendly and informative.
• On Page Optimisations – For most pages which have new equivalents, these can be copied over. This is preferable as you can see like for like, rather than adding more variables into your website migration If you are combining or splitting pages, these will need more work on titles and headers.
• Structured Data – The basics of this can be copied, but you will need to update things depending on page rewrites and merges. FAQs may be rewritten and you can work new structured data into development plans to allow automated changes in the future.
• NoIndex – On staging sites NoIndex can be awkward as it may be set across the site, but you can use other blocking of crawlers.
• Canonicals – These can be done easily on staging by looking over the end part of the URL after your top level domain (TLD).
• Internal Linking – If you are keeping a similar structure and content the internal linking should be updated to avoid needless redirects. If you are rewriting content then it can be a good time to upgrade your internal linking and make sure your best pages are easily accessible.
• Tracking – At this stage you will be limited to sample data from testing, but you can make sure that events and goals are tracking correctly, ready to be switched over.
• Security – This is straightforward from an SEO strandpoint, as you just need to ensure that the site will resolve to the HTTPS version.
• 404 Pages – As well as styling and making sure a 404 page is working, you need to make sure that there is a plan in place to deal with error pages when they occur. If you are running an online store, are you redirecting old products or keeping pages live and displaying out of stock?
• Image Optimisations – Make sure that assets which are made for the new site are run through compression software to help with page loading times.

Stage Three: Pre-Launch

Making sure your hard work is actually working and visible on staging and ready to move over to live. This means audits and thorough checking of previous work.

• On Page Optimisations – double check that all your rules and custom optimisations are in place and visible.
• Accessibility – run your different templates through checkers, such as the built in Chrome version or different plugins.
• Structured Data – Check against the schema.org validator as well as Google’s. They should be the same but it’s worth checking if there are any discrepancies.
• XML Sitemaps – At this stage you can compare you XML sitemaps against what should be indexable from previous crawls, no index and canonical work.
• Hreflang – Not an issue for everyone, but you can double check that best practice is followed to give the best chance of being displayed properly across the globe.
• Page Speeds – Although staging environments differ from live, you can set a benchmark at this point regarding page speeds. Compare any issues against existing site benchmarks and you should still have time to work on the speeds if needed at this stage.
• Redirects – You can simply crawl you old URL versions on staging to check for errors and any unneeded steps.
• Analytics & Tracking – Review your tracking code and make sure that the switch over will be good by letting developers know of any code changes, such as a staging to live tracking ID change.

Stage Four: Launch Day

via GIPHY

This stage shouldn’t involve any changes – providing everything works! It’s basically checking the staging site transferred over correctly. This sounds simple, but the realities are much more complex.

• Staging Site Crawl Comparison – Aside from staging URL differences, the crawls from staging to live should match. If you use Screaming Frog you can easily compare the two.
• Robots.txt – Make sure you remove any blocking when ready. This is an incredibly simple step which is so often overlooked!
• NoIndex Tags – Similar to the above, if you have specific NoIndex tags or other blocking across pages which you want indexed, make sure they are removed.
• Server Responses – Ensure server responses are the same on different devices, both across mobile/desktop and different browsers.
• Canonicals – Update these to the correct URL structure if needed.
• Redirects – Another redirect check, but these are important! Crawl and check the old URLs from previous iterations.
• Sitemap Submission – Once you are happy that the site is working and the server responses are good you can submit the sitemaps through GSC to expedite the crawling process.
• GSC Settings – If you are moving address then you can submit a change of property request. Also claim different variants (https/http and www/non-www) so you can see errors is any arise.

Stage Five: Post Launch

This stage will be ongoing depending on the outcome of the previous stage. The focus is on continuity again but looking more at the pre and post launch live instances.

• GSC Monitoring – This should be daily initially and then slowing down once most pages have been indexed. This is especially important if you are migrating to a new domain. It’s also a good idea to download the daily statistics for future reference.
• GA Monitoring – Check for anomalies in the channels, sources, events, goals, etc. Errors could arise anywhere, but another one to check are the page titles to see where 404s occur which might not be reported in GSC.
• Log File Analysis – The important part here are the hits from search engines. Look into any non-200 status codes as well as which pages are being crawled frequently. You may need to change frequencies and importance in your XML sitemap if your top content isn’t being crawled as frequently as others.

Stage Six: Reviewing

via GIPHY

This final stage can be set at a period after launch to suit – 6 or 12 months down the line to see how performance compares fully, rather than looking at short-term data (which can often be subjective).

• Review KPIs – Compare your most important site metrics for pre and post migration. This can be rolling in terms of hitting goal and event conversions, as well as general traffic levels.
• Review YoY – For more in-depth information, a Year-on-Year comparison would be best. Ideally with a whole years-worth of data so you can see how the site performed just before and after the migration.
• Review Organic & Non-Organic Stats – Don’t just focus on organic performance, particularly if you have ramped up your other marketing. If you move to a more user-friendly domain, you might get more direct traffic, or your social efforts could bring in more users.

Overall, this list should help you get through most situations regarding migrations. Obviously there are individual differences across sites which might not be listed here, but it should give you a good starting point. For further details, check out our SEO and SEO migration pages.