Author: LION Digital

Introduction

(0:00) MARTIN SPLITT: Why do moves such as EAT as ranking factor still come up?

JENN MATHEWS:   Why do engineers expect SEOs to prove themselves before they can trust them?

MARTIN SPLITT: Why can’t SEOs say “I don’t know” when they don’t know?

JENN MATHEWS:   Why is “it depends” always the answer?

MARTIN SPLITT: How can developers be better partners for SEOs? 

JENN MATHEWS:   How can SEOs be better partners for engineers?

MARTIN SPLITT: Hello, and welcome out there. I’m so excited to have you all back here for another episode of SEOs and Developers. Today with me is Jenn Mathews, who is an SEO at Github, which is a company that is dear and near to my heart as a developer and developer advocate. And she is known by the handle SEOGoddess, which I think is an amazing name, and I wish there would be more cool titles like that out there. 

JENN MATHEWS: And I’m here with Martin. The first time we met was over our crazy hair. We both had purple and pink hair, and now we’re back to normal. MARTIN SPLITT: There’s times for everything, and I think in wild times like these, it’s a good thing to come back to normal hair at least, if normality can’t be achieved elsewhere. Jenn, I’m super, super excited to actually have you here today with me, and I want to discuss something that I find very intriguing when it comes to SEOs and developers working together.

Why are SEOs and devs not on the same wavelength?

(1:41) MARTIN SPLITT: I want to hear your perspective because you work in such an engineering driven organization that you must have come across this as well. The thing that I am finding very interesting is that it sometimes seems– or I have the impression SEOs and developers are sometimes speaking completely different languages. And I don’t mean like German versus English versus Russian. I mean, even if we’re speaking the same natural language, we seem to be not on the same wavelength. Is that something that you have experienced in your career and how is that at Github?

JENN MATHEWS: Yeah, definitely. I think Github just as much as any place else. I mean, it’s a company that’s run by product managers, content writers, marketers, and of course, engineers, just like any other company does. And our engineers are just as bright as they are at any other company. But yeah, I think the language, definitely speaking to engineers is just a completely different thing. And a lot of SEOs today aren’t as technically savvy as I think that they should be when they’re talking to engineers, and I think there’s a gap in that. 

MARTIN SPLITT: Mhm.

JENN MATHEWS: Yeah. For sure. 

MARTIN SPLITT: I think the– yeah, I see your point, but I don’t think necessarily that every SEO has to be as tech savvy, because I mean, that’s what the engineers bring to the table, right? They are the tech savvy ones. They can help you with that. But I have the feeling sometimes it’s so bizarre that when you as an engineer are working on something, on a software product, and an SEO comes and they tell you stories that feel like from a fairy tale. And it’s stuff like, Oh, EAT is a ranking factor. That just keeps sticking around. Or stuff like, oh my God, we have multiple URLs pointing to the same content. This is going to get us a penalty. And things like this. Why does this keep sticking around? And why can’t they just move on and be more I don’t want to say honest, but more realistic about the importance of these things and also how certain they are about certain things? 

Test and learn 

(4:10) JENN MATHEWS: Yeah. I think that it’s tough for engineers to not think of SEO as a bunch of smoke and mirrors. I mean, I’ve been told that statement a million times. Engineers want concrete evidence- if I do x, then y will happen. When it comes to SEO, we never know, right? Unless Google gives us the actual sauce, the recipe to the sauce, we can’t decipher it. And so when we make decisions a lot of times, especially on my end– I’m doing this for 20 years– my best guess is my best guess. I basically could say, if I do this, in the past this is what’s happened. I can’t guarantee that’s going to happen, and so everything is always test and learn, which is the only way I can get the language to resonate with engineers, is that test and learn. Let’s try this. We’ll work together. Let’s see if it works. And if it doesn’t, then let’s try something else and just keep doing that.

I don’t know, do you?

(5:14) MARTIN SPLITT: Yes, and this is at the core. Yeah, but that you say that as if that would be a normal mode of operations and that would be the normal thing. Because I think what you just said is amazing, because I just realized how similar, again, how similar SEOs and developers are in the circumstances that they work in. Because you say, oh yeah, the developers want to know the real thing and the hard facts. But the reality is in engineering and software engineering specifically– we often also don’t know. And oftentimes, we don’t even know what we don’t know. And then we just have to, as you say, test and learn. We have to try things out. We have to experiment. But the thing that I find strange, and I think that’s causing friction as well, is that an engineer, when they don’t know something it’s like, hey, can you build me this thing? They have never built something like that before. They’d be like, I don’t know, but we can build a prototype and we can try things out, and then if we figure it out then we can make that production ready. That’s a thing that we can do, and that’s a very normal thing. So saying I don’t know, let’s find out or I don’t know, I’ll have to check or I don’t know, I have to do some research, is a perfectly reasonable thing to do for, I think, both SEOs and developers. And yet in my career, I have mostly heard engineers or developers say that, but SEOs seem to be unwilling to admit that they don’t know something.

JENN MATHEWS: Yeah, that’s true. And I think we’re constantly, I mean, throughout my career, I’ve always been questioned. Every time I start with a new company I’m constantly questioned. It’s that smoke and mirrors, right? I say something will happen if we do this thing. We’ll get on– of course I can never guarantee first position, but I’m like, let’s try it. Let’s try at least for the first page. And they’re sitting there going, Google, we have no control over this, right? You have no control. You don’t know. And so it’s hard to convince people to try to do that thing and get that result, and that’s where we get into that test and learn. And SEOs are constantly questioned, constantly. So it gets to a point where we almost get on the defensive. Yeah. So when we’re asked a question, or how is this going to work, or if we do this thing what’s the result going to be, it’s hard for us to say I don’t know just for that reason. Right? Because we’re constantly under scrutiny, we’re constantly being questioned. 

SEOs are under scrutiny 

(8:02) JENN MATHEWS: But so what I usually tell other SEOs is say, it’s OK to say I don’t know, because they’re going to say I don’t know too sometimes, right? So everybody is going to. Use the word test and learn, right? Let’s try this out, let’s work together, let’s partner, let’s try it out, let’s test it. And then let’s see what happens. And when we do launch things and they say, how come it’s not working? Instead of us digging in and trying to understand which algorithm is not letting us rank, it’s OK to say, I don’t know, and let’s try something else and move on. But it is, it’s very difficult for SEOs because we are constantly under scrutiny.

MARTIN SPLITT: Under scrutiny from whom? Is it developers questioning your expertise, or is it someone else in the organization questioning your expertise? 

JENN MATHEWS: Yeah, pretty much the whole organization runs into it. When you’re asking content writers to put a keyword in the header, and a keyword in the H2, and a keyword in the body. And they’re like, why do I have to use this word? It doesn’t make sense in the copy I’m writing. And it’s like, well, if you don’t use this word– and then they say, you know, then it won’t show up because Google won’t find it. And then they say, well, it doesn’t fit with the narrative. And you’re like, well, this is what people are searching. So it becomes this conversation and this back and forth to the point where they’re like, I don’t know if I believe this. Right? And then you just have to– that test and learn. It’s like, well, let’s just put this one keyword in the body somewhere and cross our fingers it works. And if it does then it’s like, look what you did!

MARTIN SPLITT: Interesting. Yeah. 

JENN MATHEWS: Yeah. 

MARTIN SPLITT: So it’s the– oh my God. OK. So yeah, then it’s no wonder that you’re pretty much always on the defensive if everyone fights and scrutinizes you and OK. 

JENN MATHEWS: Everybody. Yeah. Even leadership, you know? You even get it from leadership. 

MARTIN SPLITT: Oh, yeah. Yeah. But then maybe developers can actually probably be your allies, because they should and I say should because I know there’s lots of different developers out there. Developers should understand that “I don’t know” is a reasonable statement, especially if you then follow up with “let’s test and learn.” That should be on their wavelength, and then maybe you have at least someone backing you up. Even if it’s not the content side, I think having the technical side on your side as well is probably a good thing.

Priorities and impact

(10:46) MARTIN SPLITT: But then speaking of becoming allies, what could the engineering side, what could developers do to help SEOs get over that friction, get over that scrutiny? I think definitely helping you with test and learn, so being open in this dialogue on their end as well and being open to try things out with you and other SEOs. But what else? Is there something that you would say developers could do to make SEOs’ lives easier?

JENN MATHEWS: I think it’s a back and forth, right? I mean, I think it’s how engineers can best make SEOs or be best advocates for SEOs is, I mean, I hate to say it, but just make the changes that are asked. I think to be blunt, as I’m known for an SEOs say, hey– but it’s also the other side of it. SEOs need to understand that what we’re asking sometimes aren’t super easy to do. What we think might be a simple let’s say there’s a few redirects that are happening in the footer of the entire website. And we’re like, just fix this one link, right? Just have it point to the main one and stop the maybe it’s a 302 because somebody thought it was temporary, and no, no, no, we need to make it permanent. So even just having that conversation, SEOs, are like, it’s just one link. But from an engineering perspective, it’s a whole going to figure out where the programming is that makes it create the footer, it’s much more complex than just fixing one little link. And so I think engineers– I think where that partnership comes in is that engineers need to understand that we’re not just asking for simple little fixes just because we feel like it. There’s a method to our madness, as I say often to everyone I talk to. There’s always a method to my madness, and the other one is, it’s a small part to a bigger part of the problem. And so when you add up, one little fix is not that big a deal, one little redirect. But when you have, let’s say, a million pages and 850-some thousand of them are all redirects, that’s not a good thing. And so you want to clean those up as much as possible. And so that’s why I say, yeah, this one little thing isn’t a problem, but you got to do five of them because they’re creating 850-something thousand redirects. And once they see that– and so yeah, I think it’s kind of both sides of it. If engineers understand that when we’re asking for a simple fix, a lot of times it’s not just one simple fix. It’s just a conglomerate of a bunch of things, and there’s a reason more often than not why we’re asking for it, so yeah.

MARTIN SPLITT: And then there’s this quadrant situation. It’s like low impact, low effort. High impact, high effort is probably– high impact, high effort is the tricky ones. High impact, low effort is the low hanging fruit that you want. And then there’s high effort, low impact. That’s the ones you want to avoid. And I think understanding where things are in these quadrants with developers is probably also helping SEOs figure out when to suggest what.

JENN MATHEWS: Right. Exactly. Yeah, and I actually– my SEOs that have worked for me in the past, I have taught them actually how to do that low impact– the impact versus effort. And when you have fixes, make sure you put that rating in there or talk to your engineers that you work with and that helps them develop a partnership as well with the engineers. And then we can gauge what needs to get done. 

MARTIN SPLITT: That’s really cool. That’s really nice. And I think if we look at the working relationship between SEOs and developers, as you said, it needs to be a dialogue. It needs to be a two way conversation. And we can both learn from each other, I guess. Would make our lives easier, wouldn’t you say? 

JENN MATHEWS: Yeah, for sure. I mean, yeah.

MARTIN SPLITT: It would be so nice to just have that happen more often in organizations. Is there something that we can do from the developer side to make sure that these dialogues happen in our organization? 

JENN MATHEWS: Yeah. I mean, I think it’s up to engineers at that point, for sure.

What developers can do to help 

(15:46) MARTIN SPLITT: But if I am an engineer who doesn’t really know what to do to help my SEO in question, what would you say is a good icebreaker or a good door opener for me to become a better partner for the SEOs I’m working with? If I’m afraid of approaching you, kind of. 

JENN MATHEWS: Oh, gosh.

MARTIN SPLITT: I don’t know. It sounds like you figured it out, so I thought I might just ask.

JENN MATHEWS: Well, from my– yeah, I’m not an engineer so that one’s a tough one to answer. I think maybe you kind of asked your own–

MARTIN SPLITT: OK

JENN MATHEWS: Yeah, it’s a good question for you. But I mean, from my perspective. 

MARTIN SPLITT: Let me ask, exactly. Your perspective. 

JENN MATHEWS: Yeah. 

MARTIN SPLITT: What would you love an engineer to come forward with to you? 

JENN MATHEWS: Yeah. I mean, I’ll give you my perspective and then I’d love to hear yours on it. From my perspective, when I come into a situation and I get to know the engineers that I’m working with, there’s ones that are kind of like, I don’t get it. I don’t want to do it. Leave me alone. And I leave them alone, right? And that’s where maybe you can help answer that question. The other ones are– every once in a while there’s somebody who just gets a passion for SEO with what they do. And they’ll become my ally and then do some of the changes that I’ve asked, and then they actually even ask me for the follow up. Like, what would the results of this change we did three months ago? And I show them and they get excited, and they share that out with their team, and they want to do more. And they ask to be assigned to the SEO work, and so then we become this synergistic and there’s quite a few of them I have at Github, which is really nice. But there are some of them that I’ve asked them for help or had them look at something that I’m seeing and like, hey, can you help me problem solve? And they’re like, let me give it to someone else. I don’t want anything to do with it. Yeah. So maybe you can help give insight into somebody who’s just not there.

MARTIN SPLITT: I think I see where that’s probably coming from. I can see two reasons where that comes from. The number one reason is probably that they work in some sort of process or system that does not reward this kind of interaction or help. And that’s an organizational issue, I would argue. So for instance, if you are doing scrum or you’re committing to doing whatever is in the iteration and then someone comes up and asks you for additional stuff that isn’t in the plan, then you are basically overcommitting yourself. Because now I have to balance what I promise you with what I promised everyone else on the team, including the product owner and probably business stakeholders. And then it’s like, ugh. And the easiest way to deal with that is, because you didn’t come in through the regular channel of where commitments come in through, is to drop your request. That’s the obvious thing, because everything else has been committed, and now you’re asking me to commit something or to commit to some activity. So I can deny that. Which would mean that you need to figure out where in the process you can place this request so that it gets picked up by someone in the spring. So that’s one reason. The other reason that I could see for this to happen is and we come back to the I don’t know that they don’t know why that would matter. There are a lot of developers who look very technocratically on their work. It’s like, I measure myself by the features that I output, I measure myself by the systems that I build or by the systems that my code touches or something like that. Basically, they’re looking only at what they can immediately see and touch, which is the code. They might not necessarily be aware that it isn’t that much fun to work on something that no one ever uses because no one knows it exists, and no one knows it exists because it can’t be found where everyone looks for knowledge, which is search engines. So that’s an approach that I have taken whenever I talk to SEOs to developers. And I mean, I have been at lots of developer conferences, and it’s tricky to get them to listen to you when you are talking about SEO. Even as a developer, it is not necessarily trivial to get everyone in the room to listen instead of just reading something on their phone. And the way that I have done this is like, look, you want to build stuff that has an impact, most likely a positive impact on someone else’s life. And if that impact can be as big as it can be, that is great, right? You’re not building software for the sake of building software. You’re building software so that people can solve problems or fulfill needs with it. And if no one knows about your software, then why did you build it in the first place? And that oftentimes hooks them, and then you can say SEO gives us a tool, or is a tool for us to bring people’s attention to the things that you build. And I need a little bit of your time to make sure that this attention is given to your work. Sometimes that works. Doesn’t always work, but I would say these two things would probably hook most of the developers to help you, I hope.

JENN MATHEWS: That’s interesting. So instead of leaving them alone.

SEOs, become allies to your developers

(21:25) JENN MATHEWS: So how do you think that an example of myself or other SEOs could be better partners for those types of engineers or engineers in general? 

MARTIN SPLITT: There are a few things. So definitely, I love that you said I have been and we have in our organization we have been doing this quadrant thing, because that helps immensely. Because if I have to sort through lots of concurring items that all need my attention, I’m always obviously we are all human. We are not superhuman. None of us is a superhuman. We look for the high impact, low effort thing. And if that’s something that you would like to get out of the way, then presenting me with this first is definitely a good chance for me to pick your thing up. Because I don’t have to do that much, but someone out there will be very happy that I did it, and I can say I did this thing and my work here had impact. So that’s helping, and lots of SEOs unfortunately don’t do that. They come with a variety– and not even single items. They basically just come with a long list of stuff, and I have no way of ordering this list or figuring out how important any of the items really is. And then I’m like, why would I even do more research on which of these things needs to get done first if they don’t even do it? If they just throw me an unordered list of stuff I’d be like, can’t be that important because if it would be important they would be elaborating on this. So if you elaborate on it, that’s amazing. Also at least I know lots of engineers that would love to be asked about stuff. So I know that engineers have a huge issue with people coming with solutions, like oh, you have to do this thing. Oh, can you please change the template so that it goes straight to the right URL instead of redirecting in between? And then I’m like, we’re not even using templates but thanks for your suggestion. Right? It’s just we have– it’s true, isn’t it? Engineers are problem solvers as much as SEOs are problem solvers. So why don’t we do the problem solving together, rather than SEOs who might not even know the platform or the tech stack that they work with going into details there and making things up that they don’t know about, and then coming to me with a solution that is nonsensical in the circumstances that our product and our tech stack is in? Instead of that just go like, hey, I noticed that we have this weird redirect thing here and I was wondering what would it take to fix it? And if they say, well, actually that’s just a thing in the template. Can you tell me what the URL for this is? Oh, yeah, the URL that it should be is this, but the URL it actually goes to right now is this, which then redirects three times. And you’re like, oh, OK, in that case let me take that URL, put it in the template. I’ll commit it. It’s a one line change, maybe. And then the developer is happy because they accomplish something that you tell them, oh, that actually is great because this fixes I don’t know how many thousand links in one go– or redirects that are happening every month in one go. So they are happy, you’re happy, everybody wins. So that’s the thing that I think is very important, to come with problems and find the solution together, because developers A, probably have better insight into what these solutions should look like and B, also are interested in the solving of a problem, not necessarily in just stamping out the solution. 

JENN MATHEWS: Right. 

MARTIN SPLITT: Does that makes sense?

JENN MATHEWS: Yeah, that totally makes sense. And I think sometimes, like I said earlier, that the SEOs may think that they know what the solution is and yeah, like, hey, just fix this one link. It shouldn’t be that big a deal. But maybe the template is more complex, right? And you have to really dig and find it.

MARTIN SPLITT: And I understand where that’s coming from. And I understand where that’s coming from because if you are under scrutiny then you’re like, I don’t want myself to be vulnerable again to someone being like, you have no idea what this entails. This is a lot of work or something. But you make yourself somewhat vulnerable by saying, hey, I just noticed this problem. Could we work together on solving this? So yeah.

JENN MATHEWS: Yeah, I think that would– yeah. If that’s the key to working with engineers and getting them to be so the ones that are quiet, that’s what I need to do is just go to them and say, hey, I see this thing. Can you help me solve it? Maybe that’ll get them more interested.

Learn how to communicate with developers

(26:10) MARTIN SPLITT: Also one more thing and I’m pretty sure that this will get developers angry with me, but they got to be fine in the end. I promise, developers, you’ll be fine with this. Oftentimes developers don’t know if you’re genuinely interested in what they are doing to solve a specific problem or if you’re just trying to be polite or something. So when you ask them something, they might weasel out with a bit of jargon. Like, oh, it had something to do with the routing. Don’t be like, oh yeah, the routing. Yeah. Cool, cool. Because that will tell me that you weren’t actually that interested because my answer was ridiculously unspecific and unhelpful, really. But it makes 90% of non-genuine conversations go away, which is great because then I can actually get stuff done. But be asking questions, continue to ask, what do you mean with the routing? How does it actually work? And then you might get lucky and they might be excited about telling you how that actually works, and then you’ll understand more of the system. So similar problems in similar systems or other teams or other clients or future jobs, you now know at least how it worked in this one case and there’s a good chance that the way that it worked there is the same that it works elsewhere too, and then you might actually be able to help an engineer also find the solution a little quicker. I still wouldn’t come with a solution, but at least you understand a little better what the system looks like and how it actually works. And normally engineers are willing to tell you this. 

JENN MATHEWS: Yeah, and I think, so that brings it back to in the beginning when I said that SEOs should be technical.

MARTIN SPLITT: Fair. Mhm. 

JENN MATHEWS: Yeah, and you said, oh, engineers shouldn’t. And I think I’m a huge advocate any time any SEO comes to me and says, I want to learn to do what you do. I mean, I worked at the most technical company you can work at, right? And I’ve been in many interviews with other corporations where I’ve been turned down because I’m not technical enough, believe it or not. And I think it’s a trend and more companies are expecting SEOs not just to know your keywords that you’re targeting and how to target them and how to structure and whatever, but you really got to understand like the conversation with the engineer when the engineer says, oh, we can’t do that– which I’ve been told many times. And I know enough now to where I can say, actually, I know you can and if you can’t, then I’ll go ahead and write it for you. And that usually, I mean, that’s challenging a little bit rather than working with them. And a lot of times they go, oh, no, no, no, no, OK, I’ll take care of it, because they don’t want me writing in their code. 

MARTIN SPLITT: But yeah, you convinced me there. You actually– yeah, it makes sense now that you say it. Because at first I was like, hmm, but you don’t have to be that. But now, yeah. Yeah. You’re right. You’re absolutely right. Yeah, that makes sense. JENN MATHEWS:   I think what you’re saying with having that conversation and when the developer says, it’s a routing thing and the SEO says, oh, OK, and then it’s all done, right? Ask the question. So it’s OK you don’t learn, maybe you don’t know enough technical SEO now, but like you just said, have that conversation with the engineer. 

MARTIN SPLITT: Yeah. 

JENN MATHEWS:   Learn a little bit more. And then the next time you’re in that situation you may get to a point where you’ll be like, well, I’ll just do this for you if you’re not going to do it.

MARTIN SPLITT: And being vulnerable and saying, I don’t know, is A, relatable for engineers and B, it also makes you more trustworthy. 

JENN MATHEWS:  Yeah. 

MARTIN SPLITT: Because as developers, we have relatively good at finding out things or running experiments to test hypothesis. So if you present me with something that contradicts my intuition, I’ll run an experiment and I’ll find out you lied to me, and that’s definitely not a trust booster. Yeah. So why not do this learning together? As you say, test and learn. I love that so much. I think that’s one of the key phrases in our conversation today, was test and learn.

JENN MATHEWS:  Always test and learn. 

MARTIN SPLITT: This is beautifully simple and yet, rarely done.

JENN MATHEWS:  Yeah. 

JENN MATHEWS: Yeah. I mean, it’s the Github culture, which is why I love being here. I mean, we’re a culture of engineers at the heart of it. And everything we do, it’s just break things. Just push it out and if it doesn’t work, it doesn’t work. Go on and do the next thing, you know? Nobody makes mistakes because we’re all just learning, right? So I think other companies should adopt that culture. And I think what you said earlier, too, engineers are in this– it’s the culture and a lot of time organizations kind of put engineers on the spot to where they can’t feel that they can work with SEOs, and so yeah. 

MARTIN SPLITT: Breaking that barrier is the thing that both sides have to do and have to want, I guess. 

JENN MATHEWS: Yeah, for sure. 

MARTIN SPLITT: But we share so much. We share this culture of test and learn. We share the fact that we are working in things that we don’t necessarily always know every single detail about. So why not work together? 

JENN MATHEWS: Yeah. Well, we live in a world now where the engineering process is so much faster, too. I mean, with Github and development operations working in an automated way, right? I mean, Google now pumps out updates, what? Every minute? 

MARTIN SPLITT: Often. Quite often. 

JENN MATHEWS: Yeah. Quite often. Where you guys in the past, Google would update– there’d be a big rollout when you’re doing waterfall, right? So we live in a world where things can happen very quickly and there’s no reason why. 

MARTIN SPLITT: Everything is a lot more agile, yeah.

JENN MATHEWS: Yeah, much more agile for sure. No pun intended. 

MARTIN SPLITT: But yeah, I think it makes sense to just. I think if I were to take some bits and pieces away from this conversation for the developer side of things.

Key takeaways 

(32:29) MARTIN SPLITT: Be OK with SEOs not knowing everything. Invite them in as much as they might invite you in to test and learn together-. And again, this phrase is just beautifully simple. And don’t get hung up on specifics or buzzwords. Just work together, test things out, try things out, and have this conversation. I think that’s the key, really. 

JENN MATHEWS: Yeah. Yeah, and I think what I learned is don’t just leave those engineers that aren’t interested alone. Try to have those conversations and try to get them invited in. And don’t just go to them and tell them what to do. I think, yeah, like I’ve already solved it, I already know what to do. But yeah, I mean, even if you already know what to do just go to them and say, hey, look, I’m seeing this thing. What do you think? I mean, this is what I’m thinking might be the solution. What do you think or what do you think the solution is, and see if they have the same answer. 

MARTIN SPLITT: It also allows the developers to learn themselves because next time you might not even have to go to them and tell them about it because they spot it in the development process. If they know like, oh, so that’s a problem, oh, that’s something that we need to avoid. Nice. And then they might actually factor that in the next time they build something like that. 

JENN MATHEWS: Yeah, I like that. 

MARTIN SPLITT: That’s a win-win- Me too. 

JENN MATHEWS:  I have four pillars and one of them is mitigation, and that’s the technical SEO is to get to a point where companies and the engineering teams are actually not releasing stuff without all those redirects or the 301’s, the 302’s, or the redirect chains. The code is– they’re actually looking for SEO fixes before they’re launching anything, and then you don’t even really have to do anything as an SEO, but yeah. 

MARTIN SPLITT: What are the other three pillars? So we have mitigation. 

JENN MATHEWS: Oh, gosh. Oh, I shouldn’t have brought it up. 

MARTIN SPLITT: You brought this upon yourself. 

JENN MATHEWS: I have to remember them now. Yeah. So mitigation is one and that’s the technical SEO. One is partnership, so relationships with others across the organization, and that includes engineering, of course. But it’s also, like I said, other teams. You’re under scrutiny, right? Another one is, oh, sorry. Another one is analytics. So always being able to measure everything you do. And I think that helps with a lot of the relationship building too. If you launch something, you should be able to say, what is my. 

MARTIN SPLITT: It was successful or not.

JENN MATHEWS: Yeah. Before you launch it, what do you think your impact’s going to be? And you can say it in ranking position or you can say it in a number of impressions or you can say it in more eyes on the page or click through rate, however it is. But you should always be able to measure it and know what it is before you launch, and then also be able to report on what it was afterwards. And then the last one is product management sort of, so launching projects. As SEOs we get lumped in this constantly working with other teams to support them, but there’s also a place where we could actually build our own content. So we could work with content teams and we can build pages. I always end up, or companies always end up calling my pages SEO pages. Groupon has them. 

MARTIN SPLITT: If it works, it works. 

JENN MATHEWS: Nordstrom has them. Yeah, everybody has them.

MARTIN SPLITT: If it works, it works. And I think I remember them as marketing pages, but in reality oftentimes they were SEO pages.

JENN MATHEWS: Yeah, they’re just SEO pages. Which I kind of, it’s got a stigma to it, because I don’t want organizations thinking that we’re creating pages just for SEO. We’re actually creating pages for the users at the end of the day or otherwise they won’t show up, right? 

MARTIN SPLITT: Yeah, that’s true. Really nice. 

JENN MATHEWS: If the org wants to call them that, that’s fine, but they’re user pages as far as I’m concerned. 

MARTIN SPLITT: Fair enough. Fair enough. 

Wrap up

(36:36) MARTIN SPLITT: But thanks a lot for sharing the four pillars. That was awesome. 

JENN MATHEWS: Yeah. Yeah. MARTIN SPLITT: Oh my God. I learned so much today and it was fun too. Thank you so, so much for joining and thanks a lot for the conversation. This was awesome. I hope that you enjoyed it as much as I did.

JENN MATHEWS: Yes, I did. Yeah, I think I learned a lot too. I have some takeaways and I’m going to go talk to those engineers I don’t usually talk to.

MARTIN SPLITT: That’s amazing. OK. In that case, I do hope that our audience enjoyed it as much and took away some bits and pieces too. And yeah, thanks a lot and thanks for watching and hope to see you all, including you Jenn, soon again, hopefully in person in some conferences somewhere– and maybe, who knows, with wild hair again. 

JENN MATHEWS: Yeah, we might have to

MARTIN SPLITT: You never know. Yeah. All right. Thanks a lot. Have a great time and bye bye.JENN MATHEWS:  Bye. Thanks, Martin.

Sign up for SEO & Web Developers today!

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!