#731 Tech SEO with Simon Lesser, Paulo Andraus, David Gossage and Beth Woodcock

Speaker A: This is Internet marketing.

Speaker B: Kelvin Newman here and welcome to the Internet Marketing Podcast. Um, we've got slightly different change of format coming up over the next few weeks. Um, recently we had the Brighton SEO event and one of the popular elements of the program, there are panel discussions with, where we get groups of people together to have live discussions around interesting topics around search and more broadly digital marketing. So, um, we've decided to take a few of those panels and use them as episodes for the Internet Market podcast so you can get a bit of a sense of what those panels are like at Bryton SEO. So yeah, we've got one of those coming up. Um, I hope you really enjoy it.

Speaker C: All right, well, good morning everybody and welcome to the Tech SEO panel. Uh, we're so excited that you're here bright and early. Uh, and uh, out of the hundreds of simultaneous sessions have chosen this one. So we're glad to have you here. So I'm going to introduce the panel uh, of uh, amazing tech SEO experts here for us. Uh, so first up on my far left, um, I guess you are right would be uh, uh, Paulo Andras. Um, he's the lead tech SEO at uh, Stylite in Germany. He's from uh, Brazil and, and he's been doing SEO for about 15 years and loves to learn and share knowledge. Now later today at 3:20pm at the Skyline Stage, he's going to be talking about um, uh, log files using BigQuery and Google search console. So that one sounds pretty cool. So definitely, uh, put that on your schedule for later today. Um, next up is Beth Woodcock. Uh, she's the senior technical SEO at Anything Is Possible and she's been doing tech SEO for a couple of years now. But before that she was on the strategy side of things. And Beth's specialty is making technical SEO easy to understand and building the bridge between technical SEO and uh, the rest of marketing. So I think that's pretty uh, much why she's here today and I think that's a pretty good mission for anybody to have. So glad to have her here. Uh, now here's the great thing. Um, you can actually catch um, uh, both Paolo's and Beth's talk, uh, in the same session at 3:20 today. She's going to be talking about log files as well. This one aimed at uh, content creators and non tech SEOs, kind of introducing them into the, to this new world of uh, technical skills that will kind of benefit their SEO processes. So you get two for one at 320 today. Then, um, we have uh, David Gossensch, um, and he has over 10 years experience in technical SEO, working on some of the UK's biggest, uh, e commerce sites including Tesco and lookfantastic.com and um, so if any of you have a special SEO in your life with a birthday or Christmas coming up, uh, and need that special, special gift for them. He's uh, the owner of seogreetings.com which talks all kinds of useful, uh, gifts for the SEO in your life. So you might want to check that out too.

Speaker A: They're really tasteful as well. Top quality.

Speaker C: So, um, David talked about uh, uh, XPath yesterday, uh, so hopefully you caught it. If not, there's going to be a replay in a bit, but your slides are up. Um, so catch them on socials and you can find uh, that as well. Um, my name is Simon Lesser and I'm the co founder and CEO of Dragon Metrics, which is an all in one, uh, SEO software platform. And um, I guess, uh, a bit of my experience with technical SEO is I've been doing SEO since 2007. Um, starting off on the agency side, always on the tech side of things, and then about 12 in both. You know, uh, I'm from New York City, um, so both in the US and also in Asia Pacific in Hong Kong, I, uh, was doing agency stuff. And about 12 years ago I founded uh, Dragon Metrics. And so I, um, I helped design and build and test our site crawler. And I want to recommend, I don't suggest that you do this, but if anybody's looking to really fine tune their tech SEO skills, I can't think of anything more challenging than to build your own crawler and test it for the 10,000 edge cases that you're going to find when uh, when crawling the chaotic web. Uh, so that's uh, that's kind of where I'm coming from. All right, so we're going to be, uh, handling some questions both from, from us and we're going to be taking questions from the audience as well. So start, start coming up with questions yourself. Um, when we take a break for that, uh, you'll just raise your hand, we'll walk around with the mic and we'll, we'll get started with that. So uh, let's get going with our first question. Start out with something a little bit, uh, kind of general. Um, so how important is tech SEO for most sites? Is it worth it for like smaller sites or is this something that only like big sites or enterprises really need to worry about? Um, Paulo Why don't you kick us off there?

Speaker D: Um, thank you so much. It's the first, it depends of the day. I guess it depends. If your website's really small, you can use one of the ready to use platforms like WordPress or uh, Wix and then you don't have to worry with it as much and you can focus on your business. But if you have a larger website, then it becomes even more important because, um, uh, websites with 10,000 pages, 100,000 pages, they have uh, pages that are templates. So you have the product page, you have the product listing pages and they have things in common. So when you work with the technical SEO part of those things in common in those pages, you get great advantages and they are really easy to understand. After you implement something, there are tools that you can verify if it worked or not, if they got approved on let's say the mobile friendliness of a page and then you can see results right after. It's not like, let's say content that you need to first rank and then get clicks and then get conversions and then get revenue. So I um, would say that everyone that has a website should be in the lookout for technical SEO, but in different levels for sure.

Speaker E: Yeah. Uh, so I think we're all a bit biased obviously.

Speaker F: Like

Speaker E: we want to keep a job, um, but I think small, like if you have a small site that has technical issues, it can't have the potential to be a uh, big site if it has severe technical issues. Especially if you like, I don't know, have something really disallowed the whole site in the robots text for example. Like you can't make that into a big site. Um, so in my company we have like a content team that writes content but it's really important to have a tech audit first because that content can't rank if there's some serious issues on the site. So I think definitely, uh, tech SEO is the foundation. Um, and I think there should be regular tech checks on a website even if you have a really small site as well. Um, I see a lot of people kind of be like, oh, we need to do the social media, we need to do the content. But definitely like the tech is I feel is absolutely, you know, what we should be doing here.

Speaker D: Sure.

Speaker C: I kind of feel like, especially for smaller sites and I'm not sure what you guys thoughts are on this but um, I see a lot of overemphasis sometimes on tech SEO, meaning that like, especially, you know, this is a uh, problem with SEO tools. They see, oh, the Site auditor is still telling me I have things to do, all these low priority issues that I still need to do. And I think it's a good reminder for, for people that like, you know, what you're trying to do is to stop yourself from shooting yourself in the foot so that Google needs to be able to crawl and understand your site and needs to be usable. But outside of that it really is I think a focus on you know, content and backlinks and things like that. So in terms of like, it's is a baseline like, like slightly different word than foundation but it's kind of the same. Same meaning, Meaning that like uh, it's necessary but not sufficient. Meaning that once um, you do that, once you get rid of your high priority issues, then it's all about the rest of things. And that, you know, don't worry about anything that's flagged as a medium or low priority issue is almost, is rarely, unless you have a specific problem that you're like, well this is the root cause of it, then you can usually safely ignore those kind of things and optimize for other things before you head that up.

Speaker D: Definitely. And I think you cannot put uh, sugar on dog poop and call it a dessert. You need to have good quality, good content, a good product, a good service. So of course uh, technical SEO is the basis of Google related stuff. But if your product is not good enough then there's nothing we can do.

Speaker A: I think um, one frustrating thing is um, if you've got a relatively ah, small site and you do your technical audits, uh, and checks and that, and you go, well actually the site's all right and it happens uh, ah, quite a lot. So sometimes you might inherit a site and there isn't a huge amount to do from a technical point of view. And it can seem uh, frustrating because it might seem like there's time wasted, there's no insights from it. But the fact is, M, until you do those checks, until you actually dig into the site, you don't know you. You could call it Schrodinger's SEO if you like or whatever. But um, there are critical technical issues that will affect every site no matter how big or small. Until you actually know what they are, you can't know if the site can uh, progress to be a bigger site.

Speaker C: M. Okay, so since we've got two people on the panel talking about log files later today, I figured that's a uh, fair game for topics today. So I would say when should I have, or when should one have a log uh, file audit.

Speaker G: Beth?

Speaker E: Yeah, I feel like looking at the log file should be part of the SEO process. Just in general, like the audit process. Um, I feel like making it kind of like trying to do like a log file audit and then like a technical audit separately. Like you need them to link together, together. Um, because you'll be looking for things in the log files that will be part of the technical audit. So say if you just publish some content or like you think some JavaScript's on wild or something, that's what you need to be looking for in the log files. Like you should definitely be incorporating it in into your actual technical audit process. Like when you do audits, um, and then when you are with the client and you're kind of checking up on them and seeing if they've done like the audits, if they've done the um, if they've basically implemented what you've asked them to do, then you should be doing regular log file checks. So say if they've just implemented a change, it's really great to do a log file check after that.

Speaker D: Yeah, yeah, couldn't agree more. Uh, I would like to ask a question to the audience. Who in here has access to log file analysis? Okay.

Speaker C: It's actually higher than I expected.

Speaker D: What, 30% from that. It's very interesting then to answer the question when you have to do it every change of the website, especially in big sections. So if you change something on your blog or if you change something in your product page, that's the moment to check your log file analysis.

Speaker C: And what are we looking for in the log files by the way?

Speaker D: Is Google still crawling that page or crawling it more? Uh, is it crawling more frequently? Does the page, uh, weight increased or decreased? And what do you expect from that? Because every time that you have a change you expect something from it. So uh, heavier pages are usually loading slower and what can be uh, affected after that?

Speaker A: Um, I've got a real world example. So, um, has um, an E commerce site and um, each of the category pages either contained links to subcategories or products, not both. Now some of these subcategories uh, were buried as far as seven levels deep. So you had to click seven times to actually get the products at um, the lowest level category, which I'm sure you can all agree is a terrible way to do it. But we didn't have anything solid to go back to the client and say, right, this is actually how you should be uh, doing it. So when I looked into log files, um, I got the Crawl events for every category page and then put the, uh, crawl depth in a column and, um, created a simple pivot table. And what it showed was when it got to level four, um, the crawl events just dropped off a cliff. It went to nearly zero. So then I was able to go back to clients and say, right, all of these pages Google's ignoring because they're buried too deep and it's only then that they started paying attention.

Speaker C: That sounds like a great visualization. Kind uh, of on one axis would be crawl depth, the other axis would be, um, number of crawl events. And to see that's probably a very linear, um, relationship, uh, there, I would guess.

Speaker E: And that's a really good example because the URLs themselves might be indexed and you might be like, oh, they're indexed, they're fine. It's great. But Google's not looking at them regularly, so it's not serving them in search results.

Speaker C: Yeah, yeah. Or removing them or just finding out that. Exactly. It's gone. Um, now with so few hands being raised, more than we expected. But, um, for those of us who have tried to obtain log files, we know how challenging it can be now, especially on the agency side. But, um, in house is not, uh, not super easy either. So is there any point, or what is the point of learning about log files if we can't even get access to them?

Speaker D: That's a good question.

Speaker H: Me or you?

Speaker E: Me or you?

Speaker G: Which one?

Speaker F: You go first?

Speaker E: Go on.

Speaker C: I'll let you guys fight over this one.

Speaker A: I think understanding the concepts behind it helps to, um, shape your understanding of the website as a whole as well. So if you understand how Google crawls websites, um, through practicing airlog files, whether it's on personal sites or a previous client or whatever, having that experience m of seeing the airlock files and seeing how googlebot interacts with the, uh, website just kind of shapes your understanding of technical SEO as a whole. So then you can take that knowledge and even if you don't have access to locals, you can and know. Well, actually this part of the site isn't set up right. And I know it's going to have an impact, um, on xyz.

Speaker E: Does anyone use Google Search Console? Put your hands up.

Speaker G: Yeah.

Speaker E: Does anyone believe that what the information that Google Search Console gives you Is 100% accurate?

Speaker F: Accurate?

Speaker G: Yeah.

Speaker E: Okay. So log files come directly from your server, so Google can't lie or manipulate the information about what's being looked at and what's being served. So that's why you should learn about Log files because you have control of that data.

Speaker D: Yeah. And uh, to add to that, I think it's the same argument of learning pricing strategies. What's the point of learning pricing strategies if we're working with tech SEO? We know it affects ranking, we know it affects how Google sees our page, how it ranks our page, but we're not defining the price of our product or the product that we work for. But it's too important for us to know that some different pricing strategies, discounts, Black Friday will affect the performance of our websites. So if you don't have access to log files you still need to learn how they work because you can understand that in the future Google might not be crawling your website as uh frequently because you have blocked a session in your website. A uh, section of your website that maybe you shouldn't.

Speaker C: So now is there.

Speaker I: Yeah.

Speaker C: So I agree like just learning how Google crawls is such an important uh, technical SEO skill to learn. Uh, I'm not sure I have an answer for this but I'm going to throw it to the panel. So if you can't get access to log files, you sure you can learn about it in general, how they work, but there's nothing better than to dig into some actual log files and if you can't get them yourself, is there any way that you can get practical hands on experience without access to your own site's log files?

Speaker A: You could build a site. Okay, um, that's one thing I've ah done before. You get a little bit limited because you're not going to get a site that um, has as much traffic as some of the uh, big clients, uh, or the big sites that you might be working on. But it's a good place to start. Um, I'd be interested to get the other guy's opinion on the crawl stats report in the search console because um, if I don't have log file access that's usually the first place I go to. M Because although the data is a lot more limited it can give you some insights. Um, so like um, as a site where I found that um, only 3% of the pages that were actually being crawled were actually in the site map and that was from Google Search console uh, um, telling me that. So then I was able to uh, go to them and say well actually it's going to take if all pages are treated equally, which we know that not it's going to take three months to crawl the entire site which is absolutely not what we want to do.

Speaker E: Yeah, I can touch on the crawl Stats report a little bit. So the crawl stats report, if you go into the Settings tab on Google Search Console, um, and in the Settings there's a little crawl tab. And if you click into that, you can actually see when and where Google has crawled to your site, which kind of. It gives you URLs and stuff, but obviously it's limited to the first thousand URLs. And you can only see Google's bots. You can't see Bing bots, you can't see any other bots, you can't see illegitimate bots. Um, so I think that that's a really good place to start if you want to understand where Google is calling your site. But I think it's also worth. You might think that you can't get access to log files, but you'd be really surprised. Like when I've gone to a client and I've said, oh, can you have access to log files? So, totally not expecting to get access to them because they're like a small client or they're not very technical and they actually do deliver the log files to me. So if you are kind of like, oh, no, our company won't do that, or, oh, we can't get access to log files, I think maybe if you, like, push a little bit, maybe push on the clients that you have a better relationship with, um, to try and get those log files. Because generally, like, if you're doing paid work, if you're doing paid work for a client, they should be helping you. You getting access to files that are going to help you do your job better and assess their site better. So, yeah, I'd really just recommend, um, I've seen previously that some people are a bit like, oh, log files. And we can't really get access to them. But actually, yeah, if you actually have a conversation with your clients, you might be able to get access to them. Um, it's worth having that conversation.

Speaker A: Yeah.

Speaker C: So I think let's, uh, take a moment to take some questions from the audience. We got one right in back here, so please. So let me repeat the question real quick. What time frame do you recommend looking at for the log files? Is it 6 months, 12 months? Uh, 20 years? What do you think?

Speaker E: Yeah, usually. Sorry. Usually for me, it's, uh, like every 28 days. Um, I think if you kind of start getting too many log files, they are huge files. And if you're working on like a little bit MacBook, like I do, they can take up space. Um, yeah, I would just Recommend, like, first 28 days and then like assess it every month. And it kind of depends when the clients make the changes as well. Like, say if they're pretty quick to make changes, you could, you could say like, oh, they made a change last week. And um, I'd like the log files for the last week. Um, but I'd say like every 28 days is how I kind of assess log files.

Speaker C: But you guys, it depends what you're looking for too. If you're looking for something specific to compare against, then historical data could be useful. But I would say recent. The most recent is going to be way more useful than historic data.

Speaker A: I would say, ah, I think, um, my answer would be, uh, um, however much gives you the data for the insights. So if you're working on a large site that has millions of, uh, crawl events a day, you might only need like one or two days because anything more than that is just going to cripple your laptop. M. Whereas if you, um, are working on a relatively small site like a blog, um, you might need like a couple of months to get some valuable insight from that.

Speaker C: So of course, always it depends on.

Speaker A: Absolutely.

Speaker C: All right, let's take a couple more questions, uh, from the audience we see. One in the middle up here is, uh, what I saw first in the black, this gentleman.

Speaker A: So I work agency side. Um, how do you convince, uh, hosting partners or web devs to provide you with log files? I'm having a lot of trouble with that.

Speaker C: I've been out of the agency world for a while. Anybody?

Speaker D: Yeah, I think what Beth said is a great point, that it helps us do our job better. But at the same time, if it gets too difficult to get, then we can try to, um, go directly to the hosting service. That's what I do most of the cases with smaller websites, because my hosting service, I have access to the log files through the FTP. And that's something that usually you have access to.

Speaker C: Does it help to make a business case for it?

Speaker A: I think it depends on the size of the clients. Um, some clients, uh, will look at a business case and just go, what the hell is this? There's some clients that, um, absolutely would, um, I'd probably start with, um, find a problem, um, that you want to see solve. So if you've identified something that you think isn't quite right, but you need the evidence to back it up, I'd probably start with that. But I do agree it is a painful process. Uh, uh, I think a lot of time you might ask for log files and they might not Know what you're talking about. Um, so trying uh, to explain it in terms that uh, they can understand as well is uh, ah, definitely helps.

Speaker C: All right, I think we saw another question in kind of the back middle. If you put your hands back up.

Speaker J: Um, so I was wondering how much uh, maybe weight you put on the warnings in search consoles. For example, the uh, uh, block through index stuff where we start looking at it but then it kind of goes up and down with any rhyme or reason and stuff like that.

Speaker C: Which warning did you say?

Speaker J: Um, so like the index coverage stuff, right, has some warnings and um, um, it seems like they're just kind of going up and down no matter what we do and kind of what happens. And that tends to be hard to tell people internally, hey, you should look at this. But then it goes up or down without any changes.

Speaker C: My personal opinion is whenever you're getting a warning in Google Search Console, it's always at least worth a look. Whether it's worth making sure that warning goes away, I'm not sure. It's going to depend on what it is and what the situation is.

Speaker D: Totally agree. Oh, sorry, go ahead.

Speaker A: No, go on.

Speaker D: Yeah, uh, and also remember that in Google Search Console this report has a delay, so if you make changes, you don't expect them to have effect right away. Or you could um, hurt yourself and go URL by URL and then do the inspect URL.

Speaker C: Ah, you can also get up to 2000 URLs using the API per day, but that's a bit more.

Speaker J: Ok, thanks.

Speaker A: I think Scream of Frog has an API for what Simon says.

Speaker C: Yeah, yeah, I mean Dragon Metrics does too. Yeah, go ahead.

Speaker K: So I'm interested if you ever attempted for larger websites to, to um, derive a crawl budget that Google gives to the domain, uh, using the log files. Um, I'm asking this specifically because um, a lot of SEOs look at the log files and then they see, OK, I have 2 million requests per month and that's my crawl budget. But of course it's not because Google doesn't know requests, they only know server time spent. Uh, so I can feed Google like 10 million redirects that are crawled super quick and I will have 10 million requests more, but of course they're not really relevant. So I would be interested in getting uh, to know from you. How would you um, derive a crawl budget that Google gives my domain using log files.

Speaker D: My first uh, instinct here would be to break uh, down your log files by sections of your website and ideally the verify different Google, uh, Search console properties, so you can see how it affects the index coverage in each one of these properties.

Speaker E: You can filter as well. In, uh, the Blog File Analyzer, you can say if there's a specific, uh, section of URLs that you're targeting. You can basically just say if you've just written content or if there's like, oh, I just want to look at how the blog section is being looked at. You can crawl the blog section and import that into log file analyzer and see that you can cross check it as well. So you're not just looking at like millions upon billions of URLs. You can look at a manageable amount of URLs.

Speaker C: These are all great questions. Um, just so we don't become the um, log file, uh, panel today. Sorry, uh, uh, let's um, move on to a couple other questions we've got. We'll come back to the audience in just a moment. So let's talk about the kind of, the other side of things. If someone wants to get deeper into learning tech SEO, uh, what's the first thing or maybe the most important thing that they should study? I'm just gonna open it up to everybody.

Speaker E: Yeah. Uh, how to communicate with developers. Um, I think that's the first thing

Speaker C: or most important thing or both.

Speaker E: Yeah, Honestly, like, I think you could be like, you know, you could be like best tech SEO. You could learn loads of coding. You could, oh, I know Python and it's great. It's like, well, if you can't get those basic changes implemented by developers, then it's like, well, so what that you need to be able to communicate to developers and uh, have a good relationship as well with your clients in order to get to persuade them to implement the changes. I think that's the most important thing about being a tech SEO.

Speaker A: I think when it comes to developers, make sure any brief that you give is absolutely watertight. Because if anything can be misinterpreted, it will be misinterpreted.

Speaker C: Developers job is to be pedantic for a living and that extends past their code.

Speaker A: But yeah, um, I think as well, I think knowledge of HTML is probably critical for technical SEO. I know I've heard many people say, like, you don't need to code. I would argue that HTML is code. It doesn't make you a programmer, but it is code. And understanding how websites are built, how they're structured, um, what the impact of doing one thing will have over another thing, all of that is critical and you won't be able to give a developer a brief unless you actually understand the HTML itself.

Speaker C: I think I would say the most important and kind of first place to start is really understanding tech. SEO is about understanding the web and understanding how everything works. So um, you know, for example, I give a lot of tech interviews a lot for web developers. And one of my favorite questions asked is I say, explain to me in excruciating detail, as detailed as you possibly can get, what happens between, when you, when somebody types in a URL into the address bar and when you hit return, what happens between then and when the page is rendered, uh, on your browser. Describe that to me.

Speaker L: Right.

Speaker C: And so essentially that's what I think that we should learn, you know, first as technical SEO. So a big part of that is learning the HTTP protocol, not um, just, you know, the different status codes, but actually learn what it is and how it works and how do, how do web browsers work and how does the request go, how does DNS work and things like that. Just the basic building blocks of how in the world the Internet or the web works, um, is going to just kind of make so much more, make sense. Even more so than, you know, learning, learning Python or something like that. I would say learn Python or learn, learning to code when you have a problem that you need to understand code. Uh, but I think understanding how the web works is, is a prerequisite that gets too often, uh, skimped.

Speaker D: Yeah, um, scared with the number of SEOs that work on the technical area and don't know how the DOM works.

Speaker C: Yeah, learn the dom.

Speaker D: Yeah, learn the dom.

Speaker C: Um, so leading uh, off of that, um, for kind of um, non techie SEOs who would love to kind of up their skills. Do you have any tips in getting past that kind of imposter syndrome, uh, in fear of technical things? I'll take that one first.

Speaker B: Okay.

Speaker C: Um, so first of all, I would say there's two parts of it. There's one part is things that we uh, if you identify as somebody who is in tech SEO or just in tech, that we should be doing. And the other thing is what the individual can do. So I think us in the already tech SEO or tech club uh, should do is, you know, we need to reduce gatekeeping and things like that. There's still a huge problem in the tech industry of uh, you know, gatekeeping and um, sexism and misogyny and just the, you know, tech bro kind of thing. And I think we of course need to continue to do uh, a better job of that and making it more welcome and say, hey, we welcome all skill sets and we welcome learning and we want to bring you along with us. So that's something that is on us to do. Um, on the, on the other side, uh, on how to get past imposter syndrome, because I have absolutely struggled with it too. And how did I get past it? Everybody has somebody they look up to, and when I got how I got past my imposter syndrome, is I. The person that I looked up to admitted that they had imposter syndrome, and they said, here's how I got over my imposter syndrome. The person that I looked up to admitted that they had imposter syndrome. So it's imposter imposter syndrome all the way down. Uh, and so you just got to be confident and fake it till you make it and just know that nobody knows what they're doing. Uh, and no matter how much, the more you know, if you're a smart person, the more you know, the more you realize that you don't know. And you will never know it all because there is a million lifetimes of information out there and it's not, not humanly knowable. So just don't be confident. Don't let anybody hold you back. Don't let anybody gatekeep you. Just learn and find somebody, find an ally who's willing to mentor you and run with it.

Speaker A: I think the person that claims to know it all is the person to heavily avoid.

Speaker E: Um, I think I already kind of try and work this into my process anyway, like my audit process. Um, I try and get like the account manager of the site that I'm auditing or uh, SEO strategist to review my work. This helps them with understanding what technical SEO is and gets them involved. But also they have visibility over the accounts, like what PPC are doing, what's, you know, what's happening over there. Um, so I think if, if you have a particular person in your company that's like technical already or works on tech stuff, maybe asked to like, look at their work and what they're producing, um, review their work and then, yeah, just get kind of see if you can get poured into that process a bit more if you want to learn about technical SEO.

Speaker C: Okay, so should we, uh, kind of along the same lines, should we teach tech SEO stuff to content teams? So on the other side, you know, got tech SEO on one side, got, uh, content SEO on the other side, is it worth, um, kind of cross pollinating and spending that time, uh, training those teams up?

Speaker E: Yeah, I Think absolutely. Um, I'm pretty close with the content team at our company and um, if I'm doing like an audit and um, I see like a content opportunity, I will always just like, you know, give a heads up to the content team that this is a content opportunity that they could possibly upsell. Um, and it would be really nice to have that back. Like, we do get that back as well. If they notice any, anything that's like, oh, no, not really seeing like the rankings or something, something like feels a bit wrong here. Um, I'll look into it. They don't necessarily have to like learn code or learn like something really dramatic. It's literally just about, hey, I think there's a technical issue here and then we can work through it together. It's like making sure you're working within all of your teams.

Speaker C: Can we dig a little bit deeper? Why, uh, why is it, uh, time worth spending to spend the time, uh, training content team? Somebody who's like, I'm just a content writer, I don't need to know that jargon ness, you know, what benefit does that have?

Speaker D: I have a good example for that. We working with the content team, we have seasonality, um, content that's more important right now that it will be in six months, especially in the fashion industry. And then, uh, teaching the content team to look at the log files and see if that content is actually getting crawled and getting indexed as soon as possible is very important because they could be looking at the number of clicks and that's okay. But if they realize that there is a session of the website or a session of the blog session of the magazine that is not getting crawled, they can notify us and we can take an action, increase internal links, decrease the speed of the page, uh, work with the engineers to do whatever we think, uh, it's important. So the content team is the first step in creating the content and they are the stakeholders of the results of that content. So if they know a little bit of the technical SEO part of crawling and indexing, it's already very valuable for them.

Speaker A: You mentioned internal links. The survived recently, um, worked with, um, uh, a content team who were doing things like 80% right, um, but their internal linking had no strategy whatsoever and outclassed m internal linking as a technical SEO task. So that basically gave them some lessons on what to do. I think what I would also say is, um, some of the best technical SEOs I've ever worked with started in content and um, I think having it like a genuine interest in SEO in general. Sorry, General Twice will basically help anyone get better, um, at their job.

Speaker C: I think it goes back to that point, uh, of mentorship too, um, to help everybody along.

Speaker D: Okay, sorry. If I may add something here. For our content team, we created a virtual machine with Screaming Frog on it.

Speaker C: No, I love screaming Frog.

Speaker D: And they just import a, uh, configuration file, put the domain that they're working on, and it already spits out everything they need to know. They make the analysis and they tell us. In the report that I ran here, I realized that this part of the fashion magazine is not really being crawled. What's happening? And then we realize there is a, uh, no follow on the navigation, something like that. So they can start the analysis. They don't need to learn how to set it up or how to make everything happen. But it's nice for them to understand that it exists and that they can start the analysis.

Speaker C: Sounds good. All right, let's open up, uh, to the audience for some more questions. Uh, this gentleman in front was uh, the fastest that I saw, you know, wait just a moment for the microphone, uh, to make its way.

Speaker H: Hello.

Speaker G: Uh, I am the example of what you said. A couple questions about a non technical SEO who needs to know more about this sort of stuff. Um, the first real technical experience I started getting was when I started leading the overall technical or SEO strategy for the company I work for. Uh, and that's a hard time to start making that entire strategy. Uh, I am now at a point, done that for a few years, have some SEO experience in the technical side of things. Various use cases where things have happened, I've had to figure out, uh, and I'm managing people who are like more technical, focused. I don't have to worry about it. I don't need to know everything. I wondered kind of how much should I know to be able to manage that person? Well, like, if you're being managed, if you're kind of managing people, what is the level that you need to be at, uh, to be able to be a good manager for someone without needing to know everything they're doing?

Speaker C: That's a good question. And I like a few different parts of that. I mean, first of all, I would say that, um, I'm not convinced that that is the worst way to learn SEO. I think that trial by fire is always a great way. I mean, it might be the most stressful way. Um, but it is a way to learn your stuff quickly because there's no other choice. And sometimes you're on a small team and like somebody walks up to you. And in 20702007 somebody said you're the, you're SEO guy. I'm like, se what you know, and so that's just what you, what you do. Now in terms of uh, uh, to clarify your question, how high should your tech SEO level be to be able to manage tech SEOs? And I, I think that management and practicing are different skills, you know, and um, obviously there's, you can't know nothing, um, that creates its own set of problems. But I don't think you need to feel like your tech SEO skills have to be higher than your development. I manage our developers at Dragon Metrics, um, but thankfully my developers know way more than me. Uh, and that's kind of how it should be. So there are different skills and different knowledge sets. You should know kind of more of the higher level things of what's important and why and that kind of thing. And they should know how to do it. And I don't think that there's, I don't know how we can answer the question. This level four, it's hard to describe. I think we just have to think in general terms. Anybody else have thoughts?

Speaker A: Was it Steve Jobs who said something along the lines of like he hires people who are smarter than him so he doesn't have to know? Um, something like that anyway. But um, I think there is a responsibility for your team though, to be able to, to explain what they're doing to you. So it's on them to tell you what they're doing and why they're doing it and what the benefit should be. And don't be afraid to ask uh, those questions as to why they're doing it. And um, I think um, an old manager of mine had um, a classic phrase. So what's the next steps as well? So if someone's spending all their time doing analysis, you go, okay, so what are you going to do with it? Um, how are you going to take this to make, uh, performance better?

Speaker C: We're all learning as we go. So I would say use this as an opportunity to learn as much as you can, as fast as you can, but don't uh, let that hold you back or feel insecure.

Speaker G: Thanks. Next.

Speaker H: Hi. Um, we've got a global site, uh, across 20 languages. Um, I'm responsible for EMEA and we have a global dev team. And as far as they're concerned, technical SEO starts and ends with a core web vitals report. Um, what are they missing?

Speaker C: Uh, the rest of tech SEO.

Speaker A: Yeah, I think the first step would be the Hreflang, uh, uh, uh, setup.

Speaker H: They've been avoiding that for months.

Speaker A: They just, it's too much.

Speaker C: And that might be the first place to start.

Speaker A: Yeah, because uh, I think when it comes to international SEO that's like step one and then everything else follows afterwards. So you need like a single source of a. Well it usually works best with a single uh, CMS that branches off into all the uh, different sites. And how that's um, uh, set up across 28 sites is very complicated. But say that's the first thing they, they need to do. Um, if the sites are quite simple you might know. Okay, yeah, um, yeah, you need to go to them with a rock solid hre flying brief and um, um, start from there.

Speaker H: I mean uh, hreflang has been a point of contention for a long time because they've got so many other priorities and it's so time consuming.

Speaker A: So I think what I would do is to go to them with the evidence. So um, I've worked on sites where the hreflang, um, has been mostly okay, but not okay in one of the uh, countries. So then you have to go to them and say right, um, if you know what pages are ranking in what country you can go to them and go well actually in this country, um, in Mexico the Spanish site is ranking. So going to them with that, with that evidence and showing them we're missing out on all of this uh, traffic here. And um, if their own country's ranking as well, it's probably going to affect you how far, how well you rank as well. Because if all of your, your prices are in dollars, you're not going to appear, you're not going to rank very

Speaker C: well in uk I'd look at your issues first. You know, see like, because Google doesn't need hreflang, you know, it's a, it's a signal, it's, it's supposed to help them. But magically maybe Google has, you know, understood your languages correctly and maybe it's not your first priority. Some sites it really is. So I'd say are you having troubles with indexation? Are you having trouble with the cannibalization, having trouble with internal linkings or having trouble with, you know, whatever. I would say look at that. And that's how you prioritize things. But I think core web vitals is. That was actually one of my next questions. Um, but um, you know, it's good um, especially for users, but for SEO it's kind of a,

Speaker D: you can also tell them to play with schema markup. If hreflang is so impossible to touch.

Speaker C: I mean scheming sounds almost more complicated than hreflang in some ways

Speaker A: at least you don't have to link all the pages.

Speaker D: Pages Internal linking, good topic.

Speaker A: Yeah, I uh, mean through the hreflang. The way that all the pages are connected, uh, that way can get very complicated. Whereas with schema you only have to worry about the individual page.

Speaker C: Any other questions? This gentleman was extremely fast.

Speaker I: Hi Simon.

Speaker F: Hey.

Speaker I: Promise you I was going to be in the second row but my trainer had another plans so. Yeah, I heard a bit of technical, technical question if I may. Uh, so when we look into GSC and crawlstats we see three matrices. It's total download byte and uh, a response time and crawl request. Is there any insights or data we can get from it?

Speaker C: Can you repeat that one more time?

Speaker I: So when we go to GSC we go to crawlstats and then we have a time series that goes crawlstat, uh request byte and then we have responsibility response time and then we have number uh, of requests sent to the server. Is there any insights we can drive from it? Like oh, suddenly we have a massive spike in there. Like what it could be like.

Speaker A: I've had some insights from the uh, crawlstats report in the past. So I mentioned before about how um, we measured how many pages were being crawled. There's other things like um, like the impact on PageSpeed. So if you're dealing with a massive site, PageSpeed can have a big impact on crawling. And you can see in the crawl stats report if you make a change to how fast the page loads, it directly impacts how many pages get crawled a day. So that's a really easy example and just simple things like you can see um, which user agents is being used more. So if your website is still getting crawled more via desktop, there's a good chance there might be um, some uh, mobile issues there. Uh, I um, had a client recently where um, the most common type of page being crawled was JavaScript, um, when it should be HTML. So we knew that there was an issue with uh, versioning there. So um, that needed to be resolved. So there are quite a few insights. It's obviously not as good as digging into the air log files but there's insights there to be had.

Speaker I: Cool, thank you. Thank you. And second question, Can I.

Speaker A: Yes.

Speaker I: So can we correlate that server response time with total uh, time to four first byte just to see if there's a correlation between. Or it could be an indicative of uh, how we are performing on time to first byte, in addition to the normal core revverance report we get, I

Speaker C: assumed that those were the same thing. Time to press Biden server response time.

Speaker A: Yeah, I think.

Speaker I: Yeah, cool. Yeah, that was my doubt. I was like, yeah, better have the express opinion as well.

Speaker C: Yeah, cool, thank you. But I would say just use that as a jumping off point to do a, uh, PageSpeed Insights or Google Lighthouse, um, examination of that. And that'll tell you way more details than what Google Search Console is going

Speaker D: to show, especially when you change servers. You know that old case of websites that are getting bigger and they go to the next fancy server? That's the report you want to look at.

Speaker C: Um, let's do one more audience question, then we'll go back to our.

Speaker L: Just following on from that question. Um, what steps could you make to improve that time apart from things like say for a WordPress site you've got Rocket and things like that to improve speed? It's like how much more benefit would you get from moving time to hosting and what kind of hosting would that be for? Time to first byte for the um, time in the Google Search console for that um, crawling report. Because I've read a lot of SEO saying that to aim for 100 milliseconds in that specific report and we're sort of at 500 milliseconds and not getting anywhere close to that crawl speed. So we're kind of missing out on crawl because a lot of the time spent downloading each individual page and it's that specific report in Google Search Console in the settings where it's got a time metric for the time it's taken to look at those individual pages.

Speaker C: Yeah, I think decreasing your time to first byte is always a worthwhile endeavor. Um, how to do it? Anybody, um, want to handle that?

Speaker D: Um, you can try to break down your files that load on that page to be only loading the things that you have on that page. I saw multiple times that the homepage JavaScript was loading the products that only appear on the product detail page or especially on E commerces. You have like the vendor JavaScript that loads everything that needs to be counted so the conversion is tracked. And sometimes you can just break it down. Uh, Google Chrome has a report that shows how much or what's the percentage of your files that are being used on that page and it shows you the section that's not being used. And then you can ask your developers to remove those sections. Especially on very larger, uh, websites or JavaScript file, you can remove like 80% of that file, it looks tiny because it's um, I don't know, uh, less than one megabyte file. But still it makes a difference on the time to first byte and everything that needs to be loaded on the first visit from Google from a first uh, time user.

Speaker C: I think time to first byte is uh, often uh, reliant on the server, server speed and resources as well as the network and network location as well.

Speaker A: You mentioned WP Rocket. Would you say that your site is some, assuming it's a WordPress site, would you say that you've got a fair amount of plugins on there?

Speaker L: Uh, I would say it's a constant battle with my boss to remove plugins that I see as offering no benefit. But they're like, I'll give you the worst example would be Jetpack just for him to see how many people are visiting the site of day when we've got search console analytics, routy tracking affiliate links already. So it's a battle on that front. But if I can go back and say these are having an impact, can we test the site like without them? If that would lead to more crawling then that would be great.

Speaker A: Yeah. So what I would do is create uh, a staging site so like an exact replica uh, and just disable all of your plugins. And if you do that and the time to first party is still bad, then you know it's server related and enable your plugins uh, one at a time and then keep uh, testing it. And when you, when you enable one and you see there's a big jump, then you go well actually I think this is the culprit.

Speaker C: A to B test. That sounds like a great idea. Fully support that. Okay, um, so. Oh, we can, yeah we can do one more M. Okay, right here.

Speaker E: Um, is there a course or any other source link, source of knowledge you would recommend for someone who wants to learn JavaScript SEO? M. Yeah, I mean I've been having trouble finding anything.

Speaker C: Back in the day when I went online JavaScript I knew which resources were available. I no longer know what's, what's good these days.

Speaker J: Anybody.

Speaker A: I personally hate JavaScript so the viral passion.

Speaker C: So I'm probably the necessary evil though.

Speaker A: Yeah, I'm probably not the person to be asking because my answer would be to burn it to the ground personally.

Speaker E: Are you learning about JavaScript or JavaScript SEO? JavaScript SEO. SEO.

Speaker F: Yeah.

Speaker E: Um, have you heard about learning SEO IO? So that's like a really great resource. Alada. Yeah, yeah, Alada. Um, that has basically like for anyone really if you want to learn anything about SEO, it's always being up to updated. Um, that's basically how I started learning SEO. And like I've kind of gone, I go back to it regularly to be like, oh, you know, what's changed? And you know, sometimes you kind of come across an issue and you're like, oh, I can't quite remember how to solve that. And then, yeah, it has really great like list of SEO.

Speaker C: Like it's links to many, many resources, right?

Speaker E: Yeah, absolutely. Some of the best. A resource of resources. I definitely recommend that to anyone wanting to learn anything about SEO.

Speaker D: And there's a YouTube series from Martin Split from Google, uh, where he also highlights some of the important things you need to know. It doesn't go into detail, but, uh, especially like in his case over here that you need to be a manager but you don't know how to do the step by step stuff. It's perfect.

Speaker A: All right, thank you.

Speaker C: Um, so question for the panel. Uh, not necessarily, uh, which tool, but, um, just kind of with so many SEO, tech SEO tools out there, how do you choose a good one or how do you choose, how do you make sure that you don't choose a bad one?

Speaker D: What's my budget?

Speaker C: What's that? What's your budget? Well, I mean, if that's part of your decision making process, then that's part of the answer then.

Speaker I: Yeah.

Speaker D: Uh, definitely depends on the size of the company and evolution on the SEO aspect that they already have. If they are already covering everything else and then it's time to focus on tech SEO to get the extra gain. I would go for a more, um, expensive tool that gives me everything that I need to know. If I'm just in the discovery phase, then I would go for a tool that I need to do a little bit more of the work and then I would make business case of, yeah, now it's time to upgrade to X to Y.

Speaker A: That would be my process, I think. Um, the fact is a lot of SEO workers isn't very glamorous. Uh, there's a lot of time spent doing quite boring work with spreadsheets. And chances are if you're doing quite, um, a laborious task, there's probably a tool out there that will do what you want to do. Um, uh, as Paolo mentioned, it comes down to budget. Um, so you might find that the tool that you want just isn't feasible and you have to carry on doing it by hand. But if you do identify that one thing that you think, right, we need a solution for this, this solution exists in Dragon Metrics or probably more likely Screaming Frog. Then we can go down at that rate and make a business case for it.

Speaker C: Yeah, I would say, um, one thing I would avoid when you're looking evaluating SEO tools, I would say avoid anything overly, um, prescriptive. You know, there's a lot of, uh, SEO tools that say do this, you know, or do, do this specific thing. Um, you know, because it, it sells, it sells SEO tools because it's like, oh, I don't want to learn tech SEO. I just want, uh, software to tell me exactly what to do. And I'm here to say that that's not how it works and that is a recipe for disaster. So you're going to have to learn some tech SEO and then get a tool that is descriptive rather than prescriptive, or at least, you know, one that makes a balance between the two.

Speaker E: Yeah, I mean, obviously there's a lot of tools out there. There's a lot of demos, there's a lot of free tools as well. And there's also a lot of people like here today, like, showing off their tools. So if it's something that will ultimately save you time, save you energy so you can delve deeper into a technical SEO topic, then yeah, I'd recommend that sort of tool. But don't just be like, oh, well, everyone has this tool so I'm going to use it too. It's got to suit you. And your use case scenario, you have

Speaker A: to remember that your time costs money.

Speaker E: Yeah.

Speaker A: So if you can say, right, I'm spending this much time doing this, uh, task that's costing you a, this much, then you can say, well, actually this tool costs that much is less than what I'm spending on this.

Speaker C: Uh, I say this not just as the owner of an SEO tool, uh, but I do think it's ludicrous, um, how people make decisions about their software that they're, you know, a good SEO tool will save you dozens of hours or even multiple humans each month. And they're comparing like, well, this tool is, you know, $79 and this tool was $99. M. Let's save $20 here. When in your comparing, how much does it cost to hire a tech SEO, you know, a month or an extra person, how much is that, that person's, uh, time worth? You know, and when you make a comparison that way, it's like absolutely no comparison at all. And I'm not saying that you have to buy an expensive SEO tool, but the, the, the decision to make when it comes to pricing is how much time is it going to save me? Or what's the cost of making a mistake of this stupid SEO tool, uh, telling me to do this thing that wastes our time or harms my site? Uh, that's way more important than the sticker price on the SEO, uh, on the tool. All right, let's uh, we're running out of time. Let's end with one final question, which is always one of my favorites, is what, um, what is one of the biggest misconceptions or myths you think that people have about technical SEO? Open it up to the panel.

Speaker D: It's only meta title and meta description. If the Yoast is green, you're good to go.

Speaker E: I feel like, um, I get quite, I have a lot of people on LinkedIn, I follow some like amazing people and I get quite intimidated by a lot of the people that some, what people are achieving. So, like making software and things like that. Um, but tech SEO isn't about that. Like a lot of it is about the basics, the foundation. And I think if you can get that, if you can get the foundation done really, really well, then I think that makes a good tech SEO.

Speaker F: Yeah, yeah.

Speaker A: It's not really a myth, but I've come across many people who like to use long words and complicated language when making their ah, case. And I've helped big companies recruit SEOs, and I've seen some of the CVs and some of the money that some of these people are asking for and go, jesus Christ, these are terrible. And just because someone, a good technical SEO should be able to explain why, what they're doing, they should be able to be able to explain why they're doing it. They should be able to communicate, um, with someone who isn't, uh, technical. And I feel like sometimes people deliberately try and make things sound more complicated than it is just to make uh, m themselves look more intelligent, uh, um, and maybe like pull the wool over someone's eyes to mask what they're actually doing. Maybe, I don't know.

Speaker D: Very good.

Speaker C: I think. Let's do, let's end with one, one audience question. Who's going to be the lucky, lucky person with their hand up?

Speaker F: So, um, to be able to migrate a website more effectively to speed up the migrations in terms of technical SEO, what would you do with um, language models to speed it up? So, um, let's say you have a website migration used to be redirected into different languages as well. How would you run the script on a particular. If it's a Python script to be able to make it more efficient to speed up the process of redirect mapping, for instance.

Speaker A: So a nice simple question. So you missed my talk yesterday on customer extractions actually. So I actually had a solution for this. Um, so um, one thing you can do is you can pick. So for an E commerce site, for example, every product has a sku. Um, if you can extract that SKU for every product, um, you can find the URL for that SKU on the old site and the new site and suddenly do the a vlookup and then you got all of your redirects for every single SKU done in one go. So that's uh, one easy thing to do. There was a script published on Search Engine, Engine Land or Journal, one of them that uses um, LLMs to map it redirects. I've not used it personally but um, I've been told it's uh, very good.

Speaker C: I would say double check with a uh, human.

Speaker F: Yeah, yeah. So it's based on like the similarity score. So would you. So let's say you use that script, you use the tool, how would you say based on the similarity scores, of course you haven't used it, but for someone who used it, um, let's say you have a very large site and then that site needs to be well redirected based on the similarities course. Where would you start? So of course you would start on the bottom, the pages that are less um, similar. But where would you go from the bottom to m middle or would you start higher up?

Speaker A: So I would first of all identify your critically important pages and those critically important pages they need to be human reviewed so you can automate it to an extent. But unless you've got like human pair of eyes cast over it, you are risking losing huge traffic. Um, so the, the automation side of it, if you're not going to review it, I would reserve it for those pages that get a little bit of traffic or no traffic and then um, you're not losing anything but you are maintaining um, uh, those pages and any authority that those pages might have.

Speaker C: Completely agree. I would say let a human do as much as possible before letting ah, a machine do decide for you if at all possible. So I think we're going to have to leave it for there. Thank, uh, you everybody. Thanks for your amazing questions hanging out with us.

Speaker B: Thanks so much for joining us for today's episode of the Internet Marketing podcast produced by the team behind Brighton SEO, the world's largest specialist digital marketing conference covering SEO ppc, paid social web analytics and content marketing. If you want to find out more about us and the show, you can check out the website Internet marketing podcast.org and if you've, um, not already subscribed to the show, you should hit that subscribe button and can ask a favor. If you are subscribed and you're enjoying the show, can you leave us a review wherever you're watching or listening to the show? And if you want to get in touch, um, become a guest on the show, or just generally feedback about what we're doing, you can always email me. That's kelvinrightonseo.com so k e l b I n m brighton SEO.com or of course you can contact me on social media, so at LinkedIn or Twitter. Uh, my usernames are Kelvin Newman. See you soon.