Keira Davidson (00:01):

Hello, and welcome to the TechSEO Podcast, where we explore technical SEO and everything that comes with it. My name is Keira Davidson and I’m an SEO consultant at SALT. Today I’m joined by Adriana Stein, founder and B2B SEO consultant at AS Marketing. Welcome to the podcast today, and how are you?

Adriana Stein (00:20):

I’m doing awesome. Thank you so much for hosting me. Super excited to be here today.

Keira Davidson (00:25):

Definitely. I can’t wait to speak about search intent and everything that is involved in that. But before we get into the ins and outs, I always like to get to know a bit more about our guests. So to kick things off, how did you get into SEO? How did you manage to get to where you are today?

Adriana Stein (00:46):

Yeah, it’s kind of a crazy story. I’ve had a bit of a crazy career I would say, because I didn’t start out having the intent … speaking of search intent. I didn’t have the intent actually to start out in SEO or even in marketing generally, it just kind of happened on accident. So I’m originally from the US, from Oregon, but I’ve been based in Hamburg Germany for six years now. I think it’ll be six years on April 4th, so nearly the anniversary of my expat move. And I originally moved here to actually do my master’s degree because you can do them for free in Germany, which is amazing in contrast from the US. But long story short that actually didn’t end up working out, which was a blessing in disguise because I started out as sort of like an intern for a couple German companies and working in the marketing department. Because when I first moved to Germany, I was in German language school for a total of about nine months.

Adriana Stein (01:52):

So my German was pretty decent and that was kind of a in-demand skill, being able to speak and work in German, but do some content writing or translations or something like that in English, because there’s a lot of German companies who want to market to the US or UK or countries like this that speak English. So basically that was just the first job type I got, because that’s what fit my skills. And they happened to be in the marketing department. And I got a lot of training there, especially in SEO in content marketing, because when you can do that from a really local level, that’s really the best possible goal that you want.

Adriana Stein (02:34):

And I kind of realized, after I spent my first two clients that I worked with as a freelancer, these were these kind of two internships I did, I realized a lot of German companies actually needed these skills. So it just grew from there to where I was growing my freelance client database. And then that got quite successful as well, and so I decided to scale up into an agency and that’s when AS Marketing was born. And now, still true to the original intent behind what I did, that’s what we specialize in is, helping companies with a very localized approach to their marketing strategy and typically also with an SEO first approach because SEO is still my biggest passion, and I think it’s the majority of our team’s passion as well. So even though we do provide holistic marketing, definitely our bread and butter is SEO and localized SEO for global companies.

Keira Davidson (03:42):

Okay. So typically then, as a founder of an agency and consultant, what does an average day look for you?

Adriana Stein (03:53):

Yeah, that’s also kind of a funny question because it’s changing a lot. When you are growing a boots strapping business. So, boots strapping basically means no investment, just doing my own thing, winging it, it changes a lot. My world really changes a lot. In the beginning it started out more as sort of like a project manager or account manager for the clients, and then as our team grew and we got some really experienced project managers, then I’ve taken my hands off of project management, which has been really great because now I have more time for things like being on this podcast and to work really on our brand strategy, just ensuring that everything financially is balanced. That’s one of the most difficult things about scaling a business.

Adriana Stein (04:43):

I don’t even want to say an agency because I think every business feels this, that when they’re scaling you kind of, you have to always find this balance between, what are our sales and marketing and operations budgets? What should we charge clients? How do we run those projects at a profit? There’s a lot of financial elements in there that I didn’t plan on having to become a expert in. But I have to say it’s a good problem to have.

Adriana Stein (05:08):

So that’s kind of where I’m at right now. Just mainly overseeing the general financial balance of the business, working on administration things and definitely building our brand now. Which is super fun because now it’s kind of like the next step and I hope we can kind of start to make our mark in the world a little bit.

Keira Davidson (05:28):

That’s so exciting then. So you had such an opportunistic sort of time to really sort of grow and showcase what you do. So the plan for today is to talk about why search intent is the most underutilized and powerful element of SEO. And I think the best place to start on this is to explain what intent is and to elaborate on the different types of search intent.

Adriana Stein (06:02):

Yeah. So the reason why search intent definitely can be described as the most powerful element of SEO is because, when you connect the content to the keywords, that’s really where you are going to find that SEO can have the biggest impact on revenue. And so if we start by defining search intent. Basically the idea behind search intent is, anytime that someone Googles something or they use another search engine, they’re looking to find a specific type of information. They have a question or they need to know something and they’re typing in a certain phrase or set of words to find that information. And so search intent, understanding search intent, is the process of trying to find the information that the person is looking for and then create that information from within your marketing department. And it should be in a way that informs that person properly. So if you’re matching search intent, then basically you’re matching the information that you provide as a company in your content to the information that the person is searching for.

Keira Davidson (07:19):

Yeah. And I think, in my experience, it’s really important to ensure that you are matching the intent, as if you don’t, people aren’t interested, that’ll move on the next thing, they won’t click on you. I think one thing is that, the intent can be defined in different types.

Adriana Stein (07:42):

Yes.

Keira Davidson (07:43):

I’m thinking there’s four?

Adriana Stein (07:46):

I think it depends on who you talk to on how many different types there are. There are some categories and some rationale that you can put things into, I think, informational and transactional or … I don’t remember exactly, but I think the most important thing that you want to consider is, when someone is searching for something, what type of information are they looking to find? So I can give a more concrete example. If someone is typing in a question that’s like a, what is. What is something? Then they probably are not looking to buy something right away. They’re just trying to understand what something is. How do I understand this concept? So a search intent mismatch would be that, if you tried to create like a sales landing page for a, what is type keyword, that really wouldn’t make sense because that’s not the information that the person is searching for.

Adriana Stein (08:42):

You’d rather want to start with just defining, what is the thing that they’re searching for? How is this information going to be helpful to them? What else do they need to know surrounding this topic? And then that’s going to bring them deeper into what’s known as the sales funnel. So search intent and the sales funnel are super connected. For those that are newer to the sales funnel, basically there are three main categories. Sales funnels again, can vary dependent on who you talk to. But there’s always awareness, consideration and decision.

Adriana Stein (09:18):

So awareness. If we talk about a, what is keyword, that’s just someone who’s becoming aware of a topic, so they would be considered at the top of the sales funnel. They don’t necessarily have any purchase intent yet. But if you can inform them in the correct way about the concept that they need and maybe connect them to some further helpful information, some use cases or things like that, so then they can become more aware of their problem. Then kind of start to understand, okay, then I need to solve this problem. And that’s where consideration comes in.

Adriana Stein (09:52):

So consideration is where, maybe you’re comparing different solutions to your problem. So for example, let’s say that, first you were starting with the search term, what is SEO? Since we’re on a SEO podcast today. What is SEO? So that’s going to be in the awareness stage. And you want to get better at your SEO strategy in your company, so probably you need a tool. I mention Semrush. So maybe once you understand what SEO is and that you need a tool in order to get better at it, you would start comparing tools, that’s consideration. So maybe you look at Semrush versus Moz versus Ahrefs. There’s lots of tools out there. So here, maybe you would have some sort of … you would look at some sort of guide on, best SEO tools. That’s helpful for the consideration stage, and that’s a very common keyword as well.

Adriana Stein (10:48):

And then maybe you would have a decision level content piece, that’s more focused on SEO software. If you are Semrush yourself or Moz yourself, then you would be creating this kind of what’s called, bottom of funnel or high purchase intent page that focuses on capturing people who are basically ready to make a purchase decision. So it’s all really aligned, this process of the sales funnel and search intent. And so really at the end of the day, it matters because you have to provide the person with the correct information that they’re searching for. If there’s some sort of mismatch there, then they’re not going to be interested in your brand at all. There has to be … you have to provide a level of help first and a level of information first, before you can sell stuff. Just direct selling doesn’t really work anymore.

Keira Davidson (11:44):

So essentially without intent, you are negatively impacting the site’s opportunity, revenue opportunity, which is why obviously it’s so powerful and a key element of SEO. So in terms of commercial pages. I find that there are certain words that you want to include, because they kind of signal that this is a transactional sort of, you can buy something, it’s a product page. So I would usually use, buy. Or if it’s something online I’d put maybe, buy online, or something like that. Do you have any other go to keywords for the different intents?

Adriana Stein (12:31):

Yeah, absolutely. So at AS Marketing, because we’re mainly working with B2B, especially tech, then anytime that you find keywords that basically exactly describe your product, then that’s what your high purchase intent keywords should be. That’s what you should use on your product pages. And we do find that one of the ways that you can really scale this out is to find product synonyms and then match them to different use cases. So there are a lot of different ways that you can use an SEO tool. You can use it for keyword research. You can use it for competitor analysis. You can use it for understanding your domain metrics. So those are all basically use cases for a certain tool. And the angle really is just to find out all of the different ways that you can talk about how this product is useful. And then those can go into product pages.

Adriana Stein (13:27):

However, there is the caveat that you shouldn’t have this very loaded stacked site with so much content that is difficult to look through. So you kind of have to piece out, okay, what are our most important product related keywords that we know are really the closest match to what our product is, what we call it, what our audience knows what it is. And then that’s going to go on, let’s say your evergreen or your … I don’t say permanent, because content’s never really permanent, so mostly permanent content. And then maybe the rest would go into the blog, that you’re kind of elaborating on the topic a little bit further.

Keira Davidson (14:05):

I don’t know whether … about you, but I personally find having content that meets the intent of each different stage of the funnel is really important. But then also using that content, it’s like a mini hub and spoke to then link and feed customers, users, up through the funnel. So then eventually it results in a transaction or an action, which then in turn benefits the company.

Adriana Stein (14:36):

Yeah, absolutely. I mean, any type of marketing activity that you do, regardless of SEO or something else, there should always be intention behind it. I’m using this with intention. But there should always be intention behind what you do. So one common mistake that we find with our clients is, everyone has kind of come to the conclusion by now that doing content marketing is worth it, having a blog is worth it, having generally nice content on your products is worth it. But sometimes it’s not really done with intent. And what I mean by this is with purpose.

Adriana Stein (15:14):

So it’s really important that you, if you put in the time and the resources, i.e. the money into creating content, that you have some intent behind it, some purpose behind it. That it connects with your audience. That it matches a certain stage of the sales funnel. That it does follow the customer journey that your audience goes through when they’re making that purchase decision. So that they basically, from the top to the bottom of the sales funnel, they have that information at a very easily understandable and easily findable flow so they can feel like, “Okay, well that was so simple for me to find the solution to my problem. So I’m going to go ahead and buy this thing.”

Keira Davidson (15:55):

Mm-hmm (affirmative). Just out of interest, do you find that using the likes of FAQs on pages or having a dedicated FAQs helps customers on those journeys and helps to match the intent of certain queries?

Adriana Stein (16:13):

Yeah, that’s a really good point. So, one thing that we try to do quite often on our projects, because we have SEO and typically performance advertising projects that are combined, is we create pages that actually function for both. So you can create a page structure that, it has those conversion elements at the top. Like your hero conversion, whatever is. Book a demo, or book a pretrial, or talk to a sales person, et cetera. So you can still use that and put your social proof or your statistics or your data towards the top so that it could still work for paid advertising. But then you can also optimize the FAQ section at the bottom for SEO as well.

Adriana Stein (16:57):

And FAQ is a really perfect space to rank for, People Also Ask. So this is the space when you Google something and then you see that there’s these boxes that have related questions, you can get a featured snippet which means, appear under those questions by filling in the FAQ section of your content. So whenever you’re doing keyword research and you understand the search intent behind that keyword, you can actually just Google what else is showing up. And the People Also Ask search words, and then that’s what should go into your FAQ section as well.

Keira Davidson (17:35):

And then, so you mentioned around your keyword research and making sure the intent aligns. On typically speaking, would you use a tool where the intent is highlighted or identified, or would you spot check certain terms? Because I’m getting, you naturally have an understanding of what kind of intents are relating to you for certain terms.

Adriana Stein (18:08):

Yeah, so I think a tool can help you maybe if you want to summarize data. Like in Semrush, maybe we might tell a client, 30% of your keywords are informational search intent or something like that, if you’re doing some sort of report just to kind of look at. Are we creating content that follows through the entire sales funnel? Are we creating content that is more transactional so that it can lead to conversions? But I think actually, still quite a lot of the process is manual, because a tool can’t really understand the strategy behind your business. And it also doesn’t know your site structure, it doesn’t know exactly how your products work. So you can use it as a starting point, but we typically tend to do a lot of that still quite manually. Which I think is especially beneficial when you’re looking at how keywords vary across different regions.

Adriana Stein (19:05):

So you might have a different intent or a completely different search engine results pages for the US versus the UK, for example, and then you need to make sure that the content that you create matches the regional search intent and what’s really appearing there. So a lot of it is still quite manual and it’s worth it to check that. Because a third party tool again, it’s not going to totally understand how your product functions. It’s just making some guesses. Even this categorization in Semrush, I think is only new from the end of last year. So it’s still pretty rudimentary.

Keira Davidson (19:44):

Mm-hmm. and in terms of checking it, would you do it on … would you check every keyword that you’re looking at or would you just be like, “Oh, I’ll check this one. Oh, and that one.”

Adriana Stein (19:57):

Yeah. I think that’s a question that our team discusses quite regularly when we do something an SEO audit. We’re always like, “How many keywords should we check?” But a lot of it has to do with how big and developed the website is. So if you have a new website or a really small website, then probably you do want to actually check quite a bit of the keywords and what we call serv-analysis. So checking what is appearing for those keywords. So that when a new website or a starter website, it may be difficult for them to invest in those resources to create content. So you want to make sure that is as efficient as possible. And when you check the search and the search intent behind the keywords and you know that you have a match there, you can basically ensure that time and that budget is being used efficiently.

Adriana Stein (20:51):

When you have a bigger website though, that maybe you’re already on 200-300 pages or something, it’s simply not possible. It’s too much manual labor. But what you can do is try to focus on the general topics as a brand that are relevant. So sometimes people use the term, topic pillars or topic clusters, in this case. We at AS Marketing, we might define that a little bit differently than other SEOs do, but in our case, we are talking about what topics in general are relevant for this brand, relevant for their products. And then how do we create content around those topics that holistically covers the topic and also follows the entire sales funnel?

Adriana Stein (21:37):

So you can do some general keyword research there and just look at what’s known as the seed keyword or the head keyword. So it may be something that’s a high search volume kind of a little bit vague keyword about what is the search intent behind it, like a two word phrase you don’t exactly know. But you can dig deeper there into the long tail versions and then just create a keyword list from that. And then you can still get a pretty good idea that that’s going to match what you’re looking for there.

Keira Davidson (22:09):

Yeah. I think there are also occasions where, for example, a commercial page, such as a product page, and then an informational resource page, both appear in … I’m not saying it’s the same site, but both appear in the search results. So the search results are quite mixed. It might be recipes, videos, product pages. How would you go around deciding whether you decide to go for that intent or whether you decide to completely miss that opportunity or pick between the informational or commercial page to go for, to target that?

Adriana Stein (22:50):

Yeah, that’s a really good question. And actually we had a recent project where we actually faced this issue and it was a larger website. So it was not worth going through every single keyword to really check if it’s an exact match. But, for example, one of the pages we came across this was with the seed keyword, urban mobility. So urban mobility, that can mean a whole lot of things. And of course for that … the search for that keyword are, some of them were product pages, some of them were blog articles, some of them were ultimate guide type things. And that’s when you can tell that, actually this keyword is quite vague and that’s why Google itself even can’t understand the search intent. But we know that, because urban mobility for this company was a very, very relevant brand related topic. Then we knew for their strategy that this is worth it.

Adriana Stein (23:46):

So what we did is basically just expanded on the keyword research. You always want to start with this seed keyword such as urban mobility, and then kind of fill in the rest of your keyword cluster. So semantically related keywords to urban mobility that do have more of an exact match search intent. So, for example, we would go from urban mobility to urban mobility planning software, or urban mobility simulation software. Or something like this that’s a little bit closer match. But you still over time, when you create content that fills in this entire topic cluster you can start just a link for a keyword like urban mobility. Which in this case was worth it for this brand because they wanted to be known for this topic. So that’s where this strategy bit comes through that you have to understand, what is the strategy of the business. And then if it’s a worthwhile topic for them, even if the search intent is a little bit vague, then it can still be definitely super valuable to create content for [inaudible 00:24:55].

Keira Davidson (24:55):

So from my understanding then, intent is something that should be considered throughout a whole SEO strategy. It shouldn’t be like, “Oh, well, think about intent at the start when we’re doing keyword research.” And then you’ve looked at it, you’ve put it back down, and then you run about creating content. And obviously if you create that content without that intent in mind, that content might not be valuable, it might not have the purpose. So in a sense it’s wasted or resources not utilized as best. So no matter where you are in the strategy, you should be thinking about intent.

Adriana Stein (25:33):

100%. I think it’s a daily thing in your SEO strategy that you should really be looking at, the search intent. And always make sure that your content has a purpose and it matches what your audience is looking for. I can give another example there that, is a really common problem that we run into working largely on B2B projects is, sometimes there is a mix between B2C and B2B search intent. Or it’s kind of hard to tell which is which, and for a B2B company is this phrase really worthwhile for them. Or is it mostly end consumers who are looking for something different and then it’s not worthwhile. So one thing that we tend to do there is, again, this serv-analysis, you can tell if you’re … especially if you’re reading meta descriptions and Google starts coming up with phrases, because Google actually changes meta descriptions quite heavily, automatically now, sad day for SEOs who wrote them manually for so many years.

Adriana Stein (26:35):

But you can see if it’s pulling up a bunch of meta descriptions that sound like it’s talking to just an individual person. You can probably get, “Okay, maybe this is a B2C search. This is an end to consumer search, not a business related search.” Or if you get meta descriptions that say like, something for your business, or grow your business, or it helps you with this with your business or something. Then you can see, “Okay, this is a B2B type search. People from businesses are looking for this.” So then it’s worthwhile to check and create your content on.

Keira Davidson (27:09):

Yeah, definitely agree on that. So I have one final question for you. Where’s the best place people can find you on social media?

Adriana Stein (27:22):

So I’m most heavily active on LinkedIn. I think you can just look up my name. I have a LinkedIn handle with lots of numbers in it, so I won’t say that word for word now. But I’m also on Twitter as well. Adriana K. Stein. So feel free to reach out if you have any thoughts or questions or just want to chat, then I’m all ears.

Keira Davidson (27:44):

Perfect. So thanks again for joining us today on the podcast. We’ll be back in a couple of weeks for your next installment of Technical SEO. That’s all for this episode. And we’re always looking for other experts to join us and give us a fresh perspective on technical SEO. If this is of interest to you, reach out to myself, Keira F. Davidson on Twitter, and we’ll get something arranged.

The post S4E1 Adriana Stein, Why search intent is the most underutilized and powerful element of SEO appeared first on The TechSEO Podcast.

Keira Davidson (00:23):

Hello and welcome to The TechSEO Podcast, which is hosted by myself, Keira Davidson. I’m a senior SEO executive at SALT.

Keira Davidson (00:31):

This episode’s guest is Katherine, who is the owner of WA Strategies. It’s so great, you joining me today. I can’t wait to get into all the nitty gritty of migrations. How are you?

Katherine Watier Ong (00:45):

I’m good. Thanks for having me. This is going to be fun. I love chit chatting about SEO.

Keira Davidson (00:51):

Yeah. I can’t wait to get started. I think from what I’ve noticed so far, is that SEOs, their background differs from each individual. So, I’d be really intrigued to know how you got into the industry.

Katherine Watier Ong (01:07):

Yeah. So, I actually got started with marketing really early. It’s kind of odd, but I planned my first conference when I was 13.

Keira Davidson (01:15):

Wow.

Katherine Watier Ong (01:15):

No joke. I negotiated with the hotel and 200 kids showed up for the first teen conference in the Mid coast Maine area. Anyway, I continued event planning through high school and started working on national and state conferences. And then I founded my first nonprofit, my only nonprofit, when I was 16. It’s called The Rainforest Challenge. So, I got press coverage from that and grant support and in-kind support. We became speakers at the first international Youth Environmental Summit in Loveland, Colorado. Anyway, so all that before I hit college. It was bonkers. Then in college, I actually got a job at a PR shop. I mean, I was still doing marketing stuff. Then in college I just lucked out. So, it’s 1994 and the college I went to had a build your own website class. There you go.

Keira Davidson Watier Ong (02:06):

Wow.

Katherine Watier Ong (02:06):

Yeah. That was back when the exciting thing on the White House’s website is that Socks the cat would meow if you clicked on it. So it’s that era. There was no Dreamweaver or anything. We were uploading stuff via FTP. So yeah, early days of website. No, what’s weird is how long it took me to get to SEO. I studied social psychology in my undergrads. Really fascinated on how to persuade people, definitely marketing PR focused.

Katherine Watier Ong (02:33):

Then when I got to DC, still same thing. I went to start going to Georgetown for my master’s, but I’m still working full time in marketing type roles. So, I end up at the Points of Light Foundation because I was really involved in volunteer stuff, so I ended up there. I’m the director of marketing and sales for 1800volunteer.org, which is this, basically a home built CMS system and frankly, it wasn’t built to scale. It was built without a business requirements document, so there’s all sorts of issues. But anyway, I’m supposed to sell this thing because it’s a volunteer management system and underneath it are all these websites for these different volunteer centers around the country and ultimately the volunteer opportunity.

Katherine Watier Ong (03:15):

So envision it, it’s like a match.com for volunteers. So the opportunity which is, come to our shelter, volunteer with cats, whatever, in this certain geographic area. That is not posted by me, it’s posted by the shelter and the shelter works with the volunteer center. So multiple steps removed from the actual opportunity that needs to be optimized.

Keira Davidson (03:34):

Wow.

Katherine Watier Ong (03:35):

So a lot of the people running the volunteer centers were actually, frankly, senior citizens. They’re three steps away from retirement or out of retirement, come back and run the volunteer center. So I started training grandmothers on SEO. So I joke because they were the ones who had to understand it enough to make sure that it wasn’t posted as a volunteer docent, and instead it was volunteer and museum guide like something somebody would Google, right? So that was part of the challenge.

Katherine Watier Ong (03:58):

The other part of the challenge there, and this is why I really got hooked on SEO, is I was really focused on the sales part because I had a quota. So here I am trying to sell this thing and not so much on the marketing part because that was sort of secondary. Well one day, because I told you this thing wasn’t built to scale, right? So the developer’s tinkering on the back end and I don’t know. We’d already lost this site once because the PR person at Points of Light decides that we should be announced at the end of Extreme Home Makeover. Like, “If you want to volunteer with families like this one, go to 1800volunteer.org.” It tanked, because it wasn’t ready for anything like that.

Katherine Watier Ong (04:33):

Anyway, so the CFO comes in and he goes, “Hey, we’re not on Google. Why are we not on Google?” I’m like, “Oh I have no idea.” Because my previous SEO experience was 10 HTML pages kind of website and here’s this home built, I don’t even know what platform it’s on kind of thing. So, luckily I didn’t panic, but I said, “I don’t know, because this is a level of site I’ve never worked on before, but you send me to SES Chicago-” This dates me, right? Because it’s not even a show that’s around anymore, and they had a nonprofit track.

Katherine Watier Ong (05:00):

I said, “You send me to the show, I’ll figure it out.” Okay, so fine. I go to the show and they had a live audit session, which they don’t do anymore, which is a bummer. But it was a live audit session, like 200 people in a ballroom, right? Who wants their site audited? I’m first up, I forget who was on the panel up front. I wish I could remember. They say, “Okay, well I noticed a couple things wrong with your site. One, you’ve got multiple redirects going on, including a meta refresh redirect.” Because it was a phone number too, you could call it. So we had the dash URL and the non-dash URL. So that was part of it. They’re like, “And so you’re redirecting like porn sites do.” I’m like, “Okay, it’s good to know.” Then they also said, “So there’s this little file called a robot text file. Tell the robot to go away.” I was like, “All right, good to know.”

Katherine Watier Ong (05:46):

Anyway, I spent five days just absorbing as much as possible around how to fix this website and I came back with a full plan, and then I got hooked. I don’t know why it took me that long. My mom gave me a Commodor 64 when I was 13, because I grew up in Maine in the deep winter, there’s nothing to do. This Commodor 64 back in the day, the only thing you could do with it is program. I don’t know if it was C+ or what, but she got us a programming book. My brother and I would spend forever- You can save by the way, and you would just write pages and pages and pages of code, and if you got it correct, the thing would make a sound. It would meow or moo like a cow or whatever. That was thrilling. So I mean, I was coding early, but for whatever reason, it wasn’t until I was mid-twenties that I finally found SEO.

Keira Davidson (06:29):

Wow. That’s crazy.

Katherine Watier Ong (06:31):

I know, and I’ve never gone back. I’m like, this is my jam.

Keira Davidson (06:37):

Of all the stories I’ve heard today, I don’t think I’ve ever known anyone to fall into the industry at such a young age.

Katherine Watier Ong (06:44):

Yeah, right? Because I was- Well, yeah. I mean, I was coding when I was 13 for a hot second, coding again when I was 18, right? I built my first newsletter then too, because that’s when you could do that kind of thing. 18, 19, whenever that time was when I was going college. But yeah, I was in my, yeah, my mid twenties when I found SEO. Somewhat early in the industry for sure.

Keira Davidson (07:07):

That’s crazy. I still can’t can’t believe you were coding at 13. I’m trying to remember what I was doing. I was probably just watching TV or playing on my bike or something.

Katherine Watier Ong (07:15):

I know, but this is before global warming. So in Maine, the snow was deep and it’s multiple days. You’re stuck inside with nothing to do, so I just put it in context

Keira Davidson (07:28):

Still, really impressive. So can you still code today?

Katherine Watier Ong (07:31):

Oh no. No. So the funny part is, is that when I started my program at Georgetown- So anyway, I started my program at Georgetown. It’s a master’s. It’s a build your own master’s program. It’s called the Communications, Culture, and Technology program. I eventually turned it into marketing technology and using technology to market. So it’s like online marketing plus marketing with technology. I wrote a thesis about consumer adoption of wearable computers. It was actually the first study of that back in 2003. But I was taking all that out in loans and I thought, “My gosh, I’m going to have to make money to pay off this Georgetown degree. So what am I going to do to make money?” I thought, “Well, maybe I’ll be a webmaster. I coded before.” Anyway, that’s when I realized that I’m actually much more of a strategic person.

Katherine Watier Ong (08:14):

I’m very much big picture and when it comes down to that level of detail, that’s really tough for me. They offered a cold fusion class, because that was the only platform you could learn on. But I really thought that in order to be good at online marketing, I still do think this, I needed to understand how database driven websites work. Right? That’s cold fusion. If that was my only option, I guess it’s cold fusion. But anyway, because I was the graduate kid in that class, they didn’t give me a partner, because I was literally the only graduate person, all the other undergrads were paired up. So here they are building a database that pulls stuff through to the website, but you’ve got somebody to troubleshoot the code with you. Well they decided to make it more challenging for me and let me do it by myself. Cold fusion is awful because any little moment that you’ve missed some piece of punctuation or something, the whole thing doesn’t load.

Keira Davidson (09:01):

Oh God.

Katherine Watier Ong (09:02):

So painful. So painful. Anyway, that was my big eye opening moment where I’m like, “Yeah, I’m not a developer. I’m so not.” My brother can, my brother actually does. He does UX development, but not me. That’s not my mindset.

Keira Davidson (09:15):

That is so interesting. Such a really cool back story. That is definitely not what I expected. So I think let’s just get stuck in with the whole migration side of things. So I’m aware, we’ve just been previously talking and you’ve been doing like a really large scale migration. When you were coming to plan that, what were the key considerations in your mind that were needed prior to migrating?

Katherine Watier Ong (09:48):

Sure. Yeah. So this is actually, I was explaining, this is my first migration. Usually I come in after people have migrated. So I do a lot of traffic drop analysis or why do we not have the traffic we used to have? Kind of analysis and help us fix that. So that’s usually when people bring me in, but I do have this long term client that referred me to another client and they were migrating platform. So I’ve ended up working with a few associations that have academic journals.

Katherine Watier Ong (10:14):

So this is one of those and they were migrating from an old platform that’s not very SEO friendly and frankly, the developer’s not very nice. I don’t know how to say that much more delicately, but so they decide to move off that platform to a new platform that supposedly is more SEO friendly. But they have 18 different journals that they were migrating. 18, 17, 18, I think, and some of them have been publishing since the beginning part of the century and they’ve digitized it all. So I think we figured that the old site, because it had a really funky URL structure, lots of duplicate content, was around 7 million URLs and they migrated to about two and they have 30 million back links that we had to map. So I went from no migrations to that size of a site, just because I thought, “I’ve been in SEO for 17 years, I’m bored.”

Keira Davidson (11:11):

That was a big reason.

Katherine Watier Ong (11:13):

Let’s do something challenging. Yeah, I mean, part of it was that, but then the other part is that I’ve discovered this Tech SEO women’s Slack group and they’re super supportive. I thought, this is the first time in my career, and I’ve been in SEO for 17 years, this is the first time in my career that I feel like I have people that can help me. I’ve always been in-house, the only one or, I was at Ketchum running the online marketing analytics team there for five years. But again, I eventually brought on some other SEOs that could help me. But for a while it was just me and a bunch of junior kids I trained. So again, it was kind of just me. This time I feel like I had support. So I was like, “I think I can do this, and if I can’t do it, I’m sure somebody in that network could give me a hand when I need help with something.”

Keira Davidson (11:54):

Yeah, I definitely agree with you that the community that has been built is amazing. If you ever have any questions, or concerns, or just need a little pep talk, there’s always someone in the group that will help you out.

Katherine Watier Ong (12:07):

Yeah, it’s been really amazing. I did run into two moments where I got stuck, I didn’t really know what to do. At one point somebody literally hopped on the phone with me for an hour, because I had to get some quick memo back out to the client about something that was kind of anxiety producing and, yeah, she walked me through for free just to help me out. It was amazing. So I mean, I try to help other people out as much as I can in that group. Every day I scour for questions I can answer.

Keira Davidson (12:31):

That’s amazing.

Katherine Watier Ong (12:32):

Yeah.

Keira Davidson (12:35):

Areej has done an amazing job there, so I couldn’t congratulate her anymore. She’s done really good.

Katherine Watier Ong (12:42):

Yeah. So I mean with this migration, it’s a bit more challenging because I was still getting my feet wet with Google Scholar and how that interacts with Googlebot, because these are academic journals. I learned quite a bit over the last year about how that works, because as an SEO, you can’t meet with a Google Scholar rep. There’s very little published online. I’ve now published an article about the difference in case you’re curious, you can go to my website wostrategies.com and read it. It was quite a bit about that because the first web platform pushed back on a lot of the changes, because they’re like, “Well we have a Google friend.” Because they’re a Google Scholar partner, but I’m clearly seeing stuff that I know is causing problems in Google search console for Googlebot. So I’m like, eh.

Katherine Watier Ong (13:22):

A lot of these, I mean the scholar part’s important, don’t get me wrong, it’s very important for them. But the vast majority of their traffic is coming from big old Google, Google search. So you can’t do stuff with Scholar that’s going to bite your nose with Google search. That doesn’t make sense for these folks. They’re going to lose a lot of traffic. But the big thing that I’ve seen with a lot of these journals, because obviously I’ve done some competitive analysis too, so I’ve seen the two I’ve been working on plus a handful of other competitor ones and I’ve seen their back links and traffic patterns and that kind of thing. We know when some of them have also migrated and stuff. I just don’t think a lot of these platforms help them with 301 redirect mapping, because you can see when they move and how much traffic they lose, unfortunately.

Katherine Watier Ong (14:03):

At that kind of scale, that was one of the biggest lifts for me was to make sure that we- I mean, these are very- I mean one of these journals, a couple of them, published COVID research. So it’s really important to make sure that that stuff gets right back into Google search for many reasons, right? They’re linked all over Wikipedia. They’re just very high authoritative stuff, so keeping those back links was probably one of the biggest challenges. The other part is I don’t think they’ve had an SEO shadow their work. So just making sure there weren’t any other crawl issues and they had sort of a front end- Some stuff was powered by JavaScript and it’s not angular, but I’ve audited enough angular JS1 sites where I get very nervous about JavaScript usage. So I was very obsessed about making sure none of that got in the way.

Katherine Watier Ong (14:55):

It didn’t, we sorted it. I didn’t, but I was constantly checking that. We’re still trying to fix some stuff. The old platform had… It’s a platform basically on top of Drupal and I’ve worked on a bunch of federal websites, so I’m very familiar with Drupal. So the site map’s like what you would expect, it’s a plugin. But this new platform did not have XML site maps, so we’ve had to-

Keira Davidson (15:17):

Interesting.

Katherine Watier Ong (15:18):

Get them to implement that. Then there’s issues, it’s not quite as what we would like at this point. I don’t think it’s even auto updating. So anyway, we’re still working on some of those issues too. For a site with this many millions of URLs, the site map’s really going to help with discovery. Yeah. So those were the things that I was obsessed at. Then the scale of checking these redirects, obviously we’re doing patterns, but it’s a new platform and they searched through their database in order to pull the articles out. Then there’s different views per article depending on whether or not you’ve paid for it, it’s freely available, that kind of stuff. So the mapping was more challenging than I think I even expected.

Katherine Watier Ong (15:57):

We probably had 1300 root patterns, which we called sample URLs. Then I couldn’t check all 18 different sub domains for every single one of those patterns. So I ended up randomly pulling three or four articles per pattern. Then we finally got to a point where we just started pulling everything that wasn’t working and testing all of that. So on the next project, I would certainly start first with building a backlink database using BigQuery, which is what we ended up doing. But that was more near the end of the projects. Really bummer, because I would definitely do that at the beginning. Because then you can query with RegEx and some other things when you’re trying to look for specific patterns and see if they’re getting duplicated on a different sub domain.

Keira Davidson (16:40):

Wow. That is- Considering you’ve never done one before and you’ve just jumped into the deep end, that is crazy what you’ve ended up dealing with.

Katherine Watier Ong (16:51):

Well, I also got help. I mean, yes I’m solo, but I have a couple technical SEOs that can help me out when I just get too flooded with volume. But then I also knew with this project that I would need to crawl in the Cloud, which I’d never done before. I need to do BigQuery, that kind of stuff. So I actually have a friend who works on Big. His day job, or his day job used to be working with big hotel websites, but he’s more of a data analyst kind of person. He can code Python. So I brought him on board kind of part-time to help me with some of the more technical stuff from setting up BigQuery and some of the other stuff, and he tried some Python stuff for me.

Katherine Watier Ong (17:26):

But then I also have a Google analytics data analyst that I love who I’ve been working with. She actually never done BigQuery either, but she was at the point in her career where she was really excited about doing something big and she’s helped me with a bunch of the federal websites. So she’s already been working with sites that are half a million, maybe even a bigger, so she was ready for the next step too. So yeah, she helped me with a lot of that stuff. I wouldn’t say that I figured it all out myself. There’s only so much of me to go around, especially with a pandemic and two kids at home. It’s just like [inaudible 00:17:56]- At some point you get help.

Keira Davidson (17:59):

Yeah. I’m not surprised with what you were saying about this project. You’d have been spreading yourself very thin for sure.

Katherine Watier Ong (18:05):

I think it would’ve been impossible. Also, got to ramp up fast enough too. But, yeah.

Keira Davidson (18:12):

So Jeanette, you mentioned about obviously the backlinks being a main priority in trying to keep as many of those, how did you approach this?

Katherine Watier Ong (18:23):

Keeping the backlinks?

Keira Davidson (18:24):

Yeah, trying to. I can’t imagine on a scale of that large, it’s not like you can just reach out to the people, asking them to update it. Instead, I’m guessing you just basically redirected all the pages and tracked it that way.

Katherine Watier Ong (18:38):

Oh, yeah. Yeah, I mean, so for this one, it’s a long story, but they also had some issues with some knowledge graph stuff in Wikipedia, because some of their journals were not listed in Wikipedia. They probably should be, and so I actually introduced them to the Wikipedia coach I work with. I was actually on- It’s the long story, but I was actually on a panel with Wikipedians about PR and Wikipedia back in the day. So I know some people that are legit, legit Wikipedia people. So they’ve been helping this client improve some of their Wikipedia pages. So some of those got updated manually or in the process of being updated manually, but everything else was a redirect.

Keira Davidson (19:18):

Oh, that’s cool. I’m surprised that you… I didn’t expect you to go down the route of doing some manual. I just thought it might have been too time consuming, but like you said, you did have some help there.

Katherine Watier Ong (19:29):

It was for knowledge graph purposes because for some of their journals, they’ve got a knowledge graph appearing and other ones they didn’t and they wanted to fix that. So that was the reason they were doing that. Now I have, when I launched healthit.gov when I was at Ketchum, that was also- It was actually a redesign, now that I talk about it. So I guess I was on board. They went from the Office of the National Coordinator, whatever page they were on, and we migrated that to healthit.gov, but healthit.gov was also this big campaign to get everyone in the U.S. using electronic health records. So it served a bigger purpose anyway. But we did manually actually outreach because it was a new government website, we needed to link build because everyone thinks that dot govs get some special treatment, they don’t.

Katherine Watier Ong (20:17):

But I knew we needed a link build. We were in the sandbox for six months. So one of the easiest ways, because we had to be very transparent about what we’re doing, because we’re doing federal work and there’s a bunch of bloggers who love to see if PR people at Ketchum are doing something not above board, believe me. So anyway we did, we outreached to previous webmasters who had linked to the old website and we took it as an opportunity to introduce them to this entire new campaign, right? And a new website. It was a kind of- Very manual mind you, I mean we used BuzzStream, but still pretty manual. But it generated more back links, because these old web masters who had linked to this old thing ages ago were like, “Oh look at this new thing.” Right? So they’d put that link back in place, the one to the homepage, but then they would link to other stuff too.

Keira Davidson (21:04):

Oh cool.

Katherine Watier Ong (21:05):

So it actually really worked. So we did that and then we did other link building to build up links to the site and we strategically created content in different disease areas to outreach to different networks. So we’d interview a liver cancer person getting treatment who, where the electronic health record helped them or whatever. Then we’d outreached all of the liver cancer websites that talk about such things, right? As intro trying to get them to link to the story on healthit.gov, rinse and repeat for every disease group. So we did a bunch of that kind of stuff too to build links to that website back in the day.

Keira Davidson (21:42):

Oh wow. That’s really interesting. You also mentioned how traffic losses there, you’ve done plenty of them in your time and you’ve been there to sort of unpick migrations when they’ve gone wrong and try and recover performance. Do you have a set procedure, start the process or do you literally just get stuck in?

Katherine Watier Ong (22:10):

That’s a really good question. No, I mean, I think the first thing is really just taking a look at when the traffic drop happens and trying to get as much intel out of the client about whether or not they did something because oftentimes they did something, right?

Keira Davidson (22:20):

Yeah.

Katherine Watier Ong (22:20):

That’s the most obvious place to start. So one of the federal websites that I worked on, they came to me, I’ve had two that have come to me because they lost traffic. No, sorry, three. Threes federal websites have come to me because they lost traffic. So one, the traffic drop occurred about the- This is going to make you cringe [inaudible 00:22:43]. They decided to launch a beta version of their website on purpose, because they thought this was a good idea, not block it from Google search so people could look at it for six months,

Keira Davidson (22:54):

Six months? That is crazy.

Katherine Watier Ong (22:56):

Six months. So anyway, there’s that. Then I had another one that was actually a little more challenging. So I worked for a while with National Cancer Institute, and for them… So I knew the head of communications there because he worked with healthit.gov back in the day, and so he was somewhat SEO savvy. He was like, “I think we’re not paying as much attention to SEO as we should.” Which was accurate, because when they started with them, I said, “Okay, here’s your challenge, you have SEO’s driving-” Or I’m sorry, “Social media’s driving about 11% of your traffic. You have one person in-house and a team of six helping you with that. Your SEO traffic, organic traffic is driving 80, 85% of your traffic on a normal day or whatever, and you have nobody in-house managing that.”

Keira Davidson (23:38):

Wow.

Katherine Watier Ong (23:39):

Or no agencies. I think there’s a problem here. Anyway, they’ve built up a little bit of a team, but for them it was more difficult to piece out what had happened because part of it was Google was starting to surface those symptom panels in search. So all of the basic questions about, “Do I have melanoma?” Were being surfaced right in Google search and they weren’t getting the clicks anymore.

Keira Davidson (23:59):

Yeah.

Katherine Watier Ong (23:59):

The other thing for them is that that space, especially now, it’s gotten very competitive. Google started to white label a lot of the other competitors and they’re out manned. So, I mean, I basically had to tell them you’re never going to rank for breast cancer because Medical News Today- WebMD turns out has been doing SEO since before Google. I did not know that, but that’s a long time that they’ve been doing SEO. Medical News Today’s got 113 people with SEO in their title, just epic amounts of manpower. They’ve been at it for longer and they’ve got a head start and they’re savvier. So some of these federal websites will get pushed out even though it’s the official national cancer- It doesn’t matter. It’s going to get pushed out if better content’s living somewhere else.

Katherine Watier Ong (24:43):

So yeah. So for them it was a mix of stuff. Part of it was the symptom panels. Part of it was competitors. So that one was a little bit harder to suss out.Then the last one was redesign without redirects, the last vendor website, distinctly. They changed the design, they moved copy around, they created tab navigation with JavaScripts and they didn’t redirect.

Keira Davidson (25:10):

Oh no. Was it left long before you were brought in or was it-

Katherine Watier Ong (25:13):

Yeah, I mean, so it was a simmering thing. What happened is that the developers met me at a show. I was speaking at a conference and they tracked me down because of my background in federal websites. They’re like, “The CIO’s upset because the design was supposed to improve traffic and it hasn’t. So we need you to take a look, basically.”

Keira Davidson (25:33):

Wow.

Katherine Watier Ong (25:35):

But again, developers don’t, a lot of them still don’t know you need to 301 redirect and they have no clue how to test. You and I know that’s one of the biggest pieces of moving, the URL, the structure exactly as it is. I always explain to people it’s like a map pen and that 301 redirect is like a string from map pen a to map pen B, right? If you don’t have that string in between, you start all over. You start all over. I have a very- 17 years of being an SEO, I am obsessed about URL structures and patterns, right? Google is too, and it’s really painful. It’s the most painful part of the web migration I’ve decided. Absolutely. But it’s also the most critical.

Keira Davidson (26:12):

Yeah. I agree on that. If we accidentally miss something or mess something up, it could cause massive repercussions.

Katherine Watier Ong (26:20):

Oh my God. If you do an underscore versus a dash or something, or uppercase to lowercase, all of that is going to mess it up. So, yeah.

Keira Davidson (26:32):

Wow. You’ve definitely had some interesting projects there to deal with. I guess based on that, there’s no one fit approach that suits all. It’s all based on what that initial conversation with the team, whether any changes have been made or haven’t that kind of creates your path of investigating.

Katherine Watier Ong (26:56):

Yeah. Well, in some of them you can’t recover. So for one of the federal websites, when they did the redesign, their mission as an organization had changed. So that was part of the reason why they got rid of some of the content, top performing content. But if it’s not what they do anymore, okay. Right? Yeah, how can I argue with that? It’s not what you do anymore. Federally mandated, so you’re not going to get that traffic back because you don’t want to show up for that anymore. For some of the other ones… Yeah, especially on the federal level, I was just thinking about how there’s just a bucket load of red tape around what content they create and why.

Keira Davidson (27:38):

Yeah. I can imagine a big legal team to sign off.

Katherine Watier Ong (27:42):

Right? Then if Google comes after your launch with the symptom panel, you’re not getting that content back. You’re just not. What’s interesting for them, there’s a lot of other stuff that Google’s doing in the cancer space, which is also the interesting part. So I like to watch what Google is doing in their more, their labs, the more advanced stuff, because I think it overlaps. I also think Google over the years has gone into quite a few industries and ruined business models for websites, right? So if they happen to show any sign of doing that in your industry, you should be aware of it because you might have to pivot quite a bit. Like travel.

Keira Davidson (28:20):

Yeah.

Katherine Watier Ong (28:20):

Right? So yeah, and if Google’s how people are finding you, I mean, unless you have enough sway at the federal level, like the White House decides to sit down with Google and talk to them about it for your topic or something, I don’t know how you would, right? I don’t know how you’re going to compare.

Keira Davidson (28:39):

Yeah, there’s no way.

Katherine Watier Ong (28:42):

Right? You just have to pivot, you have to try to show up for-

Keira Davidson (28:45):

You don’t have a choice.

Katherine Watier Ong (28:47):

Possibly build your email list, which is what I tell all of these folks, because it’s usually not front and center. So you have an ongoing audience you keep talking to you that you don’t have to fight to have them find you again, right?

Keira Davidson (28:57):

Yeah.

Katherine Watier Ong (28:58):

So, I mean that’s part of it and also diversify, because usually they’re not focused on Bing. They’re not focused, I don’t know, on all the other places you could get traffic, they’re usually pretty singularly in one bucket, usually all in the Google bucket. I just think that’s risky.

Keira Davidson (29:14):

Yeah. That’s such a good point, actually. I’ve never thought about making sure to be almost considerate of Yandex or Baidu or anything like that. So that’s such a good thing that I should bear in mind for future.

Katherine Watier Ong (29:26):

Yeah. I mean for most of U.S. based ones, probably not those two, but definitely Bing. I mean I know Bing is a small percentage of search traffic, but it’s still a percentage and it still powers quite a few more voice responses than you would expect. Last time I looked at it, it was like 45% of the voice responses were actually powered by something in the Bing database. So it’s less of an underdog than you think. So depending on your industry, it would make a lot of sense to be focused on it harder though. Because man, Bing Webmaster Tools is just not as helpful. I was definitely trying to use some of those features in this last migration. I was like, “There is a reason.” The tools are not as helpful.

Keira Davidson (30:10):

They’ve even updated them not too long ago as well.

Katherine Watier Ong (30:13):

I know, but they don’t tell you. They don’t break out your server error issues at all in any sort of way that’s easy to export. It’s just not clear what’s going on. Sometimes they’ll show it to you in a line chart, but you can’t get to the raw data. I’m like, “Please give me the raw data.”

Keira Davidson (30:28):

Yeah, it makes such a difference being able to access that.

Katherine Watier Ong (30:31):

Yeah. I’m like, “Why even show it to me on a line chart if you can’t give me the raw data?” You’re just going to give me a panic attack and then I can’t do anything about it. It’s just dumb.

Keira Davidson (30:39):

That is literally what they’re doing, yeah.

Katherine Watier Ong (30:41):

Yeah, that’s literally what they’re doing. They’re like, “Oh, but see, look, we can’t even access something over here. Look at all these 404s and sever errors.” “Which ones?” “Oh, we’re not going to tell you which ones. Why would you want to know that?” Maybe so I can fix it. Anyway.

Keira Davidson (30:56):

Yeah. Wow. Yeah. At least we’ve got Search Console, which is good and helpful.

Katherine Watier Ong (31:01):

Yeah, and now it’s got some sort of log files in there too, which is super helpful since log files are kind of impossible to get out of most clients.

Keira Davidson (31:07):

Yeah. I think we’ve been waiting like six months for logs off log client at the moment.

Katherine Watier Ong (31:13):

Some of them, I can’t even get them. It’s really frustrating. Yeah, especially with the developers who you know that can’t check the logs themselves. So I’ve had clients where I can see access issues for instance, the intermittently bots are getting 403s. I’m like, “Just hand over the bloody log files and I can tell you what’s going on.” They’re like, “No, we can’t do that.” I’m like, “Well you don’t know how to do it, so just hand it over.” They don’t know, right? Let me help you.

Keira Davidson (31:45):

For example, if there has been a traffic loss, would you ask for the logs if you can get them just to see how search engines are interacting with the site?

Katherine Watier Ong (31:54):

Yeah, maybe. Some of the sites I’m on are kind of big, so I’d have to be strategic about what days I’m going to get logs from, because the files get huge. But yes, I use that for one of my clients and I noticed for instance, and this is usually what I tell people when they get log files, is that they were saying, “Everything is gravy. We look at the files, we look at the logs and it seems like the engines aren’t having any trouble.” Well, I start looking at the ones that are showing 200 status and they’re garbage junk URLs that should be showing 44 or miscoded server error or something. You’re like, “Well, that’s part of the problem. Of course it looks fine, because you’re only looking at the status.” But the actual URL’s blank, or it’s got some [inaudible 00:32:42] code in it or something. I’m like, “That’s a problem.”

Keira Davidson (32:44):

Yeah. So, to wrap things up let’s finish on, what would be your top three tips when approaching a migration?

Katherine Watier Ong (32:57):

Oh my God. So gather as many checklists as you can. I know I ran off of one, but I think in retrospect I would’ve gathered quite a few. The other one is trying to figure out who the players are to see if you can influence that at all. There was one part that it was kind of clear in this last migration that… I don’t know, the client just didn’t want me involved, but it actually turns out that was the one part that didn’t go so well. So maybe I should have dug a little bit more to know a little bit more about what those players were to maybe at least set expectations about how that might have been a weak spot when we came up to the migration. The folks dealing with the [inaudible 00:33:38] switch were a little… Yeah, that was where we had a little bit of trouble. So get to know the people.

Katherine Watier Ong (33:45):

Honestly with this, because of my experience with this one, I’m always now going to ask whether or not the developers are going to QA their own work. Are you going to QA your own redirects? If not, I need to obviously budget for a heck of a lot more time QAing your work, because you’re going to say it’s done, ship it over, and it’s not done. I mean, they weren’t even… It’s like one to one redirects. They’re not even executing correctly. Like A to B, that’s not executed correctly. I don’t know. I spelled it out for you. I don’t even know why it’s going haywire.

Katherine Watier Ong (34:15):

And I realize that these are like more complicated platforms. There’s coding involved in order to get the redirects in place. I get all that, but the SEO in me that built my first website in ’94 gets a little annoyed when I know with some of these, it’s a file you upload at the server level that literally you write out one to the next, you know what I mean? At the baseline, it could actually be executed that way. It could be very simple. I could literally do it for you, which I realize I can’t in this context so I try to be patient, but that is rattling around in the back of my head.

Katherine Watier Ong (34:48):

Like, “Maybe I’ll just write them all out in a text file.” Maybe we’ll get to the end result faster if I do it that way. But yeah, I would definitely ask about what is the process for particularly QAing redirects? Because we introduced this platform to Screaming Frog and it was cute. They tried to run it on their own machine for a hot second. They’re like, “It’s never finishing.” We’re like, “Of course it’s not going to finish on your own machine.” I’m crawling in Google Cloud, the client’s crawling in AWS. It’s just too big.

Keira Davidson (35:19):

I imagine that computer was going to take off.

Katherine Watier Ong (35:22):

I envision steam coming out of it. It was adorable that they were trying. They’ve never used it before, so of course they’re doing… We tinkered with the settings to get the most efficient crawl possible, because there’s a lot of garbage that could get picked up, that kind of thing. Of course that’s not what they’re doing. So it’s just like steams coming out of the machine. But the instructions for Screaming Frog to check redirects is not that complicated. So I’m still stumped as to why they couldn’t QA their own work since I know they eventually got a copy of Screaming Frog, but whatever. They didn’t, which was more work on our end.

Keira Davidson (36:00):

Yeah. At least you know now for future projects like the ones coming up to factor that in.

Katherine Watier Ong (36:05):

Yes, exactly. I can set expectations. It’s tough though, because you’re working with people that have never done migrations before. They’ve never done SEO before and here I’m telling them that the most important part that we should obsess about are these back links, because they’re high quality ones coming into high quality content, right? So we have to get most of these back links in place, that will be the success factor. It’s also going to be the most bloody painful thing you’ve ever done in your entire life. So that’s been really hard for me to sell through. I mean the current client that’s working with me, yeah, she’s got it for sure. But it’s just hard, because you’re like, I can’t tell you this is going to be fun for hours and hours and hours in the spreadsheet.

Keira Davidson (36:48):

But it’s got to be done.

Katherine Watier Ong (36:51):

It’s got to be done. It’s the most important part.

Keira Davidson (36:53):

I’m sure if they decided not to do them, they’d then be questioning you why performance had dropped or what’s gone so wrong.

Katherine Watier Ong (37:01):

Well, I mean, that’s where I sort of explain other sites that I’ve seen go through migrations that didn’t map and you can show them the reports and HRFs about how things got broken. You can sort of demonstrate some of that.

Keira Davidson (37:14):

Which probably helped your case.

Katherine Watier Ong (37:17):

Yeah, but I mean, it’s still really painful. I mean, I spent all summer in Spreadsheets I think, so did my client. There was thousands and thousands and thousands of redirects to check and then stuff would revert and stuff that you thought was fixed is now not fixed and just painful.

Keira Davidson (37:32):

Yeah. Not fun.

Katherine Watier Ong (37:33):

Not fun. So if anybody listening has this magical solution for [inaudible 00:37:40] redirects that’s not as painful, let me know.

Keira Davidson (37:46):

Yeah, I’d be really intrigued to know as well.

Katherine Watier Ong (37:49):

Yeah, because eyeballing at thousands and thousands- And some of the stuff I just couldn’t figure out a way to do a pattern. Just too complicated with the current situation, but-

Keira Davidson (37:58):

Yeah.

Katherine Watier Ong (37:59):

Yeah.

Keira Davidson (38:00):

It’s been great speaking with you today and I’ve definitely learned around some of the more interesting, intricate details when it comes to large scale migrations. So I really appreciate that. Thank you for joining me.

Katherine Watier Ong (38:16):

Oh, you’re welcome. This has been fun.

Keira Davidson (38:18):

Just to round things off, where are the best places that people can follow you, find you?

Katherine Watier Ong (38:25):

Sure. So my website is wostrategies.com and there you can check out my semi-daily SEO tips, which is actually an audio micro podcast. It’s also actually on Alexa flash briefing. If you’re an Alexa fiend. I also am on Twitter at kwatier, which is my maiden name. Find me on LinkedIn, and I also host a podcast myself called Digital Marketing Victories, where we focus on the soft skills that are required to actually sell through digital marketing strategies. So feel free to check that out too.

Keira Davidson (38:57):

That’s amazing. Yeah, thank you very much for providing those details. I’ll be sure to check out your sites.

Katherine Watier Ong (39:03):

Great, thanks.

The post S3E11 Katherine Watier Ong, Large Scale Migrations appeared first on The TechSEO Podcast.

Keira Davidson (00:23):

Hi, and welcome to the Tech SEO podcast, which is hosted by myself, Keira Davidson, a senior SEO executive at SALT. This episode is with Sören, the CEO of Audisto.

Keira Davidson (00:38):

It’s great having you joining me today. I can’t wait to get to talk about automated testing. Let’s kick things off by seeing how you are.

Sören Bendig (00:47):

Hey, Keira. Great to be here. Yeah, I’m fine. It’s really great weather here. So finally, the summer is kicking in, at least in Germany.

Keira Davidson (00:56):

Have you had the same issue with us where we’ve had rain for weeks upon weeks and then we finally had a mini heat wave?

Sören Bendig (01:05):

Yeah. We recently had a heat wave as well. So that was quite a few days.

Keira Davidson (01:13):

That’s lovely. What always happened is, we’re always like, “Oh, we really want some sun.” And then when we finally get the sun, we’re like, “Oh, it’s too hot.”

Sören Bendig (01:22):

Yeah. There’s no right or wrong weather. I mean, for us, at least it’s a topic. If you’re in a place like Singapore or something, the weather is not a conversation topic.

Keira Davidson (01:33):

Really?

Sören Bendig (01:34):

In Europe, everyone is talking about the weather because it’s too hot, it’s too wet, it changes all the time. And if you’re in a place like Singapore, they have either it’s dry or the monsoon, it’s raining, but the temperatures are more or less the same. The weather is not a conversation topic, interestingly.

Keira Davidson (01:51):

That’s crazy. I’d never have known that. Thank you.

Keira Davidson (01:58):

So you’re a CEO now, but I’m assuming that’s not how you started in the industry. How long have you been in SEO, so to speak?

Sören Bendig (02:10):

Oh, I think meanwhile it’s around more than 15 years or something. I mean, SEO started for me back then when I was still studying and then I wrote my own blocks, then realized, okay, if you put in the time, do some research about the topics that your readers are interested in, then the articles you write are much more successful. So that’s how it all started way back then.

Sören Bendig (02:38):

And then on the way to Audisto, I did different things. I was the CEO of SEOlytics. That was a rank checker for enterprise business. We sold that company to SISTRIX.

Keira Davidson (02:50):

Okay.

Sören Bendig (02:52):

And in between, I was also working for a web analytics SaaS business. Yeah. And now it’s Audisto, and Audisto started 10 years ago now. This year is our Jubilee.

Keira Davidson (03:09):

Oh, that’s amazing.

Sören Bendig (03:09):

So, 10 years ago it started and it started as a technical website crawler. So the basic tool that we offer since the beginning is a technical SEO and structure analysis software.

Sören Bendig (03:24):

And yeah, since three years we also operate second solution, so to speak, but it’s connected with the crawler, but focusing on the automated technical testing and monitoring. And from the business side of things, Audisto is focused on enterprise clients. So our software is scalable, can easily analyze half a billion URLs or more. So we focus really enterprise side of things, not the SMB things.

Keira Davidson (03:58):

Oh, that’s really interesting. And when you are doing automated testing for large sites, do you use like CI/CD to do that? So it’s basically continuously checking before deployment.

Sören Bendig (04:17):

No, there’s different ways, how to, how to do testing and monitoring. And we can elaborate on that in some minutes, but basically for us, the testing part is based on the crawler because we have the crawler expertise.

Keira Davidson (04:34):

Okay.

Sören Bendig (04:35):

So the technical SEO crawler is the basis for the data that the testing and monitoring analyzes.

Keira Davidson (04:46):

Oh, cool.

Sören Bendig (04:46):

And from the different ways you can do testing, the thing that many do is they do manual testing. Everyone is check. If you check a client website, that’s manual testing, so to speak. And you can do that. It’s really great for realizing new problems. I mean, no software will ever tell you all the issues that you have, so usually you need to realize it beforehand. But it’s expensive and it does not scale.

Sören Bendig (05:15):

And the whole testing topic in different industries, they utilize it more and more since several years, but then an SEO, you know how it is, the SEO specialist is rare. Everyone wants more SEO specialists, especially technical SEO focused specialists. And the time is expensive and people are checking for titles and snippets and whatever, which really does not make sense if you have like a large eCommerce website. No one in their mind is writing all the titles, with a human.

Keira Davidson (05:55):

Yeah.

Sören Bendig (05:55):

You develop and automate where you say, “Okay, this is the category. This is the product.” And then you combine and then create some things that you can scale through the whole platform. And then maybe for the most important products, you fine tune it manually or something.

Sören Bendig (06:15):

But that’s why we developed the testing and monitoring, because from the technical SEO perspective, we have some clients, they doing a technical SEO audit, and then they realize, “Okay, there’s a lot of stuff. It’s broken. We need to fix it.” And then they fix it and it takes them two months. And afterwards, then they just skip it.

Sören Bendig (06:41):

And half a year or year later, then they come again and then do another audit and then realize, “Oh, there’s a lot of stuff that’s broken.” And maybe in between, they realize, “Oh, stuff is broken and it costs us money so maybe we need to do something.” And that’s an approach where we say, “Yeah, but that’s so shortsighted.”

Sören Bendig (07:01):

And we have some clients that did not have any safeguards at all. And if it’s a good running shop, then it’s really easy to have €50,000 or €100,000 with some faulty changes that no one wanted but no one realized quickly enough.

Keira Davidson (07:22):

Yeah. So would you say that you are able to catch issues earlier and potentially roll out changes before they become very large on scale?

Sören Bendig (07:36):

Yeah. Well, the idea behind the automated testing is that if you compare it to a one-time audit, you do a continuous testing on your site. So it’s not once a month or something, but it’s continuous. So if you would do this, then you would analyze yourself 24/7 more or less, or at least once a day.

Sören Bendig (08:03):

Let’s take it easy and say, “Okay, I want to analyze it once a day.” And then maybe I have some issues where I say, “This is a critical issue. If this is happening to my shop or to my site, I lose money immediately. So if there’s just like one faulty modification, I need to know immediately.” So that’s the two ways you might to want to know it.

Sören Bendig (08:26):

And compared to, sometimes I do an audit or something that you want to not realize there’s changes retrospectively, after the change happened. You want to realize the issues. So, if I had realized, “Oh, three days ago, our content management system unfortunately changed all the titles and all the snippet to some default text.”

Sören Bendig (08:57):

So now Google starts indexing lorem ipsum, whatever. That’s really easy example, really simple, but it happens, and most systems do not have safeguards against something like this.

Sören Bendig (09:12):

So if someone moves into automated testing, then you have companies that already use unit tests, integration tests, and they have some test solutions that they combine with the development process itself, which are great to test for program logic, can also test more complex stuff. But they sometimes don’t scale well because a developer has to write a test for every different type of page and every different product and stuff like that. And usually writing tests is not the favorite part of every developer and developing time is short as well.

Sören Bendig (09:56):

So yeah, we write some tests. Yeah, it’s working, but yeah. So we sometimes see that it makes less sense that the developer writes his own tests because we write a test that works exactly for the ticket, what he did in the programming.

Sören Bendig (10:15):

Then some companies then have QA people working on testing. But then again, it’s often manual work. Sometimes they do some user testing, like they use something like Selenium or something to test is the login process working and stuff like that. And this is approaches you need to do anyway. What we do or someone else can do with a crawler, it will never change this process because you need to do this function test anyway.

Sören Bendig (10:44):

But the beauty how you can do crawler based testing is that it is very flexible. Everyone can run it at any time, so to speak. And because the crawler can analyze what the final user sees, this also means that, in the end, you can also test stuff like logic and code or the database content or something.

Keira Davidson (11:11):

Oh, cool.

Sören Bendig (11:12):

I mean, it’s a no brainer you should test it at a different part of your process, but often the process is not there or you do not have the solution stuff.

Sören Bendig (11:23):

My favorite example from eCommerce is in incorrect price in the database. Of course you should have some kind of logic to analyze for this within your own system, but many don’t. So if we talk about eCommerce, as I say, yeah, you do not want to offer a product for €0 or something. And everyone is laughing at us, like, yeah, but that’s not happening. But it is.

Sören Bendig (11:48):

And my highest example was a B2B shop. They were selling some compressors, and they had a compressor for €5,000 in the shop and they were selling it for €0.

Keira Davidson (12:01):

Wow.

Sören Bendig (12:01):

But you had to pay €5 postal fee because you didn’t manage to get to the €50 fee where they would send it to me for free. Or you have some marketing bundles where the shop system is not smart enough after the bundle is entwined to correct it. And then you have a byproduct you’re still selling for €0.

Sören Bendig (12:26):

We have one SEO, he ordered just to try it out 50 times the €0 product and the system sent it out. So he had 50 of the product at home.

Keira Davidson (12:36):

Wow.

Sören Bendig (12:37):

It was not the compressor. It was a marketing item that cost €3 or something. But nonetheless, the systems are stupid often and that’s-

Sören Bendig (12:51):

So that’s why with crawler, at least you can test for everything that the final user sees or operates with.

Sören Bendig (13:02):

You can leave the SEO bubble rather quickly. Also test for a price is not a SEO topic or is there a buy button or something like that.

Sören Bendig (13:13):

But sometimes it can help to look into other topics. We have some SEO teams where they realized, “Yeah, we don’t want to do the testing, manual testing, again and again and again.” And they realized, “Okay, we can automate it. And we would love to do it,” but they had no idea how to get the budget for it. And then they looked what other topics do they have that can impact the business, and then they realized, “Okay, we’re selling products where we are legally obliged to write certain things in the product description.”

Sören Bendig (13:47):

And then they went to the legal department and asked, “Yeah, and last year, how many legal issues did we have where this was not properly done? And what did it cost?” And legal department said, “Yeah, it happened three times, cost us €45,000.” And then the SEO said, “Yeah, if I can bring you a solution for a few thousand euros that can prevent this ever happening, do you want to have it?” And legal was like, “Yeah, immediately.”

Sören Bendig (14:12):

So then the SEOs would take care of, I don’t know, five or six tests for the legal department, and legal department was paying for the solution.

Keira Davidson (14:20):

That’s so good. I didn’t realize you could use it for looking at basically referencing your database for price as well as what’s being shown on the site, and also for using it for check referencing if specific legal requirements of being met or stuff like that, which is really interesting.

Sören Bendig (14:42):

Yeah. If you use a crawler based testing, it’s the same. Then if you would use like a technical SEO auditing tool, you can analyze everything the crawler sees and can analyze. And if we talk about SEO based tests, then it depends on the solution that you would use if you can utilize additional logic for it.

Sören Bendig (15:08):

So with Audisto, the background is the technical SEO crawling and auditing tool. So then, of course, there’s technical hints and logic that’s SEO focused that you could use to quickly, with a few clicks, generate SEO tests. If you want to do something else that’s eCommerce based and you have some, I don’t know, some elements of your website that you want to test from the HTML source code or something, of course, then you would need to write a test, utilize maybe XPath and RegEx and stuff like that. So that depends a little bit on the solution you would use.

Sören Bendig (15:49):

But I know that there are some SEOs that try to incorporate more and more testing solutions with the development process, and that can work as well. It really depends a little bit on the setup that you have and how many resources do you have. If it’s a developer who needs to work on a test…

Sören Bendig (16:11):

Sometimes we talk with people that want to get into the testing topic, and then the SEO guy gets someone from IT in the discussions. And the IT says, “Yeah, but we have systems and we can do everything in-house.” He’s like, “Yeah, that’s perfect.”

Sören Bendig (16:31):

And then the SEO writes a test plan, the different topics you want to test, and then he gives it to the IT, and the IT says, “Oh, yeah, no, that’s not that easy. Yeah. And some tests are more complicated. Ah, this test takes one month because we don’t have full resources for you, of course.” And then in the end, then the SEO test then would take half a year until it’s up and running.

Keira Davidson (16:59):

Wow.

Sören Bendig (17:00):

And maintaining everything right takes more. And so it really depends a little bit on the resources that you have. It may be it makes more sense to buy a software solution that’s like €500 per month. So it really depends how you do it. And yeah.

Sören Bendig (17:21):

But we see that too few people do proper testing on their websites and their shop. Some do template testing, but even with template testing, there’s lots of issues involved.

Keira Davidson (17:38):

Yeah. I’ve currently got a client doing template testing and it has gone completely wrong. They followed all of Google’s guidelines when briefing their developers, and their developers basically needed a quick fix. So they rolled out the whole template across the whole site. And there’s maybe 5,000 pages, so there’s a B variant across the whole site and there’s the original variant. And we are just having massive headaches because, despite them being canonicalized, Google is preferring to the new template for mobile and is choosing to return that page to smartphone users in the search. So we’re now having to remove that in search console from the URL removal tool.

Sören Bendig (18:35):

Yeah. The main issue I have with template testing is that usually what’s happening is someone decides, “Okay, we want to do some testing and we have different templates we want to test.” And then they take between three and ten example URLs per template and that’s what they’re testing.

Sören Bendig (18:55):

But since no one wants to adjust the test once a week or something… Always people use the most stable products that they have, the evergreen products. They’re always there, that always have been there. And then there’s 10,000 new products the shop launches, and because it’s product data from some sort of party or whatever and it wasn’t cleaned up, it’s totally screwed up. But no one will realize it because they’re just testing this handful of URLs.

Sören Bendig (19:28):

And so the stuff that breaks is the new products, the new stuff that’s happening. And, of course, you could adjust the template testing, but as long as you do some list testing, so to speak. So you have a list of URLs you are testing, you will always miss stuff.

Sören Bendig (19:46):

So I would always suggest to have a pattern based approach and analyze everything. So if I have a shop that has 50,000 products, I don’t want to just test 10 products. I want to test 50,000 products. And the way I would advise to do it is to do a pattern based. So basically you tell the system, “Okay, this URL is a product page,” and the system can recognize it by whatever, div tags, or however technically you can identify it.

Sören Bendig (20:20):

And then you define the status “green” for this product page. You say, “Okay, this product page has certain requirements.” I have SEO requirements concerning the title, the description, index ability and everything. And then maybe also you have other topics that leave the SEO bubble. And the, if you do it crawler based, crawler based testing scales very well. So you can just tell the crawler… If you do a technical zero analysis, you would crawl the full domain as well.

Sören Bendig (20:51):

And so based on this, you do with the testing and the monitoring as well. And if it’s pattern based, for the system itself, it doesn’t matter if 5,000 new products enter the shop or left the shop because it will just analyze all product pages based on the pattern. And then you cannot miss anything.

Keira Davidson (21:18):

Oh, wow. That is so good. That is amazing. So you prevent so many future issues potentially by doing it like that.

Sören Bendig (21:32):

Yeah. The thing is that, how many people do you know that do a relaunch, a website relaunch, and they do some technical SEO audits, and then they do the relaunch. And maybe afterwards they do an audit as well. But you could take the same testing and monitoring approach and really go together with the relaunch process, have like continuous SEO testing on staging and a company staging going to live and everything.

Sören Bendig (21:58):

And so sometimes I’m really surprised how much hardship people put on their own desk because they don’t.. Yeah, I don’t know. Maybe they’re not creative enough or maybe sometimes think too small when it comes to scalability and continuous analysis and stuff like that.

Keira Davidson (22:19):

That is so interesting. So you imagine how you could, if you’re doing a relaunch, you could roll out automated testing for that. Are there any other common examples where you’d use it?

Sören Bendig (22:33):

Yeah. Basically everything where you have a dynamic system and it changes. A relaunch, of course, is a good example because maybe you want to have some quality criteria tested on the staging before it goes live because you don’t want to mess it up. And there are many examples of relaunch cases where, by whatever reasons something went wrong, and it hurt. So this is a good example of how to have continuous testing on the staging, because, especially if your set up is more complex. If it’s a small company and you have a few developers and they do it by themselves, then that’s fine. But if we talk about the enterprise case, then usually you have some people sitting in-house, then maybe you have IT development in the UK. Maybe they have a second team in Portugal or Russia or something, and then they have an extra agency, and then it’s like so many moving parts.

Keira Davidson (23:34):

Yeah.

Sören Bendig (23:35):

And just to keep focus on the bird’s eye perspective is quite hard. And then something releases because, of course, time is of the issue, and so you can, of course, accommodate that and basically every case.

Sören Bendig (23:52):

The thing is that many companies that never did testing and monitoring, they say, “Yeah, but this cannot happen to us. Nah, we don’t need it.z’ And of course, this is if you want to do proper testing and monitoring, it’s not something where you can just take some software solution and magically press two buttons and everything will be covered. That’s not how it works usually. There are some solutions out there that come with a set of basic and very simple tests. But if you want to do it right, you need to create a proper test plan and you need to define what’s the status green for different page.

Sören Bendig (24:36):

And then in addition, it comes down to how much experience do you have. Just as an example, for a test, then you have some solution to test, okay, there needs to be an SEO test for a title. So, of course, the title needs to be there. But that’s not a good test because it’s too simple. If you want to, just for the title, if you want to test for it, of course, you want to test, the title needs to be there. So it’s not supposed to be missing, but it’s also not supposed to be empty. And the title is also not supposed to be outside the head, and the title is supposed to occur just once and not twice or thrice. And it is not supposed to be too short and not supposed to be too long. So you realize, “Okay, just a simple thing like the title, if I want to do a proper test for it, I need to think big.” And I need to realize, “Okay, what’s the characteristics, the quality characteristics?”

Keira Davidson (25:35):

I didn’t realize, for example, like you just mentioned there for a title tag, that there’d be so many different things that would be required to be considered when planning out the test.

Keira Davidson (25:47):

So do you know, is it just SEOs and developers that work together to do these tests? Or does someone exist as a specialist automated tester? Is that a thing?

Sören Bendig (26:04):

You have many companies that have QA resources, but usually they’re not focused on the SEO topics. So the SEOs that we get into discussion about testing and monitoring usually are the ones that realize, “Okay, we have a complex system by whatever legacy reasons and stuff breaks and breaks and breaks, and we need to do all the manual work.”

Sören Bendig (26:30):

So back to what I mentioned in the beginning, you have a technical SEO specialist, and he’s doing minor tickets for the developers. Makes no sense. Makes no sense for the company and makes no sense for the SEO.

Sören Bendig (26:45):

So then they realize there must be a better way. There must be a way to automate it because this ticket was the same topic I’ve wrote it for the tenth time. Does not make sense for anyone. So that’s one example.

Sören Bendig (26:59):

Another example is sometimes you have SEO cases where, for example, they have a business case where the company says, “Yeah, it’s working very well for the three countries we are already in. We decided we want to go in 10 more countries and copy the business case into different countries. And then, yeah, but we do not want to hire more people to do it.”

Sören Bendig (27:23):

And then the SEO team says, “Yeah, but the content is written by different people and so many moving parts, also for the other countries, stuff breaks. And our team still has the same size.” So then we need to do some automation because it also makes no sense.

Keira Davidson (27:42):

Yeah. That makes sense. So for example, if a client was wanting to expand in different regions to ensure that it’s being implemented successfully and there’s no glaring areas or issues that are… What’s the word? That are discovered. You could automate testing and monitoring to see how successful it’s been and to pick up on any issues after the implementation.

Sören Bendig (28:12):

Yeah. And, of course, if someone had a negative impact on the business, then they are quite eager to prevent it again. That’s what I was mentioning, that some people say, “We do not need it.” And then you have others that it cost them €40,000 because it just took a while until they realized something broke.So they they’re really quick to get a solution to prevent it.

Sören Bendig (28:42):

But yeah, it, so it depends a little bit on do you have a history where this kind of automation could be worse to you because you save money, be it from the technical side or the legal part or the SEO that says, “Yeah, we need to automate stuff,” because the specialist doing scrubbing really simple tickets for the developers that it just does not make sense.

Sören Bendig (29:14):

And when it comes to the test itself, like you said, that the complexity of, for example, a title test or something, I think that’s something that depends a little bit on the technical SEO approach people take. Many people do audits with Screaming Frog, for example, and Screaming Frog is a great tool and everyone is using it. But of course, there is other solutions that go much more into technical detail. And so it depends a little bit on what you do. And then usually if someone starts to use solutions where it’s more technical tests and details, usually you find a lot of stuff and anomalies that you have no idea that exists.

Keira Davidson (29:59):

Yeah, I bet the data at the end of it would be really eye opening because you probably have found lots of anomalies or things that you didn’t even know existed.

Sören Bendig (30:10):

You always need to decide then, is it an error you focus to fix this, or, I don’t care, but at least it needs to be a decision made by you and not by chance.

Keira Davidson (30:24):

Yeah. Yeah. You’ve got the data then to prove it. And you can make, like you said, make decisions based off that to see whether it would actually have an impact.

Sören Bendig (30:35):

Yeah. And data could also be important to drive this topic internally more. I can only speak from the point of view from Audisto, but I assume other solutions can offer this as well. But even without the monitoring, if you use a technical SEO crawler to analyze the site, there’s also many solutions where you can use scheduling and do automated crawling.

Sören Bendig (31:06):

So makes no sense to just crawl every now and then. But if it’s from a business point of view, it’s important for me, then at least I would say, “Okay, I want to crawl, I don’t know, once a week at least.” And then you have some kind of documentation for all the KPIs. And if something breaks or something goes wrong and then you have the data, and then you could take the data internally, maybe even you saw it fast enough that you are the first person to raise the hand and say, “Okay, yeah, stuff broke.”

Sören Bendig (31:37):

But else even from a retro perspective, you could take the data and say, “Okay, we could prevent this. If it’s important to you, we can start developing a process to prevent it in the future.” And then in addition, especially for the SEO, get many of the minor tasks out of the way, because you automate them.

Keira Davidson (32:00):

Yeah. And do you know the crawling, is it local crawling or is it cloud crawling?

Sören Bendig (32:08):

It depends on the solution that you would use.

Keira Davidson (32:10):

Oh, okay.

Sören Bendig (32:11):

For Audisto, it’s cloud crawling. I think that if you want to do proper testing and monitoring, of course you could develop something on your own with a local crawler that’s running on your machine, and I am quite sure some people do, but when it comes to this kind of solution, there’s always the buy or make decision that you have to do. I know many agencies, for example, that started to create their own crawler solutions or analysis and stuff like that because they had someone technically capable to do it.

Keira Davidson (32:51):

Yeah.

Sören Bendig (32:52):

And then at some point, because it was just one person and he’s sick and something needs to get fixed, the process stops working or stuff like that. And in addition, usually someone who is doing it more like a hobby, most likely never the real amount of hours that goes into developing something on your own is like calculated properly.

Keira Davidson (33:18):

Yeah.

Sören Bendig (33:19):

Especially in technical SEO, I mean, it depends a little bit if someone’s really interested and he wants to do it and it’s fun and the company does it more as a bonus to this person, then the company needs to judge the risks. If this person leaves the company, or if he gets sick, is in the hospital or something like that, can we still use it? Can it break?

Keira Davidson (33:44):

That’s a good point.

Sören Bendig (33:44):

But make or buy should usually be a strategic decision.

Keira Davidson (33:51):

I would never have considered it from that point. Because, yeah, it’s sort of normal for people to be ill or people to leave companies. And if a sole individual has created that tool and then leaves, it could mean that the tool’s then redundant.

Sören Bendig (34:09):

Yeah. Or you need to put additional stress on an employee. I know of one case where it was an in-house team and they were maintaining an old solution, but like the example, it was just one person. And then he was on holidays and things broke and they couldn’t work with it. So then they pressured him during his holidays, in the evenings when the family was asleep, to two nights, work to fix it.

Keira Davidson (34:36):

Oh, wow.

Sören Bendig (34:38):

And of course, yeah. But, yeah, it really depends. I know both sides and, yeah, it can work both, of course.

Keira Davidson (34:48):

I never realized that how sort of automated testing and monitoring could be used in technical SEO. It all felt always a bit above my head, whereas since speaking with you today, it’s kind of made the topic less complex and a lot easier to understand, which is really good. So I really appreciate that. Thank you.

Sören Bendig (35:15):

Yeah. I think we just covering the basics. Of course, we could discuss this for three hours and every different part in detail.

Keira Davidson (35:23):

Of course.

Sören Bendig (35:24):

But I think that sometimes people lack the fantasy. What could you do is automation and also the testing and monitoring, what can be done and how can you use it?

Sören Bendig (35:37):

And because it’s so flexible, what you can do is, I know many SEO teams that use it in a really flexible basis, even, I don’t know, start some kind of creative sim content analysis, because they use XPath and then they count elements on a page or something.

Sören Bendig (36:00):

So when it’s a testing approach and the solution is flexible enough, you can create test for everything that you can imagine, as long as it’s technical, from technical point of view, it’s possible to test it.

Keira Davidson (36:16):

Yeah. So it really is endless, which is really good to know. And I definitely think it’s something that I should bear in mind for future when, for example, doing migrations or relaunches, I think it’d be really interesting to see the results with it.

Sören Bendig (36:35):

Yeah. It goes not so deep into testing details, but we recently released a guide for relaunch monitoring. It’s more like strategic project management plan, how to do it, but if you or anyone’s interested, can go in the guide section at audisto.com. There’s a checklist there as well and goes in a similar direction, I would say.

Keira Davidson (37:02):

That sounds amazing. Thank you for that. I’ll definitely take a look at that after this. Thank you.

Keira Davidson (37:10):

I think we managed to cover the topic pretty well. I’ve definitely learned a lot. And I think from here, I need to just spend some time, but further understanding the topic now that it’s makes sense to me. So I really appreciate you joining me today and hopefully other people have liked it as well. So thank you very much.

Sören Bendig (37:33):

You’re welcome.

Keira Davidson (37:33):

That’s great. I’ll speak to you soon.

Sören Bendig (37:38):

Yeah, Keira, and thanks for having me and happy to discuss any findings that you have or any questions. So just let me know.

Keira Davidson (37:48):

Thank you very much. Thank you.

The post S3E10 Soren Bendig, Automated SEO Testing appeared first on The TechSEO Podcast.

Keira Davidson (00:23):

Hello and welcome to the TechSEO Podcast, which is hosted by myself, Keira Davidson an SEO executive at Salt. This episode guest is Manuel, who is an SEO manager at Honcho. It’s great having you on the podcast today. How are you?

Manuel Madeddu (00:40):

Yeah, I’m okay. And yeah, you pronounce it my name correctly. So you [inaudible 00:00:47] So we got it. Yeah, no, I’m fine. So, given the situation, the pandemic has being quite a hectic period for me, for the SEO and also I’m a father two, and then I’ve got a new baby is three months old.

Keira Davidson (01:02):

Oh, wow.

Manuel Madeddu (01:02):

Yeah. Which made my life a bit more challenging the last months.

Keira Davidson (01:07):

Yeah. So you’ve been working at home while you’ve just got a newborn as well.

Manuel Madeddu (01:13):

Exactly. And trying to fix issues for clients and then improving [inaudible 00:01:18] cuddling my baby the same time.

Keira Davidson (01:21):

Yeah. Wow. Here’s me worrying about my mom and dad getting home from work and making sure that [inaudible 00:01:28] walk in on a call, but you’ve got a baby.

Manuel Madeddu (01:31):

Exactly. And sometime I had some calls with the baby, so making sure maybe he wasn’t screaming and actually he was enjoying the call. So he was looking to my colleagues or client [inaudible 00:01:40]. But yeah.

Keira Davidson (01:44):

Starting them young, getting them listening already.

Manuel Madeddu (01:48):

Exactly. I can [inaudible 00:01:50]

Keira Davidson (01:51):

Exactly. So usually I find that everyone gets into SEO in all different route. So you’ve been at Honcho for a good couple of months now, but how did you start out in the industry?

Manuel Madeddu (02:06):

Yeah. Well, it’s a tricky question because essentially no one made a thing to start an SEO and it just happens sometimes. I studied something completely different. So I study robotics back in Italy. I’m from Italy. Yeah. And essentially when we came here, so I came here with my partner. We are both Italian and we came here something like 12, 14 years ago now. And I mean, we came here when there was a huge crisis and you really struggle to find a very specific job. I was trying to apply for engineering jobs but really struggled. So essentially, I mean, I started doing catering jobs or a bit of everything. And then my partner, she’s a graphic designer and we looked ourselves into the eyes and we said, “Yeah, let, let’s try to work with ourselves.”

Manuel Madeddu (03:00):

And then open our small agency. So digital marketing agency covering everything. So, I mean, again, I invented my career there because I mean, I knew how to code with some specific programming, coding languages, but nothing about websites or pretty much nothing. So yeah. I mean, we started from scratch and for eight successful years we’ve been running our agency. And that’s why essentially from when you develop your first website, you’ve got clients asking you, I mean, “Now I have the website I want to be in first page.” And that’s why that’s where you try to find any trick, any magic for them to rank better. And yeah. So essentially starting 10 years ago, it was maybe easier because Google at that point was more about, you could still try with some hot techniques and link pyramids and link building strategies.

Manuel Madeddu (04:01):

And then, I mean, from there, it’s constantly being updated. But yeah, let’s say, I mean, since I became a father, so I’ve been running my business, my little small agency for eight years, then I become a father and then me and my partner were kind of struggling with clients. And I decided to set aside and focus more on SEO because I mean, among all the things I was covering, I feel SEO is really challenging, but it’s also exciting, when you face the challenge you find the solution and then you engage more with the clients. If you’re successful, they love you. So-

Keira Davidson (04:39):

Exactly. No, that’s so interesting. It’s really good to hear that you had your own agency, because I guess that gives you a completely different insight. The commercial side of it, you will 100% get because you’ve been in that position.

Manuel Madeddu (05:01):

Yeah, honestly, exactly. I mean, when I get back to the market, so when I decided to apply as employed, it was a bit, I mean, I really struggled at the beginning because your mindset is kind of different and you are used to see things like on a 360 degrees perspective. I struggle to see how processes were or how you have to approach your manager for example because to me it was more about providing results and answer to the question of the client. So yeah. But I guess I am a kind of outsider and then that’s way maybe why I try to find the best solution for the client and maybe exploring new paths in a way. But yeah. I mean, I love to do it. I love to focus on SEO. I love the agency side of things, so-

Keira Davidson (05:54):

That’s really exciting. So the reason why I’ve got you on this podcast today is to talk about migrations. When I’m thinking back to when I first got into SEO, I didn’t realize how all encompassing migrations could be. So you could have redesign migrations, international migrations, then the standard HTTP to HTTPS. I didn’t realize there were so many different options, but one thing that each migration that I found, it’s always different. So do you use like a bespoke approach when approaching each one or do you have some go-to things that you’d always do?

Manuel Madeddu (06:46):

Yeah. I mean, I do have a go-to things, so I’ve got best practice and a checklist. But as you said, no migration is same. I mean, you don’t find two migration the same. I mean, each immigration is a unique challenge and then that’s why, I mean, you need to discuss with the client, what’s the target and budget. I mean, every time is different. So you have to tailor your strategy, your checklist based on what you discussed with the client, what the platform is, what the scope is, because there are a lot of incognitos and things. I mean, even when you’ve got more time, you can also include more tasks.

Manuel Madeddu (07:31):

For example, you can audit the current side, then you can audit the [inaudible 00:07:35] side. Then you can do a keyword research, for example. When you’ve got a lower budget and then you have to do everything in like two weeks. So that’s no time. So it’s very depends on the targets and budgets. And I usually, yeah, as you said, I mean, I usually start from my checklist, but then discuss with the client and essentially every checklist I do, every roadmap and plan I do for each migration is different.

Keira Davidson (07:59):

Yeah. So I recently came across a migration where they were moving from domains. So it would be like the client site dot [inaudible 00:08:13]. And they were consolidating all of those into like the.com into folders. And apparently they’re so rare. Someone told me I probably won’t come across them like another five years.

Manuel Madeddu (08:27):

Wow. I mean, I find it quite common honestly, because I mean, when you walk. I mean, I work on very big migrations, so I work for a company, which is huge. And I was dealing with like 16 website for 16 different countries. And yeah, I mean, on that, they were trying to consolidate each domain into one unique domain. And they were considering the option of using sub-domains or sub folders. So essentially we discuss it with A/B tested and we found out it was better to use sub folder in the case. So yeah, it was a huge case study. And then essentially we were moving 16 country under one domain.

Keira Davidson (09:11):

Oh God.

Manuel Madeddu (09:12):

Yeah. But each legacy domain used to have, they were going to a sub folder in a different country, different language. Yeah. It was a nice project and yeah-

Keira Davidson (09:30):

I’m sure there was lots of curve balls [inaudible 00:09:30]

Manuel Madeddu (09:30):

Yeah. Also, because with the migration where you are moving a lot of website, you should also plan step by step. You cannot launch every site all in once. Or you have to schedule. So for example, maybe you launch first two sites, which are minor countries, lessons for them and then after a month, so given time to test or whatever, after a month you launch other two and then maybe four and so on. So it’s very interesting.

Keira Davidson (09:58):

Yeah, that’s a good point. I’ve never thought about breaking down it into chunking it to test that everything’s gone okay. And then if it has, you can roll it out to the rest, but that makes perfect sense. And it’s interesting to see that you did some A/B testing around the structuring of the URLs because when I’ve done it, I’ve found that clients have come to me and been like, “Oh, I really want to move from this structure to this structure.” They’ve already decided it. And often there’s no data to back up why they’re choosing it.

Manuel Madeddu (10:32):

Exactly [inaudible 00:10:34]

Keira Davidson (10:33):

Interesting.

Manuel Madeddu (10:34):

Yeah. And it also, I mean, we’ve discussed that because essentially they were using different things for different countries. So for them it was kind of easier using a sub folder structure even for the authority flow. But that depends on you. You can have that discussion with developer team case by case. So sometimes sub domain is better. I do usually suggest and prefer sub folder just for the authority flow. But case by case it’s always different. So you have to check the requirements and specific case.

Keira Davidson (11:07):

That’s interesting.

Manuel Madeddu (11:08):

Yeah. Also, another thing I was thinking, because you mentioned the beginning, when you talk about migrations, it’s true. It’s such a broad term. And I started my career, I said doing websites. So essentially at the beginning I was doing migration all the time because I had client asking me to move a WordPress website to, I don’t know, Magento, for example or the other way around or using, I don’t know, WordPress for the blog and then Magento for the, so I was doing migration all the time. But to me at the beginning, migration was purely when you move a database to another server hosting, whether for SEO. So for professional, when you discuss migration, it involves a bit of everything. So whatever you change on a side that can impact on performance and ranking and visibility, that’s immigration. So even the security protocol. So even if you’re moving to HTTP to HTTPS, that’s a migration which is kind of out at the beginning, but it’s a very broad term.

Keira Davidson (12:15):

Yeah. I don’t think I realized how common they were because I here, I was doing HTTP to HTTPS and that just seemed normal. But then when I was put on, let’s say large scale migrations from one CMS to the other, I was like, “Oh my God, I’ve never done a migration. I don’t know what to do.” Yeah. But you know, because you’ve done it all before you just have to make changes.

Manuel Madeddu (12:42):

Yeah. And then again, it’s always different. So even stuff that maybe went so easy for a client then for another client, because I don’t know, maybe you’ve got two agencies involved in terms of development. It happened to me. I had to work with an agency that were after the front end of the site. And then there was another agency that were after the back end of the site.

Keira Davidson (13:04):

Wow.

Manuel Madeddu (13:05):

Yeah. And then in between there was a client, but essentially, so one developer agency was doing one thing and no one were [inaudible 00:13:14]. So when you do migration, when you support migration, you should be clear or what was going on. But even internally they didn’t know. So was kind of a mess, but yeah.

Keira Davidson (13:28):

So would you say that’s a common occurrence in the fact that communication can be poor when doing migrations, for example, between the developers, the clients and the SEOs?

Manuel Madeddu (13:41):

Yeah. I mean, I would suggest that’s one of the biggest pitfalls. So you must ensure you have a plan, first of all, because success migration, a lot of thing can go wrong. So you must have a plan. The plan must be as clear as possible and digested by the client. Also, the developers, because I mean, you’re always kind of clashing, that’s our job, but you are always kind of clashing with the developers. So the first thing, I guess you must share is you have a clear communication with the developers, they know your roadmap and timing and you both agree and if they change something, they must let you know. And if you spot something, you must tell them as soon as possible.

Keira Davidson (14:26):

Yeah. You want to work as a team and not against each other to try and make it as successful as possible.

Manuel Madeddu (14:31):

Exactly. In a nice way, because it’s not about flagging or telling them this is wrong. It’s about, “We are working together, so this is bad for the clients. So let’s try to support each other.” Yeah.

Keira Davidson (14:45):

So you mentioned before that [inaudible 00:14:49] on the budget depends on what you would suggest for a client. If given the choice, what would be your ideal scenario? Would you want to do a tech order before, continuous monitoring after? Have you ever thought about like the ideal scenario?

Manuel Madeddu (15:07):

Yeah. I mean, of course all the time, because I mean, I guess when you [inaudible 00:15:11] for migration, you just discuss the ideal scenario first and then you go down to specifying what’s needed for the clients. So I mean, ideal scenario, it’s always, yeah. I mean, ideally, when you face migration, the fewer changes you make to the website, the better, which is kind of odd because now I’m saying something and then I’m going to say the opposite. But literally for example, if you don’t need to change your [inaudible 00:15:39] because you might think you can change structure website in order to better target some keywords for categories, but it’s more, the time that maybe search engine takes [inaudible 00:15:52] the structure and maybe retrieve the ranking for those stages to rank better. So sometimes if you don’t need to change your [inaudible 00:16:00] it’s best not to change it.

Manuel Madeddu (16:01):

So this is one approach. So really you should understand what the client is aiming to, what he’s trying to achieve and suggest the best scenario for them. If they’re planning to make changes because they’re redesigning or maybe, I don’t know, restructuring the blog, for example, then I would always suggest if you have time. So for example, if you’ve got three, four months before immigration, I would always suggest that with an audit. So making sure your current side is spot on not hindering performance. So things like even, I don’t know, H1, H2 [inaudible 00:16:41] so all should be sorted with the new side. So audit on the current side then of course, audit on the staging side and in between you should have that discussion with the developers in order to maybe also improve the structure because you can do keyword research and then a bit of taxonomy to better identify the sections.

Manuel Madeddu (17:02):

And then if you have time, you can do it. Then I would suggest to go and get the best shape for the website. If the structure of the client is kind of, I don’t know, the conversation with the developers is kind of lucky. They don’t have a big budget, then I would suggest technical audit on the staging side, for sure. Just maybe avoid one on the current side. And then keyword research. Maybe you don’t need that because you can do it after, a bit of optimization after. So I would say assessing how good the staging site is and then redirect. So of course, I mean, that’s the thing you always do. So you want to map legacy pages or [inaudible 00:17:50]. So that’s the thing you have to always do.

Manuel Madeddu (17:55):

And then that’s for the pre-migration then of course you have to benchmark performance, making sure all the track is in place. And then yeah, that’s all I guess, from the pre-migration. And on the launch day, you have to make sure, first of all, benchmarking, so you have to see what’s going on. You have to also check site map [inaudible 00:18:19] so other search engines able to crawl the pages and the top priority pages. If you see any issue in the [inaudible 00:18:27] file or any section that are not correctly crawled or indexed, flag it straight away, and then also use specific tools to flag new pages to Google or changes address, for example. If you can control it also change external links referring to the new domain, if it’s a domain change and then back any issue.

Manuel Madeddu (18:51):

So try to quickly crawl on the same day and spot any issues. But then I would suggest maybe wait 24 hours for a proper crawl to find issues. And then after that, wait maybe a week or two, at least to support any issues in Google Search Console, for example. Start monitoring performance. And then after a month, just check everything. Check performance, check the issues and then flag to the client.

Keira Davidson (19:20):

Yeah. One thing that came to my mind though, it’s not something that I’ve personally done, but I was wondering, do you know, once the migrations happened, you’ve checked it after the first week it’s going well and everything sort of has settled. There’s no major fluctuations. There’s nothing horrendous that’s gone on. If you have budget, would you want to have a look at the server logs to see how like search engines are interacting with the site to make sure the new URLs are being discovered, for example?

Manuel Madeddu (19:55):

Yes. I mean, in my roadmap again, I always suggest to do the log file analysis after a month, at least [inaudible 00:20:02] because that’s the best way to double check how physically search genes are assessing and reading your website. So fair enough, you can scroll, you can check Search Console or other tools you’re using. I don’t know, extracts for example, for back links and stuff. But I believe [inaudible 00:20:21] give you a better understanding of how actually and physically search engine are reading your website and also you can score further opportunities to improve.

Manuel Madeddu (20:32):

So maybe as you said, if after a month, the performance is good, ranking is good and they maybe drop 5% or maybe they increase the traffic because it may happen. From the log file analysis, maybe you can suggest some optimization to the site structure. So maybe you see [inaudible 00:20:52] going to the wrong place. You didn’t spot before. So you can tell them, or maybe you can see, I don’t know, a server using too much resources because of an index load or to many pages being old. So you can tell to the client to optimize. So yeah, I always include the log file analysis.

Keira Davidson (21:13):

Awesome. That makes a lot of sense because I’m guessing sometimes you might discover bot tracks where it’s just getting stuck in a loop. So it means that crawl budget is being wasted, especially for super large eCommerce sites that wouldn’t be ideal and you can resolve that, which may help organic performance as well. And that would be obviously at that time, you’re wanting to show results to the client. So that’d be, yeah. It makes a lot of sense as to why you do it. I don’t know why I’ve never thought about it before, but it makes perfect sense.

Manuel Madeddu (21:54):

Yeah. But for example, I mean I work on some clients, so essentially for them, I mean at Honcho to we focus on automotive for example. And when you work for automatic website especially when you deal with used cars, you might not want search engines to crawl all the used car pages because they change so often. So essentially you waste scroll budget for search and engines. So it’s not used really. You might want to index crawl an into some of them, but not all of them. So I mean, after immigration, I mean in general log file analysis can provide you bettering side of which section search engine crawlers are within the website. And maybe you find out a lot of used car pages are being indexed and then you can better optimize the robotics file or maybe place our meta robots non index, for example. But even as you said, I mean even bot traps, so faster navigation [inaudible 00:22:59] sometimes. So in those cases, yeah. The log file analysis is really, really useful.

Keira Davidson (23:07):

Especially I can imagine for an automotive site, I’m thinking of Autotrader in my head and on the side by you’ve got so many different variables that you can select and I can imagine that would just be a nightmare if it was implemented incorrectly.

Manuel Madeddu (23:21):

Yeah. You’ve got brand, you’ve got price, of course, but you’ve got mileage, you’ve got a lot of things. So-

Keira Davidson (23:30):

So we briefly touched upon if communication isn’t there, it could be an issue. Do you have any other sort of top things that can be problematic, whether it’s on the implementation or things that you really need to think about when it comes to the implementation?

Manuel Madeddu (23:50):

Yeah. I think this is more in general, not only for immigration, but as soon as you approach a new project, new client, so the technical capabilities, so the development capabilities of the client is something you should have clear your mind for migration. I mean, even if you provide, for example, we were discussing about timing and budget. But if the client has very limited capabilities in terms of development.

Manuel Madeddu (24:20):

So maybe you don’t help them. If you perform a very in depth all day taking four days, five days, and then you provide them with a lot of recommendation and actions because they won’t do it simply. They don’t have capability to do that. And even when facing immigrations, so for example, if it’s a huge side, but they don’t have a time or they don’t have resource in the server to upload, I don’t know, 50,000 redirects at once. So I mean, it’s pointless. I mean, you can take a week to work on the redirects, but when you provide them, it’s impossible. They [inaudible 00:24:57]. So I guess as soon as you approach a new project, you have to have that conversation with the client. So making sure, I don’t know, how big is the development team? What’s the budget? What’s the timing? What’s your target and yeah, because every immigration is different.

Keira Davidson (25:20):

I’ve had lots of discussions with other teams when it comes to launch dates. Do you have a preference on days that you’d push migration live?

Manuel Madeddu (25:31):

It depends on the client because usually best recommendation is launching a new side is in quieter time. It depends on the clients. So if you have a business, which is highly seasonal and usually, I don’t know, maybe in the weekend, you’ve got very little traffic. So it’s best to maybe plan the migration, I don’t know, Saturday tonight. I mean, usually we perform migration tonight, but you might have client for which the seasonality is very different. So maybe I used to work with the clients for which the high season was December. So maybe it was a higher risk planning migration in March, for example. So it depends, but you can easily check the traffic and the seasonality and discuss with them. Yeah.

Keira Davidson (26:26):

That’s interesting. Because when I thought about [inaudible 00:26:30] I’ve taken in seasonality. Because I’d hate, for example, if December was their peak. I’d hate to do it in November because in case anything went horrendously wrong. But also when I’ve thought about it as well, I’ve also gone from the standpoint, I’d usually avoid doing a migration, maybe let’s say on a Friday or a Thursday because if Google crawls over the weekend and for whatever reason something’s gone wrong and we don’t get back in the office till Monday, we don’t got to investigate it and try and resolve it. And obviously the sooner you catch things the better.

Manuel Madeddu (27:07):

Yeah, exactly. I mean, when we are planning migration for the client, we go [inaudible 00:27:14] so we walk in the night, we walk in the weekend or we use specific tools to monitor downtime, this kind of things. So we monitor even if it’s out of hours for this kind of [inaudible 00:27:28]. But you’re right. Usually, yeah, and again, I mean it depends on the client because maybe you’ve got a business, which is usually very busy in the weekends, so yeah. And maybe you see a quieter time for them. It’s I don’t know, Wednesday morning. So yeah, it depends. Yeah. Usually you suggest doing this, I don’t know. Usually I suggest Friday night, Saturday night, but because we can monitor, but it depends on the type of business too.

Keira Davidson (28:01):

Yeah. That’s a good point. Yeah. There’s tools like ContentKing, which will like alert you if anything’s gone horrendously wrong and you can make like different dashboards as well to monitor how the pages being indexed or if something’s like, there’s a significant alert that you need looking at or something like that. So that’s a good point. Yeah. There’s always monitoring to pick upon issues.

Manuel Madeddu (28:24):

Yes. Even on analytics, you can set alerts or you can build a data studio dashboard with alerts just to slack. So yeah.

Keira Davidson (28:34):

So have you ever come across any real, have you basically, the client’s done a migration, it’s gone wrong. Have you then been left to deal with it?

Manuel Madeddu (28:46):

I mean, not personally, but it happened. I mean, once a migration went horribly wrong. So they lost a lot of traffic, but it wasn’t with us. It was with the previous agency. So I’d be quite lucky because you are in a better position to blame them. And then also because you already know what went wrong kind of, and then you can just walk on fixing or be aware of [inaudible 00:29:12]. No, it never happened to me, but I did struggle once with a client because essentially, yeah, I quickly mentioned before, but essentially because there were different agencies involved.

Manuel Madeddu (29:25):

So essentially I was working on my directory, one without map pretty much every day. It was before [inaudible 00:29:32] which was big time with them. But essentially each time me and the agency that was after the backend where kind of fixing issues, the other agency was changing URLs and staff without us knowing. So that’s why, and all of us, on my side, on the backend agency side, and even the client, we were all wondering what’s going on because we are doing the right stuff. But it’s because the other agency was changing stuff.

Keira Davidson (30:03):

So [inaudible 00:30:04] redirect, then you’ve noticed the URL have changed, then you’ve got to redo them and-

Manuel Madeddu (30:08):

Exactly.

Keira Davidson (30:09):

Wow.

Manuel Madeddu (30:09):

Yeah, it was pretty much a week before Christmas. And even on Christmas Day it was horrible. And then I was working, I was remapping everything likely not manually because I’m using a tool. I’m using [inaudible 00:30:23] which can help you in [inaudible 00:30:26] gap. But yeah, it was [inaudible 00:30:28] because the client was panicking. He was trusting us, but because it was before Christmas and the situation, there was spending a lot of money and we worked very close to the launch date has been [inaudible 00:30:41]. So literally they were calling me because at that time I was working in London, but our headquarters were Leeds. So I was even traveling from London to Leeds, but I was having conversational decline on the train and trying to fix stuff while traveling wasn’t happening.

Keira Davidson (31:05):

Yeah. That would’ve been a least favorable kind of experience I imagine.

Manuel Madeddu (31:06):

Yeah. Back exciting because you kind of gained the trust with the client, are still in contact with the client.

Keira Davidson (31:13):

That’s really good. And I guess you’ll have learned a hell of a lot from that and you’ll have changed things in the way that you work to ensure that is never repeated again.

Manuel Madeddu (31:23):

Exactly. I guess when you face the worst, then you are prepared. You go to the next [inaudible 00:31:28]

Keira Davidson (31:28):

Yeah. They can only get better from there. Had another question. It was, man, it’s just gone from my head. It was, I really can’t remember. As you’ve done the migration, you’ve done the [inaudible 00:31:53] you’ll have checked analytics, Search Console. I’m guessing you’ll have checked keyword rankings. Would you also look at measure visibility to see how the market shares gone? Would you have a look at as well see if there’s been any changes to backlink profile?

Manuel Madeddu (32:16):

Yeah. Again, I mean, it relies on what the target have, but let’s say in the [inaudible 00:32:21] when you’ve got the budget that you’ve got the time in. Yes, I would do that. So essentially for each migration, I would try to have data from each available sources because a lot can happen and a lot can go wrong. And even, so sometimes you’ve got current redirects in place that you don’t even know so best to us, to the developer, have you got something in place already? Have you removed pages in the past? But they might not even know because even the developer agency, essentially, if they changed staff three years ago and [inaudible 00:32:59] one year ago they made the changes before them on board. So they might not even know.

Manuel Madeddu (33:06):

So that’s why I will try to gather, not trust one source, but use as many source as possible. So for example, I personally, even when they tell me, “We discontinue some pages, remove these products.” I kind of never trust. I would always check for example, analytics. I used to receive traffic and then crawl them to see if their response code is okay or broken then double check, for example, external backlinks. So sometimes if have time, if at a budget, but I would export from [inaudible 00:33:43]. So historic backlinks and see if they’re going to discontinue pages. I mean, if you can address it, it’s kind of a quick win because in post migration, if you can retrieve the traffic, even if they’re broken, but if you can retrieve the traffic, it’s a quick win. So you would see a [inaudible 00:34:04] traffic. So, yeah I do.

Keira Davidson (34:08):

That makes sense. Yeah. I guess, to wrap things up, what would you be your five top tips for someone when it comes to migrating of any kind?

Manuel Madeddu (34:21):

I would say always, maybe the top one is hope for the best. But I expect the worst, which is [inaudible 00:34:29]. It is like when you study, I mean, at the university. I always perform better and my maximum when i was expected worst. When I feel too much confident, it’s where the thing go bad. So yeah, I guess my first recommendation is, yeah. I mean, hope for the best, but then work for the worst.

Keira Davidson (34:50):

Be prepared at least so [inaudible 00:34:52] shock.

Manuel Madeddu (34:54):

Exactly. And then never be too confident because try to plan everything, but never be too confident. The client understands, the developer understands. I mean, try to discuss everything and ensure everyone is on the same page and the communication. If they change something, if you change something, if the client is pushing back something. Let’s make sure you know, everyone knows and yeah. And let’s try to stick to the deadlines as much as possible. It never happens because with migration-

Keira Davidson (35:25):

They all get [inaudible 00:35:26]

Manuel Madeddu (35:27):

Yeah. But let’s try please to have a conversation and then try to plan as said in a clever way. So you don’t need to plan like big audit if the developers are struggling. So try to work for the client to improve performance or [inaudible 00:35:46] to avoid issue in migration. And how many I counted? Is like three, four.

Keira Davidson (35:52):

I think we’re at four.

Manuel Madeddu (35:52):

Four. Yeah. So I’d say, yeah, try to gather data from as many sources as possible and never trust one source. So try to always be a bit critic, not really rely or trust the data people give you, but try to double check always and from different sources.

Keira Davidson (36:15):

That’s a really good one because a lot of the time people rely upon one source and that source might not always be correct, or it might be delayed. That is a really good point to make.

Manuel Madeddu (36:28):

Yeah. Especially if the source is coming from the client. So essentially if you are supporting them, but you ask the developer to provide you something which is wrong, then you can’t really blame them because it’s your fault to not double check for example. So it happens with a migration. I was happy I wasn’t working that migration, but it happened that a colleague asked for, for example, discontinued products and the developer provided a list of discontinued products, but it was like one third of the [inaudible 00:37:02]. But you can’t really blame them because you should check.

Keira Davidson (37:08):

Yeah. They would assume what they thought was right.

Manuel Madeddu (37:12):

They don’t know because maybe again, maybe [inaudible 00:37:14] be hired one month ago, two months ago, a year ago. The client himself doesn’t know maybe. Yeah. So-

Keira Davidson (37:23):

No. They’re really good tips and I’ll definitely keep them in mind when I’ll be approaching my next migration. So I really appreciate that. Thank you.

Manuel Madeddu (37:30):

No problem.

Keira Davidson (37:30):

Thank you so much for joining me as a guest on this podcast. It’s been really good to talk about migrations and you’ve left me with lots of different things to think about when it comes to approaching them in future.

Manuel Madeddu (37:47):

Okay. Yeah. Feel free to [inaudible 00:37:48] any more questions.

Keira Davidson (37:53):

Manuel Madeddu (37:56):

Yeah. We briefly discussed before the recording, but I guess [inaudible 00:38:01] migration are very exciting because they give you the opportunities of test your knowledge on everything on SEO. It’s not just about technical. It’s not just about content or [inaudible 00:38:15] for example, it’s also about backing. So it’s all together. And then-

Keira Davidson (38:21):

Every pillar of SEO is almost covered in every migration.

Manuel Madeddu (38:26):

So it’s really test your knowledge and you face the challenge. If it’s successful, it’s exciting. If it’s not successful, then you have to keep doing it, but you always learn. So it’s nice.

Keira Davidson (38:37):

Yeah. That’s a good point. Yeah. Even if it has gone wrong, there’s so much that you can take away from it that can be turned into positives. So yeah. That’s really good point to make as well. Thank you.

Manuel Madeddu (38:52):

No problem.

Keira Davidson (38:53):

Thanks very much for joining me. I’ll let you know how they go.

Manuel Madeddu (38:58):

Okay. Thank you. Yeah. It’s been nice to have a chat with you and exciting. So I hope it’s helpful.

Keira Davidson (39:05):

Thank you. It has been really helpful.

Manuel Madeddu (39:09):

Okay.

The post S3E9 Manuel Madeddu, How To Approach A Migration appeared first on The TechSEO Podcast.

Keira Davidson (00:24):

Hello, and welcome to the TechSEO podcast, which is hosted by myself, Keira Davidson, a senior SEO executive at SALT. This episode is with Robin Allenson, who is the CEO of Similar.ai. How are you today?

Robin Allenson (00:43):

Keira, thanks for having me. I’m feeling great today. How are you?

Keira Davidson (00:47):

I’m good, thank you. It’s quite nice. It’s quite sunny out today. We’ve had a month’s worth of rain. I don’t know about you.

Robin Allenson (00:53):

Yeah. Well, I’m in Holland. It’s sunny today. It was sunny yesterday. I’m just bracing myself for the next 11 and a half months before we get summer again.

Keira Davidson (01:03):

Oh, wow.

Robin Allenson (01:05):

No, I’m joking.

Keira Davidson (01:07):

I had a little bit of looking into you and noticed that you’ve been in the industry for a little bit of time, and you’ve worked at some really interesting places, such as Yext, and you are now a CEO. How did you initially get into the industry?

Robin Allenson (01:29):

Way back when, a long, long time ago, I used to help a company called Red Fish make websites. And gradually, after that, we did a lot of different online work, but this is, oh, 20 years ago. And then, around 2009-ish, I started working at Yellow Pages and we built search engines for Yellow Pages Online to work on, and, as part of that work, I started helping Yellow Pages out with SEO. Actually, so Yellow Pages, I guess, was more 2005 or so. After that, I left Yellow Pages and started a new startup called InnerBalloons, which is a terrible name for a startup, and I won’t recommend that to anybody, but it was an anagram of my name.

Robin Allenson (02:14):

And then, InnerBalloons, we did a bunch of different things, mostly focused on SEO for verticals, and also conversion rate optimization for verticals, and then we gradually pivoted towards selling presence management and reputation management, and we used a lot of AI to build out a presence management product, so local SEO. And then we got acquired by Yext at the end of 2014, and so then I came on board to help them kickstart their operations in Europe. And then I left Yext a year later, because I think they wanted me to manage the existing business and I was interested in building out something completely new, and then, shortly after that, started similar to Similar.ai. And so we’ve done a bunch of different things as well at Similar.ai, but we’re really focused right now on how we scale SEO through APIs for marketplaces.

Keira Davidson (03:22):

Oh, that’s really exciting. I think marketplaces, from my point of view anyway, are often left behind. There’s so many opportunities and so much to learn from them from a technical perspective, but they’re usually just forgotten about.

Robin Allenson (03:40):

Mostly, what you see, there are in-house SEOs, product managers are working with a team of developers at a marketplace. Often, those developers are tasked with doing lots of different things for the marketplace, it’s not just SEO, but, yes, there’s a lot of opportunity. We talk about an inside out versus an outside in way of thinking about a site. Inside out is you take all the product taxonomy you have and, often, these sites, they have an existing site taxonomy, which is quite old, and it doesn’t always match up to how users search, but they just take all the different combinations of that site taxonomy, and so you might see a lot of things that look like faceted navigation, all the possible attributes, and you might also see pages that they could create that would match up to how users are searching now, but aren’t in the site taxonomy, which was created a decade ago.

Robin Allenson (04:46):

And so there’s a lot of missing opportunities, both too much, too many pages, and I think a lot of sites successfully took a what I call a spray-and-pray approach. You take all the possible combinations of product attributes and you turn those into pages and you get these incredibly long-tail pages. And some of those ranked and some of those got traffic, right, and a lot didn’t. And, after a while, after a few years, Google starts to get fed up with investing time and resource in crawling all those pages because many of those pages don’t match up to demand and many of those pages don’t have unique content, so they’re not sought after and they’re not interesting.

Robin Allenson (05:28):

Those are the problems that you often see, but they’re both problems with too many pages and they’re problems with lacking pages that match up to demand, so they’re missing pages. Site depth is a big problem. You have incredibly deep internal linking that’s not actually linking to pages that users would love, and a lot of those are just enormous long lists of listings. That can look a bit spammy to Google. Adding a small amount of content on those [inaudible 00:06:00] pages to orient the user could be enormously powerful. Those three problems are the things that Similar.ai is uniquely focused on.

Keira Davidson (06:09):

Yeah. And they all relate around duplicate content, duplicate pages, poor value. They don’t really provide much of a benefit to organic performance. If anything, they’re hindering it because they’re diluted link equity, they’re unoptimized crawl budget, just crawl bloat. There are so many issues that can be caused by what you just mentioned. And we briefly touched upon, before we started the podcast, about how, well, there are different approaches that you can take when it comes to deduping large sites. And, for example, if a site only has, let’s say, 100 pages, it’s quite easily to just manually do it. It might be that the product has five different alternatives and you only have 25 products. It’s not going to be horrendous to do manually. Whereas, when looking at a site that’s got, let’s say, hundreds of thousands of pages, maybe millions, it’s just not possible. No human is capable of going through each … and analyzing the data and determining what’s duplicate, what’s not, within a reasonable timeframe.

Robin Allenson (07:35):

That’s it.

Keira Davidson (07:37):

How would you approach this?

Robin Allenson (07:41):

That’s a great question. What we’re doing is really building software as a service product to be able to handle this at scale. And we split up the cleanup of superfluous pages, pages that aren’t adding a great deal of value, into two types, and they definitely overlap as well. This is the cleanup part, but we also do … we add internal linking and we add automatically-generated dynamic content that’s based on how users search. We call that user-centric content. Those are other pieces I won’t be going into as much in depth, but adding content that matches up to how users search, it matches up to search demand, is very powerful, also, for making the difference between pages more explicit. And so our goal with the whole platform is to make every single site and every single page on the site match up to a sought after user intent for which the site has answering content.

Robin Allenson (08:54):

And so, for most small sites and large sites … and so you were mentioning marketplaces with maybe more than a million pages, one of our larger customers has 600 million pages. Another customer has more than 50 million products. These are just gargantuan sites, and so we split the cleanup work into two parts. One is what we call classic duplication, so very similar to keyword cannibalization, except rather than at a keyword level, we’re looking at all the pages which answer the same user need. And so you might have 100 keywords or even 1,000 keywords which all basically answer the same user need, and sometimes people without search intent, other people would call that a keyword cluster or a topic, and we look at all the pages that target the same user need. We work out which is the best page on the site, and then we offer a file which lists out all the weaker pages and the single canonical stronger page.

Robin Allenson (09:58):

And then the site owner, so, typically, the growth product manager or the in-house SEO, decides, are we going to 301-redirect those, are we going to add a canonical tag, which is mostly for marketplaces, that’s probably too weak a hint, but that can work, especially if, on the site, users will actually see some of those redirected pages and they might navigate to those on the site themselves. You’re going to have to remove the internal linking to that. You’re going to have to make sure people don’t accidentally go there except through Google. But if you are unable to do that for some reason, then maybe a canonical tag will be fine. Other growth managers would actually prefer to add 410s, so a discontinued product way of thinking about it, just because there’s no link equity there.

Robin Allenson (10:55):

The pages that we’re deduping, they don’t have traffic, yeah, they don’t have demand typically. We’re looking at the vast majority of pages that really don’t have any chance of ranking and we’re trying to clean those up first. That’s the first target, so pages which share the same user need. And then the second group is pages which don’t target enough demand, and so there’s an overlap there. Sometimes those pages really aren’t interesting either, but what we’re doing is we’re matching those pages up to topics or to user needs and work out the total demand for the user need. And, if that’s less than some threshold level, say, 100 searches a month in the U.S. last month, then we … oh, I’m being spammed.

Keira Davidson (11:54):

Don’t worry.

Robin Allenson (12:00):

If that’s less than some minimum threshold, then we flag that page as being what we call a page to hide, and so it’s just something that you wouldn’t like to surface to search engine users or to search engines. And, again, there are some different approaches to hiding that. You might just orphan those, you might just remove that from the site map, because that’s typically search results pages that haven’t had traffic, that aren’t organically ranking, but also, more importantly, they have no chance of ever getting traffic. Even if they rank really well, they’re only going to bring in a dribble over time. Some really big sites get a ton of their traffic from really long-tail pages, so you might want to set that threshold much lower, but we look at both of those as a cleanup, so both deduping in the classic sense and also hiding pages.

Robin Allenson (12:57):

And so, under the hood, we’re building for a certain [inaudible 00:13:04] to say this is a fashion marketplace, we’re in the U.S., we’re building a transactional universe of all the possible keywords with which people could search for fashion in the U.S., and we’re pulling in all the keywords that the site ranks for as seen through Google Search Console API. And so, pulling in through the API, you get a much greater granularity than you can see in the search console’s user interface, so we merge those together. You’re typically talking about millions of keywords. And then we cluster those, we group those by user need. And so, for a single topic with the same user need, you could have five or 10 or a 100 or 1,000 individual keywords.

Robin Allenson (13:50):

We’re adding up all the search volumes. We’re getting rid of some of the search volumes that are incorrect. Misspelled keywords often have the same search volume as the correctly spelled ones, so we detect that and we remove those. Sometimes there are other aberrations in the search ones you get. We work out what the actual real topic demand is and then we use that as an underlying platform both for the deduping based on user need and also working out which pages are pages to hide. Sorry, that was a long explanation, but that’s how the cleanup part of the platform works.

Keira Davidson (14:29):

One thing that stuck out to me during that was using a 410 to highlight to search engines that it no longer exists, and I hadn’t thought about that. I just thought of canonicalizing, redirecting. That’s really interesting. I’ve actually made a note of that.

Robin Allenson (14:51):

Yeah. I think there’s four, and so the 410 was new to me too. I think it’s one of the joys about working and focusing on marketplace SEO is that we get to work with some of the most brilliant in-house SEOs, and they’ve been thinking long and hard about how to do this, right? And so, often, what we see is lots of these marketplaces have in-house efforts to do deduping, but they find the engineering effort is considerable, so they often do that one-off, or they’ve done it with an agency and they’ve done it for some parts of the site. And then they have a lot of thought about how to approach this and sometimes depending on how bloated the index is and how many of those pages they really have to get rid of.

Robin Allenson (15:48):

Some of the sites we’re working with are working through hundreds of millions of old pages. And so you can clean up a lot and still not see a great deal of benefit because they have a lot of backlog, right? They’ve been doing this for a decade, right, and there’s a lot of stuff there. Some of them just say, “Look, these pages, they have zero link equity, we have actually no interest in them, so all we’re going to do is we’re going to add a 410 and we’re going to add that to the site map, and when Google crawls that, then they’re going to remove that, and that’s going to be effective.” Others say, “Look, there’s still something there. The long-tail pages are super important to us. So we’re going to redirect to a relevant page.”

Robin Allenson (16:24):

And so 301, I think, is the default approach we see in, I guess, 70% of customers. 410 has come up recently, so we have that connotation. Others say, “We’re just going to orphan pages. We’re just going to remove internal linking and remove it from the site map. We don’t really think most of these pages are in the index anyway. We’re just going to ignore that.” You see some different things, but it’s cool because you see a range of different … I was exactly what you said, so I thought, “You’re going to 301, right, or add a canonical,” but, if you have a few hundred million pages, I think canonical, it just seems like too weak a hint. That was all I thought of, but I continue to learn from our customers.

Keira Davidson (17:18):

Yeah. My mind’s now just still thinking about 410s, about how they’ll naturally just fall out of the index, and how actually, initially, when I was thinking of it, it was like, oh, that is a really good … imagine a Band-Aid, you initially put it on, and then, if you later wanted to revisit it, you could. You could put in a different approach, but there actually won’t be a need to do another approach-

Robin Allenson (17:41):

No.

Keira Davidson (17:41):

… because it actually will solve it further down by search engines no longer needing to crawl the page. They’ll naturally just remove it from the search. I actually quite like that approach now.

Robin Allenson (17:58):

When we talk to clients who don’t have a great deal of knowledge of SEO, then they’re often very interested in adding things. They want to add more linking, they want to add more new pages, and often there are great opportunities to drive traffic that way. But the more experienced the SEO, and a lot of the in-house SEOs you work with at marketplaces are extremely experienced, yeah, they say, “We can’t get to all that interesting stuff of adding pages and adding content until we’ve cleaned up our debt, right?” Our programmers talk about technical debt. We’ve got this enormous page debt that we need to clean up first and there’s just a lot of bloat, right? We’ve got to work on subtracting pages first and then we can focus Google’s attention around … we can put more wood behind less arrows, right? And so that’s the number one and two and three goal. Yeah, then these kind of approaches can work well, but it was completely new to me, as well, until a few months ago.

Keira Davidson (19:02):

And you briefly mentioned, obviously, if you orphan the page, you’ll want to remove the internal links. Do you know if you’re, let’s say, 301-redirecting of that 410 and you’re probably going to want to point the internal links straight to the end page instead of creating redirect chains. Do you have a way of almost automating that instead of having to go in manually one by one? Can you create a rule or something?

Robin Allenson (19:31):

Yeah. That’s a great question. We crawl all the pages. We build out this intent universe or topic universe or keyword universe that’s got all of the intents. It’s interesting, actually, for a big domain, you might have millions of keywords, but, typically, you’d have 10 of thousands of user needs, so that actually comes down to a surprisingly reasonable manageable number, except that many of those user needs have tens of different keywords that can express that same need. And then we match those up to the pages and we work out, for pages which share the same user need, what the strongest page is. And then, typically, we’re recommending 301-ing to those strongest pages.

Robin Allenson (20:24):

But sometimes we’ll start by only looking at pages which don’t rank or only looking at pages which don’t get traffic, and then thinking more carefully about if you have … We have some examples where there’s 10 pages, which all target the same user need, and so, less for marketplace … in marketplaces, you’d see more things like … it depends. Some marketplaces are really focused on … they have a really strong internal taxonomy, and they used that without thinking are there users who are looking for this combination of attributes? Other marketplaces have used on-site search as a proxy for Google search, and so they create pages internally at different places within the site taxonomy and with different tags, which correspond to what users have typed in.

Robin Allenson (21:17):

But users, just like you see if you look at Google Search Console data, users misspell things all the time, right, and they’re searching in different places on the site, so we might have 10 or 20 pages all targeting the same … I’m thinking about an automotive example. There’s a Volkswagen Polo, and then there’s, I don’t know, five different misspellings of Volkswagen because, mostly, car brands and makes and models, they’re foreign words for everybody, and people misspell foreign words, so people misspell those. Polo, you’d think it’d be simple, but you’d be amazed, right? There’s lots of misspellings. And then, also, there is a place on the site for the Volkswagen Polo, but there are lots of other pages that are created elsewhere on the site.

Robin Allenson (22:05):

We crawl all the pages, all the [inaudible 00:22:08] pages. We’re pulling them all in and we’re matching up to what topics they match up to or what user needs they match up to and then we’re identifying which user needs are common, and then we’re trying to work out what is the right page to redirect to. We also have pages which don’t have any demand, where, again, if the client would like to 301, then we need to find a relevant page that has demand, that has listings or has content, to which we can redirect those pages, and sometimes there’s going to be overlap in those. And, when there’s overlap, we need to be very careful that we don’t create a chain or we don’t create loops, as an example. We’ve built software that does that.

Robin Allenson (22:52):

Before we create the export … really, the way it typically works, the marketplace builds a very simple service on their side to do a 301-redirect based on a bulk file of weak pages going to stronger pages, and then we give them all the information of, “Here’s the list of weak pages and the stronger page to which you should redirect them or to which you should add a canonical tag,” or whatever that might be. The actual implementation on their side is very simple. And then, on our side, we’re doing the heavy lifting of working out which pages are tied to the same user need and how we check for overlaps.

Robin Allenson (23:31):

And then we make sure, for the whole of the site … and so, for a small implementation, we might be talking about millions of tens of millions of pages, right, so it’s pretty high scale, but then, yeah, we’re checking that there aren’t chains or loops in there before we hand that file over. We’re typically doing that in bulk so that, every day or every week or every month, we could hand over a new file and we could make updates to those things or remove redirects that were there.

Robin Allenson (24:03):

That’s part of the advantage of doing that in an automated way. The disadvantage is it’s insanely complex, but the advantage is, well, it’s going to be pretty complex anyway, but now we can actually enforce that with software. Because we think doing deduping at this level, it’s not the kind of optimization problem for humans to execute, but that’s a machine problem, that’s machine learning, that’s a software problem, but you still need people on the other side to work out, well, should we be doing a 301, should we do that for pages with traffic? There are lots of permutations to think through the strategy, and I think that’s the kind of thing that’s not easily codifiable, that you need amazing SEOs for, but going through page by page and working out does this match up to the same intent, yeah, I think that’s software and AI work that the SEO should hand off.

Keira Davidson (25:01):

Yeah. That’s so interesting. My mind is just going 100 miles per hour just thinking about all the different possibilities and different approaches. It’s really interesting. I really appreciate you joining me today. I’m definitely going to be looking into this a little bit after we finish up here today.

Robin Allenson (25:22):

Happy to give you a demo one-on-one, and, if there listeners who’d like to see how this works in practice, always happy to show them around what we’re up to.

Keira Davidson (25:31):

That’s perfect. Thanks so much. Really appreciate you taking the time out of your day to join me and thank you so much.

Robin Allenson (25:40):

Yeah. Keira, it’s been wonderful. Thanks so much for inviting me.

Keira Davidson (25:42):

No worries.

The post S3E8 Robin Allenson, Deduping Large Websites appeared first on The TechSEO Podcast.

Keira Davidson (00:21):

Hi, welcome to the TechSEO Podcast. I’m Keira Davidson, your host, and I’m joined today with Sophie from Rise at Seven. Thank you very much for joining me. Don’t suppose you’d be able to give a bit of background information on yourself and your experiences in SEO to this point.

Sophie Gibson (00:41):

Sure. So I’m Soph Gibson. I currently work at Rise at Seven as an SEO strategist. Previously for this, I’ve only really worked agency side. So I tend to work a lot on e-commerce websites. That’s kind of my jam. I love shopping. And I love talking about shopping. I love analyzing websites that talk about shopping.

Keira Davidson (01:04):

What’s your favorite thing to shop for?

Sophie Gibson (01:09):

You know what, anything. I suppose clothes is my favorite thing. So I like looking at ASOS and Next, those kind of retailer websites. Find really interesting, nevermind, it’s kind of, because you’re already interested in kind of the stuff and you know the technical side of how stuff should be implemented and whether they’re getting the best…

Keira Davidson (01:37):

Out of it.

Sophie Gibson (01:38):

… for their book with how the website’s set up and what pages are indexable, et cetera. So I find it really interesting that I now can’t go shopping without analyzing that stuff.

Keira Davidson (01:48):

You’re the exact same as me. I was recently having to look into infinite scrolls and find examples. So at the weekend, when I was just looking at, on different sites for clothes or something, I would then get a bit sidetracked and start looking at how they’ve implemented their infinite scroll, it’s such a sad thing, but I just enjoy it.

Sophie Gibson (02:13):

I know. And you notice stuff straight away. I find, whenever I see a URL that looks like really horrible and long I’m like, “They should have really looked at that.” Be looking. So Animal Crossing teaming up with Build-A-Bear.

Keira Davidson (02:37):

Yes, that’s cool.

Sophie Gibson (02:37):

So they’re going to be releasing some Animal Crossing toys and they had a sign-up page to register your interest and it was such a long and complex URL, which had like platform details in it, it wasn’t set up properly for good SEO from that kind of perspective. And I was just like, “Sharing that on social is going to be very difficult. And how are people going to find this?”

Keira Davidson (03:04):

I can imagine that had some impact, people not being able to easy find it. It’s not like a URL where you easy just type it in especially if it’s like gobbledygook and just random letters.

Sophie Gibson (03:17):

Exactly. And it’s not like the be-all and end-all of a website, but stuff like that you can’t help but notice.

Keira Davidson (03:26):

Yes, exactly. So that brings us onto, so you love shopping, you love retail e-commerce websites. How would you go around, let’s say doing competitor analysis for those kind of sites, is there certain areas that you’d focus on or would you, especially with ASOS, for example, it’s such a large e-comm site would you like chunk it almost?

Sophie Gibson (03:54):

I think usually I start off just clicking around like a user. I find whilst, yes, looking at tools and over information on site, like that is kind of good to do. I find just having a look around yourself and finding how the site is linked to, each section is linked to each other, if there’s any common themes that jump out. Because with e-commerce there’s general things that tend to be an issue.

So looking at stuff like navigation, how stuff’s linked by the collection, so where the new collection pages if they actually are set up correctly, or they’ve got multiple versions of collections, because they’ve got the featured products, and then they’ve got new in, that kind of thing, and how that’s set up. And then you’ve got your additive navigation. So generally on bigger sites, that’s always, there’s usually some kind of problem with whether those kinds of pages are getting indexed or not. Now, I think being aware of what the top issues tend to be, I find that’s usually a good place to start checking those key areas.

Keira Davidson (05:21):

I guess that saves so much time, as well, because you sort of highlight how the user sees it. And then also you get to the point, and you get straight to it, uncovering those potential issues early on instead of potentially going away, getting all this data, and then being like, “Oh God, I need to do this. This is what’s actually caused the problem.”

Sophie Gibson (05:44):

And I think it’s kind of unpicking it from that point of view. So starting small with just choosing those top level stuff, which could be a problem, and then digging deeper to find out how much of that is a problem. I really like that kind of way of working instead of going straight into looking at loads of data. Because it can and feel a bit overwhelming, especially when you’re looking at bigger e-commerce sites. I mean for smaller retail websites that have a limited product range any issues tend to be a lot smaller.

Keira Davidson (06:24):

Big sizes can be very messy.

Sophie Gibson (06:27):

It can get very messy, very quickly. So being able to pull out key things and then finding out from that how big of a problem each area is, what the top common issues are and how much of the site has that issue. I think that’s really good way of sectioning it out because it can be really daunting, I think, approaching big retail websites.

Because, I mean, I’ve come from working for a very small retail business and viewing site audits on very small websites up to bigger ones. And the process is the same, but it does feel a lot scarier, especially if you’re dealing with clients yourself, because there’s so much more at stake. There’s more people involved. As companies get, you not just got a point of contact who owns the business you’re actually speaking to people who then have to report stuff to higher management. And then you’ve got to tie in, make sure that all of your recommendations actually get implemented if you’ve found some key areas and you can say how much of a problem each area is, then you’ve got to be able to then communicate it, but in different ways to different people, depending on who-

Keira Davidson (07:57):

That’s something I’ve been learning recently.

Sophie Gibson (08:01):

It’s really, again, it can be daunting, especially when you’re kind of new to working on larger sites. Definitely want to think about… And there’s always more to learn.

Keira Davidson (08:17):

Exactly. No, definitely. It’s like, especially when you get onto a larger site, you initially you’re only just scratching the surface and you might find there’s like initial problem. And then when you start truly looking into it, you reveal this massive iceberg sometimes. And then when trying to convey the importance to your point of contact can be difficult, especially for them to relay it to the right people. It’s really important and tricky, I personally find, to speak to them in the language that they ultimately understand.

Sophie Gibson (08:57):

Definitely. So I know there’s a lot of talk of, to be able to appeal to those highest stakeholders and people up in the business is trying to tie technical fixes to some kind of revenue. And it’s a very hard thing to do because it doesn’t help that most of the stuff that we’re able to measure, we can’t even say that Google Analytics is a 100% accurate. With GDPR, we can’t track absolutely everyone. There’s some information there, you’re tying stuff from case studies, from other people’s information because you can’t necessarily say that implementing action X will equal revenue increase Y. That’s just impossible to do. We can only really estimate.

But I think as long as you’re able to keep pulling out figures, being able to, at least, give an indication of a general ballpark of where the money is, I think, it’s much easier to then explain to stakeholders. “We want to prioritize this, faceted navigation bits, because it’s costing you at the moment.” Like a certain amount in loss sales, or it could be worth an extra X amount.

Keira Davidson (10:33):

Exactly. I think definitely having data or estimated data can help persuade implementations and ultimately people buy in.

Sophie Gibson (10:49):

Definitely. So I think that’s the more complex side of working on e-commerce sites. And when you’re looking at, as well, competitor sites, being able to estimate either what they’re doing, I think, that can be obviously a bit harder because you’ve not got the internal data there. So you’ve got to estimate based on publicly accessible data. So when I did my Brighton SEO talk, it was about all the different free tools that you can use to get data insights on competitor sites. And there’s a few different places that you can look. There’s a lot of case studies that can give you figures.

And there’s, I think, it’s Similarweb that has general traffic estimates for other websites in your industry. So it can give you stuff on e-commerce and other kind of business areas. So that’s always a good place to look if you’re wanting to get some general ideas of what competitors are up to, what their organic traffic looks like, whether they’re reliant on PPC, or how much of a percentage of their traffic goes to that. But of course, I’m sure there’s people that work at those things that would tell you the Similar information is completely wrong. But being able to at least have some kind of indication of figures and even just showing the process of that being worked out, I think, is really beneficial to clients.

Keira Davidson (12:40):

I’d agree on that. I think, no matter what we say, ultimately it’s got to be taken with a pinch of salt because we can’t guarantee anything. We don’t truly know, ultimately, what their competitor’s ultimately doing. And I think it’s a really good guide to at least provide the client.

Sophie Gibson (13:02):

For sure. So I’m thinking about other tools as well. So I think when we’re looking at a lot of data on competitor, most tools generally have information on whether it’s keyword intersect to see what share of different keywords your competitors have with you. You know, that information’s kind of really good from a top level, because you can… A piece of work I’ve done recently is looking at whether this different areas of products that the site that I’m working on has, and whether they’re actually missing out on traffic or whether it’s stuff that they don’t sell. So being able to find what products other sites getting lots of traction for that we are not. So I think it’s always a good way to just confirm that the right products are being focused on.

Keira Davidson (14:08):

I think that’s a really good idea actually. I’ve never thought about it from that side of things. Because it could help, ultimately, guide this or help guide the clients with potentially diversifying their product range or considering investing more in a certain area. I think that’s a really good idea actually.

Sophie Gibson (14:33):

It was really interesting because it was useful for them as a business as well as the, not just the SEO strategy. So I think uncovering that kind of information’s always really good in the context of looking at competitors and how you can use that information to help your own decision making.

Keira Davidson (14:59):

Can probably help confirm them as a business, the direction that they want to move in.

Sophie Gibson (15:06):

And I think it’s really good way to see what websites area of uniqueness as well. Because you can say we dominate a certain area because we’re the only people that have that stuff. So again, you could be like, maybe we need to use that idea as, push that as our USP, our unique thing, this is what we do better than anyone else. I think there’s all sorts of information you can get from that kind of, just looking at what keywords people are ranking for on different sites.

Keira Davidson (15:46):

Definitely. Like my mind’s going crazy. I’m thinking, you could get a whole branding strategy concept from this. You could get new product lines. And then also opportunities for on-page SEO growth and stuff like that. So many different routes that could be taken from just looking at the products.

Sophie Gibson (16:07):

So I really like data for that kind of analysis. Because I think sometimes, as well, when looking at the third party tools with keyword information on, sometimes we can get, maybe, a little bit stuck in the keywords as well. So I think it’s really worth remembering to visit the site sometimes, type in a keyword yourself. I know sometimes our location might have an impact on what comes up. I think it’s really good to see, from your own eyes, what kind of content is being served up when you type a phrase in and seeing how your competitors position themselves in the TRPs and just what’s on there.

Keira Davidson (16:56):

The intent for a keyword can be so mixed. It could have like product pages, category pages, but then it could have like list posts, comparison pieces, it could be such a mixed bag. So I think definitely checking, just putting the keyword into Google can give so much information, as well, to make sure you’re going after the right thing. Because it’s great looking at volume and everything, but it’s not the be-all and end-all.

Sophie Gibson (17:23):

For sure. Because I always find, as well, sometimes there is other meanings to words that you wouldn’t necessarily think of if you’re either not in the industry or you are in the industry, and you wouldn’t think of how other people use a term. I’m trying to think of an example, but it’s really hard to think of one specifically.

Keira Davidson (17:47):

I have one off the top of my head. I’ve got a butcher’s client, well, they’re basically an online butchers. And we found that they have a load of jargon heavy terms that they use for the cuts of meat. For example, like a tomahawk steak is quite commonly known, so that’s what the user search is. But for a more, let’s say rare cut, I’m trying to think of what, I could try to think of one, but let’s say, for example, minute steak, that might not be something that you or I would typically use. But it’s what they know. But it doesn’t mean that it’s going to bring the right people to the site.

Sophie Gibson (18:30):

Exactly. I think really focusing on what language people use and just making sure that your expectations are reflected in the search results. Because sometimes you can think you’d know exactly whether a term would be, have a lot of products on it or that’s the term that people use, but sometimes you can get shocked about what alternate meanings of what other stuff.

Keira Davidson (19:09):

You can get some interesting insights. I think that’s why I really like keyword research because you get the chance to learn about the topic for almost like a day, and you learn some bizarre things and random facts. And then almost a week later you’ve forgotten it.

Sophie Gibson (19:27):

I find that when you’re writing content, as well, for kind of niche sites that you do start learning very random stuff, which you don’t think, I don’t even think would help me in a pub quiz. I think, maybe, random stuff like, for example, I could tell you all about the different types of decorative aggregates that you could get for a garden, which is like pebbles and stuff.

Keira Davidson (19:51):

At least you know, though, if you ever have to decorate your garden or redesign it, you have different ideas and you know what to look for.

Sophie Gibson (20:01):

Exactly. So I think definitely check your assumption on that kind of thing. Because as well, sometimes a competitor can be using different terms and getting more of a benefit from it than you might be. Because I think sometimes, maybe, clients can’t see past their own knowledge a little bit. They wouldn’t expect, this is what we call the item, so why would we not use this word?

Keira Davidson (20:37):

Exactly.

Sophie Gibson (20:40):

So if you’re talking about PVC something or other, just trying to think of clothing, people say pleather, like you wouldn’t say PVC leather, maybe. So just making sure that the actual words do match up with what you want to see. I think looking at the different keywords you and your competitors are ranking for can show that up sometimes.

Keira Davidson (21:15):

And it’s quite important to be doing that. Especially like it can probably highlight, well obviously it will highlight keywords that you are not targeting, but by giving them a quick search you can quickly determine whether it’s something you should go after or shouldn’t.

Sophie Gibson (21:32):

Definitely. So I think being able to weigh up that as well is quite an important skill when it comes to doing competitor audits. Because you do have to weigh up whether going for an additional term that your competitors do use, perhaps, whether it’s worth that or not. Or whether you look at a different product, is there actually space for you to make an impact or is someone else very far in and it would take a lot of effort to go for that kind of keyword. So being able to dissect that a bit more, and pull in some numbers, and at least, showing how you stack up against the competition. Because it’s all well and good looking at them separately as an entity in itself, but really it’s about whether there’s room for you to take on that area.

So I think when you’re looking at different aspects, being able to perhaps rate each section to say, product X, Y, Zed, how does that stack up in competitors? Because we also may sometimes forget that it’s different in, for each different product area. So just in [inaudible 00:22:58]. If you’re selling, I don’t know, gym equipment that you might have completely different competitors compared to your trainers, for example. So I think being able to actually, accurately, convey to someone who their competitors are online versus who they think their competitors are is also really good conversation to have with a client at the beginning. Because it’s not always what the client thinks their competitors are. Because generally they’ll be like, “Oh, our top competitors are X, Y, and Zed.” Well, when you bring in a search engine to it and look at the different areas of the site as well, you could have 100s of different competitors depending on what you’re looking at and who you’re looking at.

Keira Davidson (23:48):

Exactly. You could have a, especially for a large site, it could be broken down by category almost, but each one has different competitors because the category itself could be like a mini microsite anyway.

Sophie Gibson (24:04):

Definitely. So I think it’s always worth noting that sometimes yes, you might just have three competitors that you always look at, but be mindful that if you have got a lot of different categories that the different competitors might differ between those areas. Because it was really funny, I had a conversation with a client and they were saying, “Well, this one site, we don’t think they’re much of a competitor to us. We do similar things, but we not.” Well, actually when we looked at all of the keyword intersects, they’re actually a lot bigger of a competitor online than they are kind of as an entity in general.

Keira Davidson (24:53):

Yeah.

Sophie Gibson (24:54):

So being able to uncover the kind of, I don’t want to say hidden competitors, but the ones that they should really need to kind of keep an eye on when it comes to their online visibility. It’s really useful information to tell them and to be able to change their minds on who they view as competitors.

Keira Davidson (25:21):

That is such good point. Because someone might have, an independent, might have a shop presence, but the majority of their purchases or orders all come from online, and it might be that they need that dot presence to be able to get certain contracts, but they don’t really care about making the money there.

Sophie Gibson (25:46):

Exactly. So then you pull into that, I suppose, when you are dealing with e-commerce clients, “Do have a retail presence?” Then you’re getting into the, how does in-store and the online channels kind of intersect and mix. And I think that’s really interesting because being able to increase… I suppose, now a lot of people are using click and collect more perhaps than they’ve previously would’ve done before. So being able to make sure you can make those different channels still be a seamless experience. But then I feel like you’re kind of getting into user experience and the customer experience as a whole. But I find, I think that’s, what’s so interesting about kind of e-commerce work, in general, is that kind of wider conversation it can spark about how we do things and whether or not a site is able to do that.

Keira Davidson (26:55):

We started off talking about product pages and analyzing them and then this, so many takeaways that can be made from that for a business, which then starts that conversation of just wider business conversations. And then it just keeps going. I think that’s where it gets really fun. There’s endless things to learn and so many rabbit holes to go down.

Sophie Gibson (27:23):

I think when it comes to technical SEO, at least, I think finding rabbit holes is the funnest part and being able to completely immerse yourself into all the different parts. It does take you on a bit of a wild ride, I think.

Keira Davidson (27:42):

You come across some random stuff.

Sophie Gibson (27:47):

Definitely.

Keira Davidson (27:49):

It’s been great for you joining me today. I’ve really enjoyed speaking with you. Thank you very much for being a guest on the TechSEO Podcast.

Sophie Gibson (27:59):

No, it’s been great. Thanks for having me. It’s been great to, basically, talk shop for a bit.

Keira Davidson (28:06):

Exactly. Thank you very much.

The post S3E7 Sophie Gibson, Competitor Analysis appeared first on The TechSEO Podcast.

Keira Davidson (00:24):

Hi, and welcome to the TechSEO Podcast. Today I’m joined by Charlie, and we’re going to talk about all things SEO recommendations, and getting them implemented. It’s great to have you joining us today, Charlie, do you fancy given a bit of background information about yourself?

Charlie Williams (00:44):

Yeah, sure, and thanks very much for having me, it’s lovely to be joining you. So, I’m Charlie, I work as an SEO and content strategy consultant, I have my own consultancy called Chock Digital, though it’s just me, sounds grander than it actually is. I’ve been working in SEO for over a dozen years now, but started my own consultancy several years ago. Before that I worked for a couple of agencies, including SEOptimise and Screaming Frog. My work today is very much dedicated on that consultancy side of SEO, and it’s all about content, and technical SEO, and sort of splits into two bits, I suppose. Helping people become better at doing SEO, so that’s training or improving processes for my clients, and then the other side is helping solve SEO problems. That split between the content side, so people wanting to know which bits of their content are doing well, or which ones aren’t, what they need to be doing in their market, what their audience wants to know. Then the technical side, why is Google having problems crawling a site, and things like that?

Keira Davidson (01:51):

That’s definitely really exciting, and I guess, because you see both sides of it, it’s probably super rewarding as you might get the technical implementations fixed and resolved. Then you focus on the content, and then you start getting all these like really big wins.

Charlie Williams (02:12):

Yeah, absolutely, that’s a great way of putting it. It’s nice to be able to help people and all the onsite stuff. But yeah, it’s the way they work together, because normally if someone’s having a problem with their technical side, there’s often something from that you learn about how the content’s being done, which you can help with there and vice versa. What I find quite often is doing a lot of technical work, I help people using and understanding the data they get from search console, in terms of indexing and the coverage report. Of course, a lot of those things in that coverage report under the excluded tab are technical issues, but sometimes they’re actually content quality issues caused by technical problems, and things like that. So yeah, I find the crossover is really quite common.

Keira Davidson (02:58):

Do you find that when you… Because obviously, you do consulting, do you find that when you’re dealing with… Do you deal with the client directly, or do you deal as in getting recommendations done, or are you able to work with developers?

Charlie Williams (03:13):

That’s a great question, it varies, it really varies depending on the business. So, some of my larger clients at the moment that I’m doing projects for, there’s a mix. A couple of them I’m able to speak directly with the development team, which is great, because I’m able to kind of forge that relationship and understand where they’re coming from and how their process works. Then in other ones, especially with larger businesses, I’m working with the marketing team, and the heads of marketing, and the heads of digital, and things like that. That means there’s then a process to then get tickets raised and to [inaudible 00:03:46] the dev team. I’ve had some good video chats with some of them on specific issues, and that’s often the way to kind of approach these things, and that’s really beneficial. But in that case, you have to learn how to raise a ticket with your marketing team that then the development team can then work on.

Keira Davidson (04:01):

So, would you say then with the ones where you go straight to the developers compared to the ones where you go to the marketing team to then the developers, do you find timelines, because of the process, it varies a lot?

Charlie Williams (04:21):

Yes, absolutely. Of course, different teams work in different ways. A lot of teams work in an agile fashion using sprints, scrums, or whatever process they like to use. So, there’s that variance there, but I do find that when you can speak directly with the developers, you can sort of tune into that process they have internally a little better, for sure.

Keira Davidson (04:43):

Yeah, and from my side of things, it’s always good to get the developers on board, and to work with them, and sort of fitting into the processes and the methodologies that they use, because I personally find that it results in you getting the fixes that you need doing ultimately.

Charlie Williams (05:04):

Yeah, a lot of the time, if you’re dealing, as the subject or these podcast is about, technical SEO issues, the developers that you’re best friends. They’re the ones who are actually going to be able to do things, and they’re the ones who can tell you what’s possible and what’s not, so you’re not wasting everyone’s time by doing huge recommendation for things that are never going to happen. I’ve often said that sort of my secret way of getting things done within a project is coffee or beer, it’s taking out the development team, and sitting down with them, and finding out the problems they face, and understanding how they want to work. Sometimes, especially if you’re helping improve internal processes, the barriers in language between the marketing team and development team. If I can come in and help smooth some of that out, that often goes a long way to making everyone happy, well, long after I’ve actually left the project.

Keira Davidson (05:54):

Do you know what? You’re not the first person who I’ve heard say coffee or beers goes a long way in trying to get things resolved.

Charlie Williams (06:04):

I bet, it’s a really, really just, well, polite way of going about things actually, sort of getting down to sit down with people and talk about it. Because sometimes, especially in larger businesses, I’ve worked in house as well, there can be sometimes this feeling of not us versus them, but very much different teams with their own agendas. I think the cool thing about SEO is that you have to get in everyone’s business, we just come in and cause trouble everywhere. I have to come and annoy the PR team by saying, “I need more links,” [inaudible 00:06:33] with links, but you can do.

Charlie Williams (06:34):

I have to come and annoy the product team and the marketing team by saying, “Your content’s not good enough.” I have to come and Badger the technical team, the development team, by saying, “This needs to be faster, this isn’t a very good site response, this is causing duplications,” whatever it happens to be. So, I’m an equal opportunity annoyer, I will annoy every member of the departments that I can. Sort of sitting down with people and talking to them, finding out what you can do, rather than just making any assumptions, huge win.

Keira Davidson (07:05):

Yeah, definitely, you’ve got them engaged, you’ve got them on board, and you’re all working towards that final end goal together, and it’s not a battle.

Charlie Williams (07:16):

Yeah, definitely, it’s very easy for everyone to become siloed, even with the best possible intentions. Because we’ve all got our own individual goals, and different priorities, and SEO is often this… Everything affects SEO, so when you can bring people together and say, “Look, what you’re doing, creating this content, is causing a problem here, but it’s also causing duplication here, which you then the development team can fix,” or whatever the example is. It’s great when you can sort of show that everyone can contribute to this without having to change their jobs, without having to do something massively different, just by understanding some of the things that happen. That’s when I think you can get really good results.

Keira Davidson (07:52):

Yeah, I guess if they were to massively change their jobs or their role to try and fit into it, into what’s needed, long-term that’s just not going to work, because people will go back to what they know. So, it is probably quite important to try and not make these big changes, for it to be a long-term sort of sustainable process.

Charlie Williams (08:15):

That’s a really great point, I think absolutely, if you try and change everything for everyone else, they’re just going to resent it. I think if you’ve worked in SEO for a while, you will have… All seen situations where you meet people who kind of go, “SEO, what keyword do I have to stuff in to ruin my article? Or what do I have to change on the website? Or what tags do I have to do?” It’s kind of this chore, it’s kind of there’s somebody coming and just nagging them and saying, “Do this.”

Charlie Williams (08:43):

Whereas, I always try and frame things in one, bite size improvements, but two, just within the very simple context of we are looking to do this to improve things for our users or for search engines. This lets our user do improvement X, or this makes it easier for search engines to improvement Y, and then you give them a reason for it. It makes them more successful, because you’re doing something that’s going to make them look better to their bosses, and so on. So yeah, that kind of feeling of forcing people to do something, I agree, that’s never going to be a long-term thing.

Keira Davidson (09:18):

That’s a really good point, especially bearing in mind that all the changes that you may be wanting or asking for, it’s really important to revert back to how’s this going to impact search engines and users? Because ultimately, the end goal is to enhance both of those, and if that isn’t achieved, is the implementation really needed?

Charlie Williams (09:44):

Yeah, exactly, if we’re trying to make a technical change just for the sake of ticking a box, and it’s not something we are really doing because we know our users need this more, or we know search engines are having trouble with this, or potentially could be. Then yeah, it doesn’t really seem like it’s a high priority ticket, does it?

Keira Davidson (10:02):

Exactly, so other than basically trying to get the developers together for coffee or a beer, do you have any other good tips on how to get implementations done?

Charlie Williams (10:17):

I will try my best, absolutely. So, I think the key thing for me is actually breaking things down into individual improvements, or reviews, or aspects. What I mean by that is I used to do large technical SEO audits for my clients, I would often start a project off with one of these, not every time, but a lot of the time. I would produce these very large documents where I’ve checked everything, and I’ve documented everything that I think you should do to improve. While there was a summary at the beginning, these would become very large documents, sometimes 10 to 15,000 words. I think back to university, and I struggle to write a 2000 word article for a thing. I’m just churning that out in an hour, whatever, I was like, “Wow, this is ridiculous.” So, I’m producing these huge documents, and there’s supporting spreadsheets with pass, fails, or with tabs with here’s all the pages that have this problem, all the pages have this problem, and things like that. It’s a huge amount of information, and I’d pass it onto clients, and they would be impressed.

Charlie Williams (11:21):

They’d be like, “That’s great, look at all this information we’ve got for our money, this is good value.” You just knew on following up conversations that they’ve read the summary, and looked at one or two tabs of the data, and that’s it. You’re kind of going, “Well, you’re paying me, that’s good. But I don’t really feel like I’m making the right kind of impact.” So, the big change I made about 18 months ago, was I stopped doing them, I just stopped doing them. I mean, one, they were a lot of work to go through, and I just started breaking things down., Both in terms of sales process, but also in terms of just the work I was doing. If somebody came to me just wanting a full technical review, I wouldn’t give them a full technical review document. I would be, “Right. Okay, here’s the first document where we are looking at your current indexing situation, again, using that search console thing what’s happening when we do look at the index in your site, what are the problems we’re facing there?”

Charlie Williams (12:14):

Then I do a crawling review, and if I try and crawl your site, what happens here? Then we’ve got a schema review, or a mobile review, or a page speeding review. The kind of individual components are up to any SEO, because for every SEO there’s a different way of approaching things. However, the key thing was to break it down into those individual parts. I think a lot of people liked that when I was trying to sell SEO to them, because they can understand what each thing was going to deliver for them, much more than this big nebulous idea of a technical audit. It also made my life easier, because I was just focusing on one thing at a time, and then it was much easier to get by on implementations, because we’d agreed that we were going to look at page speed, or whatever it was. Here’s the recommendations, everyone’s already signed in, so let’s start looking at the fixes, so that’s my first recommendation is breaking things down that way.

Keira Davidson (13:07):

Yeah, I think that’s a really good one to bear in mind. It’s great, it’s all fun and well delivering these massive technical audits, but also, delivering the information in bite sizes can help with getting it done, as in getting it all sorted. You can slowly work your way through instead of overwhelming the different teams, so I definitely agree, that is a big one to bear in mind.

Charlie Williams (13:34):

Yeah, absolutely, and it also really helps I think with the second thing that I’ve learned, especially over the last several years of doing this as an independent consultant, and that is when it comes to making recommendations for implementations, you can tweak some things there. So, if you’re doing smaller documents, you’ve got smaller recommendations anyway, just a smaller number, which is really helpful, focusing on one thing at time. But when it comes to implementation, there’s a couple of things you can do, you can make sure your document is in a format that the development team really wants. So, if you are dealing with the developers is one thing, another thing for the marketers, but what document format works best for this team? Do they want it in a long written document?

Charlie Williams (14:17):

Do they want it in a presentation format, quite visual, with supporting data, or do they actually just want it straight up just the data with a summary thing at the beginning with a line for each job, and your prioritization, and things like that? Then the second thing about the implementation is understanding if you are doing the implementation part beyond just the recommendations, how can you help make sure the implementation is done? Sort of the stewardship of those implementations is still part of your job. How would you make sure they’re done? Is it that you need to actually write the individual JIRA tickets, if you’re using JIRA, or whatever the system is? Do you need to really have a call for each individual point, so that you can talk people through exactly what to do? It can vary, but actually have a plan of how you’re going to guide that implementation in place, if that’s part of your job.

Keira Davidson (15:11):

That’s a really good point to make, and do you know for this sort of plan, would you sort of outline it initially when the project comes on board, or when the development work needs completing, to make sure that all teams are on the same page?

Charlie Williams (15:28):

I think you can do, I think it’s really important to get all teams on the same page where you know that’s going to have an impact on your ability to get these things implemented, or even if you’re just making recommendations to make sure that you’ve got the best chance of everyone understanding the impact of what you’re doing. That’s going to be your end goal, and I think that’s quite crucial, so whatever works well for that, I’m all for, definitely.

Keira Davidson (15:53):

Yeah, especially trying to use the systems that they use is the way forward. Do you typically find that depending on the size of the organization depends on the way they prefer the information to be delivered?

Charlie Williams (16:11):

I’ve not found that, I mean, I imagine there’s probably some patterns towards it, but for me, it’s always been such a varied thing. I think an awful lot of people use something like JIRA, or something like that, because they’re wanting to use a documented ticketing system, rather just relying on emails, and the equivalents of those. I’ve also used things like [inaudible 00:16:31] quite regularly, where they want to… The equivalent of a ticket, once it’s agreed, is to raise a new card, and then guide it through the stages of the implementation. So yeah, there’s a few different things, but I haven’t seen any hard and fast rules. I think mostly what depends is… The size of the business will affect it more in terms of who you are dealing with, and how many people you’ve got to convince, or how many people have got to be included in each stage, and things like that. That’s what I think the biggest difference is.

Keira Davidson (17:04):

Yeah, that brings me on then to ask, so you know if you’re dealing with a corporation where you have to get sign off for implementations from let’s say the directors, or the CEO of the company, how would you approach that?

Charlie Williams (17:24):

Yeah, that’s always a bit of a difficulty if you’ve not been dealing with them from the beginning, for sure, so they haven’t got to know you. So, what I like to do is approach things in a couple of ways to make it easy for them to understand what we’re trying to do and the potential value of it. So, one is actually the recommendations you do, so making sure you’ve got that in a format that the majority of people can understand and can kind of get on board with, that’s a good thing. But I also think it happens even before that, when you start planning your review work, or your retainer, or your project, or whatever you’re doing. So, selling SEO can be quite tricky, because you can’t actually buy physical units of SEO, or something like that, and selling services is more difficult than a product, isn’t it? Because you can’t physically pick up a service, and understand it, and look at it, and it kind of makes some decisions that way, there’s not statistics about it, like technical specifications.

Charlie Williams (18:23):

So, when it comes to selling in your recommendations or your service to begin with, there’s a few core things I found really helpful to do to make it easy for people to grasp what we’re trying to do. So, one is that process we talked about a few moments ago, about the idea of every recommendation being this lets our users do this, or this makes sure search engines can do this, so we can reach more users. So, that kind of framing of every recommendation I think is really, really key, and then when it comes to explaining everything about high level about why you’ve been this auditing work when introducing the recommendations as a whole, there’s a few good things we can do. We can give a really good explanation of what we want to do, not everyone knows SEO, not everyone understands why we’re doing it or the benefits. So, giving concrete definitions of what we’re doing, at least with this particular set of recommendations, or this audit, or whatever it is, that can really help.

Charlie Williams (19:15):

Just put it in normal English terms at the beginning, what we are looking to do, so [inaudible 00:19:19] on board. Wherever possible, you want to try and get a few quick wins in before you start asking for more difficult stuff. So, what we’re doing there is we’re improving the trust people have in us, and we’ve already seen some positive results because of this. Doesn’t have to be more traffic, because we know we have to wait a bit of time often for SEO to kick in. But they’ve seen it’s easy to work with, the recommendations made sense, it was easy to implement, [inaudible 00:19:43] all the data we wanted, and we can see that X, Y, or Z has started to improve as a result. So, getting a few bits of that before we start doing more difficult ones, I think gives you that trust, that when you start making more difficult recommendations, they believe that it’ll be worth the effort. Then finally, wherever possible, I like to alter the amount of risk that’s implied with the job.

Charlie Williams (20:06):

So, it’s not always that easy with technical SEO, but imagine something like site speed. If you sort of have come in with some really strong recommendations about site speed, and people aren’t too sure about it, it’s much easier to get buy in if you say, “This makes a site better for users full stop, it’s not just about SEO. Even if this gave us no SEO improvement whatsoever, this would actually improve the experience of everybody who visits the website.” It’s very hard for anybody then to argue with that as being something they shouldn’t consider doing. Whereas, if you come in and say, “This might give us a small tweak, it’s a small SEO improvement in the scale of things, but if we’ve got an even match with somebody else, it’s a good tie breaker.” That is not really a good argument for site speed, but saying, “This makes it better for everybody who visits the website, no matter what channel they’ve used,” that is a much more compelling argument.

Keira Davidson (21:01):

That is a really good point as well. I’ve personally found, as soon as I mentioned that it’s going to benefit user experience, going to just benefit their journey, the clients are more on board with it, because they realize the impact, and the potential uplift it could have.

Charlie Williams (21:19):

Yeah, definitely, when in doubt, just crib off other disciplines that people understand a little bit more. I bring up UX all the time, absolutely, because people know UX is really important. If anything the last year has taught us, obviously, about this kind of real emphasis on digital is that there is a lot of competition, and there is a lot of stuff that people expect from their online experiences. So, when you can put things in that context of UX, it really does help. Not always easy with technical SEO, but even sort of other things can do it. If you’ve got something in your system that’s producing duplicate content, or crawl traps, or anything like that, you can just say, “Well, from a user experience, if they came across this, what would you think? You’d think it wasn’t a good experience, we should nip this in the bud,” or you can say, “What if you imagine Google’s your user, it’s a user who can rank you afterwards, do you want them to see this? No, of course not.”

Keira Davidson (22:12):

You’ve made a really good point there about referring Google to being a user, that is such a good point to make, because sometimes people or clients don’t really care about Google. They know that they have to do well and sort of please Google, but they forget that it ultimately matters, and that considerations need to be thought around search engines as well as the user.

Charlie Williams (22:41):

Yeah, it does make it easy to think of Google as a user. I mean, another technical thing that comes up of course is something like in websites that target multiple countries. People wanting to do auto redirecting, basing on IP addresses, and stuff like that. You kind of go, “Well, think about Google’s a user, Google comes from a computer in the US, so it’ll always see the US stuff. Do you really want to force them only able to see that part of your website?” Yeah, that framing, that’s a good shout, that framing can be a really useful little tool in your toolbox for helping convince people of the glory of your SEO recommendations.

Keira Davidson (23:19):

I’ve really enjoyed speaking with you today, thank you so much. It’s been really interesting to speak with you about this topic, and you’ve given me some great thoughts and insight to bear in mind in future, when I’m speaking with the different teams, so thank you.

Charlie Williams (23:39):

Thank you for having me here, and I’m glad it’s been interesting.

The post S3E6 Charlie Williams, Getting SEO Recommendations Implemented appeared first on The TechSEO Podcast.

Keira Davidson (00:21):

Hi, and welcome to the TechSEO Podcast. Today, I’m really pleased to announce that I’m joined by Billie from the SEO works. I don’t suppose you’d like to provide a bit of background information about yourself.

Billie Hyde (00:34):

Hey. Yeah, of course. So I’m Billie, also known as Billie Geena or Billie Hyde or that really annoying person on Twitter. I’m a senior account manager at the SEO Works. I’ve been there about a year and before that I worked in-house doing SEO. And before that, I was a copywriter for a large newspaper publication, nothing fun, I just wrote bereavement notices. Yeah, so that’s kind of me.

Keira Davidson (01:08):

Well, that’s super cool. So you’ve been in-house and you’re now agency side so you’ve seen it from both sides, which is really interesting and because of that, you’ve probably got some really good insights on getting recommendations implemented because as an SEO, that is something I am constantly… It’s like a massive barrier and it can be quite frustrating, especially when there’s pressing stuff coming up, like the page experience update. It’s really important to be making these changes and well, firstly identifying the changes and then writing a ticket and passing it to your developer to get it done but sometimes, they have a massive backlog and it can be a nightmare. Do you have any tips on how I can help the process?

Billie Hyde (02:10):

Yes. I’ve got a few different things that have been tried and tested in both backgrounds really. Some of them, it won’t work for every developer or every client that you’ll have. So something that’s worked with me, it worked fantastic for me, when I worked in house. And it’s only works maybe twice since I’ve joined an agency, but I’ll be sending my suggestions over to a developer and they’ll be getting turned down or we’ll look at that in a few sprints time. What I’ve started doing is just saying, “Can I come to one of your sprints maybe once a month? Or be like, “Attend one scrum meeting?” It doesn’t work with every developer. I’ve had a few no, “Why you even asking this?” How dare you kind of reactions, but I’ve had a few where they’re like, “Yeah, let’s do it.”

Keira Davidson (03:11):

That’s very good.

Billie Hyde (03:14):

Yeah, really surprising when they went for it. It was much easier in-house to do that, but it gives me much more understanding of their workflow and what things they’re rolling out in the coming months. And there’s been occasions where they’ll be rolling something out, which is going to improve page speed without me even nagging them about it. So then I can kind of, “Okay, this is going to do this. I’ll just move on and start [inaudible 00:03:41] on something else.

Keira Davidson (03:44):

That’s really interesting how the strategies that you used in-house aren’t fully transferable to agency side, but I guess it kind of makes sense as in-house, you are a part of the team. It’s not like they can run away from you whereas agency, I’m guessing you usually dealing with the client’s developers.

Billie Hyde (04:11):

Yeah.

Keira Davidson (04:12):

There’s a barrier almost.

Billie Hyde (04:15):

There is. The developers kind of sees us a third party and I think coming from agent, there’s much more barriers to break down to kind of get the developer like, “Okay, yeah. Let’s actually listen to these suggestions they’re making.” And there’s a lot of relationship building. For some situations I’ve found it really works, if your client’s using a third party developer, they’re kind of passing along messages from me to them. It happened just because the client was kind of sick of not getting it right what I’d been telling them or the developer had been telling them to tell me. Not the developer, sorry. The client was like, “I can’t do this anymore. You need to talk to each other.”

Keira Davidson (05:17):

Yeah. I can imagine that’s a massive headache for them.

Billie Hyde (05:21):

Oh yeah, definitely. It didn’t help that they took one thing that I said is, make every single page of the website a PDF.

Keira Davidson (05:29):

Oh God, so the homepage is a PDF.

Billie Hyde (05:34):

Literally. I don’t know. I never said anything along those lines and that’s just what they were convinced was happening. So that caused the developer to be like, “Well, this SEO person doesn’t have a clue what they’re on about.” But then I was under the impression the developer wanted to make the entire website PDFs. So it was kind of butting heads quite a lot. And then once we was able to talk and we kind of had those monthly sprints, things became a bit more understandable between us and our goals became aligned.

Keira Davidson (06:18):

Yeah.

Billie Hyde (06:20):

It’s hard to do. And most clients will say, “No, why do you want to do that annual contact?” But I think it’s just worth asking.

Keira Davidson (06:31):

Yeah. I think I’d agree on that because I’d say similar to you, I’ve not been in-house but I’ve experienced the fact of, basically you’ve done a massive audit and there’s, let’s say, 26 issues or recommendations from that audit. They then get passed to the client. They then have the opportunity to sort of misinterpret or miscommunicate it by passing it on to the developer, so I definitely find going straight to the source is best. And like you, for one of my current clients, I have a, I think, it’s monthly scrum or… I think it’s monthly to discuss certain tickets that we’re currently working on. And I personally find that so insightful because you sort of forced to talk to each other, but you can get great results from that because you can get on the same page and you can work together instead of against each other.

Billie Hyde (07:30):

You 100%, yeah. I always find as well that they’ll be doing something that I’m like, “Oh my God, I’ve never even thought of that. There’s so much opportunity there.” And then that can create a whole new adaption to a strategy. So I think there’s a lot of developers and SEOs working against each other and it just needs to become a collaborative thing. And once we’ve got that, all of our jobs will just become so much easier.

Keira Davidson (08:06):

Yeah. No, I agree on that. I’m personally in for an easy life. So I’m all more for, let’s get the developers on side so I agree. I hope you don’t mind, but I noticed you put a tweet up yesterday. It was a little poll regarding when Technical SEO identifies an issue. For example, page speed or mobile usability, whose responsibility is it to resolve the issue? And the two voting options were technical SEO and the other option was developers. What’s your thoughts on that?

Billie Hyde (08:45):

I’m not sure. I’ll be honest. There’s some stuff where I’m confident that I know how to fix it and make things better but then there’s other things where I’m like, “Should I spend time to learn how to remove unused CSS or HTML or JavaScripts? Well, how do I know what to get rid of?” Kind of things and that’s kind of why I’ve started that poll because I just don’t know where the border is sometimes and I think that a lot of SEOs feel that.

Keira Davidson (09:27):

Yeah. I could say I definitely do.

Billie Hyde (09:31):

The polls coming up on my side, because I would normally be like, “Yeah, that’s the developer’s job.” And so far 78% of the people poll have said, it’s the developer’s problem not us.

Keira Davidson (09:43):

That makes sense. For me, like you saying, if it’s such a simple task and you can do it and it’s going to be quick and easy, then the time that it takes to write a ticket, brief the developers, then get them to action it, it’s actually quicker just to go in and do it. But from the other side of it, where it’s completely out my conflict zone, I am not going to touch it because I don’t want the liability and the risk of potentially breaking something or just making a massive mess so then on that, out of the two options, I probably would side with the developers, but I’m glad that 78% also agree on that.

Billie Hyde (10:29):

Same. Because if everyone was like, “No, that’s up to the technical SEO to fix,” I’d very much be thinking I’ve not been doing my job right at all, ever.

Keira Davidson (10:39):

Yeah. I could do the basics developer stuff, but no I can’t build a theme. No, I can’t make page speed changes and all of that. No, I can’t fix the CLS shift. No, it’s a whole different thing in itself.

Billie Hyde (11:01):

It is and I think that’s what some clients don’t realize that a technical SEO, even if they do know Python or HTML and JavaScript and can do all the things like that, they’re still not a developer. They don’t…

Keira Davidson (11:15):

Exactly.

Billie Hyde (11:16):

Well, there’s probably some out there that had experience resolving those issues, but majority don’t and that’s because it’s a developer’s job to understand that. An SEO specializes in SEO, we don’t specialize in developing a site, so it’s just to setting those expectations and reminding clients that two different jobs and two different skill sets or that they overlap.

Keira Davidson (11:46):

Yeah, there’s definitely overlap. And like you said, you probably can get someone who can do it all, like a T-shaped marketer, and then you’ve also got people who specialize and excel at certain points and can do bits really well, especially in development. So I think ultimately depending on what the end goal is, depends on what type of person is used for the role but either way, the same strategies for getting the tasks implemented can still be used, no matter the type of person in the role.

Billie Hyde (12:27):

Yeah, definitely. Sorry, I can’t get my words out now.

Keira Davidson (12:35):

It’s fine. Don’t worry.

Billie Hyde (12:41):

Even the most advanced technical SEO, I’m not them so I’m speaking completely, just imagining the situation. I think if they’re wanting to make changes to fix something big like that, they do need to tell the developer. It probably needs to go through the same scrum process. They probably just can’t do it there and then, so they need to still probably be that ticket system or the communication or something, even if they’re the one implementing the fix.

Keira Davidson (13:16):

Talking of ticket systems, do you typically find that, typically speaking, each developer will have their own ticketing system, whether it’s Trello, [inaudible 00:13:28] Basecamp or whatever? When trying to get these recommendations implemented, will you try and take to the ticketing system that they use to almost be on their side?

Billie Hyde (13:42):

Yeah. So I try to adapt any ticketing into the way that I know the developer likes to communicate. So for me, I’m basically a walking spreadsheet. Every bit of my life is in a spreadsheet and that’s how I have to write out the issues I find for myself and I like to break that down. It’s all color coded, like traffic light, how urgent it is, broke down into which area it falls into and then the issues, and I list the implications. And then even if it’s something that I completely don’t understand, I’ll still link myself an article about it so then I’ve got all the information ready to send to a developer.

Keira Davidson (14:26):

That’s helpful.

Billie Hyde (14:28):

Yeah. I’m so lucky that majority of the developers I work with have just accepted this system. When I initially sent it over and they’ve just ran with it, but it’s in a way that I could just easily copy and paste it into a Trello board or a [inaudible 00:14:46] or a Jeroo or whatever they use. And I think having it listed like that for yourself and then also what I do, so then there’s no deniability that I’ve sent it, I also mark off when I’ve sent it and date it so then I’ve got everything I need there. And then I know they’ve got it as well and I just find having that full picture of every issue for myself just makes everything easier for me knowing I’ve done everything I need to, and now it’s up to the developers.

Keira Davidson (15:32):

Yeah. I definitely think I like your style on making it clear as to when it’s being sent so there’s no sort of rigging out of that one. I think that’s a smart move. Something I should probably think about more, which is cool. Today I’ve been introduced to, I don’t know if you’ve heard of it before, it’s called Fibonacci. It’s do with prioritization and apparently it’s something developers, agile developers, typically use and it’s quite cool because it gets the developers involved in the process. So you list all the issues and then we, as the SEOs, we put an impact score and then we then send over the doc and we get the developers to list what they think the ease of it, the impact score is and basically the implementation. So then my score and the developer score is then combined and it then creates this overall prioritization, which I think is actually a pretty smart way because then we’ve managed to get their buy in almost.

Billie Hyde (16:44):

Yeah, that sounds actually amazing. What was that called, sorry?

Keira Davidson (16:48):

It’s called Fibonacci. I can happily send a message over to after if you’d like.

Billie Hyde (16:54):

Oh yeah, 100%. That sounds like an absolute dream. From experience, I’ve learned to never assume how easy a task is for a developer to do so. I love that they can put their ease in so that’s something that I think is just going to be super helpful. It’s like you’ve said, you’ve got that almost immediate buy in because they’re basically saying they’re probably going to do it, especially the higher score they give you and they get it, it means it’s going to fall higher on their workflow.

Keira Davidson (17:30):

Yeah. It’s a higher priority. So I think the highest score is 53 off the top of my head is in… Sorry, the highest impact score that it can have so that’s like, “This is urgent. Red light sort of flashing issue.” Whereas an eight is like, “Oh, there’s an issue. It exists, we’ll get round to it sort of thing.”

Billie Hyde (17:55):

That’s really cool.

Keira Davidson (17:58):

I thought that was really interesting and quite useful. And I think, like you said, as an SEO, personally, I don’t honestly know how hard certain things are. So I think getting, getting a developer’s opinion on it helps to clarify things and so when I’m demanding something or asking for something, I now have better clarity understanding how difficult or complex the task is.

Billie Hyde (18:31):

Yeah. It’s just so difficult to know… Sorry, my words aren’t coming out again. We think we’ve got a lot of data and spreadsheets and formula to know. They’ve probably got a hundreds more, especially if it’s a fully custom made CMS they use and things like that so we genuinely, unless it’s something like updating a meta tag, not a meta tag, a meta viewport tag, I feel like every SEO knows that’s pretty easy now.

So I would be like, “Look, it’ll just take you two seconds for something like that.” But if I was asking them to even just automate some content, run a quick script, I don’t know how difficult that would be for them, depending on how much content I want to change kind of thing because I don’t know the languages and the programs they use that well. And again, as an agency, so I know a little bit of Python, that’s great but what if the website they’re working on in C# or [inaudible 00:19:56] So we can’t just assume things are straightforward if we don’t know, but one of the best things I’ve ever done and I know it’s probably not as easy as it sounds, but from not agency work, I don’t know these in a work capacity, but I’ve befriended a few developers. And if I’m stuck on something, I just want to know, “Look, does this sound insane? How wild?” So

Keira Davidson (20:28):

Billie Hyde (20:29):

Yeah. I was like, “If I came to you and I was like, this needs doing now, what would your response be?” Kind of thing.

Keira Davidson (20:36):

No, go away.

Billie Hyde (20:38):

Yeah. Literally, they’ve told me that but just a bit more explicit.

Keira Davidson (20:42):

Yeah. I think that’s a really good idea because it helps prevent irritating anyone because ultimately we need to keep developers, on our side and as friends.

Billie Hyde (20:55):

Yeah. And developers are people too and I know that’s a very obvious thing to say.

Keira Davidson (20:55):

It’s forgotten though.

Billie Hyde (21:05):

Yeah. It’s often forgotten all the time and how we talk to them is just like, “Do this or [inaudible 00:21:14]” All the time in the world to do whatever we need. So befriending people at work in that level of tech has just been so helpful for me to just be like, “Oh yeah, I kind of need to chill a little bit.”

Keira Davidson (21:35):

Yeah. They’re just not going to like me if I ask this.

Billie Hyde (21:39):

Yeah. And basically, once that relationship between you and the developers being damaged, it’s so much harder to repair a working relationship than it is to just build one from the onset.

Keira Davidson (21:55):

Yeah. I definitely agree especially because you can gradually build that trust whereas once that trust’s gone, it’s painful. It’ll be challenging.

Billie Hyde (22:06):

Yeah. That’s a little understatement really.

Keira Davidson (22:11):

Basically it makes your life hell.

Billie Hyde (22:15):

Yeah.

Keira Davidson (22:18):

So then this brings me to ask my final question. Do you have a top three of absolute don’ts? Don’t even bother trying to taking a certain approach to get recommendations done.

Billie Hyde (22:34):

Well yeah, a little bit. Okay. I’m just picking my top three here.

Keira Davidson (22:45):

Sorry. I’ve put you on the spot here.

Billie Hyde (22:50):

No, it’s fine. I love it. So my first thing would be to not oversimplify what you are asking them. I’m saying this with experience. So I’ve, on occasion, done a crawl on Sitebulb, found a bunch of hints on it and just copied and pasted the hint. And what I like about Sitebulb, it tells you what the issue is and its implications but what I’ve found. It either explains them just a little bit oversimplified. And then if some of them, it’ll say it’s critical or high issue, but I’ve took it to the developer and they’re like, “You’re being a bit dramatic here.”

Keira Davidson (23:42):

I think we’re all probably avoid on that, I think.

Billie Hyde (23:48):

Definitely. I don’t know an SEO who hasn’t done that, but I try my best to steer them away. So my advice is to take those hints and the advice any tools give you, use them as your base of what you’re going to suggest to them, but do your own research and rephrase it to how you think the developer would respond better to ,it if that’s the approach you’re taking by doing a crawl like that and just using all that data as your baseline. Another bit of advice would be to consider the evidence you’re taking to them. There’s no point in spending hours trying to find a thousand examples of an issue.

Keira Davidson (24:33):

Yeah.

Billie Hyde (24:34):

I’ve done it. I think everyone’s done it.

Keira Davidson (24:35):

I was going to say I’ve done that.

Billie Hyde (24:38):

I literally did it just today and I’m like, “I need to practice what I preach sometimes.” It’s so easy to get swept up into, “Oh, here’s how bad this issue is. Oh, here’s another example.” And all of a sudden you’ve got a massive spreadsheet. Just try to reduce that sample you’re getting. Try and take them 20, 50 or a hundred examples of it. Vary depending on how difficult the issue is to identify or how long it’s actually going to take you to find, because on more than one occasion, I’ve took the issue to them and I’ve found loads of examples. And then the developer wants to see if I’ve got all the examples and stuff like that, and they just run a really quick script in Python and then have this massive list and I’ve spent six hours compiling things [inaudible 00:25:32] in 20 minutes.

Keira Davidson (25:34):

That is always the way. And in that moment, I’d probably just want to curl up in a ball and cry for the amount of time I just wasted.

Billie Hyde (25:41):

Definitely, your heart just drops but you can’t admit that it took you that long.

Keira Davidson (25:46):

You definitely can’t.

Billie Hyde (25:53):

Yeah. So always provide examples but just don’t go wild with it. And then my final don’t is to not do the research on the issue. So you know what the problem is, but how is that problem going to translate to the CMS and the program? Is it something that’s going to be really complicated to resolve? Does the CMS even have the capabilities to do what you want it to do? Consider things like that so then if the developer looks at it and says that they haven’t got capacity or they can’t do it, you are less disheartened but then you kind of knew it was coming, so you’ve probably got alternative suggestions.

Keira Davidson (26:51):

Yeah. That’s a good one actually, taking into account what you actually have there, what the platform is, because certain things aren’t possible across all platforms. They have their own nuances.

Billie Hyde (27:05):

Definitely. There’s a Chrome plugin called whatruns.com and I use that all the time. It just tells me literally if it’s built on WordPress, what plugins they use, what theme they use and stuff like that so it just helps me with that bit of research.

Keira Davidson (27:26):

Oh, awesome. Thanks for that. Yeah, that’s the one I should have a look into.

Billie Hyde (27:30):

Definitely. I probably say its name three times a day. I’m just so obsessed.

Keira Davidson (27:35):

Soon you’ll be getting a discount code and…

Billie Hyde (27:38):

I’ve been trying.

Keira Davidson (27:43):

That’s great.

Billie Hyde (27:47):

Then there’s Grammarly.

Keira Davidson (27:47):

Oh, I love Grammarly, it’s a good one.

Billie Hyde (27:48):

I don’t think I can write a sentence without it these days.

Keira Davidson (27:53):

Oh, I really enjoyed speaking with you today, Billie. Thanks so much for joining and being a guest on the TechSEO Podcast. So I’ve really had great fun.

Billie Hyde (28:03):

Me too. Thank you so much for having me.

Keira Davidson (28:06):

Thanks. I’ll catch you in a bit.

Billie Hyde (28:08):

All right, bye.

The post S3E5 Billie Hyde, Communicating With Developers appeared first on The TechSEO Podcast.

Keira Davidson (00:22):

Hello and welcome to the Tech SEO Podcast. I’m Keira Davidson, your host, and today I’m joined by Sara. It’s great you joining the podcast today. I can’t wait to speak with you. Let’s kick things off by finding a bit more about you.

Sara Moccand-Sayegh (00:37):

Hi, so thank you for having me. So about myself. I work at Leap, a web and Mumbai development agency. I co-hosted a [inaudible 00:00:50] called SEO North Switzerland, and I’m also part of the Community Women in Tech SEO. And I just feel that is one of the more inspiring community that exists in the tech world.

Keira Davidson (01:06):

Couldn’t agree more with you. The Woman in Tech SEO Community has been really useful for me personally. Like yourself, I came across you in there. And so many of the people have been really helpful and lovely to work alongside with.

Sara Moccand-Sayegh (01:22):

Yeah, for me, it’s the same. I mean, I met some fantastic people in that community.

Keira Davidson (01:28):

So today the plan is to talk around JavaScript myths for SEO. And as an SEO, as soon as I used to think of a JavaScript, it’d be like, oh my God, red light. Geez, this could be bad, sort of thing.

Whereas JavaScript can be okay. But we’ve got to set these myths straight to make sure people are aware of this transparency around it all. So that brings us onto what is your first myth that you found relating to JavaScript?

Sara Moccand-Sayegh (02:09):

So my first myth is that Google can index JavaScript without any problem. Okay. Before I dive deeper into this myth, please let me explain something. So, as I said at the beginning, I work in a development company. So for me, this myth come from the developers because for SEOs, we are always scared about JavaScript, as you said. And developers are not scared enough about JavaScript.

So I would say that is the main problem. And we need to find a common ground on that. And that is the reason why I wrote down this first myth because of the feedback then I had inside the development company.

Keira Davidson (03:00):

Yes.

Sara Moccand-Sayegh (03:00):

So probably, I mean, most of your auditors know how Google process JavaScript, but let me give a refresh. So then it makes it clear for everybody. So how Google plus JavaScript, normally it will happen in three phases. You will have the crawling, then you will have the rendering, and you will have the indexing phases.

So when we have a website that doesn’t have Java script. So let’s say a plain HTML website. And then what will happen is that you will have a URL for example, and then the HTML will be downloaded. Then you will check this HTML, you will find links. There will be the extraction of the links. Okay?

Keira Davidson (04:02):

Yep.

Sara Moccand-Sayegh (04:03):

And then you will have a download of the CSS file and everything will be sent to caffeine for indexing. So that’s mean that you will just have two phases, crawling and indexing, and that’s all. And that’s make it so much easier. With JavaScript, especially with a website then our heavy JavaScript website. We will speak a little bit more about that in the next few minutes, maybe.

So the situation will be a little bit different. If you ever seen a website having JavaScript and you remove, you can have all this extension where you can remove JavaScript for example.

Keira Davidson (04:03):

Yes.

Sara Moccand-Sayegh (04:50):

And then you will see, then the page is completely empty. There is nothing. And why that happened because the HTML of the page is empty too. There is nothing on the HTML. So that’s mean then if links are so important and then Google try to, it will download the HTML, and then it will look for the links. But I have no links because there is nothing on that page. Okay?

Keira Davidson (05:20):

Yes.

Sara Moccand-Sayegh (05:21):

And then we are obliged to create, by we I mean Google, obviously. It’s obliged to create an extra step and that extra step is the rendering.

Keira Davidson (05:34):

Yeah.

Sara Moccand-Sayegh (05:34):

Okay. Because it needs to see the initial HTML and the final HTML in the almost, it is not exactly the same, but almost in the way that we see it. Okay?

Keira Davidson (05:47):

Yes.

Sara Moccand-Sayegh (05:47):

Because like this, it can find the links and can extract them. It can do exactly the same process in a certain sense, then it would be with the crawling and indexing. But you could see in the rendering, it will find the link. It will find the entire, the content of the page too. Okay?

Keira Davidson (06:14):

Yes.

Sara Moccand-Sayegh (06:14):

So that is why this rendering phase is important because it give you, it will give to Google a better vision. Okay. I would speak about Google just because it is the main search engine, and the one then would probably render JavaScript best. So the more advance on that.

Keira Davidson (06:38):

Mm-hmm.

Sara Moccand-Sayegh (06:40):

Okay.

Keira Davidson (06:42):

And that makes sense, because I personally have come across websites, where if you turn off JavaScript and then keep critical areas of the sites such as the navigation, they don’t work. And that causes a massive issue because search engine bots then can’t discover all these links within the nav to then find all these pages, which need indexing. It just cause a massive headache.

So yes, it’s great using JavaScript, but we’ve also got to do some testing to ensure that the page is able to be rendered and indexed because that is critical for us as SEOs.

Sara Moccand-Sayegh (07:19):

Exactly, exactly. So I will already switch a bit here and there, as you are speaking about that. Yes. So as SEO, you’re absolutely right, we need to check and we have some tools that support us. Like the search consult or many other tools.

We can at least see a little bit how it’s rendering and is Google taking everything? We can see if there is a problem in the JavaScript part. So you are absolutely right. That is part of our job and we need to check that.

Keira Davidson (07:56):

Mm-hmm.

Sara Moccand-Sayegh (07:57):

So coming back again to the rendering part. So as we say, and as we say now about the tools and what you were saying, then we need to check. So the rendering is dedicated. It’s very dedicated. So many things can go wrong in the rendering part. So more resource you are having, more complicated will be the rendering part because there is all the fetching.

So it’s a little bit complicated. So better if you reduce as much as possible, all this part. Then there is another problem with the rendering. It depends obviously on the size of your website, but rendering require a lot of resource.

Keira Davidson (08:45):

Yes.

Sara Moccand-Sayegh (08:46):

And we know the resource are limited. So we will speak a little bit about that later on.

Keira Davidson (08:55):

That makes sense. Yeah. That sounds really good. And I think it highlights the importance to see how your page is rendering. Like you said, it can be done in search console. It can be done in dev tools. You can see the little square blocks sort of how search engines look at it, which is, I find quite fascinating, especially when it’s loading, when you’ve got like random blocking issues. And it’s like, oh, just blank screens initially. And then the page is loaded.

Sara Moccand-Sayegh (09:22):

Oh yeah. That give you an indicator at that point when you’re waiting. And you’re like, oh my God, there is nothing. Why there is nothing? Oh, okay.

Keira Davidson (09:32):

Exactly.

Sara Moccand-Sayegh (09:33):

So, yes, I understand what you mean. So this myth a little bit come from developers, then there is no problems. And then the question is what can we do? Because there is something that I have learned from developer. We need to give them a little bit of guidance.

Keira Davidson (09:33):

Yes.

Sara Moccand-Sayegh (09:55):

Okay. As much. I mean, I have learned so much from the developer. Because each time then I have a technical question, then I absolutely understand nothing. I will go and say, “I have a question.” I give them a bad headache because I will continuously try to understand. So, okay. But anyway, they’re fantastic. They help me, but we still need to give them a little bit of guidance too.

Keira Davidson (10:20):

Mm-hmm.

Sara Moccand-Sayegh (10:20):

And these are some of … We can have some solution to help the web rendering service. So for example, if the initial HTML and the final HTML are the same, or similar, that will help for sure the web rendering service.

So for example, if you use server side rendering, that will help. We will explain. We will discuss with you a little bit about it later on, but that’s something that could help. Then we often check in the dev tool, for example, if some, all the JavaScript use it? Yes or no? So for example, a developer could use three shaking. So it’s a technique to remove code then is use it, or like dead code.

Keira Davidson (11:17):

Yeah.

Sara Moccand-Sayegh (11:20):

So, I mean, I don’t know exactly, as you would say, but whatever it is that you don’t need.

Keira Davidson (11:20):

Exactly.

Sara Moccand-Sayegh (11:26):

That is an option. And then most of developers nor they will use like Webpack. And I test it myself in the past and I really hope that I would never, ever again, could use Webpack for the rest of my life. But what I’ve learned from that is that Webpack create bundles. And so these bundles are fantastic because bundles of code all together. But sometimes they’re too big.

Keira Davidson (11:26):

Which causes a problem then.

Sara Moccand-Sayegh (12:05):

Yeah. And then became a problem. Then something that is good, it became the problem. So there was, I remember a couple of years ago I’ve seen, I don’t remember her name, but it was the head of SEO of Philip Morris International. And she said, “Bundle your code, but split into reasonable bundle.” And I was like, oh my God is so much that.

Keira Davidson (12:29):

That makes perfect sense.

Sara Moccand-Sayegh (12:33):

Yeah. That is like the perfect sentence. And yes. So that’s something, the sentence I take it from her. Sadly, I don’t remember her name, but yes. That are some idea on how you could help also developers. I would give direction.

For sure there are many more. Now I don’t know how is your experience with developers? But obviously they are aware of many things at the moment and you make them aware. They will try to find solution and search. I don’t know-

Keira Davidson (13:07):

Exactly.

Sara Moccand-Sayegh (13:07):

What do you see?

Keira Davidson (13:09):

And I think if we can make the developer’s job any bit easier, then it’s definitely within our interest to do so. As it should hopefully result in fixes being implemented a bit quicker.

Sara Moccand-Sayegh (13:22):

Exactly. I absolutely agree with you. And then there is a last part. That is a little bit complicate to explain, but let’s try to do it together. So there, I will ask a little bit of support. Because we know then we have the web rendering service.

Then you have, so what you want to do often, to have a better user experience, it will be having a cache. So you will cache in the other. Which means that sometimes there is the risk, then Google will not know that you refresh your JavaScript file. Okay?

Keira Davidson (14:09):

Yes.

Sara Moccand-Sayegh (14:09):

So let me give an example because I think then it will be much easier to understand with an example. So often, I don’t know, tell me your experience. But what I’ve realized is that normally eCommerce website, they have a lot of products and then their products will be populated with JavaScript.

Okay. So now let’s side on this product, you have some new stuff. I don’t know, which new stuff, but some new stuff. And then what you will do is developer will create a new code, but they will add it on the same JavaScript file. And then you will have this new code with the same name as before, and then what? Nothing, because Google, as we say, will have limited resources.

So Google will not re-crawl the new file. And would just keep the old version because you have exactly the same name. So why should it crawl the website? So what happened is, and that is what Google advise to use. And that is something that you can discuss with your developers, because for sure they know what I’m speaking about, is to use content fingerprint. So you have on your file, you will probably, you will change all the numbers that came after the-

Keira Davidson (14:09):

File.

Sara Moccand-Sayegh (15:46):

The file. Yeah. You will change the number and then it will be point GS. Okay?

Keira Davidson (15:46):

Yes.

Sara Moccand-Sayegh (15:54):

A and okay. That you can also find it in the dev tool. I will not explain it because maybe it’s a little bit complicated in a podcast, but you can also find it in the dev tool. And you can check if your company is using content fingerprint. For example, in my company, we use query parameters.

Keira Davidson (16:16):

Yes.

Sara Moccand-Sayegh (16:17):

Instead of content fingerprint. It’s not the most indicated, but it looks and it works fine.

Keira Davidson (16:24):

I guess it does the same thing as well, doesn’t it? It’s a way of identifying each file and making that file unique so that when a new, updated version is created, it can be assigned a new parameter.

Sara Moccand-Sayegh (16:40):

Exactly, exactly. You got it perfectly. So yes, it’s exactly that. So that is something that you can always do also to help a little bit the process. But again, probably discussing with developer, you will have tons of other fantastic idea and way then you can improve your JavaScript and help the web rendering service.

Keira Davidson (17:04):

Wow. That’s yeah. I definitely think that’s a good idea. Also, this popped into my mind, do you know, let’s say a JavaScript file has been updated on a particular product page. If the SEOs submitted that page in Google search console for indexing, would that then mean, because obviously that would then start a crawl for the page. Would that then help search engines identify that their file has been updated and a new name has been given to that file? So they recognize it?

Sara Moccand-Sayegh (17:42):

So if you gave the new name, yes. If you keep the old one, I don’t think then that will make, maybe will make the difference. But if you keep the old file name, I’m not sure then-

Keira Davidson (17:42):

Okay.

Sara Moccand-Sayegh (17:54):

That will help. I mean, because anyway, Google cache is not the same thing, same type of caching, but it will cache already the resources. So it will have already all the list of resources then you already gave him. So I don’t know exactly how it will work in that case. Because you are submitting and say, “Hey, do it again all.”

Or if you’ll keep anyway we not do it again all, because a lot of resources are already cached and you see, okay, this is equal to that one. So why should I do it? So-

Keira Davidson (18:32):

Exactly.

Sara Moccand-Sayegh (18:33):

I would advise anyway to change the name. But that is a good question and we can always ask Google.

Keira Davidson (18:40):

Yeah. Let’s just stick with changing the name, just to prevent any kind of issues.

Sara Moccand-Sayegh (18:45):

Exactly. So you changed the name, or you do as I do time to time, then I’m like, okay let’s ask the Women in Tech Community. Let’s ask directly to Google. So I will be it like, sorry, I have a question. Yeah, that is an option. But yes, I would say intuitively, I would say you need to change it to play it safe. And that’s probably the best solution, but yeah.

Keira Davidson (19:15):

That sounds great.

Sara Moccand-Sayegh (19:15):

I’m not 100% sure.

Keira Davidson (19:19):

No, that’s fine. So another myth that you might have faced is Google has no problem with SPAs.

Sara Moccand-Sayegh (19:31):

Yeah.

Keira Davidson (19:32):

Can you quickly explain what an SPA is just for my benefit?

Sara Moccand-Sayegh (19:35):

Yeah, sure. So a single page app. So that come from the previous myth. Because if you have no problem with JavaScript, why should you have a problem with a single page app? So let’s check together a little bit more of what is a single page app before diving a little bit deeper.

So a popular single page application framework are like Angular, Reactive, UGS. I’m sure then you know many more than I do. So there are tons of this single page application framework. So how a single page app works? So let’s start by making a difference and probably is the easiest way to understand how they work. So the traditional website is a static website. Okay?

Keira Davidson (20:27):

Yeah.

Sara Moccand-Sayegh (20:27):

Which have for each page you will have a HTML page and then you will have a CSS and the JavaScript resource, this one for each page. Okay?

Keira Davidson (20:40):

Yep.

Sara Moccand-Sayegh (20:40):

Now when you have a single page app, what you will have is just a single HTML page for all the … They’re not really pages, but let’s speak about pages. It would be a little bit easier. For all the pages then you can imagine, there is just one single HTML. Okay?

Keira Davidson (20:58):

Yes.

Sara Moccand-Sayegh (20:59):

The problem is then this was single HTML has no content.

Keira Davidson (21:04):

Okay.

Sara Moccand-Sayegh (21:05):

So why it doesn’t have content because it needs to be populated. It will be populated with JavaScript for each single of your pages, sort of pages.

Keira Davidson (21:20):

Yes.

Sara Moccand-Sayegh (21:21):

You shouldn’t really think about pages, but probably is the best way to explain it in a visual way if you want.

Keira Davidson (21:28):

Yes.

Sara Moccand-Sayegh (21:29):

So what happened? So you have this HTML page then is almost empty. And then you will have portion of the page then will change. And that will be the update. You will not change the entire page. You will change this portion of the page.

And an example, like the way then I finally understood it, because for me it was also, huh? So it was at the moment then somebody explained me, “But, Sara, you use it every day. Just check Gmail.” And then I was like, oh, that is it. Okay. Finally, I got it.

So if you use Gmail, you will realize then you will have new emails coming. But then you will not have … It will not update the entire page. You will just update the portion of the emails.

Keira Davidson (22:26):

Ah, okay. Yeah.

Sara Moccand-Sayegh (22:28):

And that is also how social networks works, for example. So if you use Twitter, then you can see it visually how it works also. And that is the logic of a single page app. So if you use Twitter, for example, you will have your tweets then update all the time. No?

Keira Davidson (22:28):

Yes.

Sara Moccand-Sayegh (22:28):

But not everything else.

Keira Davidson (22:28):

So it’s like the new-

Sara Moccand-Sayegh (22:43):

And that is the-

Keira Davidson (22:44):

Tweets are loaded in and they’re the new, they’re the change, and then the old tweets are just shifted down.

Sara Moccand-Sayegh (22:56):

Yes, exactly. So that is the way that it works. And that is like, so you have just portion of the page now updated. And to update this portion of the page, you have a method and this method is called adjuncts. So what will happen is that adjunct will have send a request to the server. And then you will get back your data, normally [inaudible 00:23:34], to update this portion of the page. I hope that was clear how it works.

Keira Davidson (23:42):

Yes.

Sara Moccand-Sayegh (23:45):

Okay. Whew, because that was difficult to explain. Okay. Whew. We did it. So now then we have the basic, now it became a little bit more complicated. So the problem is this, we have a single page app, but then we know from what we saw before, then URLs are super important. No? Because all the crawling system works through the URLs.

I would say, all the phase of crawling, rendering, and finally indexing. I mean, if you don’t have a URL, you have nothing. Okay?

Keira Davidson (23:45):

Exactly.

Sara Moccand-Sayegh (24:26):

So that’s mean then these are super important. But now we saw, then the problem was then in the single page app, we just change a portion of the page. So that’s mean then we are not having a response from the server. We are not having each time a new HTML, each time a new URL, and that’s make it more complicated. So luckily now single page app are a little bit more modern. Is that correct? The word modern in English?

Keira Davidson (24:26):

Modern.

Sara Moccand-Sayegh (25:02):

Modern. Thank you. So are a little bit more modern. And so what happened is then you will have your first request to the server and then you will have your answer, but then you will not have anymore really. In the past they contact with the server. Everything will happen on your browser.

Keira Davidson (25:27):

Okay.

Sara Moccand-Sayegh (25:28):

Everything will happen just on you browser. And this is something that makes special single page app. So everything happen in the browser. So is in the browser, then you’ll update also, you will have a lot of updates.

So when you have the single page app, you have a routing model. And they can act in two ways. So whatever I said, now, maybe you can forget it because it makes it a little bit more complicated. The only thing then you need to know is then you have a routing model and this routing model, what we’ll do is to help you with the URLs. To have URLs for your page.

Because if not, you will not have them. If not, you will always have, I don’t know, I work at Leap. Then I will just have Leap for all the page. Leap point ch for all the page. And that will be the problem. So you have this routing routine model then will help you.

And then you have two options. You have hash based routing history, API routing. Again, I will not explain it longer. The history API routing, you will speak to your developers because that is the method then is advised to use.

Keira Davidson (26:47):

Okay.

Sara Moccand-Sayegh (26:48):

Okay. Instead, and it will create the URLs the way then you can imagine URLs should be. Instead, the hash based routing method, what it will create is the hash. So for example, you will have like, let’s take again, my website, like the company that I work for. So Leap point ch, and then let’s say we want slash blog, for example. Instead of having slash blog, you will have an hash. Okay?

Keira Davidson (27:23):

Okay.

Sara Moccand-Sayegh (27:23):

And then blog.

Keira Davidson (27:23):

Yes.

Sara Moccand-Sayegh (27:23):

Okay.

Keira Davidson (27:24):

I think I’ve seen these.

Sara Moccand-Sayegh (27:27):

And that is bad. Why is bad? Because Google, that equals a fragmented URL. So the problem is then hash are, is way off sign to search engine. What come after that is not important.

Keira Davidson (27:41):

Yeah. Ah, okay. That’s interesting. I haven’t thought about that before.

Sara Moccand-Sayegh (27:47):

So yeah. So if you saw it now, maybe they did it on purpose or maybe not. Because normally, historically I think, I hope that I’m not saying something wrong. But historically I think then the hash was created, to jump from one part to the other one of-

Keira Davidson (28:05):

I’ve seen it-

Sara Moccand-Sayegh (28:06):

The page in their own.

Keira Davidson (28:07):

Yes, exactly that. That’s what I’ve seen. They might have do you know, at the top of a page they’ll have an executive summary and then they might have bullet pointed links. You click the link, it will then take you, let’s say to the bottom of the page where that content is. And that makes sense why they don’t care about it having the hashtag in the URL because it just gets ignored.

Sara Moccand-Sayegh (28:29):

Exactly. Because for that, it makes sense. Instead, if you want to go to another page with a completely different content, then you don’t want that.

Keira Davidson (28:29):

Exactly.

Sara Moccand-Sayegh (28:37):

Okay. I’m happy then you understood what I mean, because I was not so sure to explain it. Because it was looking a little bit complicated, but thank you so much. So, okay.

So now let’s think a little bit deeper. So now we have this URLs. But now what we know, we have some golden rules. What we know is then to index the page, Google need unique URL. So that we cite, we saw why. So that’s mean then when we generating URL, it needs to be unique. Ensure all links have a hash ref. Okay?

Keira Davidson (29:17):

Yes.

Sara Moccand-Sayegh (29:17):

So it means then you need your HTML mark cap with hash ref. Google was very vocal about that. They never hide it. They say, “You shouldn’t have an hash ref. We don’t even recognize it.” So, okay. So now we know you need an hash ref. There were several very creative way of writing links. Now we know then all these creative ways, they are no go.

Keira Davidson (29:44):

Yes.

Sara Moccand-Sayegh (29:45):

So, okay. So we know then we have a unique URL. We know then we need an hash ref. So the HTML cap. We know, then we need a target URL. Okay?

Keira Davidson (29:58):

Mm-hmm.

Sara Moccand-Sayegh (29:59):

What we also know then when you’re using a single page app, then you should use the history API and not the other method and create the fragmented. Because we know then fragmented is no, no, no, no. Okay?

Keira Davidson (29:59):

Yeah.

Sara Moccand-Sayegh (30:13):

So this is exactly what we know and how we should apply everything. So that’s mean then the only thing that we need to keep in mind, if we don’t see a URL with hash ref, and then the page then you want, and better, if there is the actual text, then it’s the wrong URL. Then something is wrong in that URL. So the good URL is that one.

And if it is in the final HTML, is perfect. It just shouldn’t be hidden. Everything, we also have to remember, that Google don’t click. So if you need to click something-

Keira Davidson (30:55):

They’re not going to find it.

Sara Moccand-Sayegh (30:59):

Have it. Yeah. It will not exist. So that is important. So now we know a capital thing about how single page work. We know how we should write a link. And that is the same logic also for single page app and not single page app.

Now single page app, obviously, because they’re single page app, they have an extra particularity. So we have site then. So let’s repeat it just to make sure. We have one request to the server. And then everything else happen in the browser. Okay?

Keira Davidson (31:44):

Yeah.

Sara Moccand-Sayegh (31:45):

So when happen in the browser, we say client side rendering. So the client side routing, the routing was that stuff then was taking care of the URL. The routing then will take care of the URL, as we said before.

Keira Davidson (32:01):

Yes.

Sara Moccand-Sayegh (32:02):

And the problem is that, as we said, we have a response code. The response code will always arrive from the server. But everything is happening in the browser and we don’t have anymore. They contact in a certain sense with the server. So we have a problem. Because if we have a 404, it should be the server, and server say 404.

Keira Davidson (32:30):

Yes.

Sara Moccand-Sayegh (32:30):

And then we don’t see the 404 for a single page app. Then there is Google, if you check the documentation about fix a JavaScript problem. I don’t remember exactly what was the name of documentation. But again, there, you will find some solution to this problem. And if, when you discuss with the developer, if they’re using single page app, just remind them, then they have to generate 404.

Keira Davidson (33:07):

Okay.

Sara Moccand-Sayegh (33:09):

It’s important. Because for us in SEO, we know we need to keep control on the 404. We want to know if there is a 404.

Keira Davidson (33:09):

Yes.

Sara Moccand-Sayegh (33:19):

And then that is important. Then to complete this part of the discussion, there was like, Jamie [Alberico 00:33:30]. She is so smart. Now she always have smart questions. And one of the question then there was this video, JavaScript SEO [inaudible 00:33:42]. And then she asked it in the video, what abouts adjuncts? How that affect crawl budgets?

So I don’t know if you remember what we say at the beginning, but so at the beginning, between, to change the portion of the website and we want to change, we use this method. And the method then we use to change the portion is adjuncts.

So this method is the contact with the server in a certain sense. So the process of sending the request to the server and bringing back the response without reloading the page. Because that is the key, not reloading the page.

So that’s mean then we have adjuncts and we are using this method. And then we still have a lot of request because we have to be in a complete web page. So before I give the answer on that, then I saw it on the video obviously. Let me just make clear for everybody, what is the crawl budget? Because maybe the most easy way to understand the crawl budget is how much reserve. I say reserve.

Keira Davidson (33:19):

Okay.

Sara Moccand-Sayegh (35:14):

I can do it. How much reserve the server hosting the site can allocate to crawling? Okay?

Keira Davidson (35:24):

Yes.

Sara Moccand-Sayegh (35:24):

So the problem is this, when you have too many requests, you don’t want to shut down your server. So obviously Google will be also careful how your server is the same server. Yes or no?

Keira Davidson (35:42):

Yeah.

Sara Moccand-Sayegh (35:42):

So if it is the same server, you will have many more requests from Google. So it means then at a certain point, we will have a limit. Also, because it can’t spend the entire night on your website because it needs to take care of the entire web. And plus there is the problem of your server. Okay?

Keira Davidson (35:42):

Mm-hmm.

Sara Moccand-Sayegh (36:07):

So how adjunct affect the crawl budget? So there was this example, if I’m not wrong. Yeah. There was this example. So say you have adjuncts for a product page. So what you will use is you have one request, but then you need to supplement your piece of contact for the product page.

So instead of just having one request, you will have nine extra request. So you think then you have one request, but then you have to supplement entire page, or the product page. And then each time is a request. Another request, another request, another request. So at the end, you finish to have 10 request to supplement your page. Okay?

Keira Davidson (36:58):

Yes.

Sara Moccand-Sayegh (37:00):

So that’s mean then you’re using your crawl budget. But, and this again but, as Google always say, we cache aggressively. As a result, that will happen just the first time. The next time they will have already cache all the information. So they will not need each time to do the same thing. So the next time then they will come back, they will ask for less crawl budget. Okay?

Keira Davidson (37:36):

Yes.

Sara Moccand-Sayegh (37:37):

But again, it doesn’t mean then you need to throw away your crawl budget. Especially if you are a large website, last thing then you want to do is throw it away like if it is nothing.

Keira Davidson (37:37):

Exactly.

Sara Moccand-Sayegh (37:52):

So anyway, be careful. And then, so it was a little bit complicated, this part. And then what as a SEO, we can do, as we say before, we were speaking about the testing tool for in general, and that could be applied on the single page app to use search consult, mobile finding test.

You can always use the site command if you want to check. So a little bit manually, I always taking the content. So you can always use that on Google and check if it’s taking the entire content of your page. Especially for the product page, maybe you want to check.

Keira Davidson (37:52):

Oh, wow.

Sara Moccand-Sayegh (38:35):

Okay. I don’t know how much time do we still have? This we decide if we go to the next meet, or we switch a meet, what do you think?

Keira Davidson (38:45):

As much as I’d love to go on, I think maybe we could potentially revisit this again in the future. For now, it’s been great speaking with you. I personally now actually understand SPAs. I didn’t realize that I’ve come across them in the past without even knowing it. It’s been great speaking with you. I’ve had great fun and I’ve learned so much. Thank you.

Sara Moccand-Sayegh (39:12):

For me, it’s super to speak with you. And it is really a pleasure. Yeah. You’re an incredible host.

Keira Davidson (39:12):

Thank you.

The post S3E4 Sara Moccand-Sayegh, JavaScript SEO Myths appeared first on The TechSEO Podcast.

Keira Davidson (00:21):

Hi, and welcome to the TechSEO Podcast. I’m Keira Davidson, your host and today I’m joined with Mercy. Would you mind giving a little bit of background information on yourself, please?

Mercy Janaki (00:32):

Thanks, Keira. Thanks for having me. It’s a pleasure talking to you here. And hello everyone. I’m Mercy and I have more than 10 years experience and I enjoy what I do in all [inaudible 00:00:47]. And I’m currently working with a growth marketing agency, which is Position Squared. It is headquartered in Santa Clara, California, and I am based out in Bangalore, India.

Keira Davidson (00:59):

Oh, that sounds really exciting. So today the plan is around progressive web apps, JavaScript and how all that ties into SEO. Progressive web apps is a relatively new concept to myself. How would you go around learning information on this?

Mercy Janaki (01:23):

Yeah, so as you said, maybe more websites are coming into progressive web apps, and there are lot of advantages. Probably there is certain disadvantages in terms of SEO. But SEO it is not just one part of it.

The users and how you quickly wanted to load the content. How interactive you wanted to have your website. Then [inaudible 00:01:55] is a great solution for anyone.

So, based on that factor only I feel that many websites are recently taking an approach of getting the website done using JavaScript framework. Something like React JS and Angular JS and also the progressive web app. So especially when you are in a agency site, you always get a opportunity to learn more. Because you always tend to get lot of new clients and every client is not the same client, even you get to eCommerce client, each website will have a different set of issues. So you need to look for a different set of solutions. That is where the advantage for people who work in an agency is what I believe. And that is when I started facing certain websites that come for optimization that has the JavaScript framework. And that is how I started learning about it. And I should say that it is very challenging and very interesting to know.

Keira Davidson (03:12):

Yeah, from what I’ve read around, it’s quite complex, but it definitely sounds super interesting and something I should spend more time learning around. So my understanding is PWAs and JavaScript. It can affect the rendering of the page. And obviously, it’s really important that there’s no issues around that. How would you typically go around checking this or making sure that it’s okay and working correctly?

Mercy Janaki (03:47):

So as you rightly said, the rendering is the first thing that anyone has to take a look when they wanted to optimize the JavaScript or PWA website. So, and also people should be aware that indexing is different and rendering is different. Both are not a similar concept. And Google search consult is the perfect tool for you to go and identify is your Google bot is rendering all the information that you are serving via Java script. And sometimes you might not be able to get the Google Search Console access for multiple reasons. Like the client might not have just Google Search Console configured or for some reasons that is getting delayed, getting access is a problem. So in that case, I would recommend that you use your the mobile, the Google’s version of mobile friendly checker tool. There also, you can take up URL and see whether the Java script powered content or powered features are rendered particularly. So these are the two specific tools that I would recommend.

Keira Davidson (05:04):

That sounds great. Just out of curiosity. Can you also see it in dev tools as well in the performance tab?

Mercy Janaki (05:16):

So no, the performance cannot be seen through the mobile friendly checker. The Google Search Control is the only option where you can go and identify the the search queries that you are receiving and the clicks that you are receiving. But the other crawling tools that are available in the market is also becoming so sophisticated to solve these problems. So I use Screening Frog a lot to crawl a big volume websites. And do you have an option to specifically set the JavaScript crawling and rendering?

Keira Davidson (05:59):

Yes.

Mercy Janaki (05:59):

That also gives you the right information. So there are tools available. So you don’t have to specifically call out tools. None of the SEO tools are so comprehensive that it covers each and every aspect of it. So, but my choice would be the Screaming Frog and also the Deep Run.

Keira Davidson (06:23):

Yes. Ah, sounds super interesting. And are there any ultimate dos and don’ts when it comes to implementing this at all? Or are there any key considerations that really need to be thought about before making the move?

Mercy Janaki (06:45):

Definitely. That’s a great question, I think, because most of the time, the problem that I see is when the website is being developed using the JS framework, what happens is it also comes with the client side rendering. So, the client side rendering and the JavaScript rendering goes hand in hand for user perspective. You can deliver a very interactive website. You can deliver a very fast loading websites. All of these things can be taken care of in terms of users, but when it comes to SEO world, this is definitely going to be a problem because only the Google bot is currently have the resource to crawl the Java script, not the other bots. Maybe they’re not sophisticated yet enough to do as much as the Google bot does it.

And also… So this is what I would say, instead of rendering the content through client side, probably the websites can, or the developers can, think of a scenario of doing it in a server side rendering so that the content and the basic SEO elements, like page title, descriptions, and canonical tags and meta robots tag and stuff like that can at least be rendered through server side. And probably the other things like the video embeds and stuff like that can be happened through the client site rendering. That is what I would recommend to do it.

Recently Google has also been promoting a lot about dynamic rendering. You use both server side as well as the client side rendering. To be specific, you can identify which is actually crawling the website. So if it is a user bot coming to your website, then you serve the details through server side so that the bots doesn’t have any issues in crawling your content, crawling your SEO specific details like metatag and robot, meta robots, and et cetera. When a user browse your website it comes from a browser point of view, then probably render the information through client side so that the interactivity or the fast loading experience can seamlessly happen for the user. So this is the, do’s and don’ts I would recommend on a large scale.

Keira Davidson (09:28):

That sounds great. Thank you. Are there any courses out there where you can learn about this, or is it a case of just using the typical sites for information on this? Like how would it beginner get into get gaining more knowledge on this?

Mercy Janaki (09:49):

Sure. I have started, I actually went into a situation where I have to learn about it, then I learned about it. So there was a website came for an optimization. I was not aware of JavaScript [inaudible 00:10:05]. And then I decided that, okay, this is where I led and I have to do it. So there a lot of resources that are available on online, especially that I have to say this because SEO community is one community where everyone is so happy to share their experience and share their learning for free of cost. I never seen such sharing happens in other communities.

So you name a problem, you have a solution online. So there are DIY guides come from tools like Screaming Frogs and even individual experts have done that. But the first recommendations that I would say is Google has been doing a video series on the JavaScript series. So that is a lightning talk happens. It is not so complicated. They make it very easy for the layman to understand the language. That is what I recommend to start with. But once you get the hang of the basics, probably you can start reading about more so that you can expand your knowledge in that.

Keira Davidson (11:18):

That sounds great. Yeah. I’ve been watching a couple of those videos that Google’s been put out and they’ve been so beneficial. So I think if I keep sticking it, then I can move on the reading side of it and it’ll all make a bit more sense.

Mercy Janaki (11:37):

Yeah, correct.

Keira Davidson (11:40):

So, do you have like a checklist on how to implement this? Or like you said, there can be things that are overlooked or key things that need to happen to make sure it runs smoothly. Do you typically follow a checklist for this? Or how do you go about that?

Mercy Janaki (12:01):

Yeah, first thing I would say that before getting into SEO optimization, the first thing to check is whether your content is being rendered by the bots. That is, if there is a problem in that, how much optimization you do, how much of content you put in on the website in terms of blog or product page and category page or whatever it is not going to help, because bot is not going to read that. So half the website has a launchpad for your organic growth. The website rendering is the key. So fix, have a check and identify whether it is all good to go. If not, probably all your concentration should revolve around that to fix it. Once the rendering is happening, then we can gradually get into all the SEO optimization. It is not totally different. It’s not a different set of game. Like you do optimization separately for a HTML website and do separately for a Java website. It is the same, but to make sure that the code the SEO optimization that you do is visible for the bot. That is where the problem is. So the checklists, I would say, remind the same for like the other websites that you optimize, but the initial the additional checkpoint should be is your content rendered by any bot, not just Google, but any bot.

Keira Davidson (13:35):

That sounds great. Yeah. That’s really important to make sure that it’s being rendered at all and that bots can access it no matter whether it’s Google or Yandex, whoever it is, it’s really important.

Mercy Janaki (13:49):

Yeah, you’re right.

Keira Davidson (13:52):

So my understanding is that you have some… You’ve been working on some sites that have taken this approach, obviously as of May, Google is going to be rolling out their page experience update, and it’s obviously not going to be an instant take instant effect. It’s going to grow over time. Do you find there’s many issues around these sites where there page experience issues?

Mercy Janaki (14:23):

Actually, I would say that these JavaScript and the PWS sites have a edge over the other websites in terms of page experience, because the main objective of doing these frameworks is to improve the page speed and provide the right interactivity for the users and the business. So in that way, I see always the edge over for these websites on the Google code launch that is going, I mean, it’s going to happen in the coming days. But probably the CLS is what we should be really care about. Is there going to be a large shift happening around it because, you are going to call different JS modules in different areas. And if you don’t do that, right, probably the CLS gets affected and you might need to have a look around that.

And also mistakenly what happens is we, the developers by mistaken tend to block certain JavaScript resources for Google bots as well. I mean, generally for bot, not just Google bot. Yeah. So we should also be careful about that so that if not every element of your page might be visible for the bot. So it is not related to the page speed, sorry, page experience metrics. But while talking about it, I just got about that.

Keira Davidson (16:02):

That’s great. Thank you for providing that insight. Yeah. It’s really important that to be aware of what developers are doing. So no, no accidents occur.

Mercy Janaki (16:16):

Yeah.

Keira Davidson (16:19):

I’ve really enjoyed speaking with you today. Thank you so much for joining the TechSEO podcast. It’s been great. And it’s highlighted to me personally, how much I’ve got to learn around PWAs, especially. Because it’s not familiar at all and so much information out there that I really need to tap into. So I really appreciate that. Thank you.

Mercy Janaki (16:47):

Thanks. Keira, it was a pleasure talking to you and we all learn from each other and grow together.

Keira Davidson (16:53):

Exactly. Thanks so much.

Mercy Janaki (16:55):

Thanks Keira. Appreciate it. Bye.

Keira Davidson (16:55):

Bye.

The post S3E3 Mercy Janaki, SEO Challenges with PWAs & JS appeared first on The TechSEO Podcast.