In Search Podcast: 5 SEO Site Migration Mistakes to Avoid With Sara Moccand

Have you ever been involved in a catastrophic website migration? Maybe you’ve been brought into a project to deal with the effects of a badly thought-through website migration.

Today we’re going to be discussing five key mistakes to avoid when migrating your website with a lady who last year gave in and subscribed to Netflix and Disney Plus. She’s the co-host of the SEO Nerds Switzerland meetup and SEO Specialist at Liip, a web and mobile development agency with six offices in Switzerland. A warm welcome to the In Search SEO podcast, Sara Moccand.

The mistakes to avoid are:

1. Poor planning
2. Not testing redirects
3. Not auditing the staging
4. Migrating in a period of high demand
5. Having the staging indexed

5 Site Migration Tips to Keep an Eye On

Sara: Hi.

D: Hey, Sara. You can find Sara over at liip.ch. So Sara, why is website migration such a big issue for SEOs?

S: Mainly because you can lose all the organic traffic which is the source of revenue, I would say. That is the main reason, so everybody has to be very careful in their website migration.

D: So today, we’re talking about the five key mistakes to avoid when migrating your website. Starting off with number one, poor planning.

1. Poor Planning

S: Yes, one of the biggest mistakes is poor planning. I have a couple of examples. Poor planning can start from the beginning. For example, in an agency, selling the wrong number of days, which means you have to re-discuss the budget, which makes it extremely complicated. There are several examples but let’s start with the main problems. Obviously, you don’t get things implemented the way you want if you don’t plan properly. The second problem, as I said before, is the loss of traffic. That’s the catastrophic scenario, loss of traffic, and the solution to this is to learn the name of everybody that is involved. That is the secret. Learn who is the developer, who is the front end, backend, the designer, etc. Learn everything you can about their names and what they do so you can always contact them.

Each website migration is like a new project. So you have the project, which then has a plan. And there is where you can see exactly where SEO can interact. That is important to keep in mind. For example, at the beginning, developers know what to do, they will choose the technology to work with. So it is interesting for an SEO to know which technology they plan to use. And maybe you can also influence the technology being used. Sometimes, not very often, but sometimes. This is just an example about learning the overall planning and figuring out where you can interact.

D: There are many things that you can include in a plan, of course, but are there any standard elements that you would incorporate within a plan? Or is each project quite unique?

S: I would say there are three standard things. Knowing when the technology is chosen, knowing when the designer will start to design the architecture of the website, and knowing at which point it will go live then you can analyze the staging to make sure when they go live. This brings me to the breakdown of the website migration. You have your plan and then you break it down into phases. First is the phase of preparation, which is where you interact with the developers. And in there you have to also analyze how the website is doing, which pages are important, etc. And you will also prepare your redirect map. The next phase is to have the testing phase where you test everything because whatever is in staging will go 100% live so if there is a problem there, there will be a problem after.

D: You also mentioned URLs there as well. I guess some website migrations are easier than others. Some you might be migrating servers and keeping the same technology, CMS, the same URLs possibly as well… What happens if you’re changing every single URL or the majority of URLs because you have to? Maybe you’re moving from something that’s got ASP, for example, at the end of URLs into a fairly plain URL? Is it possible to keep all your rankings and change URLs at the same time?

S: As I work in a development company, people come to do that. They don’t come to just change the server a little. What they want to do is exactly that. They want to change everything. That is my problem. So yes, it works. You have to do your redirects, you have to do your redirect map, and you have time where the search engines need to adapt a little bit. Most of the time it works fine, because when you do your redirect map, the goal is to do it smartly. For example, you know that if a page is ranking for something specific, then you will redirect it to the same topic. Then you have to be a little bit careful in your redirect map, and then it works. Again, the most case scenario that I’ve seen is exactly where they changed everything.

D: One other follow-up question in relation to what you said. You said that sometimes search engines need a little bit of time to adapt. How much time is reasonable to give to search engines before you should be seeing the same rankings that you had before?

S: No, I meant before you panic. I would say it depends, but I’ve seen some times where they don’t change everything, but they change quite a bit and they adapt quite fast. I would say a maximum of a month, a month and a half. And if after that it is not adapting, then there’s some problem somewhere.

D: Let’s move on to number two, not testing redirects.

2. Not Testing Redirects

S: Yes. Let’s do a couple of examples on the wall of shame where I did poorly. I remember at the beginning I organized my redirect map, and every single file was fine. Then I gave it to the developer to prepare everything I tested. And I said that everything is fine. Then it went live. And when we went live, I was wondering what’s happening. And then I realized that it was generating a redirect chain, which I was a bit surprised about. So I was lucky enough to have a very good relationship with the developers, who were able to fix that on the spot. That was one case scenario where I tested but I didn’t test well enough, because I didn’t realize it before going live.

Another time on the wall of shame and to be aware how important it is to test everything perfectly. I remember there was a website with many countries, but there was a specific role for the URL. So I asked the developer to please help me do a script for me so we will go faster. He did the script and then I booked half a day with the developer to do the test but then he said, “Hey, Sara, I tested it.” Fantastic. If you already did it, fantastic. But let me try one country. So I tested it in the US and I said, “Everything is working. Great. Thank you. Bye. Give me five!” Then we went live. I checked everything and when I checked I was, ”What’s happening? What is jumping? Where is Japan and Kuwait?” So I see we migrated everything, but we were missing Japan and Kuwait, which I didn’t realize before they went live. And again, I was lucky because they helped me recover it immediately so there were no real repercussions because it happened on the day that we corrected everything. But that is a problem. You have to test.

D: I guess that also relates to point three because point three is not auditing the staging.

3. Not Auditing the Staging

S: Yes, that is part of point three. In the beginning, I had my tickets, I was checking them, and everything was fine in the staging. Fantastic. The tickets are implemented. But then I realized then I was not auditing like I would audit a website normally. For example, you start to see weird stuff. I remember this website, which happened recently and on the server-side it was rendering perfectly. I could see everything in the code in the console. So I was happy. But I have a problem with hidden elements, I always check hidden elements. What happened was that JavaScript was behaving super weirdly. It was removing all the texts from the hidden element. So you could see it but not in the code. That is an example of how important it is to audit the staging of the website and to check all the implementation.

The other thing that you need to do is to have your own checklist, repair the checklist, with all the tasks, exactly like an audit, and then you can always add a column. For example, if you use a Google Sheet, have a column that for this task I have a ticket, for these tasks it is not required, I could take it. For example, for the JavaScript case that I gave, you don’t open a ticket, you only open it if there is a problem. And then you give your list of priorities on another column, the status. Which status URL to do in progress, and then you comment. Comments are super important, everybody takes them away, but comments are important because you need to know why something is getting blocked. For example, if a person is blocking or another ticket is blocking, you need to know to block it. That is a little bit about auditing the staging and its importance. It depends, but some developers will also use, for example, the noindex on all the pages, in the code. And then they will forget to remove it when they go live. The problem is that you have to be aware that they’re using it so you can ask them to remember to remove the noindex before going live, please.

D: And point number four to avoid is migrating in a period of high demand.

4. Migrating in a Period of High Demand

S: Yes. This should be obvious because you have this problem of losing traffic, or at least for a short period of time, it is not always like this. Again, it depends on the website migration, but there is a risk of time of adapting. And then if you have time for other activities… Let’s say you are in eCommerce. Between probably October and the end of December, you don’t want to migrate your website because Christmas is coming and a lot of people will buy via your eCommerce store. The client normally knows that in that period they have a high demand. So you can check with the client their analytics to avoid a problem.

D: You mentioned earlier that some developers might even put noindex on every page to actually try and avoid pages being indexed. Mistake number five is having the staging indexed. Would you advise that noindex tag on every page in the staging environment to avoid that kind of thing?

5. Having the Staging Indexed

S: No, password protection is always the solution. You can do noindex but, as in my example, you might forget when you go live. At the end, the best solution that always works is to be password protected, full stop. I remember once the staging got indexed some years ago, and that was probably the most shocking experience I had. Staging got indexed and the problem was… you could buy tickets on the website and the problem was that the people who were trying to buy the tickets on the staging website were a little bit catastrophic. Can you imagine people trying to buy on the staging website? So they contacted me saying that they have this problem. And we were able to solve it as it’s relatively easy to solve. That’s probably one of the main points for me. Once the developers put in password protection and put in the noindex. So I need to be careful not just to check that it’s password-protected but to also check the noindex.

D: I’m sure that you could have expanded this conversation to 101 mistakes to avoid when migrating our website, but hopefully, we’ve got your top five there. As always, that’s great stuff from Sara there. Let’s finish off with the Pareto Pickle. Pareto says you can get 80% of your results from 20% of your efforts. What’s one SEO activity you would recommend that provides incredible results for modest levels of effort?

The Pareto Pickle – Website Migration Planning

S: For me in a website migration it’s the planning. Take a little bit of time in planning. It’s not an enormous amount of time compared to the work that you have to do. If you have structure, then you don’t make mistakes, and then you save yourself a lot of time because for each mistake, you need to ask for time to recover from the mistakes so definitely planning.

D: Plan properly. I’ve been your host, David Bain. You can find Sara over at liip.ch. Sara, thanks so much for being on The In Search SEO podcast.

S: Thank you.

D: And thank you for listening.

by Darrell Mordecai

Darrell creates SEO content for Similarweb, drawing on his deep understanding of SEO and Google patents.