Author: LION Digital

Introduction

(0:00) MARTIN SPLITT: Don’t developers want people to use what they build? 

MONICA LENT: How do you prove your worth as an SEO? 

MARTIN SPLITT: How would you measure your work’s impact? 

MONICA LENT: Why don’t SEOs listen to developers?

MARTIN SPLITT: Hello, and welcome to another episode of “SEOs and Developers”. With me today is Monica Lent, who is a developer-turned-entrepreneur building her own software-as-a-service product, and she’s a seasoned blogger too. 

MONICA LENT: All right, and I’m here with Martin, who is a developer advocate at Google Search and a passionate underwater photographer. 

MARTIN SPLITT: Monica, I’m super, super happy to have you here as my guest today. We met at a developer conference, I think in Austria the first time when I remember correctly, back in the days when conferences were an actual thing. And I remember we talked about so many different stuff like technical topics, but also we talked a little bit about SEO because you started building your own product. And as a developer turning into product management and building a product, that must have been a super interesting challenge. And I’m guessing one of the challenges was also to pick up SEO and digital marketing skills, hasn’t it?

Build your website and they will come?

(01:19) MONICA LENT: Yeah, totally. I mean, when I started building the product, like a lot of developers, I started with the code. And figuring out where to get customers was, I wouldn’t say a secondary thought, but it was not something I realized was going to be as hard as it actually was. So SEO definitely played into getting customers and building the kind of pipeline that we have today, but it took so much longer than I was expecting.

MARTIN SPLITT: I got to say I’m not super surprised, but I have been exactly that way until relatively recently. Coming from a developer background, you’re like, oh, you just got to get all your technical ducks lined up in a row, and you’ll be fine, right? But yeah, it turns out to be a little trickier than that. So this makes you the perfect interview candidate for the series where I try to bridge the gap between the SEO world and the developer world. And you know there is this weird chasm that we somehow need to build a bridge over, and I would love to hear your perspective on these things. Like what has been the biggest cliff that you fell off when it came to SEO? What has been a thing that you needed to learn and explore to get there? What did you find hard coming from a developer’s perspective into the SEO world?MONICA LENT: Yeah, I think one of the most challenging things, especially for developers who are just getting started with SEO, is there is a lot of theory, misinformation. It’s really hard to separate the stuff that’s proven and the facts from one-off observations and anecdotes. And as a developer, when you’re used to working in code and concrete facts, things that either work or don’t, coming into the world of SEO, it feels like you don’t have those kind of more scientific tools or more fact-based tools that you can use to know for certain, if I do A, B, and C, this page is definitely going to rank. So you’re in this kind of nebulous space. And I think coming from the developer perspective, it’s almost disarming or it feels unnatural because you’re just not used to having so many variables at play which you can’t control and can’t even directly observe.

When reality and expectations aren’t the same

(03:47) MARTIN SPLITT: That’s true. That is true. But then again, sometimes in development you do have this, like, uncertainty, too, especially, when you are charting uncharted territory. And I know what you mean because I as a developer used to be very comfortable in this world of API documentation that you just happen to follow, and then the right things happen. But I don’t know what APIs you have implemented or integrated in your developer life. But oftentimes you have the same problem as developers because the API documentation says one thing, and then you try that, and it doesn’t work. And it turns out you actually need to do something slightly different to actually make the API work the way that you expected it to work. So it’s similar to SEO, I think, because oftentimes as you say, there’s a lot of lore, a lot of anecdotal evidence out there, and it’s missing bits and pieces. And it’s also mixed with misinformation– downright misinformation, unfortunately. Yeah.

Navigating the murky waters of SEO as a developer

(04:53) MARTIN SPLITT: I see that that’s a tricky one. How did you navigate that uncertainty?

MONICA LENT: I think ultimately I had to rely on my own experience and observation, which unfortunately is the very slow path. So if you’re not just taking courses or listening to what other people say, and you’re kind of putting it into practice and you have to find out what’s true for the topic that you’re covering– what’s the space like, what’s the competition like– all of those things are quite different in different spaces. So at the end of the day, even though when I talk to some people, they may say, oh, I don’t really believe that that made a difference. But it’s hard to take that at face value when you say, look, I made just this one change and saw that impact. So at the end of the day, it was a lot of trial and error and doing it for a very long time. And luckily, before starting to build my product, as you mentioned before, I ran a blog. And so that was kind of like baby steps, I would say, towards understanding how to get search traffic. But it changed quite a bit going from writing content for informational blog posts versus trying to get people to become customers. And yeah, there are just so many facets to figure out along the way. 

MARTIN SPLITT: Yeah, it is not easy, and it’s a hard thing. And I do hope that you did find and will find companions in the digital marketing space who are experienced enough to actually be able to kick start this kind of journey or accelerate this kind of journey thanks to their experience. But I see that this is tricky because as you say, it’s different for every niche. And finding an expert who is holistic enough and practical enough in the niche that you’re in is not necessarily easy, right? That’s a bit of a tricky thing.

Communities help you learn SEO

(06:53) MARTIN SPLITT: So did any resources pop up on your journey where you’re like, oh, that was definitely helpful? 

MONICA LENT: I ended up learning a lot from being in different SEO communities, so lots and lots of Facebook groups. And what I found most valuable about that is that instead of things like courses or blog posts where it’s really one person saying, this is the facts on the ground, this is my observations, you always had room for other people to contradict the advice or to offer different perspectives. So no matter what you’re learning about or what question you have, in SEO you can get directly contradictory advice from two different people who swear that it’s true. But at the very least, you’re exposed to all of those different options, and you can kind of reason through it yourself. So I think that’s something that has been really helpful, is being in these SEO communities as opposed to only consuming unidirectional course material. But it is a much less organized way to learn as opposed to doing a straight-up course or something like that.

MARTIN SPLITT: Yeah. But I think that’s very important. That’s a very, very important point because it is such a wide field, and you can look at it from so many different perspectives and focus on so many different aspects. You might not necessarily get singular truth or singular advice in the right direction. And if you’re being honest here, the same is true for development courses or tutorials. If you read a tutorial on whatever framework is the framework of choice today in the front-end world, they’ll be like, oh, yeah, you can use this other framework, but, you know, it sucks. And it’s going to be terrible, and it’s going to ruin everything, and you’re going to have spaghetti code. And look at our beautiful code here. And then that kind of keeps rolling and changing all the time as well. So I think seeking out experience from as many perspectives as possible is a good idea. That’s not a bad idea.

Telling the good and bad apart

(09:04) MARTIN SPLITT: How did you then evaluate what worked and what didn’t? I mean, you said you experimented, and you made a change, and you watched the impact.How did you do that? What kind of tools did you use? Where did you find out if your changes had a positive effect or had no effect at all or a negative one? 

MONICA LENT: Yeah, to be honest, I wouldn’t necessarily say I have a super scientific process. There are definitely people who are running in-depth SEO experiments, single-variable testing, and so forth. But pretty much what I did is I know that when you publish something or create something, it takes time to rank. So at that point, you just have to kind of keep going and trust. Trust somehow that if you create something that is really good, one day the algorithm will be good enough to reward that. Doesn’t always happen off the bat, but that’s like, something I at least– I strive for or hope for. That if I know what I create is better than anything else out there, eventually– eventually, it will be rewarded as such, and sometimes that takes a long time. But as I learned, what I really did is I would go back through the entire corpus of content that I had written or published and regularly refresh it with the new lessons that I had learned, whether that’s making my title tags better. Hopefully, Google would use my new title tags. Or maybe it’s changing the structure, making the article more complete. Or even the opposite, taking out sections that were maybe not fitting the search intent so well and could be split out into their own articles, and just kind of doing this iteratively. And I could see that content that had previously never ranked at all would eventually start to rank once it fit into those patterns that I had learned. So any time I had a piece of content that did really well, especially really quickly, I would just say, OK, what’s different about this compared to all the other stuff that I have? And try to take those lessons and apply it to old content because it’s so much more efficient than just only publishing stuff that’s new. And yeah, it’s not so scientific, but observations, using, for example, Google Search Console– I am in there every single day. And being able to see, OK, something is starting to pick up impression. Something is starting to pick up clicks. Or what are the terms that this is getting impressions for but I’m not really mentioning in the content? What does that mean? Do I need to include it? Or does it mean that I’m showing up for stuff that’s kind of irrelevant? And maybe I need to hone in the messaging so that I get shown for the terms I really want people to find me with. So all of those were things that I use to take a library or backlog of content and iteratively upgrade it as I learned SEO slowly but surely in practice.

What devs can learn from SEOs

(12:18) MARTIN SPLITT: It sounds like a really, really interesting journey that you have been on coming from a developer’s background, looking more into the SEO bits and pieces. If you think back at the developers who are still working as part of a larger team and working in-house in a product company or in an agency, would you say that you as a developer benefited from this journey despite maybe not having your own product to build with? If you were part of a larger team of developers, would you benefit from this knowledge that you gathered now? 

MONICA LENT: I think so. I mean, the thing about SEO which I feel a lot of developers maybe get distanced from is just the business impact of your work. Because you can really see how certain kinds of rankings or showing up for certain terms means that you’re having a really direct impact on the bottom line of the business. And ultimately, the type of content that brings in customers has a specific search intent. It communicates specific information that draws in the target customer. You present a solution, and so forth. So kind of understanding how the product that you’re spending so much time laboring over actually gets discovered by people I think is really rewarding. Because especially with my background is a front-end developer as my technical focus, the thing that drives me and people who work in similar fields to me is getting something I’ve created in the hands of users, right? And SEO is one of the key ways that people can actually discover the thing that I’m creating. And I think a lot of times engineering teams end up being distanced from marketing because it’s seen like we’re building the product, you find the people. And at the end of the day, it doesn’t quite work that way unless there is this seamless journey from discovery to activation and so forth. And yeah, I think SEO’s a very valuable skill for developers to learn, and I am trying to get as many people interested in it and picking up the basics, at the very least, because it’s just such a valuable skill when it comes to getting people to actually use the stuff that you’re building.

Why discovery matters for devs, too

(14:55)  MARTIN SPLITT: Absolutely. And I never quite understood that because in the end, I’m building my product. The code I write is for people to do something, to accomplish something that they couldn’t accomplish or couldn’t accomplish as nicely without my code being out there. And I wonder, people to this day still think like, oh, I just build it and they’ll come, but that’s not true. If you just put a website online and do nothing else, no one will come. No one will find it. You have to make sure that you can actually be found. And how do people discover new content online? Intuitively, that’s through a search engine. You just search for something. 

MONICA LENT: It’s true. I think at the same time, a lot of people may rely on these kind of one-off channels. So while let’s say I launch on Product Hunt or I launch on Hacker News or something like that– and you can get an incredible wave of traffic, lots of people talking about you. But at the same time, that’s not as important as having the same number of people visiting your site every month or having some kind of consistent flow.

Web Dev and SEO – two parallel universes

(16:12) MONICA LENT: Yeah. It’s funny because as a front-end developer– and I’m sure you’ve seen this, as well– you learn so much about how websites work. But the kinds of technical aspects of a website that you learn when you are doing SEO is actually quite a bit different than what you learn when you’re making a typical website, going through a web development course or boot camp, or learning to build front-end apps. It’s like a completely different side of web development. And so you can talk to someone who is 10 years in the web development field, and they might still say, I don’t really know what a canonical URL is for. And that doesn’t mean that they are bad at their job. It’s just there is this entire parallel aspect to web development that you don’t necessarily learn when you’re learning to build apps or a typical website.

MARTIN SPLITT: It just happens to not be part of the learning path. Most tutorials are like, OK, we put in a title because you kind of need to put in a title, but we don’t touch it. It’s just like, demo app, here we go. That’s our title. “Hello, world” is our title. Done. Meta description? No, ignore that. Meta viewport? Maybe, because mobile is actually a thing these days, so fine, we’ll put in the meta viewport. Canonical URL? We don’t need that. None of this actually matters. None of this– the tooling is all there. It’s just you need to know that you need to use it because it’s not part of the learning path. So it keeps blowing my mind. 

MONICA LENT: Yeah, totally. I don’t know. What do you think is the solution to that? MARTIN SPLITT: I don’t know. I’m trying to do a little bit of developer education there. So we did create a JavaScript SEO video series on our YouTube channel, the same channel that you’re probably watching this on. Javascript SEO series → https://goo.gle/3oxYY0e. And I explained the basics there because there are a lot of people who are using frameworks like Angular or Vue.js or React, and they’ve never even thought about it. And then they encounter these weird moments where an SEO pops in and goes like, are we using JavaScript? And then the developers go, duh, yeah. Of course we are using JavaScript. And they’re like, oh my god, if we’re using JavaScript, we can never be found in Google Search. This is a huge problem. We need to switch away from JavaScript. How can we do that? And then they’re like, I mean, I guess server-side rendering maybe, but that’s like, a lot of work. And they’re like, oh, but we have to do this. It’s very important, which is not exactly true. And there’s an education challenge on both sides because on one hand, what this SEO has said has been absolutely true, let’s say, like, five to 10 years ago, but it’s no longer true in today’s world. And the developer not even being prepared for something like this and not knowing where this is coming from or why this is a problem or how to solve this problem or how to even just come back with an informed decision-making is not necessarily a thing that happens in a lot of teams. And so I’m trying to do that with documentation and education, trying to go where developers are, to developer conferences, talk about SEO.

SEO – all smoke and mirrors?

(19:28) MARTIN SPLITT: But oftentimes, as you say, developers are like, SEO is this hand-wavy, black magic thing that I absolutely don’t care about. I care about technical things and technical decisions and technical, interesting stories. And it’s tricky. But I hope that videos like this maybe help to shed a different light on SEO and shed a different light on development as well.

MONICA LENT: Yeah, definitely. And I think there’s also this aspect where a lot of times, developers may not realize that a lot of SEO, or getting it right, also has to do with technical setup. And when I talk to developers about SEO, this is actually the part that they find most interesting. They love the tools. They love the analytics. They love, basically, how can you get a perfect score? Or how can you make sure it’s all dialed in correctly?

How to make SEO appealing to devs

(20:33) MONICA LENT: And so there are aspects that really appeal to developers about SEO. The trouble is most of them don’t realize that that’s even out there. But at the same time, they can have a really big impact by fixing a lot of these problems that tend to pile up over the years, especially when nobody’s been paying attention to it. It’s like the entropy of a website. If you don’t look at it– it’s like CSS. CSS will naturally decay. That’s my opinion. 

MARTIN SPLITT: It’s true, yeah. 

MONICA LENT: And in some ways, the “SEO,” quote unquote, or at least the technical aspects of SEO, they often also tend to do that because unless somebody took the time to explain to the developers, this is why we’re doing that, it will be forgotten. And they’ll be like, oh, I didn’t know that was important. We upgraded our framework and didn’t include that plugin that was generating the sitemap. Or we changed our styling system, and we decided to update all the headings so that they looked right, but now they are no longer ordered as you used to expect them. And these are examples of things that have happened to me when working in a tech company with an in-house SEO. And yeah, it just repeats itself that if you don’t explain the why, developers don’t want to do anything unless you can tell them why. That is in our nature. Because is not enough. 

MARTIN SPLITT: And it’s wild because both SEO and development are such broad fields.

Finding the right niches

(22:23) MARTIN SPLITT: You might have someone who focuses explicitly on back-end development. They might not touch the front-end side of things, and that’s perfectly fine. And it’s the same way with SEO. People are like, oh, there’s this SEO that talks about content and content strategy, and I’m not interested, so I’m not interested in SEO. But that’s ignoring that there’s also the technical SEO people, who are as nerdy, as geeky, as us developers are. And they’re like, oh, I’m really excited. I want to try to figure out how we can pre-render our shadow DOM in a puppeteer instance. Which is something where developers are perking up their ears and going like, that sounds like an interesting thing. How do you do this? Can’t you just serialize the DOM? And it’s like, no, because the shadow DOM is hidden behind the shadow DOM border. And that’s an SEO concern some search engines– not necessarily Google Search, but other search engines– might struggle with. So you might need to find a technical solution to overcome this challenge. And there are so many technical aspects. And as you say, if no one cares about them specifically, your SEO might accidentally not care about them or don’t know about them because they might not be in this specific niche of SEO where they are looking at the technical things. They might just use a tool that gives them a report, and depending on how good the tool is, you might get a complete or non-complete report. And the incomplete report might actually give misleading information, too, because it might just be the wrong tool for the job. And the problem there is that developers then tend to just downright dismiss everything that comes from the SEO department or from the SEO side of things instead of going like, oh, right. Let’s sit down and talk about our requirements from the technical side so that you can figure out what the requirements are or how we can fulfill the SEO requirements with this technical setup that we have. There are very, very few people out there that actually do this, and I would wish that developers would also look into this and pick it up. And I spoke with Bartosz. I spoke with Mike on previous episodes of this series. They are one of or part of this group of people, and it’s amazing to see how they work. And it’s unfortunate that from the developer side, there doesn’t seem to be much picking up on the SEO tasks. As you say, SEO naturally decays if you don’t pay attention, so yeah.

Sharing goals and wins

(24:55) MARTIN SPLITT: I don’t know how to make this more visible to developers or how to motivate developers more to look into these things. Any ideas? 

MONICA LENT: It’s tough, I think, because especially depending on the size of the company that you’re at, it’s really hard to see sometimes how your individual efforts move the needle. And that’s not what motivates developers. So I think on the one hand, if there was a way that you could actually show reports to people and say, all right, so we spent this time working on the technical SEO of our site, and there is a tangible increase in the organic traffic, that’s something that you can feel pretty good about. But on the other hand, a lot of times those improvements might be slow to show up. It’s also really hard to attribute changes in rankings, in traffic, to one specific change on your website. It’s really difficult unless you have a lot of patience and you’re just going to change only one thing for potentially weeks or months or however long it takes. It’s not really practical in some ways to just say, OK, we’re going to make this one improvement and not touch the entire site. So it’s always a bit of a mix. But I think getting developers to the point where they can see the impact and just actually explaining to them why it matters.

Explain the why

(26:35) MONICA LENT: Another thing that I think we’ve talked about before in some of our conversations is accessibility. So a lot of times it’s not so easy to convince the developer. Let’s say, oh, we want to do this for SEO reasons only. So usually when did you come to a developer and you say, we want to improve the SEO, and that’s why we’re doing this, this is a nonstarter, right? Because they’re like, well, I don’t want to make things for machines. I want to make things for users. Or in the case of accessibility, I want to make these things accessible to more people. So I think appealing to users as the reason you’re doing something as opposed to just search is a more pragmatic way to motivate people to get interested. Because at the end of the day, that’s what your focus should be on as somebody who is improving the SEO of your site. It should ultimately come down to users, although we all know that there are aspects that you have to do sometimes to appease the machine a bit. But that’s also just the way computers work. They’re not mind readers. So I think it’s that kind of balance of explaining the why, like, this is how Google discovers, indexes content, serves it, and ranks it. And then on the other hand, this is the impact it’s having on users. Here’s how we can make stuff work better for both search engines and users at the same time, make it more accessible, easier to understand. Cleaner DOM, more performant, all of those interests are actually aligned between SEO practitioners and developers. It just doesn’t usually get discussed. And I think part of that also comes down to the fact that both devs and SEOs struggle sometimes to get prioritization for these tasks so at the end of the day, you’re more hot-fixing stuff than you are working on strategic things together, and that’s a challenge too.

MARTIN SPLITT: True. It’s also that the departments are usually like, there’s an engineering organization, and then there’s the business or marketing organization. And bridging the gap, working proactively together, is not always easy on an organizational level. So that’s also probably hindering these kind of conversations and collaborations to happen. And yeah, interesting.

The search engines’ perspective

(29:10) MARTIN SPLITT: I just realized I remember the way that I usually try to get developers hooked is also to just have them think about building their own search engine. What would websites have to do to be friendly to these? And what kind of optimizations would you do as a search engine, where developers might choose a path that these optimizations cause problems. And that also sometimes works trying to figure out, turning it around and going, OK, so now you’re solving the engineering problem here on this side, on the website-creator’s side, but what would you be working on if you were on the engineering side of the search engine? And then things like accessibility and having properly ordered your headings and having a meta description, having links being actual links with URLs to point to so that you can crawl them. It becomes an obvious choice, which it is not when you don’t think of the other side. So that’s my approach to this. And I like your approach of saying here’s what you need to do and what needs to be happening for the bot to be able to consume your content, and this is the impact it’s having. I think I was missing the impact component a bit, so that’s really interesting. That’s really interesting. And you say measuring impact on ranking is so hard, and yeah, naturally, because the ranking also depends on what other people are doing. So it never is single-variable testing, right? 

MONICA LENT: Yeah. I mean, you can try to make a test, and then Google decides, well, it’s Christmas. Let’s have a code update.

The bittersweet core updates

(30:50) MONICA LENT: OK, I’m a little bit bitter because we’ve had a lot of updates this summer. But you can try to change something. And this has happened to myself. It’s happened to friends. Don’t mean to call you out, but you make some changes, and then it’s like, well, now there’s an update or whatever it is. And you’re like, well, anything that I was trying to test is now suddenly even less stable in terms of being able to give me some reliable learnings. So yeah, there are just so many factors that at the end of the day, I don’t obsess over it that much. I just try to keep making it better, keep iterating on old content until it ranks number 1, and I stop touching it out of fear, usually. Usually. Sometimes I have to, to make sure it’s still accurate. But I don’t know. I think at the end of the day, it’s a fluid situation and you have to treat it as such.

MARTIN SPLITT: Yeah. It’s exactly that. Focus on building the actual product and doing the right thing for the user, and as you say, eventually search engines usually reward good things. It just might take a while. And yeah, core updates are an unfortunate reality, but they are important to make sure that we keep adapting as the web keeps adapting. And to improve our search results, we need to change things around, which unfortunately collides with everyone trying things out and testing sometimes. But that’s just an inherent feature of the reality there. Cool, awesome.

Wrap up

(32:39) MARTIN SPLITT: So yeah, in that case, I am very, very grateful for the conversation, and also happy to see developers crossing into the SEO sphere. And yeah, it was great talking to you. Thanks a lot for your time. And thanks to everyone watching this. I hope you enjoyed it and learned something as well. And yeah, stay tuned for more episodes. And again, thanks a lot, Monica, for being here with me, and all the best for your product. And keep blogging. I really like the blog. 

MONICA LENT: Thanks, Martin. Really appreciate you having me. Yeah.

Sign up for SEO & Web Developers today!

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!