Technical SEO considerations for replatforming

James: Hello and welcome to the second episode of Re:Platform. We’re delighted this week to have a highly experienced SEO and analytics specialist with us, Gerry White. He’s very well known in the industry and never shy of sharing his opinions or giving us insights into where things go wrong. So the aim of today’s podcast is to focus on technical SEO in the context of replatforming. Technical SEO is such a wide-ranging topic including information architecture, URL schemas, indexation control, et cetera. What we really want to do is pick Gerry’s brain around some of the things that people need to think about that can impact the success of a platform if you don’t have the right SEO thinking upfront. And also we’ve got Paul who has got a huge amount of experience in this area. So first off, I’ll stop rambling. Gerry, welcome and please give a quick intro to people on you’re currently up to and what your background is.

Gerry: Absolutely. I’ve been in technical marketing or technical SEO for about 15 years, online for about 20 years, very much a case of trying to figure out why you should be doing SEO and what it is today. The first five years was more analytics and project management and even building websites for companies. I think I started off building my first website in Word at one point! Then I discovered something amazing called Frontpage. It shows how old I am that no one’s ever heard of people actually building websites in Frontpage anymore. So yeah, today I’m working with Just Eat as the technical SEO lead on international, which means that what I’m doing at the moment seems to be focused around replatforming and basically just making sure that nothing breaks as we rebuild a lot of the platform and the website.

James: Fantastic. It’s going to be interesting to hear your international insights because that obviously raises the bar when you’re replatforming across different domains, languages, et cetera. Cool. So let’s start at the high-level and work down into the nitty gritty. So firstly, I’d quite like to hear from you Gerry , and also chip in Paul, how would you define technical SEO? Let’s help people understand what it really means in the context of platform selection. So what is important, what do you need to think about in order to make a sensible platform investment decision?

Gerry: Yeah, it’s a really good question. And the reason why is that it’s one of those things where SEO people always answer, well it depends! “It depends” seems to be the most popular response to anything and everything. Getting the right platform is quite challenging in itself. But generally nearly every platform can be used for good SEO. The platforms that seem to be struggling at the moment from a technical SEO point of view are cloud-based ones. And I’m seeing more and more of these ones in the cloud and you can’t edit things like robots.txt files. So from a technical SEO point of view, you want to be able to control the header responses, which means whether or not it’s really is a 404 page or a proper page all the way down to how the HTML is served up.

For instance, JavaScript seems to be getting more and more popular nowadays. And again, going back to what I mentioned before, cloud-based platforms are often serving their content increasingly in JavaScript, which means that Google and other search engines can’t kind truly evaluate how the page looks to user. So it often means your ranking suffers. The other side of it is that international is increasingly popular and more to the point when you’ve got multiple languages and you want to be able to define the relationships between pages.

That’s something that a lot of the time you want control over. The platform question is very much about control. Can you control all of it? Can you add in things like simple redirects, can you add in all of the kind of the media types or all of the types of page types that you want to, and will you be limited down the line if you decide that you need to add something additional into it?

Paul: I have a question just to add to that. You’ve worked on a lot of big retail websites and I’d imagine a lot of them have moved from one platform or technology to another. How involved have you been as the SEO expert in those discussions and decisions?

Gerry: In terms of replatforming, not so much generally speaking, a lot of the time they almost turn around and say, “Oh, we’ve moved to this platform”. And I come along and say, “Oh, that means it’s going to be a huge investment because we’ve got to rebuild this part or we’ve got to really re-evaluate”. And often I come along with almost a checklist approach where I say, “Oh, actually we just need to make sure that this works or we’ve got the capabilities we need to satisfy”. There are also different reasons for the replatform. Sometimes it’s the commercial reason. Like for instance, one platform has reached the end of life and is no longer supported or it’s unable to support the number of products that are on the platform or something else. There’s often commercial reasons why the replatforming is required and it’s not always down to an SEO requirement. But you know, I’ve seen that and everybody’s seen it where if the SEO fails, then the company will almost go bankrupt. So it is something where big companies really do need to understand that because the implications of replatforming can be absolutely huge. More so if you get it wrong, nobody notices if you get it right! But if you get it wrong, everybody knows.

Paul: Yeah, absolutely that makes sense. I think the other question for a project of that size, when would you generally get involved? Would it be narrow to the start and scale up later?

Gerry: It does seem like from an agency point of view, I’ve been brought in later. In that, you know, they have already replatformed and something is going a little bit wrong. They’ve kind of spotted that what should have been perfect now isn’t and so myself or somebody similar has come along to understand the problem. I can then tell them, “The reason that it’s failing is because of, X, Y, Z”.

There is a potentially huge list of reasons why it’s not working quite right after a replatforming. But that said, I’ve also been involved early on for a big international site, so my involvement was right from the start, making sure that everything was going to be perfect, everything was going to be really, really well done. And then a year later when we finally launched it, it was almost completely flawless and it was great to be involved all the way through.

James:      And a question for me on this because you say about a lot of the time you get brought in further down the line when people have already made decisions, they haven’t necessarily thought through the implications from a technical SEO point of view. A lot of the time I find in projects you say to people, right you need a technical SEO because you don’t have it in-house, so budget this amount. And it’s normally a ballpark from a few thousand up to tens of thousands depend on the complexity and size. And then the budget holders say, “No we don’t want to spend that money, we want to spend it on these other features”. However if they get the SEO planning wrong, it will often bite them on the back side and they end up spending much more further down the line to rearchitect because they’ve ruined that organic visibility. So how do you as a consultant help to manage people’s expectations to get them to buy in and understand the importance of investment in technical SEO so they don’t push it down the line?

Gerry:       That’s an interesting question. The really short answer is it depends. Sometimes it’s a small ecommerce website and it’s going to be a such a simple task to replatform as long as they plan it right. As I mentioned before, it’s more often that they do things wrong than lack of planning. That’s when things get really expensive. So taking the time to do it right is cheaper than doing it wrong. To fix things up requires huge amounts of investment to investigate, to make sure things like the redirects are working right. The one thing that I would say is you should always check the developers’ knowledge; they don’t always know the sorts of subtleties for SEO, where a specialist SEO will e.g. what type of redirect to use if you need a redirect, or making changes to a page template that blocks it from Google or something similar. This is where testing is so important.

It’s quite time intensive and understanding that, you know, there will be time investment and the longer the project goes on, the more costly it will be. The cost starts to stack up so you have to plan for that. So it’s more a point of communicating that if you get it right from the start and make sure that everything’s detailed and documented, it will be a lot cheaper in the long run.

James:      I agree that point about factoring in time for whoever the SEO lead is to do proper testing is critical. As you say, you can have a clear specification of what you need but it’s not implemented correctly and therefore it’s counterproductive. Which leads me onto the next question and it’s something that I’ve often heard people talk about in projects where they say, okay, well we, we need to get our SEO requirements defined before we go and talk to vendors. What do you think an ecommerce team needs to understand before looking at vendors? I always say look at technology after you know what you want, otherwise it’s just a beauty parade. But what would you advise people, what should you know about your SEO requirements before you can meaningfully evaluate the platform?

Gerry:       Yeah, again it depends on how complex the site is. I worked on a light bulb website and we wanted to have comparisons across all the different product data and be searchable across everything. So we needed a platform extensible enough that we could put in all of the different requirements, features and facets that were required and make sure that from an SEO point of view that didn’t create huge spider traps. That was my single biggest requirement. For another website, for instance travel, it needed highly customizable pages based on the locations and time of year.

So you need to know how users see a page and how search engines see it. Basically can it be crawled, can Google understand it and then can Google return it. You need to know if the database is customisable to fit the requirements of the product. And then can we build the site architecture around it so we don’t have 20 million URLs due to indexation control issues, which I’ve seen before.

James:      And once you’ve decided what’s relevant to the project based on the size of the business, the industry, complexity, etc. what are your tips for doing a proper platform evaluation? Because one of the classic things that vendors get sometimes criticized for is saying they’re SEO friendly, like for URL structures, which we know doesn’t really mean anything unless it’s properly executed. So how do you go from someone telling you it’s SEO friendly to properly understanding whether it really is in the context of the business?

Gerry:       Yeah, I think the easiest thing is to kind of look at a similar project. So, for instance, if they say, “Oh yeah, we did this one or we did the other one”, then you look at the live site and check if actually this has got major limitations, major problems from that point of view. So seeing something in the wild, have they got a previous client example, then that’s a great place to start. And even if they haven’t, let’s take a look at what it says and how it builds, is there a demo store or is there something where you can really evaluate what is happening.

The best examples that I’ve seen recently are company career sites. For some reason these are never particularly well SEOd, they’re often terrible and it’s just seems to be the common one where the vendor thinks it’s SEO friendly and the biggest problem is the use of JavaScript. So you need to ask what’s stopping them from repeating the same problems with us? And what is their response from you doing a tech audit on a sample site and flagging problems?

Paul:          Can we come back to something you said earlier about the SaaS platforms, not being able to own things like the robots.txt and maybe not having as much control over URLs and things like that. In a scenario like that, if you’ve got a business that where the platform really makes sense to them and is really aligned with their business needs, how important do you think those areas in particular, some of those kinds of common restrictions to a SaaS platform? And how would you go about working around them and manage expectations in that scenario?

Gerry:       Well, one of the things that a lot of SEOs do badly is they don’t work within the limitations of a platform. So for instance, if you can’t edit the robots.txt file, maybe that’s not the end of the world. Maybe there’s something else that you can do. Sometimes there’s a hack. Sometimes there’s a solution so you can do it in other ways. And you sometimes have to just accept the limitations you’ve got especially if you’re talking about a relatively small business, like an enterprise level business, often it makes far more sense for them to be on a hosted platform. That means that they’re not going to worry about the website being hacked. They’re not going to worry about the maintenance and support.

It is critical that you do understand that as they grow and expand, they can be moved off it. So it’s not the end of the world if they decide to go for a limited platform initially. So you know, a SaaS platform that actually meets all of their short term needs. And you know, SEO is absolutely critical, but so is the fact that they’ve got to be able to afford to maintain, manage, keep it running, make sure it’s scalable, make sure it’s delivering constantly. And that’s what a lot of these platforms do really well is the fact they’re always up. The uptime for them is incredibly high and they don’t have to invest in admins who are running the site.

Paul:          Indeed. I mean I had a situation recently where basically the business really wanted to move to one of the SaaS platforms. There was quite a lot of compromise on the SEO side. So a main one was they had to change every URL for the site. And the other one was that they had to change the international domains because the platform didn’t allow for sub folders. But essentially when we looked at the compromise and they looked at the potential loss of mostly non-brand organic they decided that the long-term benefits outweighed the short term. Is that something that you’ve had to deal with in the past where you’ve had to set expectations around that kind of stuff?

Gerry:       Yeah. I’m a classic SEO guy. I always want everything to be perfect and everything has to be done my way! I don’t ever want to kind of find that the problems that are going to occur are going to be SEO issues. And every SEO out there will be working with a client that will have problems and platform limitations. I’ve never met the perfect platform that I sit around and say, you know, no problems at all. There’s always going to be some reason that it could be done better. And the classic thing is a good SEO can often figure out solution for it.

XML sitemaps are one of the classic ones where you kind of go, well, actually I want this particular XML sitemap. One of the things you can do is host it externally and do it how you want to, then reference it. It’s submitted to Google Search Console and it’ll still work. So from the point of view of being an SEO guy, there’s always going to be compromise, there’s always going to be limitations and usually any good SEO is more about the user experience than obsessing about technical limitations.

The only kind of compromise that I struggle with at the moment, and this is the one that does seem to be everywhere, is bad JavaScript and by that I don’t mean script that Google can easily render properly itself, but stuff where it just breaks all the time for Google and so on so forth. But going back to the original question, it is challenging to say we’ve got to get this live, we’ve got to get this done and accept compromise. Let’s get the business moving. Otherwise we’ll be kind of here in two years time. We’ll try to figure out how to kind of get the basics of the shop up.

James:      I think that’s such an important point as you said you earlier, no platform is perfect. No one has an endless budget and endless resource so you can’t sit there and deliberate everything and get it perfect, but you have to find compromise. I’m interested in your viewpoint on the fact that people are getting more and more obsessed with performance and speed and the whole UX element of it, you could say about time they should have been long ago, but the technology has improved rapidly to enable people to speed up pages and be more lightweight, say things like single page apps, progressive web apps, et cetera, and there are different viewpoints to them. For Single page apps, I’ve read an equal number of articles saying these are great or they’re the devil for SEO. Do you have any strong views in terms of the modern technologies and which ones are actually really positive for SEO versus those which create new problems that you have to really understand.

Gerry:       They all create new problems, so you do need to understand them. A lot of the websites I’m working with at the moment are built in React or Vue and you know, we are making sure that things are pre-rendered for example. There is especially compromise between JavaScript and I think Google are calling it universal JavaScript where you provide Google with enough HTML to get it started and it has to find the content to find the links. I know a lot of people hate JavaScript from an SEO point of view and that’s because so many developers do it wrong.

I’ve had so many discussions with developers they simply think that Google just understands JavaScript. And I’m looking at the JavaScript that’s being produced by them and I know Google doesn’t understand this JavaScript. It doesn’t understand the way you’ve implemented your links. It doesn’t understand the fact there are 404 pages in the single page app.

Progressive web apps. This technology is amazing stuff. This is really, really going to enhance the experience of, of users across the internet. For people who don’t know what this means, it means that you load like the, the top, the bottom, all of the parts of the website that never change. And then you just pull in the HTML code for the main part, the navigation part. And so, you know, it’s much faster and improves the user experience and on top of that, the browser bar still changes the URL.

Everything about it feels like it’s an old style website. It’s just faster, smoother, cleaner. And if Google comes along and loads one of those URLs, it’s still the pages you’re seeing. So there’s not a problem at all from for SEO as long as it’s all built correctly. The biggest issue is testing this properly because there could be problems with site architecture, like duplicate content issues, the lack of the 4o4 page; all these things can create serious issues for websites. And if you don’t get it right, it will be quite expensive because Google’s going to come along and do odd things like canonicalise pages to different pages.

For instance, I saw this on a huge website where Google decided hundreds of articles weren’t actually separate pages. It decided they’re all the same page and it basically said that all of these were duplicate content because Google couldn’t understand the relationships between the pages. It didn’t understand that this wasn’t a single page app and how it could find this out. This when you need to use the Google Search Console and look at all the different pages and see what it considers to be the canonical. So it was something that was easy to diagnose, but then the visibility just fell through the floor and that means that you know, their traffic drops off after a huge amount of investment because it just wasn’t perfectly implemented.

James:      I think there’s a common theme that’s come out in a few of the questions we’ve been discussing tonight, the relationship between SEOs and developers. It is hugely important from the start of the project through the development, through to the test and release and then ongpoing. It’s because let’s face it, future releases can screw up things that previously had been working fine and probably quite a nice point is to emphasise to people how important it is that the SEO speaks to the developers and vice versa.

Gerry:       Yeah, that’s usually been my biggest issue; you know it’s a hearts and minds operation. You kind of go in and you help train the developers so everybody has got the SEO perfect. And then six months, 12 months time, a few of the developers have left, a few of the new developers come in and things are crap. Suddenly you find that actually a lot of the pages templates have a key problem. It creates spider traps; it creates URL issues, duplicate content issues. Something has been injected in a way that maybe conflicts with Google’s preferred guidelines. And these things can just creep in. If you’re not constantly testing, constantly looking, it is really hard to spot everything that happens. There are a few tools out there like content King that can really help.

These tools allow you to keep an eye on everything changing all the time. If you’re agency side or client side and you’re working with a lot of different websites, being able to monitor everything is a daily challenge or a weekly challenge in itself. And if things mess up in, you can see the visibility for the website drops. There was a big commercial websites that was completely invisible at one point. The robots.txt blocked that the entire site for about a month or so. It was incredible to see that big companies often actually robots.txt out their entire site and don’t seem to notice for weeks!

Paul: One of the things that I find fascinating is the idea of doing SEO at the scale that you do. So you now work with Just Eat, and before you’ve worked at BBC. How have you found that that differs from working with a mid-size retailer and also how have you gone about creating an SEO culture in those businesses?

Gerry:       The good thing with Just Eat is that they are really, really pro SEO at the moment. The great thing is the fact that anytime there’s a project, I kind of get involved quite early on and normally it’s a case of talking to them about what they want out of it, what the implications are for SEO and just testing as we go along. It is a really, really good place from that point of view. The only downside is the fact that we release basically every day except maybe Friday because we have a code freeze on Fridays. So every day there’s code going out. So if I go on holiday for a couple of weeks, it’s scary what I’ll come back to.

From that point of view, we do use monitoring tools like SEMRush. We use Deep Crawl to monitor huge amounts of pages constantly. And I use Screaming Frog constantly. Every time I see something interesting, this looks a bit different, I run Screaming Frog over it. I run a few of the tools over it. We use Lighthouse in the cloud, which means that we’re constantly monitoring hundreds of pages, a great speed auditing tool. And all of these results goes into Big Query. It is a great way to monitor hundreds and hundreds of different pages. At scale, not a lot really changes. It’s almost the same. It’s just kind of making sure that nothing breaks faster.

James:      That makes sense. Really interesting because doing everything at scale brings in all the challenges, especially around all the different stakeholders involved. Gerry, that has been really interesting and I’m sure we could probably carry on with loads of questions.

If anybody wants to follow up with Gerry on this you can hunt him down through social media, @dergal on Twitter. Just a quick parting thing before we wrap up, it’d be really useful for you to just spend a little time telling everyone about Take It Offline. So I think anyone who’s interested in SEO, expanding their knowledge and connecting with Gerry and other smart people in the SEO world might be interested in taking a look at what you’re doing and the events you’re running.

Gerry:       Oh, amazing. So Take It Offline is something which started off as a small pub meetup type thing, which apparently every meetup does. We’d decided that it would be great to basically talk through with local businesses and agencies about what their problems are, how to handle them. And it’s kind of grown a little bit from there. We’ve done more classic presentation type things, but it is very much about how do we get people talking. It was how do we get the actual experts talking to other experts and talking to people who’ve got real problems. We managed to do an event in Amsterdam a couple of weeks back where we ran an un-conference style, we stole the idea from Measurecamp.

The biggest problems, the biggest challenges that’s what we focus on. We’ve learned that often the best conversations aren’t the presentations, but the conversations after the presentation when you actually talk to the presenter or the people who are on a panel and say, “Hey look, I appreciate what you’re saying but I found this, what do you think about this?”.

James:      Excellent. Thanks for sharing all that. I came to one of the London Take It Offline events and it’s really useful, I met some very smart people. Thanks for giving up your time and for sharing the insights Gerry, we always appreciate it and great to chat to you.