Candour

Episode 106: SEO QA with Gianna Brachetti-Truskawa

Play this episode:

Or get it on:

What's in this episode?

In this episode, you will hear Mark Williams-Cook joined by Gianna Brachetti-Truskawa from Startdowns.de to discuss QA in technical SEO, including:

  • What is QA in SEO and why does it matter?

  • Tools and processes for QA in SEO

  • How technical translation and technical SEO are similar

  • How to build relationships with internal teams

  • Advice for those getting into technical SEO

Show notes

Gianna's twitter https://twitter.com/tentaclequing

Kafe Rocks career page https://kafe.rocks/careers/

WITSEO episode (episode 75) https://withcandour.co.uk/blog/episode-75-women-in-tech-seo-with-areej-abuali

Little Warden (episode 97) https://withcandour.co.uk/blog/episode-97-site-monitoring-with-dom-hodgson-from-little-warden

Transcription

MC: Welcome to episode 106 of the Search with Candour podcast, recorded on Tuesday the 6th of April, 2021. My name is Mark Williams-Cook and today I am going to be joined by Gianna Brachetti-Truskawa, who is the VP of SEO at Stardowns.de and we're going to be talking all about QA in SEO. That's quality assurance in SEO, what that process looks like, how it can save you time, money, and from doing endless audits.

Before we kick off, I want to tell you this episode is very kindly sponsored by the brilliant Sitebulb. If you haven't heard of Sitebulb before, it's a desktop-based SEO auditing tool for Windows and Mac. I've used it for years, we've used it at Candour for a long time. So, absolutely happy talking about it, really glad they chose to sponsor us.

Every week, normally I pick up on one thing I particularly like about Sitebulb. And here in this chat we have with Gianna, we're going to talk a lot about languages and international SEO, what we do at the beginning. And this is one thing that Sitebulb is particularly strong at, which is the checking and validation of the nightmare that can be hreflang tags. So, if you're dealing with an international site, I'm sure you know what I mean. It can become very difficult to make sure all of those hreflang tags are bidirectional, that you're using your x-default in the right place, that you've got, ideally, your self-referential ones and they're only pointing to canonical pages.

Sitebulb does this incredibly well. It will audit the entire hreflang relationship and give you a breakdown of any gaps that you've got. Even on sites that I've worked on where I've given good briefs, checked it as it's gone, I've found issues when I've run this tool on the staging site. Because, of course, you are using a staging site and not putting stuff straight out on live, right? I thought so. You can get a free trial of Sitebulb on their site, but if you're a Search with Candour listener and if you go to Sitebulb.com/swc, you can actually get an extended 60-day trial of the software. There's no credit card or anything required, so no excuse not to give it a go if you haven't already. It's really quick to get going. Sitebulb.com/swc.

And today, we are very kindly joined by Gianna Brachetti-Truskawa. I think I got that roughly correct? I had a quick stab before we started recording and Gianna was very kind to say I got it close. But I think it was slightly better that time?

GBT: It was definitely.

MC: So, thank you for joining us. We're going to be talking today a little bit about technical SEO and especially QA, quality assurance, in SEO, which I think is a really interesting topic because, actually, I hadn't heard that many people speak about it, and I know you've got a lot of experience in SEO.

So, those that don't know you, do you want to just give a little bit of background as to where you're currently working and maybe how you got into SEO as well?

GBT: Mm-hmm, of course, thank you. So, how did I get into SEO? Or should I start with what I do right now? I should start with what I do right now.

Right now, I am the Vice President of SEO at Startdowns, which is a German company. But we do have another company that's called Kafe Rocks Ltd., which is... How do you say that? We are the subsidiary of them, let's put it that way. And as such, I'm consulting, as the Vice President of SEO KaFe Rocks, as an in-house service. So, I'm actually an in-house SEO, though it might look from the outside like it's an agency because Startdowns do have other projects. But I'm not involved with other projects currently.

What we do is we have websites. We're doing affiliate websites, actually, in iGaming. And so far we've got 60 domains that I'm managing with my team. So, it's quite a lot, in different languages and markets, and the number is rising. So, that's what I'm doing right now.

What I did before - I did a lot of SEO in the past few years, both in-house as well as in agencies. And mostly I was working with big websites. For example, I was working with one of Europe's biggest recipe websites and since we had millions of URLs, my main tasks were often technical because you have to do some things that have some kind of leverage, to some degree. But I was also, obviously, also consulting their editorial teams when it came to optimising content. And before that, I used to be a technical translator for IT and for engineering.

MC: So, this is something we actually spoke about before we started recording. We actually ended up talking about languages instead of SEO. And you were bringing up how, in some ways, there's similarities between translation and technical SEO?

GBT: Mm-hmm.

MC: Do you want to just explain that for people that have no idea, like me, about actually what technical translating is involved with?

GBT: Of course. In general, any kind of translation is actually a very analytical thing to do. Many people don't know because translation, as such, is not a protected entity.

What I mean by this is anyone can call themselves a translator, whether or not they have studied it or have experience. They can just say, "Oh, I grew up bilingual, I can just be a translator." But actually, when you study it, which is what I did, and you learn a lot of techniques and it's a very analytical, logical thing to do. So, you analySe from, let's say, a text that you want to translate from one language into another. Let's say from German into English.

So, you analyse and kind of deconstruct any cultural implications the German text has and any structures. And then you do the same with the English target... Well, you don't have an English target text. You have to produce it. But you do it with, for example, similar texts. So, you figure out what structure that text needs to be for an English native speaker. And that, of course, isn't the same for every country where you speak English as a first language.

So, you have to figure out - is it different in Britain or in Australia and so on. This can go a long way. For example, I had someone ask me to translate things from their Australian online shop into German and French, and then they said, "Are they..."

They provided me every document they had, which was mainly product websites. But I told them, "Well, you need some legal documents for Germany." There's some... I don't even know the English word for it, but you have to provide some legal document that, when you order anything online, you've got 14 days to revoke that order as a customer. And if that's missing, you're in big trouble here.

So, of course, he did not provide me with a source document to translate into. But translation is consulting. A lot of times, it's consulting the clients and saying, "You need this. I can't provide it for you, but you need," for example, "to get legal advice to make sure it's actually legally correct." In some cases, translators can do that as well. It's just a question if you want to be liable or not.

But anyway, basically what you do is, you look for patterns. You look for patterns in both languages, but also in the cultures. And you try to also reconstruct those into the other language. And I think what I do in SEO is a lot of times looking for patterns. So, it is not that different, actually.

MC: I think you touched on something really interesting there, as well, from people who are maybe already in a technical SEO role, when they're dealing with international SEO because it was certainly something I was ignorant about, being someone that primarily only speaks one language And until I actually made a friend who worked in the translation industry, translation, to me, was very much about, "Here are some words, can you please make them in the other language?"

But as I came to do more international SEO and got involved in it, and especially from a marketing point of view, as you say, even in English and when you travel, say, and you go to the States, you just hear, you see a TV ad and realise just how different even stuff in the same language is because of the culture.

Because the TV ads, to me, in the States were almost offensive in how hard-sell they were, coming from England. And this made me think, "Oh, wow, I wonder how the conversion copy," if you like, "that we have for the UK looks in the US." And it looks awful, basically, because it's not what they're expecting. This was only magnified when I spoke to this person working in translation around certain phrases and meanings and what's culturally important. It just doesn't translate right when you just translate the words.

GBT: Yep, true. And it's not just about the mere words, but also about the need for information that also differs largely in the culture.

So, for example, let's say you have a travel website and promote travels to Sardinia. Then a British person, what would a British person have to know, other than, I don't know, some facts about Sardinia? They should probably know, "Hey, please bring a sun blocker and don't leave your empty beer bottles at the beach." But when it comes to an Australian person, they don't need to know that they do need a sunblocker. They might already think about that. So, for them, that is information that is useless.

But what they might need to know if you can go swim there, there's no sharks. Or something like that. But there might be drunk British people, and when it comes to an American person from the US, they might need to know where Sardinia actually is, that it's in the northern hemisphere of the Earth. I mean, of course, that's a bit extreme, but that's just to get across what I mean. They have different needs for information as well.

MC: So, just to frame this correctly, although Startdowns is an agency, really, you would see your role almost as an in-house role, that be comparable?

GBT: Yes, entirely in-house.

MC: Yeah.

GBT: Because I'm only, at least for now, I don't think that's going to change soon because we've got 60 domains to manage, managing the domains of Kafe Rocks and I'm managing the SEO team of Kafe Rocks.

MC: And that's an incredible amount of domains in any niche. But are they all, if you can tell me, are they all in iGaming?

GBT: Yep.

MC: Because, I mean, I haven't done any work recently in iGaming. I mean, I did some SEO in iGaming, some affiliate stuff. And the way I ended up actually being an affiliate in iGaming was to, and this was a long time ago and you'll get an idea of why in a moment, was actually compiling books on how to play poker and tips and sharing them on LimeWire and embedding affiliate codes in them because I found, then, I didn't have to rank. I could just get the files shared. But at the time, that was brutally competitive. Is that still the same now?

GBT: Oh, gosh. Yes. Absolutely, if not even worse. Yep.

MC: Yeah, so to people listening, my advice would be if you meet SEOs that are working in iGaming, I always prick my ears up because these people are really up against it in terms of they're not just making some good content and then just ranking, they're having to pull out all of the tricks out the bag normally.

But speaking of tricks, the thing is what makes us very different from other companies in that niche is that we are only doing white-hat SEO.

GBT: And when you do that, gosh, yeah, that is not easy because your competitors don't play that fairly. So, you see a lot of websites ranking with PBNs and so on.

MC: Hm.

GBT: So, we're not doing that. But if you want to get ahead of them, or compete with them successfully without doing that, then yes, you have to know what you're doing, I would say.

MC: Yeah, so I wasn't trying to cast aspersions there. I meant all the tricks as in every single box checked in the white-hat list of making sure everything's covered.

GBT: Yeah.

MC: So, let's start to talk about this because I had written down some questions for you around audits and tools and things. Something you mentioned you wanted to talk about was QA in SEO, and I had to double check with you, you meant quality assurance, right? And you were like, "Yeah, of course. It's really important. It's a big topic." And apart from, I think, I've heard Aleyda touch on it before when I spoke to her around... And this was actually around kind of after you've done an audit, checking stuff's actually been done and it stays right.

Apart from that, I actually don't think I've heard anyone speak about QA in SEO, really, at all. So, do you want to just give us an intro into why you think that's important and what it looks like, what are those processes looking like?

GBT: Of course, I'd love to. Basically, QA's important because, let's say, if you just relied on doing technical audits, you might just move too slowly.

So, for example, we've got 60 domains. I mean, I'll never be done. And by the time I'm done with 1/3 of them, I could actually start over because there's even... Things have changed and so on. Also, you will not catch things that might happen in deployment cycles. So, the most important thing here is to understand processes like how deployment cycles work in your company, or in the company you're working with because you can totally also do QA for a client.

But this requires them to link you very closely to their deployment, so their tech department and development, and if they have the product department as well. Let me just tie that into a few cases that I've had, that make you sure first understand why SEO is important, or why QA in SEO is important.

There was a deployment that, and just, I don't know, just a week after the deployment was done, one of our pages lost all our rich snippets in the search results, everything. And on top of that, traffic was going down 10% each week. So, when you realise that, the first thing is you have to be able to see, "Is that happening... Was there an update? Or is that happening due to a technical issue on our part?" It's much easier if you do QA regularly and not just on-demand when shit is already burning, so to speak.

The issue was that, when you look at the domain, everything looked fine. You could just, as a user, you could just browse the page and everything looked fine. So, this is an odd thing. And then you start doing some kind of, let's say, technical audit, but not a complete one, just tied to that one issue and trying to find out what happened. But until we found the issue and until we could actually solve that issue, we lost traffic. And by that, we also lost revenue because we don't do any other marketing. So, there is only SEO as only organic traffic. So, that hurts us a great deal if that happens, which is a good thing for me because SEO is the most important thing we do.

Or another thing that happened was, not with Kafe Rocks right now, but with my previous employer, was suddenly Googlebot could no longer access our sites. And I only realised, again, because traffic started going down. And we couldn't find any issue whatsoever. We did cross technical audits and so on. There was no negative attack whatsoever. And there was no deployment. That's the funny thing, though. There was no deployment that they... They told me there was none. Of course, they always do, but there was really none because I secretly spied on our developers at the time as well with the monitoring tool.

So, what happened was they had the Kernel update on one of our service, they were running a Linux. And that caused an issue which only blocked out Googlebot. So, in checking that and finding that issue, I found it through checking crawl frequency, and that was going down. And it was going down because suddenly the time it took to download a document for Googlebot was just super low, which you usually would think is a nice thing. But if it's going to zero, it's not a good thing.

So, these kind of things happen and they happen more frequently when you don't do QA. And then it takes up all your time. So, whatever nice SEO strategy you have thought of, in that moment, when it happens, you have to stop everything you do and try to go look for the error. I'm not saying that this still can't happen, even when you do QA, because there's always things that slip through. But it just happens much less frequently. And if they do, they're usually edge cases that are just a bit more complicated. It's also always fine when that happens, but then at least you know that everything else is going to be fine.

So, it's basically to avoid losing traffic at the end of the day. It's that and the easiest way to avoid that, because when you're not involved in any of the deployments or the deployments cycles, then you don't know what things they are going to work on next week, for example. So, you don't know what to check even. Or, you might... I have often seen people not actually doing any QA. So, that's maybe why you don't hear it often. They do audits on-demand or regular, but not the way you do QA. And they might not even know all of the things that developers do.

Or, if they do, they only check the tickets they think are relevant for SEO. But actually everything that is happening on the front end is relevant for SEO, to some degree. And even some things happening in the back end, because it can affect the performance of your site. What I often see is people just check the tickets. So, there's a ticket, I don't know, let's say it's only, as they say, only affecting title tags. Okay, that sounds nice. But it can still, theoretically, break something else that is not entirely unrelated to title tags, just due to the way the system is built and it is very hard to estimate that upfront.

So, sometimes you can because there are obvious cases, but sometimes you simply can't. Sometimes even your developers will not be able to estimate that this could happen, especially if you're working with custom-built CMS's or older ones and no documentation in the code and so on.

But it can even happen with WordPress. I don't know. Maybe you forgot to update a plugin and there was a backdoor that someone used. Or there's so many things that can happen. So, it's important to check, to make a list of all things that you think that could theoretically be affected, no matter what the tickets are and then you have some... So, these other things that you check regularly, every week, or every deployment cycle. If the deployment cycle is longer, then, of course, it's not every week.

Ideally, you have a testing environment, so you can check before and after the deployment. And I have also seen a lot of companies just working on the live site, which makes QA even more important.

MC: Wow, brave.

GBT: I have seen that happening so often, more often than, actually, people having test environments, yes, it's awful. It's sad, actually, but it does happen. It makes your job just very exciting. Yeah.

But anyway, you have those things, things that you should regularly check. I don't know. Our title text is in there, you don't have to check every change to them, but theoretically they could also just disappear. I don't know. Are images still there? Is there a higher number of internal errors or is that kind of thing... And then you have that list. And on top of that, for every deployment cycle, there might be a ticket that might just add something extra to it.

For example, if you have a ticket that is introducing structure data of some sort that you haven't had before, then of course that's extra and you're checking that extra. But that way you know what you're checking every week or every deployment cycle. And you can also, of course... So, theoretically, if you test things very thoroughly, even with different devices and so on to make sure it's working on every device, then it's taking up a lot of time and then you won't be able to do any SEO strategies anymore. And someone in the company's going to ask you, "You're doing QA all the time and why are you not doing SEO?"

So, you have to figure out a way to lift some of that off your shoulders. And what you can do is you can use monitoring tools to your advantage. I just recently showed, at a German conference, I showed the way to make that process a little better.

So, you figure out, you have that list of all the things you want to check. Then you figure out if there's a tool that can check that for you. So, some things are already checked by Search Console, for example, and Search Console is sending you alerts and when those come, you can actually use other tools to bring those alerts into whatever channel you're using with your team. So, for example, we're using Slack as the main communication because our company has always been remote, not just since the pandemic. So, for us, that was the most efficient way. If you're using, I don't know, a team email address or something like that, you could also use that. But I'm just taking Slack as an example for now because that's what we do.

So, you could filter all the emails from Search Console and actually you're going to see that Search Console was using a code in each email for a specific error type. And it's the same for each error type, it's the same code, which makes it much better to filter them instead of just filtering for words like, "Search Console," because then you get everything.

And I mean, we regularly update our disabled files for example. If you have that for 60 domains, you get a lot of alerts and then our channel would be full of alerts and you don't see the important ones anymore.

Anyway, so we figure out the codes that we want to filter for and either you have a developer or you know how to do that yourself, to fetch those things through Google Search Console API, if that is possible, or, whichever is way easier and faster, you just use a middleware kind of thing, which would be, for example, Zapier. And you can use that and set it up, saying, "If an email comes with that code in it, forward it into this Slack channel," so we have a QA alerts channel where that comes in, as well as down times of our service, for example, via pingdom tools.

But, of course, Search Console doesn't check everything and sometimes you want to be alerted of things before Google notices them or before they become a problem. There's other software you can use, for example, Little Warden. Didn't you have... The Little Warden guy, what was his name?

MC: Dom Hodgeson.

GBT: Okay, yeah, you had him on a podcast, right?

MC: Yes, yeah, lovely chap. Always raising money for charity and yeah, they've just rolled out, I noticed, all of the core web vital stuff now with Little Warden, which is great because I think that's caused some misunderstanding, certainly, with people between the Chrome user experience data that you've got in Search Console, which is obviously helpful.

But then people taking these one-off snapshots with lab tools which, again, aren't so helpful. So, Little Warden now can constantly just ping away your site and you can actually then get a decent average because that was actually something I learned fairly recently, which was a lot of that data in Search Console for the core web vitals is a month-old before it gets aggregated and put on there.

And like you said, that's something really, if you make a change, you don't want to be waiting a month before you've noticed because then it might be another month before it's fixed. And then there might be a tangible impact.

GBT: Exactly, yep. But we use Little Warden, for example, but there's obviously other tools that are similar things like, for example, ContentKing, for the German market there's card score so there are a few tools you can use. The advantage of Little Warden is they also already have a web connector for Slack, so you can just easily have any notifications from them coming into Slack. So, we get those as well. You can set up custom alerts in Google Analytics.

So, for example, I set up one to alert me if traffic from one week to the other drops by X% and you get those as well. And this all goes into our QA alerts channel and then we figured out, with my team, some kind of... You can attach emojis to messages there. I don't know if you can do that with Microsoft Teams or whatever people are using. But I find that pretty helpful because we have some kind of code. So, when someone's looking up that, they're just using an emoji and so we know if someone is looking into it and the others can relax. And when it's done, they add a green arrow, that kind of thing.

There's another connector between Slack and Jira, because we're using Jira and Confluence as well. And so we can directly use that, if you've figured out what the issue is and create, from Slack, without having to change out of Slack, you can just create a Jira ticket directly. And because it's connected to the QA alerts channel, we would also see the status of the ticket. So, that's also very helpful and just makes things way faster if you need to get them fixed.

Yeah, ultimately, it's just about processes. So, getting people to understand, either clients or your in-house teams, that you need to be included in development processes at all times, and to what extent and what that means. For example, in our case, that means adding SEO acceptance criteria to every ticket, even though this ticket might not come from us. So, as an SEO you have more than just one function, right?

On the one hand, you are, let's say, the subject matter expert for SEO. And so you give your feedback or the acceptance criteria for tickets that are requested from other departments. But also, you can be a stakeholder for your own tickets because you might ask them to add a feature for primarily SEO purposes. So, you always have those two functions, at the very least. That can sometimes be a bit tricky, but that's a whole topic altogether. But as the subject matter expert, it's super important because you're accountable. At the end of the day, whatever they do with your website, you are the one accountable if your traffic drops.

MC: Yes.

GBT: Especially if it’s organic traffic. And that's why I made... In my case, it was fairly easy because it's our only marketing channel. So, it was easy to tell them that we need to do QA.

MC: In terms of, you mentioned about getting involved in that deployment process, so maybe when developers hopefully, as you said, have a staging and testing environment, the development staging and live environment, rather than just old-school, whack it when it's live and see what happens, how do you feel about where that responsibility lies?

Because I always think this is an interesting conversation in that developers learn their craft and a lot of them are very, and rightfully, user-centric. They think about the user in whatever they're creating. They might be thinking about things that users obviously notice, like speeds and accessibility is obviously something that comes under development remit. I think technical SEO, and I specifically define technical SEO a lot of the time as sometimes it's the stuff that is not visible to users, but it's there for search engines. So, stuff like canonical tags, hreflang are things that the user never notices are there, right? And schema is another one. And they're there to aid search engines in the understanding of the site.

So, it's understandable that I still encounter developers nowadays who maybe they've just missed that chapter and those things have never been important to them. When you're reviewing sites at this development stage, do you think it's the job of the SEO to try and integrate and give the responsibility of those things to the developer almost? So, you could say, for instance, as a rule you could apply anywhere, all of our main pages need to be accessible without JavaScript or something like that. Is that something you would pass onto a developer? Or do you think that should stay with the SEO team?

GBT: Well, first of all, we have to define what is responsibility. There is responsibility and there is accountability. So, we handle those as two different entities in our company. So, for example, I'm accountable, no matter what, but I'm accountable at the end of the day for the visibility of our sites. But the responsibility can be shared or can be handed over. It's just a question of how you do it.

So, one thing that I have done previously and that I've found very helpful was we defined... For tickets, you cannot define a definition of, "done” and only when those boxes are all ticked, the ticket can be moved to done. Usually, these things are not at all related to SEO, but you can make them so. You can ask the product owner or whoever or to see whoever is involved or the lead developer, you can ask them to add specific things for SEO to make them understand if these are not checked and are not okay, then the ticket is not done. And that way you hand over the responsibility and even make it measurable to some extent.

So, for example, you can say, "Pages indexable” or we did it a bit more vaguely. We said, "Does this ticket make a change to the indexability? And if it does, then ping the SEO first." And only when you've done that, then you can set it to done or tick that box. We had multiple of those, so we had to make five SEO boxes in the definition of done in that ticket, and that way you make it more just systematic in a way.

MC: I really like that breakdown between responsibility and accountability. I think they sometimes do get merged together.

GBT: Yes, often they do, yeah.

MC: So, I know you've dealt with a lot of leadership teams before while you've been working in SEO. And this is, again, potentially a big question, but I will just put it out there for you: How do you go about communicating the value of technical SEO to leadership teams at a strategic level?

Because I know lots of technical SEO people and I see them struggle with this because they dive straight in. And again, as soon as you start talking about hreflang, canonical tags, you can almost see people falling asleep. So, how do you get that value across?

GBT: Oh, I had to learn this the hard way as well because I tend to lose myself in the technical details, and that's not good. You have to really break it down to user stories, so to speak. So, that's what I really like, what I learned about or through agile development. I hate to provide user stories myself to my tickets, to be honest, but it doesn't make sense for anyone who's non-technical to understand why do you want this, because whatever you want as an SEO, there's many people in the company who will see this as, I don't know, annoying or making them work more, just adding more tasks to the list. And they don't like it unless they understand what it's for.

So, that's where user stories are interesting. And from that point of view, either what you want is good for the users because, for example, they can find your website through Google and maybe that's the main point of entry that they're using, especially new users who do not already know your brand. Or you treat the search engine as a user because, ultimately, it somehow is. And you have to get everyone on the same page. So, is organic exposure what you want at all as a business? If you don't, then you're going to have a hard time.

But on the other hand, if we're talking technical SEO, a lot of things you do should ideally also be done by developers, some parts of the QA, for example. But it just helps them focus on coding. Ideally, also, reviewing their own code. But it's just another instance of checking and making sure things are working properly, and that's what you ultimately want.

So, for example, while internal broken links do seem like a purely SEO thing, they're obviously not. You might want people to convert to another internal page. And if that link is not working, it's bad either way. So, there's so many links between SEO and other departments or other disciplines that it does make sense that, for example, SEOs do proper QA and so on, and have a say in things that you do in your business. Unless, of course, organic exposure is not at all what you're after. Then it's difficult.

For me, it was fairly easy because it's our only marketing channel, so then it's not that hard to make people understand strategically. But still, you have to break it down. So, of course, talking about hreflangs at-length isn't helping. But talking about... I mean, why are you ultimately doing this? You want the users of the correct market to come to your page and convert.

So, if I'm not using them correctly, and that means my page for, I don't know, let's say you have a shop for Australia, but it's ranking in the UK and people just jump off your page back to the search results and choose a competitor who is Australian because they don't want to pay high shipping fees and customs, which makes total sense, then it's easy to tell it, "Hey, we have a technical thingy that we can use to make sure that our British website is ranking, and that means we have less people abandoning their cart or jumping back to competitors."

So, ultimately, they're converting better, we get higher revenue. So, people even go at-length, calculating what the revenue could be through SEO. To me, it often feels highly speculative, but there are management teams who need that. I'm happy enough to be in senior management, so I have a say in everything we do there when it comes to anything for our organic exposure. But if you're not, then, yeah, you have to find proper arguments, just basically breaking it down. Just imagine you explaining it to a user who might... Just a user off your website who might actually not know at all what you're doing in the background, and just plainly breaking it down that way.

If you struggle, what I sometimes do, to be honest, is I just look it up in, for example, they have an online wiki. And they try to break things down in very easy words and sometimes I just use that. Though that is already targeting SEOs to some extent, and other online marketers. But you get to a better level, probably.

MC: i really like that. It says it's rising kind of... why you're actually making that change, up until you get to the end benefit or the end value. It's then, yeah, understandable. And that's a really interesting point you make about how they're tied into a lot of other disciplines as well, and that's something we talk about a lot anyway and we have on our podcast, about how this Venn diagram of SEO is now...

There's bits that go over site performance and there's bits that go over people that are dealing with user experience, mobile friendliness, and it's almost like everyone sees their SEO as the most important thing. But it is contributing to all these different areas as well. So, maybe you can make some friends if you've got other people in the team as well to put that forward.

GBT: It's also important to understand that, as SEO, basically you're doing a service for all other departments in the company. You're the internal consultant if you're not already the external one. And so you're the subject matter expert where it comes to SEO, but tied to every other department and you can… If people don't feel like you're telling them how to do their job, because people don't like it, editors don't like it, developers don't like it, and designers don't like it, and that's also entirely fine because nobody likes that.

But if you tell them, if you can agree with them on the same goal, so if we all have the same goal, for example, getting more people on our site, then they understand that you're providing consultancy service to make that happen, additionally, to their job. And then that... I found that very helpful, to navigate that, between departments.

MC: So, while we're here, I guess it's a good time to ask this, while we're talking about communicating with departments, we recently spoke to Sophie Brannon from Absolute Digital Media and the episode before that, Billie Geena from The SEO Works, and they both come from self-described content backgrounds and they're moving into the technical SEO space. And I know SEOs, again, that have been on a similar path that have sometimes felt very intimidated and nervous talking to technical teams and breaking into that area.

What advice would you give someone who's starting fresh in technical SEO, maybe, and this can be, whether it's resources or mentors or where they go for information or just some general guidance, for if that's what they want to do?

GBT: There's a lot of things you can do. So, it really depends on what their basic knowledge is, of course. So, one thing you can do, if you're more of a learning type who prefers to be on their own, what you can do is, for example, you use Sitebulb or Screaming Frog, and you crawl a site, just any site.

If you have the impression that your own website or your employer's is maybe too small or uninteresting or whatever, just choose something you like. I don't know, your favourite online shop or whatever. Don't crawl Facebook. That's not fun. That's really not fun. But something like a nice online shop. And don't crawl Amazon, it's also not much fun. Something else maybe a tad smaller.

But anyway, just like a crawl one and then go read their documentation, and both Sitebulb and Screaming Frog have great documentation, and read everything about anything you find in there, so that way you understand, bit-by-bit, more of what you find in a crawl, and that's giving you a very rural, from my point-of-view, technical knowledge.

Of course, not everything that flags tells you if that is actually an issue or not, but when you read the documentation, you will understand. You can also use your favourite developer, if you have any, or if you can try to make friends with one as a mentor in the company. By just getting them as an ally and say, "Hey, if I learn more, then I might be able to write better tickets, which helps you do your stuff more efficiently, knowing better what I actually need, and I might understand your tickets better and so on." And then you just pick out some issues or have them explain some of their tickets to you, and just learn by that.

If you really don't know where to start, I mean, technical SEO, as such, is already a broad field. And if you don't already know what your favourite thing would be, then you can use the latest great resource, learningseo.io because it gives you many options. It gives you parts.

So, for example, if you're into automation, you might look into Python and so on. But maybe you start with HTML and CSS first and it just gives you all those parts and it gives you all free resources that you can use, and these are giving you a very thorough understanding.

I also suggest highly following non-SEO technical people. For example, in information security or web development. I learned the most interesting things from them, actually, or in accessibility because that's also... Often what's good for accessibility is also quite good for SEO. Yeah, so these are resources you can use.

For mentors, if the people who want to move into technical SEO are identifying as women, there's the Women in Tech SEO community, which I highly encourage to join because they have mentorship programs. But you can also just find mentors there by just connecting to people outside of a program. They do workshops. It's also extremely well-organised, so it's highly, highly encouraged.

For developers, there are mentorship programs online. I don't remember the website just right now, but I do have it in my bookmarks somewhere, where you can find a mentor online when you're just starting programming.

So, for example, if you say, "Yep, I want to be a technical SEO, but I want to learn JavaScript," or something like that, then if you don't have a trusted developer or if they don't have time, then this is a very good way as well.

For just SEO mentors outside of Women in Tech SEO, I don't know of any group. Though there's also a queer digital marketers group, so maybe you might find something there. Other than that, the main thing you can do is networking, really, and then try to find people who are well-meaning and just nice folks who might have the time to help you out there. There are many SEO groups, but I don't find all of them, outside of the Women in Tech SEO group, I don't find all of them helpful when it comes to the tone in communication, to say it in a diplomatic way.

MC: I don't think that's a secret to anyone in SEO. If you're listening and you are interested in the Women in Tech SEO group, I'll put a link to this in the show notes at search.withcandour.co.uk.

In episode 75, we did an episode with Areej AbuAli, who's the founder of Women in Tech SEO, and that's a really nice, half-an-hour podcast there where Areej just goes through how the group was founded, a little bit more about the mentoring programs that they do, and the online and, hopefully soon, offline conferences. But I've heard nothing but really great things about that. So, yeah, definitely a good place if you are identifying as a woman and you do want to get into tech SEO. But apart from that, loads of different avenues you can explore. So, it's more a matter of just managing your own time, really, I guess. There's a lot out there.

Finally, because we're stomping through this. This is amazing. We're, yeah, over 40 minutes. Finally, where can people maybe follow you, find out a bit more about you? And I understand you have got some roles open at the moment for maybe people that are looking for jobs? Do you just want to tell us about that as we finish up?

GBT: Of course. So, getting in touch with me is easiest through Twitter, actually, because I'm really bad at reading emails. I might miss them. And so if you want anything, then it's easiest to just drop a question through Twitter. Other than that, I think you can add the link to the podcast notes?

Of course, I do have a LinkedIn account. You're free to get in touch there as well, but again, I don't look into LinkedIn all day or everyday. And yes, I do get emails from LinkedIn, but I don't read them. So, it might just take a little while. If you're very patient, that's fine as well.

I never look into my Facebook, so you can also try, but you have to be very patient. Other than that, yeah, we're looking for two senior technical SEOs right now to join my team. But also we have a lot of other, open positions right now, ranging from C-level positions like a CFO, down to, literally in every level, we're looking for someone.

For example, we're looking for content editors. I think we might even be looking for a country manager right now. So, there's so many open positions. So, if you go to our website, kafe.rocks and KaFe, not like coffee, but K-A-F-E, and then .rocks, we have the career section. You're going to find all of them. I'm sure that, to some people who are listening, there is something off to your liking, and I'd be glad if you could submit your application.

MC: Brilliant. We will put links, again, to those in the show notes and you can find them at search.withcandour.co.uk.

Gianna, thank you so much for your time. It was really interesting talking about, mainly about QA in tech SEO. That was a topic I wasn't kind of expecting a couple of days ago, but really glad you put that forward and we could talk about it. I really appreciate your time.

GBT: Thanks for having me. I really enjoyed this.

MC: So, we will be back in one week's time, which means you will hear from us again on Monday the 19th of April. In the meantime, if you are enjoying the podcast, go and tell a friend about it, subscribe if you really like, and otherwise, I hope you have a lovely week.

More from the blog