Month: March 2023

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!