Intro
MARTIN SPLITT: Why do SEOs give strange recommendations to us developers sometimes?
MICHAEL KING: Why can’t the Google documentation be up to date?
MARTIN SPLITT: Why won’t all SEOs use their tools and documentation properly?
MICHAEL KING: Why is the Google documentation written so strangely?
MARTIN SPLITT: Hello, and welcome back to another episode of SEOs and Developers. Today, my guest is Michael King, who is not only running an SEO agency and has a technical background, but he’s also a rapper. So I’m really looking forward to see what we’ll be getting into today.
MICHAEL KING: And I’m here with Googler Martin Splitt, who’s a diver, magician, and an individual who is as dynamic as his hair. Very excited to speak with him today.
Checklists, beginner SEOs, and tools
MARTIN SPLITT: (01:00) So I’m really, really excited to be joined in this episode by Mike King. And, Mike, I actually have a really good question for you. So you’re running your SEO agency. And I know that you have a technical background, so you maybe understand where I’m coming from when I say, as a developer, I have met so many SEOs who are basically barging into the development room and going to the team, like standing in front of the entire team, going, oh my god, stop everything that you’re doing. We have a massive issue. And then you’re like, so what’s the issue? We need to fix our canonicals. And you’re like, but why? Oh, you know, it’s going to break everything, and everything is going to be like we’re going to get penalties, and everything is going to shit, and we have to really get everything back up to speed. And, oh my god, this has to happen now, now, now. And I’m like, why is it that a bunch of people are operating like this? Where does that come from?
MICHAEL KING: (01:55) Well, it comes from the fact that everyone in SEO comes from a different background. Like, not too many people are as technical as someone like me or some of the other great people in the space. And so a lot of it is like, OK, I read this checklist. It tells me, OK, I need to do these things. I have a tool that tells me that everything is on fire. So I’m going to focus on the thing it says is most on fire. So what it really comes down to is differing levels of education. I think that there’s some difficulty with people understanding what priorities are or how they align with priorities and an actual business, and then also from the perspective of what it’s going to be the impact of doing any of these things. So it’s very easy for an SEO who is inexperienced to put together some sort of PDF report from a tool that they’re using that says, OK, these are the 10 things that must happen right now. But it doesn’t necessarily reflect what the impact is going to be of those things.
MARTIN SPLITT: (02:59) Right. Yeah, I’ve seen these PDF reports, and that has me wondering like, why can’t tools not just be doing the right things? Like, why are these tools generating these 30-page reports with all this stuff in it? How did we end up here?
MICHAEL KING: (03:18) Yeah, I mean, that’s the thing like, when you build a generic tool around a series of SEO best practices, it’s not going to take into account the context of the actual website, right? So in the example that you gave with canonical tags, there may be a reason that you have so many duplicates. There may be a reason that the site needs that, right? Like, if you think about a site that has a bunch of franchises, and that content isn’t any different per franchise, it makes sense that you’re not canonicalizing those to one version of the page. Like, the business wants to have these different permutations of pages for different service areas. And there are any number of reasons why this may be of value to the actual business. So a tool is just going to say, well, the best practice is for every URL to be canonicalized so the version of it that’s very similar to it or is an exact duplicate. But it doesn’t know that that actually makes sense for that business. So I think that there’s an opportunity, I think this is generally true that technology for SEO is very much behind, of course, what Google is doing. But it’s also behind what it can actually do, right? I think that there needs to be some sort of layer that’s added to these SEO tools, where it’s like, I’m this type of business. We have this type of concern. These are our priorities. All right, now spit out something that is prioritized or takes into account what makes sense for this business. And so when you don’t have that, you need an expert that’s able to interpret it from a business-use-case perspective, from a perspective of, what can we technically do? And again, because you don’t have enough people in SEO that are able to interpret things that way, you get these reports straight out of the tool that’s like, again, everything is on fire. And so that’s what our job is, is to interpret that to the frame of what the business actually needs to do.
Why does context matter for automation?
MARTIN SPLITT: (05:18) All right, OK, I get that. So one takeaway from me, don’t be mad at me here is that from a developer’s perspective, I always thought this stuff can probably be automated away, right? We don’t really need that many actual people doing it. But it sounds like that’s not the case, right? There’s a bunch of stuff that depends on the context, and the tools can’t capture this, right?
MICHAEL KING: (05:43) Well, I’ll put that back on you. Like, at this point, we’ve also got tools that can automatically write code. We don’t need developers, right? It’s the same sort of thing. You know what I mean? Like, of course, we need developers. Like, there still needs to be that interpretation of, what are we trying to do here, and how do we account for the nuances of what we’re trying to do? So to your point, yes, I agree that a lot of SEO can be automated, but there are things that let’s say, for instance, we’re talking about an internal linking structure. That could be entirely automated. But if you don’t have the right rules in place, it could go crazy really quickly, right? Like, let’s say you even got it to the point where you’ve identified all the pages that own individual keywords. So let’s say you’ve got your whole keyword list, and you’re like, OK, there’s a mapping of keyword to URL. And then, you have something that crawls the site and looks for the instances of those keywords so that you can automatically build a keyword-relevant internal linking structure. But that could easily go crazy, where you have every word on the page has internal links on it now. And now it’s like a completely bad user experience, and there’s any number of filters that could be tripped as a result of that. And so you still always need that human interpretation so that we’re doing things right, and it just doesn’t go haywire.
MARTIN SPLITT: (07:08) Yeah, yeah, I see that. No, that makes perfect sense.
Do tools give outdated recommendations?
MARTIN SPLITT: (07:11) And another thing that I’m surprised by, let’s put it that way, is that there’s a lot of the guidelines you said, like, the best practices and the guidelines are there, and the tools are going along with them. But a bunch of the tools seem to be making proposals or suggestions that I think are either not quite there or actually completely wrong and outdated and no longer are a thing. How does that happen?
MICHAEL KING: (07:46) Yeah, you’ve got things like text-to-code ratio, or W3C compliance that are still, I mean, I’m embarrassed to see that type of stuff still, because it’s like, was that ever really a concern? Or was it just something that some SEO at some point was like, hey, I think this is a thing, and then every tool just has it as a result? But, yeah, I think no one’s really gone back and looked and taken a critical look at things and said, hey, what do we actually need to be looking at? What do we actually need to have rules around? I think it’s largely been like, you have to have feature parity with other tools. And so they’re just copying what they saw Moz do or what they saw SEMrush do, or whoever, and this just continued to persist. But I think that there needs to be. I think SEO as an industry probably just needs a product manager to stand up and be like, yo, let’s stop doing these dumb things.
MARTIN SPLITT: (08:48) Oh, man. I mean, I understand that that kind of cruft accumulates over time, but we have so much in terms of updates and documentation and reading material and guidance out there that we are trying to update whenever something changes. But yet, the tools are still spouting things. And for instance, the W3C thing that has been a tricky one because, obviously, writing compliant, semantic, and correct HTML is great because that makes it easier for us to understand what you’re trying to accomplish there in terms of the semantics of the content. But if you make mistakes, it’s not that we stop understanding the page and be like, oh, we don’t know what that is. We are out of here. We are still trying to make sense of it. We just might need to, like, we might lose confidence on the way, right? It’s like. This might be a headline, but we’re not sure.
MICHAEL KING: (09:40) Right, but realistically, if that was actually a requirement, I’m going to guess that over 90% of the web just wouldn’t load, you know? Because what is truly compliant across the web? And so to that end, obviously, you guys, the crawling capability is fantastic. And you’re rendering the full page anyway, so if my browser works, it’s likely that your crawler will work. And so just the fact that we’re still, like, even considering that is difficult. But at the same time, there are things that you do that achieve compliance that do help. So I agree with what you’re saying, but it’s not the metric that we should be looking at to determine it.
Documentation drift and doing your own research
MICHAEL KING: (10:27) I think that there’s a lot of instances where, if we’re talking about documentation, where the documentation may be out of phase with where you are as an organisation. And I think you can say that not just from what’s public facing, I’m sure that’s happening internally as well. And so the reality of it is that it’s very difficult to look at that documentation as the single source of truth because things are changing so quickly. And so even if all the SEO tools were like, OK, let’s follow Google’s documentation perfectly, it still wouldn’t necessarily be the ideal state for how these tools would tell you things.
MARTIN SPLITT: (11:08) OK, I’m guessing this also aims a little bit in the direction of previous/next links, where we had this thing. OK, yeah. So what happened there was unfortunate. And you’re right; the docs are not always in phase. We are doing our best to work with the teams and help them to keep their documentation updated, but it does every now and then happen. In this case, a bunch of engineers in search of quality figured out, hey, hold on. We actually don’t really need the rel=”next” and rel=”prev” links anymore to figure out that there is pagination going on. We can figure that out from other things on the page by themselves. So they just removed the code. And then we were in this, and now, we go into our position, come to our side of the force, and what do you do? Do you either update the docs to like just quietly remove that part because it is no longer relevant? Or do you go like, hey, by the way, this is no longer necessary? And, truthfully speaking, it hasn’t been necessary in the last six months, knowing very well that people are reading the documentation, making recommendations based on it to other people, and these people then invest work and time and money into making that happen. And the alternative would just be to let it live there in the documentation. Even though it’s wrong, it doesn’t hurt. So we went with the full frontal way of going like, OK, here’s the thing this has been removed a while ago. We are sorry about that, but now our docs are updated. And I think none of the choices are easy or necessarily perfectly good, but it’s just what happened. So I think we are trying to keep the docs updated as much as possible.
MICHAEL KING: (12:50) Yeah and I get that it’s hard. Again, you have a large team, which is like an offshoot of another even larger team. You’re both moving quite quickly. I get it. It’s just very difficult from this side, where you’re making recommendations to people. And then you’ve got an engineer who’s second-guessing you. And then they find something in the documentation that’s out of date, and they’re like, no, you’re wrong. You don’t know what you’re talking about. Google says this right here. So it just makes our job a lot more difficult. So I get what you’re saying, but you also got to come to our side and see what we’re dealing with because I’m just Mike King. You guys are Google, right?
MARTIN SPLITT: (13:31) Yeah, no, no worries. That’s exactly why we are so transparent and say like, hey, by the way, this has been removed. We’re sorry, but the docs are now updated, because we understand that we have to make sure, to our best knowledge and to our best ability, that the docs are a source of truth.
Who is the documentation written for?
MARTIN SPLITT: (13:37) Nonetheless, it is tricky, because of what you just said, like, oh, the engineer finds this piece of documentation and argues their way around it, it’s so hard to write these docs to the right audience.
MICHAEL KING: (14:03) Right. Yeah, and that’s the thing it seems like from what I’ve read and I’ve read most of it, from what I can tell it’s like, the writer’s aiming for the middle, but that doesn’t really support the use case, right? Like, it doesn’t necessarily align with the people that are actually going to use this. At the same time, I get that there’s a very wide audience of “webmasters” how many small businesspeople are really digging into documentation like this? So why are we necessarily writing for them? Or should it be the type of thing where we have a section that’s more for the advanced user or more for the enterprise user, where you’re able to speak to these use cases in more specific ways? There are a lot of situations in the documentation where there are just too many edge cases for you to say the things that are being said. Like, there’s something that came out more recently where it’s like, hey if you see a traffic trend or a click trend that looks like this, that means this is what happened. I’ve seen plenty of trends that looked like all four of those things that are shown in the documentation that wasn’t the thing that the documentation says it is. So now, I’ll have a client that’ll come to me and say, well, we saw this, and the documentation showed us a screenshot of this, so this must be why. And so they may not be so receptive to what’s actually going to need to happen in order to recover. So that’s the thing it just doesn’t really solve the problem in the way that we would hope it does.
MARTIN SPLITT: (15:38) And I understand that, and I understand that it’s tricky. And we learned that, and that’s why we relaunched our documentation at some point in the past. I think it was in November 2020 we relaunched or February 2021. I can’t remember when exactly we launched the new Dev site. But we are trying to group it differently because we realised that even though with the new grouping, we’re still seeing feedback to very technical things, like robots.txt, coming from small business owners being like, I don’t even know what any of this means. Ahh! And we’re like, OK, but this is a very technical thing. Like, how did you end up here? Why did you end up here? And what are you trying to accomplish? So it’s really, really tricky, and we have to try to write for the broad use case and then the edge cases. That’s a tricky place. Where do they live?
We read documentation feedback. Give us feedback!
MARTIN SPLITT: (16:27) I did that for JavaScript. I have this extra fixed JavaScript issues page with all the edge cases where things might go wrong. But it’s tricky. It’s not easy to catch all these things. And that’s why giving us feedback on the docs and in the docs, there is an opportunity to give us feedback right there. We read this. It’s really weird because we can’t give a response back as easily. Like, you don’t know that we read it, but we do read it. And it’s quite interesting. Like, a lot of it is really useful, constructive, helpful feedback that allows us to improve our documentation. A bunch of it is people saying like, aw, you guys suck. And I guess that’s the reality of the internet– wherever you give people the opportunity to say things, they might say things that you might not want to hear, but that’s OK. If they think we suck, that’s, you know, I’m sorry.
MICHAEL KING: (17:15) Well, I do want to give some props because, especially around the JavaScript thing, I really appreciate what you did with that because that was very much something that we were very early on discovering at my agency. Like, we wrote a blog post a number of years ago, probably, like, 10 years at this point, called “Googlebot is Chrome,” where we introduced the SEO world to the idea of headless browsing. And I also wrote some subsequent stuff around that about how this could be done. And I appreciated that you especially came out and were like, no, here’s how we do it. Here are some specific things to know because it was a lot of speculation on our part and a lot of testing. But I appreciate that you were able to say like, no, no, here’s the way that we do it, and then we can refine it across the industry. So that’s what I mean. Like, there are definitely instances where the documentation has been incredibly valuable in shedding light on how we need to be thinking about things because, for a long time, we may have been going in the wrong direction entirely. So yeah, there’s definitely some value to it. I just think that there are instances where things are very vague or don’t really speak to the problem and create more problems for SEOs.
Why documentation causes misunderstanding
MARTIN SPLITT: (18:35) So with the create more problems, that’s exactly what we want to improve on and what we want to constantly get better at. And also, thank you very much for the positive feedback. And for the other bit, like, it’s very generic or very strangely written, that one is a tricky one because it is what you said it. You said it yourself– SEOs come from a wide variety of backgrounds. And they have a wide variety of different focuses, and they look at the same thing from very different angles, like the W3C validator thing. If you ask me like, so does our HTML need to be written well? My answer would be, yes, it has to be written well. But I don’t mean specifically compliant with W3C specs, which is what some people might hear who are coming from that angle. Someone else might be like, oh, so it doesn’t have to be compliant, but it needs to be well done? OK, fair enough. And it’s not just documentation where this is hard. I find that also with the tooling, it is incredibly hard to do that from the tooling that we provide. PageSpeed Insights, for instance, or Lighthouse, gives you a score. That’s so dangerous. I know, but some people need that score.
MICHAEL KING: (19:45) But let’s dig into that a little bit. So one of the common things that I hear, and I heard it at a conference the other day. They’re like, oh, I ran it three times. Why is it different? People don’t understand that network conditions impact all of these scores here. And so if there was some sort of callout, maybe there is. Maybe it’s in a tooltip that no one clicks on, but I think there’s some value in helping them understand that because you’ll see your score is, like, 45 right now. Now, suddenly, it’s 52. And you’re like; these tools don’t work. I don’t trust these tools. And then also, let’s talk a little bit about the difference between a click in GSE versus a session in GA. Most people don’t know. Like, it was very widely misunderstood that those are not the same things. And so I ended up writing a blog post, going into very great detail. I did some patent diving and looked at some of your documentation and showed people, no, here’s why they are measured differently. One of these comes from logs. One of these comes from clickstream, and so on. And so if that information surfaced a bit better and again, I’m not saying you don’t have it. There was a section in there that talks about the differences to some degree like, what is average position versus what is a ranking? Things like that. These are things that are just not obvious to people that I think could be surfaced a bit better, so these questions don’t come up as much.
Challenges with trust and supporting each other
MARTIN SPLITT: (21:09) That’s very, very good feedback. That’s exactly what we’re trying to do. And I know that especially the Lighthouse team, for instance, tries to be ridiculously transparent. Like, you can figure out how the score is being calculated and evaluate, and as well as how that changes over time because the same score might actually change even if everything else is the same. Over time, you might actually see different scores because the way that the different metrics are weighted is changing. It’s challenging, though.
MICHAEL KING: (21:39) Of course, of course. I think the bigger challenge, though, is that, again, sometimes a developer will come into the project. They’ll look into the documentation. And they’re like; this doesn’t match up with what the SEO has told me. And then they just don’t trust them. And then there’s also some messaging that I recall from a year or two ago, where there was a video talking about how you should choose an SEO. Obviously, that created a bit of a firestorm in our space because it felt like Google saying, this is the way that we need to be. Here are the expectations you should have. I wish there was one where y’all were like, hey, here are the expectations you should have of our documentation.
MARTIN SPLITT: (22:25) Yeah, I understand. I understand. Yeah, see, and this is exactly what happens because I like two things, particularly what you just said. Number one, this video created a firestorm amongst SEOs. It was not even meant for them. It was not even meant for their customers, necessarily. It was meant for small businesses that are like, I am running a kid’s clothing store in a back street in Zurich. And I have zero budget. I’m basically running it out of my basement, and people WhatsApp me or Facebook message me or FaceTime me or Hangout me or write me a text message or whatever to pick up their order or something like that. But I want to be taking part in the online world of e-commerce. How can I do that? And it was meant for this audience. Like, if you get an SEO, look for these very obvious red flags and things that might not be up for what you are trying to accomplish. And because of the wide variety of people, that is what happened. Like, it was misunderstood and misrepresented, and it wasn’t necessarily presenting itself very well. And the other thing was trust. We said like, a developer comes in and doesn’t trust what the SEO says based on what is in the documentation. And that seems to be the core of all this. I just realised, thanks to you, SEOs, and also developers, probably, as well, come from so many different backgrounds. And it’s unfortunate that we choose to use this, like, the trajectory that we come from, like, I’m coming from here. You’re coming from here. Instead of looking at the entire spectrum in between and learning from each other’s perspective, it seems to be more like, I come from this angle, and I see this. You come from this angle. You see this. You must be wrong.
MICHAEL KING: (24:33) Right. Yeah, I don’t think it should be that us-versus-them dynamic that we currently have. And I think that there’s so much beauty in the fact that SEOs come from so many different backgrounds. Like we said in our introduction, I rap. That’s what I did before I did SEO full-time. And there’s so many people that you meet with so many interesting perspectives on so many things, and I wish, when we work with engineers, we were able to come to the table better and be like, look. I want to know everything about what it is that you’re doing. And what can I learn here? How can we work together more effectively? And that’s very much my approach. I don’t try to come into it like; this is the way we must do it because it’s the way I think. I more try to come to it from the perspective of, like, hey, I know a little bit about what it is that you do, probably more than you might expect. But I want to learn this from your perspective, and I want to help support what you’re trying to do. One of the things that we do at the beginning of any of our audits, there’s this thing it’s like the prime directive from some agile thing that we read, where it’s something like, we’re just assuming that everyone did their best with what they knew and the whole thing. So that we’re coming from the perspective of a level playing field, where it’s like, I’m not just hating on your work. I’m just trying to say like, hey, from the perspective where I sit, these are the things that can be improved so that we can make things perform better. And at the same time, I need to understand your limitations. I need to understand what you need in a user story for this to work for you. I need to know what sort of supporting data and documentation you need to see in order for you to get this on your prioritisation schedule. And I think a lot of SEOs aren’t really thinking that way because a lot of how things are presented both in our space and from that us-versus-them dynamic is like, all right, well, you’re going to bring all this great stuff to the table. And no one’s going to do anything with it because they don’t trust you. And it’s all just humans working together, so what do we need to do so that we can all come to a space of trust and make this work and make it, so everyone gets bonuses at the end of the year?
MARTIN SPLITT: (26:54) That’s a nice way of looking at it. From a developer’s perspective, what I can say is that what I observed myself as well is that, as developers, we are used to know that we don’t know something, and then we have to get better at figuring it out. There are still a lot of developers who are like, I know everything, which is unfortunate. But usually, developers are curious creatures, and we are like, oh, I don’t know how that works or how that is supposed to be. And then we research, and then we prototype, and then we have something that solves the problem. We are problem solvers. So when someone comes in, and often, SEOs come in, and I think it’s also because there is such a wide variety of people’s backgrounds in SEO, they might feel inclined to say, oh, it’s like this, even though they are not sure about it, or they don’t know it. So they cling on to their PDF reports. They’re like; this report says this is a problem without necessarily thinking about it. And I would love to see more SEOs admitting, hm, I actually don’t know. Let’s find out together, or let’s test this together. Let’s do some research together.
Knowing, not knowing, and doing researching
MICHAEL KING: (28:01) Well, that is easier to do when you’re in-house. It’s harder to do when you’re a consultant because they don’t expect you to know everything when you’re in-house. They expect you to know enough and work through it. Whereas when you’re a consultant, they want you to have the answer, even if there isn’t a definitive answer. But as far as developers, I like to think of them on a spectrum. And I think I’ve mentioned this to you via email before. I think of it as the Anderson-Alderson spectrum, where Anderson is Thomas Anderson, like Neo from “The Matrix,” who hated his job, and didn’t want anything to do with anybody. And then you’ve got Elliot Alderson, “Mr Robot,” who was the guy that was working all hours of the night, just kind of doing work without anyone telling him, being super proactive. And so there are those developers like you’re saying, this side of the Anderson scale, it’s like, I know everything. You don’t know anything, and they present that way very much, even when they are typically more intellectually curious amongst their peers. And obviously, those people are very difficult to work with, and you’ve got to have documentation for everything. And again, that’s the person that’s going to find the Google documentation that says that you’re wrong, and that’s that. Yeah, exactly. Whereas on the Alderson side, I had a guy who’s a developer working with a client at one point. We were presenting the site audit on-site with them, walking through everything. And he was committing code, fixing things, as we were talking and asking questions. And probably, that’s not the best way to do development work. Of course, you need to run it through your whole process. But it was really good to see how receptive he was to what we were doing, and he was very collaborative. That’s the ideal situation: someone who’s going to ask questions, someone who’s going to help you clarify things so you can make the recommendation far more pointed and actually make it happen. And obviously, those are the extremes. But obviously, something in the middle is where things work best, where it’s like, hey, SEO, you understand that you don’t know everything about this website because you didn’t build it. And, hey, engineer, you understand you don’t know everything about SEO because those requirements are not in your day-to-day. So let’s all get together and figure out how to make this work and trust each other, and that’s it.
MARTIN SPLITT: (30:37) Sounds easier said than done, but I think, yeah, to sum it up, SEOs should value the difference of perspective from different people and be receptive to doing their own research. And also, developers need to be more trusting towards SEOs and take them on the journey with them and work together to figure things out together. And I think that would probably make things easier for everyone.
MICHAEL KING: (31:05) Yeah, I’ll tell you that no SEO is trying to ruin your website. Like, they’re not actively trying to mess things up for you. Their remit is helping it improve its visibility, and drive traffic, ultimately driving conversions. So the reality of the situation is it’s an antagonistic relationship because the whole job, or a lot of the job, is telling an engineer that they’ve done something wrong. And again, we need to reframe that so it’s a better working relationship.
MARTIN SPLITT: (31:39) Yeah, interesting. So let’s hope that people out there watching this conversation are finding their way of reframing it and actually getting onto a table and collaborating with each other rather than trying to prove each other wrong. Because I think if we try to just prove each other wrong, we’re not getting anywhere, and we have the same goal. We want better websites.
Conclusion
MARTIN SPLITT: (32:02) Awesome. Mike, thank you so much for being here with me and taking the time to talk this out. And I think I am full of new ideas, and I will definitely try to make our documentation better together with our lovely team and our fantastic tech writer, Lizzie Harvey, and all the others. And yeah, thanks a lot.
MICHAEL KING: (32:20) Thanks for having me, Martin. This has been great. And I, again, just want to really thank you guys for all the things you’ve been doing. I’ve been doing SEO for 15 years, and it’s been a dramatic improvement in how you’ve engaged with the community, the documentation you’re doing, the tools, and so on. So I definitely appreciate the progress and look forward to where this continues to go.
MARTIN SPLITT: (32:43) Thank you. Thanks a lot for the nice feedback. And thanks to everyone watching this. I hope that you had a good time. Stay safe and healthy, and bye-bye.
Sign up for SEO & Web Developers today!
