How to ensure SEO performance is retained during a site redesign

Look, I think there are loads of migration and site redesign blogs out there for SEOs. So rather than entirely repeat what they say, I thought I’d focus on sharing exactly what I did for a recent client during their site redesign.

This client will remain anonymous throughout, but I will share some very no-context style graphs you might often see and love on LinkedIn.

My client were doing a complete site redesign and launch, meaning all site templates were changing, including navigation, footer, blog and commercial pages.

Project Plan

Firstly, lets look at what the plan focused on. This was a relatively small website, and no content review or keyword research was required, so, while in some cases I might include keyword review and staging content optimisation, in this case I did not.

You’d also want to be careful about what you optimise during this period, as if you do too many content changes, it may result in confusion over what exactly resulted in a performance change – positive or negative.

 

Instead, this project was focused on the more technical side of things, ensuring the new site has no technical issues that may impact performance, but also ensuring it doesn’t inherit any bad technical practices from the old site.

Aims

Before I dive into each aspect of the project, I want to be clear on what my aims are when I go into a site redesign or site migration.

The aim for SEO during a site redesign or migration is to see no negative impact. This means, in reality, a successful migration is seeing little to no change to performance, but a really successful one is where we see a positive impact - I’d never promise that though.

Benchmarking

This project, whilst not impactful to the project in terms of results, allows us to have a clear understanding of pre and post-performance across the site.

With this kind of data we can more easily see the impact of the migration to the site’s current performance. This can also feed into resource allocation, meaning teams focus on areas of the site that are most important.

This is particularly important to do before migration when the domain is also changing, but I tend to do it before in all projects.

I’ll run through how I put this together, but to view a sample of this, I’ll share a link below.

Keyword tracking

Firstly, I collected a set of keywords that were worth tracking. My project didn’t include a keyword research, so whilst the keyword set needs to be detailed, it doesn’t need to include everything. Essentially, we just need enough that we’re able to ascertain performance changes to organic keywords.

To put this together, I used two main tools:

1. Ahrefs – I exported all keywords from the Organic Keywords tab. This provides details of what keywords have the most opportunity that my client already rank for
2. Search Console – export all keywords and data for previous 28 days. For this, I needed to use a tool like Search Console API or Looker Studio to create an unfiltered list of keywords.

Once I have these data tables, I combined them and retained only keywords that were included in both sets. This meant I could quickly remove any that:

1. Were misspellings
2. Didn’t generate clicks (sometimes software data is wrong – shock!)

I did also review any keywords in Search Console that were being removed that had a high number of clicks, but what I tend to find was these were often misspellings anyway.

Page tracking

I extracted page level Search Console data for the last 28 days before launch.  Again, as I wanted to ensure I got a complete set of data, I needed to use Looker Studio or the Search Console API to get the most-unfiltered data.

Once completing the redirect mapping, I would also include the new URLs mapped, so I could do a like for like with the old URL.

This may mean you need to be aware of any new URLs that are mapped to multiple old URLs, meaning their data would appear twice, meaning data for new URLs show up twice. This can often be quite minimal, but does happen, and can confuse the data a little.

Core Web Vitals

For this, I pulled data from two areas:

1.       CrUX Looker Studio dashboard – I didn’t need to do anything fancy here actually, as there are already default dashboards created by the CrUX team. All I used this for was screenshots.

2.       Screaming Frog with Page Speed Insights API – I crawled the site with the API activated, meaning I get both CrUX data and Lab data. I found only a few pages actually had enough user data for CrUX report, so the lab data was able to fill in any gaps.

It’s worth noting that in the post-migration benchmarking update, you need to wait 28 days at least before updating this information.

Google Analytics

Finally, I exported GA data, including such metrics as:

1. Sessions
2. Revenue
3. Conversions
4. Bounce rate
5. Time on page
6. Pages per session

Whilst this is primarily there to understand the impact to performance, you can also use the data to feed into any potential UX issues that are resulting in users either spending less money or time on the site.

With this client – in the end I wasn’t able to use their GA data as we discovered the new and old sites were using different GA properties and weren’t always working as they should be, so the data was highly inaccurate.

Technical Review (Staging & Current)

The next project I worked on was a full technical review of the current and staging sites. In this case, both versions of the site were relatively small, so I could do both at once. Taking this approach also lets me determine whether I see the problem on both sites, or just one, and can provide a more detailed description of the problem.

There were some key issues on the site that required work before launch.

Parameters and additional characters appended to all links leading to duplicate URLs

Two major issues they had to fix prior to launch of new site were resulting in a high number of duplicate pages. This resulted in potentially up to 7 or more URLs for the same page.

There were 2 reasons why this was the case.

1. Firstly, they had used tracking parameters on the website, which were appended to every link on the page you land on. This resulted in essentially creating a whole duplicate website with the tracking parameter attached.
2. Secondly, there was also a problem with a Google Tag Manager snippet that was appending “?” or “?&” to some links on a page. Again, this would result in a duplicate site with all URLs using the same “?” appended.

Fixing this was a high priority, and I viewed it as one of the most impactful fixes we could make.

We also had to ensure canonicals were being utilised properly, so when parameters did need to be used, they were using canonical links back to the non-parameterised version.

Content is loaded white font on white space before JavaScript loads, which could be seen as misleading by Google

It’s sometimes the case, as it was here, that design choices on the new site are found to be a potential SEO problem.

In this case, the site was designed so text would appear on page as you scrolled down the page, with opacity set to 0 on load.

What that means is two things:

1. When JavaScript was disabled, this text doesn’t appear, meaning it would remain as transparent text
2. Even when Google does render the JavaScript, it cannot change the opacity, because crucially, Google does not crawl a page like we do, and therefore does not scroll. So Google will just see transparent text throughout

Fixing this was another priority, as it could lead to future complications such as penalties for hidden text or cloaking and negative performance growth.

Staging site > PROD updates

There may be some things on the staging site that are implemented because it’s a staging site. For example, robots.txt file may be blocking everything, “noindex, nofollow” meta robots tag may be utilised to avoid indexing or there may be many test pages that haven’t been complete, or won’t be complete.

It’s important, in my opinion, to write these down at the same time as you do the technical review, even if the developers get annoyed as they think you’re assuming they don’t know. The reason being, is there is SO much going on during a site redesign or migration, that sometimes things get forgotten, and mistakes can happen. Therefore, having these listed for the dev team to be reminded of, and for your own checks post launch, will mitigate the likelihood this happens.

Redirect Mapping

A staple in the migration world, this ensures that every page on the current site has a destination on the new site, or if deciding to remove a page without redirecting, at least significant thought has gone into that decision, and it’s based on data.

To do this, it required a crawl of the “completed” staging site, or at least a complete list of the URLs that are being created on the new site, and a crawl of the current site.

That way, I’ve got two clear sets of pages that need to be combined.

Then starting with the obvious and priority pages, start mapping current pages to the new site. There are people much cleverer than me that have created scripts to map pages using things such as the URL or title similarity score, but when it’s a smaller site, you can often just complete this without that.

Post Migration Checks & Actions

Once the migration had taken place, I needed to first resubmit the Sitemap to ensure the new site is crawled.

Note that if there is a change of domain, then update Search Console with the change of domain tool.

Additionally, I had to make sure there aren’t significant technical problems with the new site. For example:

1. Robots.txt – sometimes a new site is launched but the robots.txt file used on the staging site is ALSO migrated when it shouldn’t be. This should be your first point of call.
2. Review previously highlighted issues and double check they are no longer going to be a problem on the new site
3.  Old links or staging site links – in some cases, the homepage URL used on the staging site can be /home, these links should be updated. Additionally, sometimes key areas of the site, such as the navigation can still retain the old links. These should be updated to avoid too many redirects – although I wouldn’t worry about every one…
4. Placeholder text – there was some missed content that hadn’t been updated from the placeholder “Lorum Ipsem” text usually used on templates.
5. Canonicals – in this case, the canonicals were using the http version, rather than secure https.
6. Sitemap – there can sometimes be old links included in the sitemap that should be rectified.

 

Result

Ultimately, a good result when migrating a site for SEO is to have no change to performance at all. However, in some cases the results can be quite astounding.

For this client, as I said, I can’t share too much, but the migration was successful, and fixed some glaring technical issues, meaning crawling and indexing pages was much easier for Google. This opened the door for some successful campaigns.

I won’t say that the above uplift isn’t all down to the technical improvements we made. They have also added some new blogs that have had success.