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.
If you don't want to read on after this point and want to jump individual sections then use the links below:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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).
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.
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.
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
Configuration >> Spider >> Extraction
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:
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.
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.
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:
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.
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:
If you want a more thorough checklist, we've embedded one below.
Pre Go Live Testing
Monitor And Cleanup
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.