Website migrations are known to be the bane of SEO’s life when done wrong - we’re here to find out how to get them right.

However, first things first: there are multiple types of website migrations, so we need to familiarise ourselves with these to then understand what we need to do to avoid a catastrophic loss of traffic and what can cause losses in the first place.

Download our free Domain Migration Checklist to help you keep track

Know the beast: the different types of website migration you may have to deal with

People tend to think differently about what classes as a website migration - some require a little work, others become a behemoth project, so I’m going to highlight the most common types I’ve seen over the years:

Domain name changes: perhaps you’re rebranding or perhaps you finally purchased that perfect domain when it became available - either way, your URLs are all going to change.
Changing CMS: been stuck with a clunky CMS slowing your site down for years and now finally getting that snazzy new one? Or perhaps your business has grown and your old one doesn’t have all the functionalities you need, such as eCommerce options. This is also a website migration and requires planning as things are most definitely going to change.
Merging websites: this is quite a common one. In the old days when people were told that having 8 (maybe an exaggeration) websites to dominate the SERPs was a great idea (hint: it was not), they’re now having to merge all of these various versions of their sites into one to avoid looking spammy. Or perhaps you simply had different branches of one business that you now want to merge into one. Or you bought out a new business that you’re now going to amalgamate into yours. Whatever the reason, this requires migrating multiple websites into your main one (or a whole new one).
URL amends: maybe you want to shorten your URLs as over time they’ve gotten more and more complex with subcategories, tags, dates etc. being added - this is a migration as you’ll be moving these to new URLs.
Merging content: perhaps you’ve done a content and cannibalisation audit and seen that over the years you’ve accidentally written a tonne of pages on more or less the same subject and have been penalised for thin and duplicate content as a result. So now you’re pruning! Removing, redirecting and rewriting pages also counts as a migration as a lot of the things you’ll be doing to retain traffic are the same.
SSL certificates: you somehow missed the boat and need to finally migrate from HTTP to HTTPS.
Redesigns: you and the brand/UX team took a look at the site (good going, working together is the dream!) and decided that for everyone’s benefit it’s going to be a good idea to redesign the site. This also counts as a web migration as there’s no doubt that some content/categories/menus/pages are going to be moving about and URLs might be changing.
You’re changing the website architecture: turns out, the menu and categorisation of your products or services simply does not work the way it is currently and it needs a refresh. This is 100% going to lead to changing URLs and page structures so it’s going to require planning as a web migration - but just for some pages.

There are of course other types (or even different permutations of the above such as a brand (therefore domain) and design refresh merged with multiple websites being amalgamated), but these are the most common types of migration I have come across. And besides, reading long lists is pretty dull.

Why are web migrations risky?

Essentially, think about it from this standpoint: in SEO, URLs are sacred. If your pages are indexed and (hopefully) already ranking, they get traffic, they have decent links pointing to them and people have shared them on socials etc.

So why on earth would you go and mess that up?

In some instances you won’t necessarily. A good content prune just means that your best performing page will presumably perform even better as that’s the one you’re moving all the others to to become some sort of powerhouse page.

In the case of a CMS migration, you have to do it for functionality, plain and simple. But my advice, always, is to try and keep the URL as it is, if that is even remotely possible.

Otherwise, you’re going to have to wait for the old one to be removed from the search engines’ index, the new one crawled, picked up, rendered, indexed in the first instance, then the rest in second phase indexing etc. and then you’ll finally see where that new page ranks. Essentially you’ve got a lot to lose.

However, I do understand that sometimes there’s just no two ways about it, they have to change. And that’s also fine, there are plenty of ways to mitigate the worst side effects of a migration (and even avoid any negative effects whatsoever in some lucky - and thoroughly planned - instances).

But this does call for a lot of research, some intense planning and developers, content teams and directors who are willing to work with you on this. And this won’t always stop your pages from dropping down the rankings. Migrations can sometimes take up to 6 months to level out in terms of SERPs performance - but as long as you know that, you can mitigate the effects to your business via other channels and plan for the worst.

If you’re just in a rush and need to get things done and out the door immediately, well I’m afraid to say that you’re going to lose a lot of traffic and it’ll take a tonne of backtracking and extra work to recover it. So you may as well do it beforehand to avoid shooting yourself in the foot.

If waiting is not an option, that’s fine, but just be aware of the losses you’re about to make and plan for this by mitigating the effects any way that you can (having SEO resources, using PPC as a backup etc.).

After all, a lot of top SEOs say that their top migration advice is: don’t do it. And these aren’t lazy people, they’re experts who love a technical challenge.But a terribly planned and executed migration makes it an absolute nightmare to ascertain what was lost, why and how to recover it.Again, if for whatever reason there’s an absolute necessity to just get it done and out the door, that’s fine as long as you’re aware of the consequences.

Key web migration planning phases for SEO

Bear in mind that this list is to prepare for a full website migration (to another platform, a new domain etc.) rather than the steps you’d take for a content prune. But some of these will still be useful, just stick to the ones that apply in your specific scenario.

Goal setting & plan overview

Goals

Firstly, discuss with stakeholders, developers and marketing teams what the ultimate aims of the website migration are. Gain traffic? Brand refresh? Company merger? Each one will be important, but in some instances (like trying to improve rankings and increase traffic) you will have the ultimate say in what happens in this migration - that’s important to know). Regardless, make sure to let the team know that you’ll be involved at every point of this project out of necessity.

It’s also important to question: is this migration absolutely necessary? If it’s a case of just using up some leftover budget, or the fanciful whim of a new marketing manager - make sure that you expose the risks: loss of rankings means loss of traffic, which means loss of sales. It may seem as though I'm being melodramatic for effect, but this is definitely a reality, and a very costly, long process to try and fix.

Scope

What is changing and who within the business may be affected? If it’s a whole site overhaul, suddenly everyone in marketing (SEO, social, paid, content, developers, designers, product managers etc.) will need to be involved. The bigger the project, the more parties will need to have a say in order for the new site to work for all involved. If you’re just changing some content around, that wouldn’t be necessary, just let the relevant teams know of any changes and ask if they require any input.

Timings

You absolutely need to know timings - what are the multiple phases of this migration and how long will it take overall? This gives you both your whole timeline and lets you insert yourself into the rest of the process (if the site is being redesigned, you want to be at the meeting where the new design is being shown for feedback etc. This allows you to be able to keep all of the important elements of the site that you know you need - again, keeping your power in this whole process).

This also allows you to plan the launch based on best timings: launching on a Friday is a terrible idea (any fixes would need to wait for the weekend to be addressed), launching prior to a huge sale or event is also risky, and if you have a development team, they may well work in sprints so it needs to tie in with their other projects.

Teamwork

Now you know what’s going to be done to the site, who is involved and when it’s happening. Create a timeline for the entire team: all parties who need/want to be involved so that they can pick and choose when to get involved.

For example, an SEO will want to be involved to see how the design impacts UX, and require more copy. This means the copy team now know how much they’ll be required to write and can plan accordingly. Or a developer may want to be involved when the new designs are being presented to have a say in how much resource and time certain functionalities would take - which can either give the green light or make the case for a second design option.

Although you won’t please everyone all the time, you want to minimise the negative impact on various teams and ensure the work can continue smoothly.

Tasks & Delegation

Prior to everyone going away and doing their thing, ask everyone to make an initial list of all of the tasks and checks that they are likely to want to complete at every stage of the launch.

This means that you can then add blockers. If X not complete, Y cannot proceed etc.

It means that all parties are definitely included and their work is taken into account to properly plan and implement this launch with absolute military precision.

Phase 1: pre-launch plan for SEO

Defining new site requirements

First of all, define the technical SEO requirements for the new site for the developers’ reference - among other things you’ll need:

Same Google Analytics code on the new site
URL structure (make sure blog posts include /blog/ for ease of tracking and ensure that the least amount of URLs change as possible if within the parameters of possibility. Either way, make sure each subfolder on the site doesn’t add loads of URL parameters)
Meta information (titles, descriptions, alt tags etc. need to be on the pages and easily editable)
Body content and headings
Hreflang if applicable need to be implemented
Dynamically generated and correctly formatted XML Sitemaps and robots.txt
Structured data (eg. Schema.org) needs to be on the new site (article, breadcrumb, product, organisation, localBusiness etc. - whatever is applicable)
Load time needs to be good as a priority - or at the very least, better than the current one
Self referencing canonicals for URLs and the ability to change these
Minified, bundled and compressed HTML/CSS
Important on-page elements to be injected via HTML rather than Javascript if possible
Important links and business info in footer
Non intrusive pop-ups

And many, many more - make sure to read the basic best practices for on-page and technical SEO to ensure your developers include everything that needs to be included on this site. I’m not talking bells and whistles like AMP functionality on a site that doesn’t need it, just the absolute fundamentals that will have an impact on SEO performance.

After all, if the old site didn’t have it, chuck it in there. You’re building a new website so it may as well be much better!

You’re also going to need to look at and evaluate the designs - you should have final say on certain elements of the page such as having text content on category or product pages, headings and the order in which they appear, images sizes for SEO etc.

So these are the minimum design and development requirements that you want to define for the new site. This way everyone is aware of what they need to add into their own work (meaning that they can also plan their resources and minimise the amount of back and forth that is likely to happen in the future if they’re not implemented).

Now you need to look at what was important and doing well on the old site.

Take stock of what worked on the old site

Do a full inventory of all the content you had on the old site: import pages from the CMS (HTML pages, and PDFs, documents, images etc.).

Look at as many data sources as you possibly can to extract all the URLs from the old site:

Crawls: Screaming Frog, DeepCrawl, OnCrawl - whatever is available to you
Crawl from tools: Sistrix, Ahrefs, SEMrush etc.
Crawls from your data: GA, GSC, log files etc.

=> this includes old URLs that were redirected as you’re going to need to update that redirect to whatever the new URL is.

Essentially at this point the redirect from page A to page B will become two redirects: page A to page C and page B to page C.

This is important to avoid any redirect chains and loops, as well as page speed being slowed down by redirects. More than anything, a URL’s value is transferred by a redirect - but only about 90% of it - so the more redirects in a chain, the less value assigned to the final page. Add to that the fact that Google stops crawling pages after 6 redirects - don’t risk it.

All of this is so that you have an absolute list of all the URLs on the old site. You’ll also have prioritised lists based on amounts of traffic, number of backlinks, number of bot hits in log files and pages that tools deem to be of a priority.

You then prioritise these lists: the most valuable pages that got a lot of traffic, led to goals or sales, the pages with the most or best links pointing to them, pages that ranked number 1, prompted a featured snippet or that many people shared via socials etc.

Now you’ll have two lists: a list of all your URLs, and a list of all the important pages (make sure to make room for these on the new website - will they exist, be moved, consolidated or do you need to remove them?). All of this will help you stave off any loss of traffic and will also inform your 301 redirect plan.

Website architecture

You need to make sure that the key pages are kept and prioritised when redesigning or rethinking the new website’s architecture. For instance, if a key page features in a top level navigation, I'd avoid removing it from the architecture on the new site, as you’re effectively telling search engines that this page is no longer of as much priority as it used to be.

Also look for new pae or architecture possibilities! If you’re doing a website design and content overhaul, this is a massive opportunity!

Redirect plan

Page URLs are likely to change so ensure that you include every URL from all those datasources in here, including old redirects. Create a table with multiple columns:

Column A - URL from old site
Column B - URL on new site (if they’re the same - no need to create a redirect). Another great reason to avoid changing loads of URLS is if your site is massive, this is going to take a very long time to do manually or you’ll have to pay for some very expensive matching software.

If there’s no exact page on the new site to redirect to, just make sure to redirect it to the most appropriate equivalent (try to avoid catch all rules that would simply redirect to the new website’s homepage, they’re not that helpful).

Also ensure that your redirects point to the correct version of the page, the one that the page’s canonical tag is set to (so say the version with trailing slash - it’s very untidy to have sitemap/canonicals/redirect versions all being different).

Quick note on domain redirects: it's a common mistake to incorrectly configure domain redirects during a website migration, resulting in multiple redirects.

For example:
http://www.oldexample.com redirects to https://www.oldexample.com which then redirects to https://www.newexample.com - make sure that every possible version of the site redirects directly to the final version.

Again, redirects only transfer about 90% of the link equity from old URLs and search engines stop reading them after 6 redirects - don’t waste them on easily avoidable domain redirect chains.

For some websites, this redirection plan could be an enormous undertaking as you’ll have thousands of pages to redirect: speak with your developers to see if there is anything that they can do to help, chances are, they will.

As well as redirects, remember to change your links to the site wherever else they appear (social accounts, emails, Google ads, social ads etc.).

Phase 2: pre-launch checks & testing

The new website should be built on a testing/staging platform (blocked to crawlers), allowing you to do all of the necessary checks prior to launch.

With all the prior tasks completed, you’re going to be checking for:

Key pages presence on staging site and navigational priority given to them
Technical checks (make sure all the requirements mentioned previously are in fact present on the new site), check page speeds etc.
Design checks: check all key content is present
On-page SEO checks (make sure all of the old site’s meta data has been carried over)
Check redirects are working (crawl the staging site to check)
Ensure all internal links work
Make a list of changes to pages, on-page SEO or removed pages (so that you can address any potential ranking or traffic changes by testing re-adding old features or content)
GSC: keep the old sitemap in there and also add the new one in. Some people even go so far as to recommend keeping all of the old website URLs in the sitemap for a period of 1 month while the search engines index your new ones. I’ve never done this myself but it could be worth testing out.
Check schema markup is present and working
Check for any broken pages
Check canonical tags are correct (and also in line with the redirects you created)
Test the staging site on mobile: how is the useability, design etc.

Phase 4: Migration

The day has finally come! Let the developers move the site, change DNS settings if necessary and wait for it to be live!

Phase 5: Post-migration review

Once the migration has gone through, make your shiny new site accessible to both people and bots (remove robots or noindex directives, http authentication etc.).

I’d go through the pre-launch checklist on the live site just to make sure that everything is in fact still there and intact on the new live site, just to be safe. As a side note, page speeds on the live site will likely be different than on the staging environment, so it’s important to check this and have discussions with your developers about any potential areas for improvement.

Add the new site and sitemap.xml to Google Search Console (and in the case of a new domain, make sure to use the ‘Change of address’ tool to point Google to the new domain) and Bing Webmaster Tools, make sure to update URLs in all your social profiles.

For your most important pages, make sure to use the fetch and render tool in Google Search Console to see how Google may be seeing your pages and if there are any problems that you can deal with immediately.

Make sure to update your robots.txt to ensure that you’re not blocking top priority pages or resources and that you’re not using the same directives as the old one.

Check that Google Analytics is measuring traffic to the site, that goals (and eCommerce insights if applicable) are working well and integrated with the site (make sure that it’s possible for your CRM to process a sale and that it also shows up in GA for example). Make a note on there too to mark the launch of the new site so that you have a very obvious benchmark for performance.

Phase 6: Post-launch monitoring

Over the coming weeks and months, make sure that you are regularly checking Google Analytics data for key areas of the site: has traffic dipped, stayed the same or increased?

If you see a dip, check Google Search Console to see how your pages are faring in there, how many pages of your sitemap.xml have been indexed, if any of them present any issues such as unparsable structured data etc.

Also check your ranking software: have rankings changed at all? If they’ve dipped, or if pages that used to rank as a featured snippet no longer are, check these pages to see if there is anything that you can do on these to change that. Always make sure to check against the old versions of the pages in case there’s something that you forgot to carry across to the new site.

Make sure to regularly monitor and audit the new site: you can run audits in paid tools such as Ahrefs site auditor or SEMrush’s version to check for any potential technical issues standing in your way, as well as keeping an eye on Search Console data. Log file analysis can prove useful as you’ll be able to see how bots are interacting with the new site and if your crawl budget is being wasted anywhere.

And finally, use Ahrefs or SEMrush to check up on any potential lost backlinks: if they have been, either get in touch with the publishers to get them to renew the backlink to your site or set up 301 redirects to get some of the link equity back.

To conclude

Website migrations can be pretty complex beasts to handle, and almost alway lead to an immediate slight dip in traffic, but this should help you to avoid any big losses in traffic. I hope it’s been helpful!