Author: Chris Green
This post was last updated on April 17, 2024.
In my first post on the site migrations, I covered the fundamental elements you need to be aware of to run a successful migration. We looked at:
Whilst it was a relatively comprehensive article, believe it or not, we only covered the basics. Now, it’s onto the advanced techniques to help manage migrations effectively.
Table of contents:
Content auditing
One of the primary reasons migrations go wrong (or outright fail) is because content is lost as part of the process. Sometimes this loss is intended, other times it is by accident or simply not thought of.
I strongly advocate migrating as much content as you can if you want to retain organic performance, but there are clear times when this is not ideal or practical (for example, if you have years of content that is out of date, or no longer relevant). Whatever your situation, there is no valid reason for not taking inventory of your content and auditing it to see what you have and what is working.
So, what pages are working?
To determine the performance of any given page, I like to capture the following data points about each:
Organic traffic (Google Analytics)
Conversions (Google Analytics)
Backlinks (Your tool of choice)
Clicks/impressions (Google Search Console)
For small(er) sites, this can be done at the page level, but for larger sites, you may need to report on the directory/section level.
How to obtain historic content performance data
While you can pull this data manually and use something like VLOOKUP to match up the different metrics, this method can be time consuming and error prone over large data sets. One of my favorite methods is to instead use Screaming Frog to pull all this data in one go. The process is as simple as crawling the website (as you would usually), except before you start, you want to set up Google Analytics, Search Console, and either Ahrefs or Majestic APIs.
As each URL is crawled, it will also pull the traffic/ranking/impression/backlink data, which enables you to download a complete spreadsheet that you can sort and filter by metric. Very handy.
Seer Interactive has a great guide on using APIs in Screaming Frog, and you can find some more tips here. For more on content audits in general (and how you can run them), this blog/video shares some great thoughts.
Wix users can utilize the Top Page in Google Search Results report to see which pages are most important on organic search.
But, what if there is no data?
In too many cases, I have come to audit content only to discover that Google Analytics (or similar) is not present and Google Search Console has not been set up. This means two things: 1) the content audit is made more challenging and 2) the business has no idea what is/isn’t performing.
In this circumstance, I would opt for running an initial benchmark ranking report. By this, I mean:
01. Crawl the site
02. Extract the titles/headings
03. Clean and de-duplicate
04. Run this list of key terms/phrases through a rank-tracking tool
05. Re-check performance after the migration
This is clearly a less-than-ideal method, but it still provides you with a list of the content that’s performing best.
Mapping your site’s keywords and content pre-migration
Mapping your target keywords to your content is a crucial step in the migration process. This is like creating an IA (information architecture) or a sitemap which UX designers and web designers will likely work on. A really important thing to note is that it is not the same as those, however. The differences are crucial, as they can cause some large issues.
This process is similar to creating an IA (information architecture) or a sitemap for UX and web designers.
However, a really important thing to note is that it is not the same as those. Design/UX sitemaps usually map out the structure of the key pages, but they often do not include keywords or URL structure. In the above example, the UX sitemap has entries for “Store” and “Blog” but does not itemize these URLs individually. The differences are crucial, as they can cause some large issues.
In SEO, keyword mapping documentation is an important tool that can be used in the migration and throughout the ongoing website activity including:
Plan redirects
Determine page content hierarchy
Identify content gaps
Reduce keyword cannibalization
Building content clusters
As we’ll be using this mapping to also create the redirects, it really helps if the process is as complete as possible.
Mapping your keywords
Mapping your keywords to content can be time-consuming—it should be. Cutting corners during this process is not advised and the better your planning is, the better the migration will be. Trust me.
To assist with this process, I have detailed the steps and created a template to help you on your way. (Note: You must first make a copy of the template before you can use it.)
I start this process by checking that the most important pages are documented, just to ensure they are present. Return to your content audit and ensure you’re retaining as much of the key content as you can.
Missing content and content gaps
Assigning keywords to relevant pages is an important element of this plan. This accomplishes two things:
Ensures you can retain the keywords you currently rank for
Clearly highlights where any gaps or opportunities are
In my experience, this stage is usually where you need to start managing the expectations of the wider team. In an ideal world, this is where you dictate everything that is best for SEO, but there aren’t many projects where you will get 100% of your recommendations implemented.
You will have to make compromises, but you’ll be able to clearly illustrate—as a result of creating a sitemap—which keywords are missing and the respective traffic that may be lost (based on the content audit). If they don’t want to bring the content across then fine, so long as everyone realizes what is lost as part of this.
301 redirect mapping
Once we have an account of the key content that needs to be present (and which pages are targeting which keywords), it is time to map the 301 redirects. This will tell search engines the new location of the URL after the site has been migrated. I covered how to manage redirects in my previous article, but this will go into more depth.
How to map 301 redirects
01. Run through your keyword mapping document. For each new page you have created, assign the URL (or URLs) of the old pages that should be 301 redirected to it.
02. Export a list of pages from Google Analytics and Google Search Console for the last year. VLOOKUP these against your initial list and note what is missing. There may be a lot of noise here (e.g., URLs with tracking parameters, mixed casing issues, or similar), but for this stage, you’re best off mapping everything.
03. Run through the list and assign the page that will be the best-case match once the site is live. If you find that the page only “kind of” matches or it doesn’t really, then consider letting these pages 404. This is assuming you’ve already matched your most important ones, though!
04. Format a spreadsheet into two columns (OLD and NEW) and sort OLD in ascending order. Check to see you do not have any duplicates.
Bulk Redirects for large websites
If you’re working on thousands of redirects (or hundreds of thousands, for that matter), matching each redirect line-by-line is going to be pretty tough. Here’s some advice for getting started:
Look for IDs or unique values in the URLs paths, if you can ensure that these URLs will stay consistent on the new site, you can match URLs using regex or a tool like the Wix URL Redirect Manager.
If you have content on a staging site that is staying the same as the live site, crawl both sites and then export to Excel with titles, meta descriptions, H1s, or any values that are unique. With both crawls, you can use a VLOOKUP to match one to the other.
In some instances (such as adding redirects via Nginx or .htaccess), you can first set rules to force all URLs to lowercase and add/remove trailing slashes. This will cut down on individual matches for each variation.
Likewise, if you don’t need parameters on the new URLs, creating redirect rules to match to URLs (whether the URL has or doesn’t have parameters in place) will save a lot of time.
The above list is more to make you aware of what is possible, not necessarily solve each issue—the implementation and technical setup will heavily influence how you do this, and I don’t want to give advice that may cause issues. Just know that you don’t have to match EVERYTHING manually and there are workarounds.
For instance, on Wix, in the URL Redirect Manager you can write the entire URL path that you want to redirect from, starting from the first slash (/) of the URL. With a tool like this, every URL with this exact path will be redirected meaning that you can manage an entire folder at once.
Testing redirects
Where possible, always test redirects on a staging environment. Always make time for this, fixing redirect issues post-launch (when everyone is busy doing their planned post-launch tasks) is NOT a situation you want to find yourself in.
Work with your developers to implement the redirects during staging—as you would with a live site—you can then modify your redirect list to run a test.
Get your original 301 redirect mapping and then run a Find & Replace on your OLD column, but replace the OLD domain with whatever your staging domain is.
For example:
https://www.youroldsite.com/a-web-page
becomes
https://stage.new-domain.com/a-web-page
Crawl the list of OLD URLs and then check the destinations against your original URL list—redirects that take place as expected on the staging environment should work on the live site. This gives you more confidence in what you have set up, and the ones you identify as not working are ones you can fix before launch.
Even though you have tested—and fixed issues—in a staging environment, ensure that one of the first things you do after launch is re-crawl all your original URLs to verify everything works as expected.
Tech SEO checks
Ensuring that your new site is technically compliant is another key element of the migration process. This (somewhat) lengthy guide isn’t going to get into the nuances of technical audits, but these are the core elements you especially need to focus on.
Crawlable front-end framework: If you’re changing to a JavaScript front end, ensure that any content that is important for SEO (i.e., content and navigation) is rendered server-side. JavaScript SEO is one of the most technical areas you can venture into—this guide is probably one of the best out there if you want to learn more.
Web Performance: Your new site needs to be as fast—if not faster—than the old version. Page speed is a ranking factor and a step backward here can be detrimental to SEO and user experience.
Internal linking: Significant internal linking changes (particularly reduction) will require some serious investigation.
Crawl the site to get an overview of its technical health: You can use Google Search Console, Bing Webmaster Tools, or third-party SEO software to understand how compliant your new site is from a technical SEO perspective. There are many things to look out for—a more accessible site-audit process built around Screaming Frog can be found here.
There’s so much else you need to get right, but (at a minimum) you want the new site to be as good as the current site. Do not accept lower standards than you currently have and strive for as close to perfect as possible, anything less sets a terrible precedent and is often hard to recover from.
Comparing your staging and live sites
A quick way to ensure your staging site is going in the right direction is to run comparative crawls with the live site. Screaming Frog has a simple way to do this, but most crawlers have this kind of functionality. The key things you need to watch out for are:
Changes in titles/metadata
Changes in crawl depth
Changes in the number of pages
Changes in internal linking
There are many other elements to check, but again, significant changes to items in the list above can have profound impacts when you complete the migration.
It goes without saying, but you may expect there to be significant changes—after all, you’re launching a new site! But, this is where you’re going to use the audit to highlight changes you may not have been expecting—this is your focus.
Reporting and benchmarking
A key part of site migrations is the story you tell about it. You may not believe this, but one of the most common conversations I have with new clients is how their SEO performance has been slowly getting worse. And, they also changed websites around the same time. But, nobody put those elements together.
If you are not tracking and reporting on these things, many businesses do not know it happens. Unless you are trying to cover up a bad migration (please don’t), you always want to report on progress and own your own narrative here.
Ranking performance
You need to be aware of all the keywords that currently drive clicks/impressions to your site. Without a solid view of ranking performance before the migration, you will find it harder to show the success (or troubleshoot issues) post-launch.
The more complete a view you can build of this, the better. I recommend the following tools to access the data you need:
Google Search Console — Look at the top traffic-driving queries for the last year (export via API or Looker Studio if you have a lot of data and don’t want to be limited by sampling).
Semrush/SISTRIX — You can use these tools to collect all ranking keywords (and their pages). Both platforms require a subscription, but basic-level access will provide the information you need here.
Rank tracking software — If you’re already tracking rankings for your most important keywords, this data is invaluable. A rank tracker can let you track your own keywords, which gives more control than found within Semrush’s and Sistrix’s pre-existing databases. Both tools will also enable you to run your own rank tracking campaigns, although there are other options readily available.
In my experience, you will need a combination of the above keyword sources to see the full list, but if you do not have all of this available, the bare minimum is the Google Search Console data. If you are changing domains (and want an easy way of comparing the old site to the new site), then this guide provides a great walkthrough of how to achieve this using Looker Studio (formally Google Data Studio).
If you are adding content or making other improvements as part of the migration, you will want to start tracking the new keywords before the migration. This is essential for measuring the growth post-launch.
Benchmarking other metrics
Rankings and visibility are the best metrics to judge the elements SEO has the most control over, but you will also want to understand other metrics. I like to think of metrics as being on a spectrum, from those that have technical value to those that have financial value.
To help visualize this, I have created the metric chain (see below), that illustrates the key migration-related metrics and where they fall on the technical/financial spectrum.
A technical metric is less closely related to revenue, but you need to understand this to do your job better. Financial metrics don’t give direct implementational information, but they are great to provide to stakeholders to showcase your impact on the bottom line or to lobby to get your recommendations implemented.
Create a snapshot of the key metrics (before your migration) where you highlight what’s most important to the wider team. I usually build these in Looker Studio and include:
Clicks (Google Search Console)
Impressions (Google Search Console)
Organic traffic (Google Analytics)
Organic revenue (Google Analytics)
Organic conversion rate (Google Analytics)
Organic average time on site (Google Analytics)
Organic pages per session (Google Analytics)
CRuX data (from here)
If you are using Looker Studio, you can easily change the date range covered in your snapshot. This is important as you are also going to want to select the date range to compare against.
I usually default to six weeks prior to the migration (but you will need to keep an eye on crawl stats for potentially six months also). This is because six weeks is the usual post-launch window to understand the full impact of the migration, and you want to compare like-for-like as best you can.
If your traffic is highly seasonal, comparing a six-week period pre/post launch may not give you a true representation of traffic performance. So, I usually compare six weeks pre/post-launch and the six weeks post-launch against the same period the previous year. This gives you multiple ways of understanding performance and what is related to the migration against other factors.
Wrapping Up
A successful site migration is entirely possible—you do not need to lose traffic just because you have moved websites. You can’t take it for granted, though.
To reiterate, you need to focus on:
Ensuring that you do not lose any content that currently performs well
Ensuring the new content contains the content/keyword focus you agreed is needed for the new site
Testing 301s so you know they will work
Auditing the site to maintain/implement strong technical SEO standards
Benchmarking, tracking, and reporting on success so you can tell the story of the migration to stakeholders
The best place to start is at the beginning. Familiarize yourself with the elements discussed above and use it to form a plan. Ensure all key people involved are aware of the plan and get going!
Chris Green is an SEO consultant and trainer of over 10 years. A lover of all things digital and uses spreadsheets for more of his life than he really needs to, Chris specializes in migrations, auditing, reporting, training and standing up new processes for teams. Twitter | Linkedin