A Website Replatform Guide & Checklist

  • Posted by Martin Nolan
  • On January 14, 2020
  • SEO,

There aren't many tasks that are as thankless in SEO as a  website migration or replatform.
You've got everything to lose and usually not too much to gain.

It is also labour intensive, it requires little to no creativity, and by the end of it, you'll be booking yourself an appointment at Specsavers because you've stared so hard at a spreadsheet.

That being said, it is essential.

If you get a site replatform wrong, then the arse tends to fall out of the performance of a site.

So with that said get your spectacles at the ready because we're going to walk you through how to do a replatform.

What is a website replatform?

I guess before we get into the meat of walking you through it, we need to define what a website replatform or migration is.

In it's simplest definition, it is switching from one system that a website is built with to another.

Unfortunately, that definition leaves a lot of room for interpretation and replatforming is a pretty broad church. 

A site replatform to someone in IT can be something entirely different for a Product manager or an SEO. It can include changing a selling system that powers the pricing and inventory on a site, to the CMS or even overhauling the whole site top to bottom.

Why replatforms are important?

There's usually a reason you change something, right? 

And that something is that the old platform that you were using wasn't up to scratch. It probably had a whole heap of legacy issues that made it inflexible to work with. And there was probably something newer on the market that was a lot better suited to your current needs.

So it's a good thing that you're moving to a better tach stack. One that's more flexible and performs better.

 Yeah, it's a lot of work, and it can be soul-destroying at times, but if you mitigate the risks properly, then it can set you up for success for the next 5 to 10 years.

Which brings us onto step 1.

An SEO guide to replatforming

Step 1: Understanding the risks

Define the replatform

You need to know what is changing to know what the risks to SEO are and how to mitigate them.

There are 4 questions that I like to ask to get a gauge on this:

Are we changing the framework? 

Here I'm asking whether we are changing the codebase. If so, we need to know which framework and factor in SEO recommendations based on that.

Is onsite functionality changing?

This should establish whether the search functionality is changing. Helping to find out whether there is anything that you may need to block from crawlers and whether there's potential for multiple URLs to be generated. All of which are pretty important for Organic SEO performance.

Is the site structure changing?

If the answer is yes, it more than likely means that the URL structure is changing. 

If the URL structure is changing, then you'll have to map 301 redirects. And if the site architecture is changing, you need to make sure that where the pages sit on the site is optimal for ranking in Google and that all the relevant pages link to each other. Either that or risk your performance plummeting quicker than Tom Daley leaping off a highboard.

Are we changing the page templates?

If templates are changing, then you will want to get your eyes on them. You've likely spent a lot of time optimising those templates to rank in the SERPs. It's also likely that there are changes that you wanted to make but couldn't, it's also important to factor those in as well. Remember there's always room in a site replatform to sneak a few things in that you couldn't previously do.

Once you've asked those 4 questions, you've got a top-level overview of what is changing and what you need to do. 

After that, you need to start drawing up a plan.

Which brings us nicely onto Step 2.

Step 2: Define your must-haves and where you need signoff.

As the old ancient SEO proverb goes:

"Assume makes an ASS out of U and ME."

Okay, maybe an SEO didn't make that up, but if you make the assumption that whoever is in charge of the project is going to know everything that you require from an Search Engine Optimisation perspective and every point that you need to feed in then you are the proverbial ASS.

You need to define this to them.

This is your responsibility as a specialist in SEO.

 

This is even more important if you are working across multiple teams and with various agencies because managing stakeholders is incredibly hard for project managers, so just giving them everything is super helpful.

To do this, we create an SEO requirements document. It doesn't have to be any simpler than a spreadsheet with two tabs.

Tab 1 - Requirements

These are the things that we currently have that are essential to SEO performance. They absolutely have to be factored into the new platform.

We tend to split this tab into three sections:

Technical SEO Requirements For Migration

All the technical SEO elements, with an explanation of each and the risk around them. 

The above doesn't have to be hyper-specific because you may not have the full picture yet. But you need to identify what's essential and what you need to get signoff on.

Eventually, it will get to a point where it will look like the below.

SEO migration checklist

On page

This is the same premise as the above. You need to identify what are the key on-page SEO elements that you want in the new world. Then you need to articulate why. And finally, be clear about the risk around removing them.

Testing

The 3rd and final section of the 1st tab is to make sure that testing is factored in properly.

I cannot stress how important this is. Rushed decisions are bad decisions, and unless you're bullish about this, you can be left with 48 hours to test a complete replatform.

So you need to make sure you clearly outline:

  • How long is an adequate timeframe giving the size of the site and the proposed replatform.
  • What testing environments you need access to and for how long.
  • What tools you'll need to use and any considerations around them being given access to the test environment

Tab 2 - Process

This tab is about being clear on your process and when that comes into play so that when they plan their design or development sprints, they know where you fit in.

You need to take all of the things that you've highlighted in Tab 1 and think about what you need for each.

So for example, for the On-Page requirements, you will probably need to feed into the wireframes, mock-ups and the final designs.

These would probably be separate tasks and would happen before they go live.

And it's just a case of doing the above thought process for each until you have a sort of process map built of this needs to happen here.

Like the above tab, we like to split it into sections:

Preparation -  The things we need to do before we get to testing

Testing - The things we need to do when testing the site

Pre-launch - The things we need to get in place so we can measure whether it was a success or not

Post-launch - Measuring and cleaning up if anything goes wrong (and there will be a cleanup).

Step 3: Doing the work

This is going to be wildly dependent on the type of replatform that you are doing. But because we can't factor in every single kind of replatform, we will only cover some of the core things that continuously crop up as part of replatforms and how to approach them.

How to map redirects in a replatform

Yes, here it is. The silver medalist of mundane SEO tasks.

Oh the spreadsheets. 

Those URLs.

The sleepless nights fearing you've missed a part of the site. 

Maybe that was too melodramatic, but because it is such high stakes, it's a melting pot of stress and boredom that makes it one of the worst SEO tasks.

So, with the big sell out the way here is how you map redirects as part of a site replatform.

  1. Crawl the current site pulling in as much data sources as possible

What you need to do here is gather as much data as possible and get a rough sites structure.

To do this, I use Screaming Frog and integrate it with Google Analytics API and Google Search Console API:

First, I make sure we are crawling it quickly, so to do that I uncheck the following options:

Configuration >> Spider >> Crawl

  • Images
  • CSS
  • Javascript (NOTE: This depends on what framework your site is built off)
  • External links
  • Pagination
  • Hreflang (Note: Only if there aren't multination versions)
  • AMP 

Configuration >> Spider >> Extraction

  • - Meta Keywords
  • - H2
  • - Wordcount
  • - Text to code ratio
  • - Hash value 
  • - Page size
  • - Response time
  • - Last modified
  • - JSON-LD
  • - Microdata
  • - RDFa

Configuration >> Spider >>Rendering

 For this, I leave it on text only. Again be careful to make sure that you're not already on a SPA framework as this would be the wrong option for that.

After all those boxes have been unchecked, I will go to the robots.txt setting and uncheck the "show External URLs blocked by the robots.txt" box.

Hooking up the APIs

Then it's about hooking up the APIs. 

The reason we hook up the APIs to Screaming Frog is that it works only discovers pages that are linked to. Now just because a page isn't linked to on your site anymore doesn't mean it's not in the index.

That's why we throw Sessions from GA into the mix as well as Impressions and Clicks from Search console.

By adding all of them, you've got a pretty healthy coverage of all URLs.

To connect the API, you take the following steps:

 

  • - Go to Configuration >> API Access
  • - Go to Google Analytics
  • - Click on or add the user account and connect
  • - Select the account you want to use
  • - Select the date range to give a reasonable amount of coverage (I usually opt for a year)
  • - Repeat for Google Search Console

Then once the above is done, run the crawl. 

2. Save The Crawl

Once the crawl has finished, I like to save it. Mainly because I'm paranoid and I've been hurt one too many times in the past.

3. Switch The View To Tree Table & Export

Then I look to export that data into a spreadsheet. However, before I do that, I prefer to export it in the tree table view. 

Now there's a little trick to this to make sure all the folders are open. Hover over the top-level category, and right click then select "Expand all".

If you don't do that, then some pages won't be in the export.

Once that is done we've got the majority of the URLs, actual stats to know which ones are important and an idea of structure. We're ready to do the same for the new site.

4. Repeat the above on the test site

That's right. You'll have to go through all of that again on the test site.

5. Compare URL structures

What you're looking for at this point is to compare the two sites side by side.

See where the structures have changed, what pages are missing, and where you need to implement a redirect.

This is where the real work gets done and depending on how different the URL structure is it can be a very manual process of going through it URL by URL.

How to audit pages template changes

This is quite simple; it's just a case of looking at the proposed new template and comparing it to your current site.

The two most important thing to do in this phase are:

1) Make sure you are thinking mobile 1st because Google's index is based on the mobile version it crawls.

2) Ask loads of questions. I mean like loads. Don't be afraid to be that person who's always like; "So what does that do?" or "Where does that take you?" because the reality is that you are going to see the page in many forms. Some bare like wireframes. Some fully fleshed mock-ups. And by asking those questions early on, you get an idea of functionality, and you can stop any potential red flags that may cause issues for your Organic performance.

If you do the above and scrutinise every detail of each page, scrutinising where copy looks like it could be cut down, have any internal links been dropped or have features been added to the page then you won't go too far wrong.

How to audit the main navigation

The main navigation of a site is always the most hotly debated topic of any replatform.

It's almost like a proxy war between the departments.

Product and sales teams want more pages in it.

UX want no pages in it.

Merchandisers want messaging all over it.

It's almost a never-ending battle. But from an SEO's point of view, you want to make sure that the crucial pages are in it and that one's that are doing nothing aren't.

To find this out, you need data.

Now it's quite a long process, so I'm going to jot down the crib note version:

Pull the URLs from the main nav

Crawl the site and look at the current total number of links into them

Take the total impressions, clicks and Avg Position for them

Then start having some fun with maths. I tend to look at the following:

=impressions/total links

The higher the number, the better. It means the page has high traffic potential.

I then do the same with clicks, which shows the pages acquiring the most traffic.

Sometimes I then take other pages that aren't in the nav and do the same. And then multiply them by the Avg position. This will identify underperforming URLs with high traffic potential.

You can even make stupid names for it and leave yourslef with something like:

Then it's taking all that data and making a logical decision based upon it.

Step 4: Testing

Now, is the part of the process you're making sure that everything has been implemented properly.

The most important things to test are below:

  • Make sure that key content on landing pages hasn't been lost
  • Make sure that pages can still be navigated to from one to the other
  • Test the different behaviours on the site thoroughly. Run searches like you are a user. See if anything that should be blocked is and nothing has been missed
  • Check the key technical elements are all still there Eg Canonicals, Server side redirect rules, Schema etc
  • Check any redirects that have been recommended have been implemented

If you want a more thorough checklist, we've embedded one below.

Website Migration SEO Checklist 2020

Preparation

 

Site structure:

  • MAP EXISTING SITE; Finding every URL that is currently on the site and indexable. Mapping this into a clear site structure so that it can be cross referenced versus the proposed new site structure to see where pages are being removed and where redirects need to be implemented.
  • PROPOSED SITEMAP REVIEW; A sitemap of the proposed new site. If applicable this needs to include the new url structure.
  • PROPOSED SITEMAP REVIEW; Comparison of the existing sitemap Vs the new sitemap to see which pages are being dropped, the risk around them and to get an idea of the number of redirects that need to be mapped. Also any potential pages/page types that currently do not exist on the works site that have the potential to drive additional traffic.
  • TITLES, H1S, DESCRIPTION MAPPING; Map of the Page Titles, H1s and Descriptions for the proposed new site.

Functionality Review:

  • WALKTHROUGH OF USER JOURNEY; A walkthrough of how the site will work as well as core functionality. The goal of this is to identify any functionality that may affect the way that Googlebot crawls and indexes the site.Things to look out for:- How the search functionality will work and what string that generates
    - How filtering works
    - The booking flow and whether the URL changes
    - Can pages be auto generated
  • ACCESS TO THE SANDBOX/ DEV ENVIRONMENT; Following the walkthrough of the user journey it would be good to have temporary 48 hour access to the site to double check there are no things functionally that may cause an issue for SEO.
    The goal here is to make sure there isn't anything that we need to fix at the 11th hour.

Technical Requirements

  • SCHEMA REVIEW & MAP; supply a list of the current structured data that is on the site mapped to the page types that it is implemented on.
    Also supply a list of additional structured data opportunities for review.
  • GUIDELINES ON XML SITEMAPS; Supply guidelines on how to format the XML sitemap as well as pages that shouldn't be included within it.
  • ROBOTS.TXT RECOMMENDATION; Based on the functionality walkthrough and access to the sandbox/development environment, {agency/in house team} will make a list of recommendations to be implemented for updating the robots.txt.
    This will mainly be looking at how any URL strings generated from the new search functionality have changed and then editing the robots.txt to make sure they are blocked.

On Page

  • PAGE TEMPLATES SUPPLIED; Each version (mobile and desktop) of the page templates to be supplied to {agency/in house team} to be reviewed.
  • PAGE TEMPLATES REVIEW; {agency/in house team} to review each page template supplied.
    The goal of this is to identify any key components that are being lost from the old version of the site as well as being able to ask key questions about how certain features of the page works.
  • TEMPLATE FEEDBACK; {agency/in house team} to feedback on each template with risks of features missing as well as any other components that may be beneficial. As well as whether new templates are required for content that The Works currently does not cater for.

Mapping

  • ACCESS TO THE TEST SITE; {agency/in house team} and it's tools to get access to the test site to start mapping the page to page redirects.
    The only tool that requires access is screaming frog. This is on our local machine so the only IP address that needs to be Whitelisted is our ip address.
  • REDIRECT MAPPING; Map of the page to page redirects that need to be implemented.
  • COMBINE REDIRECT MAP & TITLE'S, H1'S AND DESCRIPTIONS; Combine the redirect map with the Titles, H1s and Description map. Where there are URLs not included in the original proposed sitemap add the titles and descriptions into it.
  • REDIRECT IMPLEMENTATION; Page to page redirects to implemented as per the proposed map.
  • TITLES, H1'S & DESCRIPTION IMPLEMENTATION;Implementing Titles, H1's and Descriptions.

 

Testing

 

Pre Go Live Testing

  • REDIRECT TEST; {agency/in house team} to test all the page to page redirects to make sure that they have been implemented correctly.
  • TITLES, H1S & DESCRIPTION; {agency/in house team} to run a crawl comparing proposed titles, desc, h1s and titles, desc, h1s currently on the test site. The goal is to identify any titles that aren't implemented correctly.
  • PAGE TEMPLATE TEST; Testing the built page templates. The goal is to identify where the expected behaviour and features of the page differ from what is on the live version. Eg Are there any links missing that we thought there would be? Does that go to where we thought it would go to?
  • FUNCTIONALITY TESTING;Testing the behaviour of on site functionality looking for any issues with the fully developed version versus what was expected.
  • FIXES IMPLEMENTED; Agreed upon fixes from any of the above phases implemented.

 

Pre Go Live

 

Benchmarking

  • PULL RANKING DATA; Pull ranking data from last year as well as a previous 4 weeks to benchmark go live performance against it.
  • TOP LEVEL DASHBOARD GSC; Build a top level dashboard in real time data studio dashboard to measure Avg position, clicks, impressions and sessions to sport any major dip.

 

Post Go Live

 

Crawling

  • CRAWL ALL THE REDIRECTS; Crawl all the redirects that have been mapped. Identify any difference in behaviour from test site to the live
  • CRAWL SITE;Crawl the site to make sure there aren't any major issues with indexability, on page elements, structured data etc
  • FIXES FOR ANY ISSUES; Any major issues highlighted to be fixed.

GSC

  • FETCH THE HOMEPAGE; Crawl all the redirects that have been mapped. Identify any difference in behaviour from test site to the live
  • CRAWL SITE; Crawl the site to make sure there aren't any major issues with indexability, on page elements, structured data etc
  • FIXES FOR ANY ISSUES; Any major issues highlighted to be fixed.

Monitor And Cleanup

  • MONITOR PERFORMANCE; Look for pages that have massively dropped in rankings and then look to see where/how they have changed versus previously Eg Less internal links
  • Monitor GSC and look for 404 pages from the previous site. Implement 301 redirects where applicable.
  • INDEXATION ISSUES; Monitor GSC for URLs that are incorrectly being indexed or different canonicals are being implemented
  • FIXES; Implement fixes for any issues highlighted above.

So there it is a guide to planning for a replatform. If you follow the above steps, you should be in a good place when it comes to the go-live date.

If there are any questions around it, then you can hit me up on twitter or leave a comment on the blog.

Tags:
0 comments on A Website Replatform Guide & Checklist

Leave a Reply

Your email address will not be published. Required fields are marked *

Call back form
  • By submitting this enquiry I agree to the website’s Privacy Policy
  • I consent to receiving marketing communication from Broadplace. You can unsubscribe at any time