Author: LION Digital

Positioning SEO As An Opportunity, Not A Challenge

(1:12) MARTIN SPLITT: What is SEO? Oftentimes SEOs barge in to the development team and they’re like, “oh my god, we need to like figure out our canonicals and there’s this other problem here with duplicate content, we’re gonna get a penalty”, and oftentimes they are met with a blank gaze from the people they just spoke to.

“What’s happening there?”, “Why are we are working on the same thing?”, we are all working on the same projects together and yet we seem to be so very very different in terms of the vocabulary we use.  What’s happening there?

CRYSTAL CARTER: I think, I absolutely agree. This is something that I’ve seen a number of times and I think that one of the things that’s tricky is that we’re sort of coming at it from different perspectives.

Sometimes if you think about it, it’s a bit like a band. Like if you have a band, you have your bass player, you have your guitar player, you have your drummer and you’re all trying to make a beautiful song. But the bass player has different things that they need to do, the drummer has different things that they need to do and sometimes they overlap, sometimes they intersect, but really what we all need to focus on is making sure that we’re making beautiful music together.

And so, I think that, yeah, it can be tricky, and I think sometimes it’s because people who’ve built the website, the developers behind the website, they’re very often like they spend a lot of time and effort putting that together. So, it’s quite tricky when someone comes in and says, “oh, it’s broken”, “oh, it’s wrong”, or it doesn’t work.

And I think that it’s really important to think about that when you’re speaking to developers as an SEO. And one thing that I found that’s really useful is to think about it as opportunities.

So rather than saying, “this is broken or this is wrong”, say “we have an opportunity to make the website faster if we do X, Y, or Z”, “we have the opportunity to make the website easier for users to access in a different way if we do this, that, or the other“, and I find that generally speaking, if you go to it from that perspective, then it can sort of make those conversations a bit less brutal.

Sometimes if you think about it, it’s a bit like a band. Like if you have a band, you have your bass player, you have your guitar player, you have your drummer and you’re all trying to make a beautiful song. But the bass player has different things that they need to do, the drummer has different things that they need to do and sometimes they overlap, sometimes they intersect, but really what we all need to focus on is making sure that we’re making beautiful music together.

And so, I think that, yeah, it can be tricky, and I think sometimes it’s because people who’ve built the website, the developers behind the website, they’re very often like they spend a lot of time and effort putting that together. So, it’s quite tricky when someone comes in and says, “oh, it’s broken”, “oh, it’s wrong”, or it doesn’t work.

MARTIN SPLITT: Oh, I love that. I love framing it as opportunities and possibilities to make things better because fundamentally that’s what developers want to do in the first place anyway.

So that’s really, really cool. I like it better than framing it as a problem or like a thing that needs, is broken or needs fixing. Because to be honest, it’s also that developers are not even necessarily aware of these things.  It seems to be like you are preaching from the holy book that is written in a language that isn’t ours and it comes out of nowhere and out of the blue, right?

One day you’re just implementing this feature and you’re making sure it works in all browsers, works on all devices, is fast and then out of the blue someone is like, “it’s broken”. So, I like changing that into here’s an opportunity to make it even better.

The Importance of Testing And User Data For Both Web Dev & SEO

(04:18) MARTIN SPLITT: I do read up constantly on new technologies, on new things that browsers can do, on new trends and design, but I don’t really even know where to get started on SEO. And I think one of the things that us developers need to do more is get out of our little bubble of development and actually look at SEO as at least at the technical side of SEO, as something that is just part of what we deal with. Not necessarily it’s not part of our job to do this, but like we should know about it, I think.

CRYSTAL CARTER: Yeah, I think so and I think Google’s really good at trying to bridge the gap between those spaces and trying to make it more clear for people to understand how that works.

I think one of the things that’s really useful, when you’re thinking about developing an SEO and understanding SEO as a developer, is remembering that with SEO.

We’re essentially taking the technology that a developer has built and we are interacting with it in the real world. Users are using it in lots of different ways and the ways that users are using the site, the ways that users are interacting with the site, are going to be very different from, you know, there’ll be millions, billions of possibilities for ways that people can access the site, ways that people will search for the site, ways for people that people will use the site, from what we are able to test in a sort of test development framework.

And so essentially, as soon as we build a site, they always say, “we built the site can somebody run it through a few tests”, and I always run it through a few calls and there’s always a few things that we pick up because the SEO is essentially thinking about, you know, it’s search engine optimisation.

Which means that you are thinking about how people search for and arrive at the site and how people interact with the information on the site and how people use the site. So, SEOs will have lots of user data based on that site itself.

Let’s say you’re rebuilding a new site. We’ll have lots of historic user data about how people use the site, and then there’ll also be general sort of industry user data. So, it might be that, you know, you’ve built a lovely shopping framework, but we also know that within the shopping, the eCommerce space, that users have an expectation of being able to see this and be able to pay in this way and being able to sort of have a cart that’s really clickable and that sort of thing.

So, I think that, you know, development is a really tricky job because there’s a million different ways that you could build a website. Like there’s a million different ways that you can build an app, that the possibilities are endless.

I think developers can speak to SEOs and ask for more user data to help them build ahead of time. And I think that using some of the, like Google, has a lot of tools that are over cross development tools I use all the time.

It’s tricky to expect one developer or even one developer team to know every single possibility, possible way you could build a website. But when people are using the site, that’s where SEO and development can interact and I think that developers can speak to SEOs and ask them for data about, you know, “what are the sort of customer expectations for this type of website?” or “how fast should it be?”

So, for instance, eCommerce sites tend to be a little bit slower than other websites, and that’s because they’ve got lots of different tracking things on them. It’s all sort of, it’s all relative. We want to make sure that we’re meeting user expectations.

When I’m speaking to developers and, you know, just things like view source can be really, really useful in Chrome and that sort of helps bridge the gap between the two, and I think that where there’s the willing to understand the two different parts of both how users are interacting with it and how businesses need a website to work and how it’s built in the framework and that sort of thing that there’s opportunities for growth and opportunities to make the web better for everyone.

MARTIN SPLITT: Yeah. And you said two things that I want to address with you now. Let’s start with, so the one thing that you said is you run a bunch of tests and there’s a bunch of tools that developers can use and then the other thing is like, there’s a bunch of different solutions. And I think those are two very interesting aspects.

Let’s start with the tests. Because you said like, once a website is done, I run a bunch of tests, that’s what we as developers do while we are building it. So, we have a bunch of tools that we are running to figure out bits and pieces, like “how fast is this website?”, “where our problem’s coming from?”, “is it behaving the way that we expect it to behave?” – and we actually write tests. We write test cases such as “if I click on this button and then, I should see this thing”, “If I type something into this thing and then I click this button, something should happen” – So, like we are having a bunch of tests.

Tools To Help SEOs & DEVs Work Together

(9:40) MARTIN SPLITT: I wouldn’t even know what tools or tests to use for SEO. Because for pretty much most of the things, I can run a browser, basically remote controlled by code, so I can click on buttons and fill in form fields and then see what happens. But what would I be looking for for SEO? I actually don’t know, and I don’t know where to find out or what tools are available to me. I know Lighthouse has an SEO audit, but that seems very, very basic.

So, what would you say is something that developers should look into to support their SEO teams?  What are technical aspects that developers should be aware of? Or where would they find out how? Or what would they have to? I don’t even know what to ask an SEO.

CRYSTAL CARTER: I would say that normally what happens when we launch a new site is I’ll crawl it with something like ScreamingFrog, which will give you information about crawl errors and then the other thing is things like Search Console. Search Console gives you lots of information about the way that Google is seeing it. Because different search engines will have different ways that they read websites, different bots will have different ways that they read websites.

Search Console gives you lots of information about the way Google sees it, and it can also give you information about how different users are seeing it. So, a page experience report, for instance, is based on real user information.

So, it might be that within your test framework that everything looks perfectly fine, everything’s lovely. But it’s sometimes like if you’ve ever written something and then you try to proofread it yourself, sometimes you don’t see your own writing. Things because you’ve spent so much time writing. Whereas if somebody else reads it, they’ll go, well, you’ve missed a full stop, or you haven’t said and there, or that sort of thing. Because they’ve got sort of fresh eyes.

The other thing is that as a developer, you’re looking at it from a developer’s perspective and you’re fairly tech savvy. Whereas users are going to be coming at it from lots of different perspectives. So, I think it’s really important to look at it with the way that it’s rendering on different browsers, the way that it’s rendering on different machines, the way that it’s rendering on different mobiles, and devices as well.

Tools like Search Console give you user data, how people are using it. And once a new website is live, I think it’s really important to think about what to expect to make further changes and potentially expect to make further changes even six months down the line. Because you’ll have more data based on it. I think data is really important, particularly for businesses that are seasonal or businesses that have sort of peaks.

So, the way I think about that sometimes is like, if you were to do data on a tree, like on an oak tree, for instance, and you took all your data from between May and June, all your data would tell you that trees are green, oak trees are green, they have green leaves and they’re great. But if you do it for the whole year, then you learn that sometimes they fall, all the leaves fall off, and sometimes there’s none, no, sometimes the leaves aren’t green at all. So, the more data you have, the better you can prepare and if you had the full data on the full year, then you’d know that we’d also need to buy a rake to go with the tree.

MARTIN SPLITT: I love that image, that’s a beautiful picture you’re painting. That is awesome. It’s really nice that you mentioned Google Search Console because I remember as a developer, again, coming from a developer background, the very first time I came into contact with it was when it was still called Webmaster Tools, if I remember correctly, and I was at the same, this is gonna sound really weird, at the same time I was overwhelmed and underwhelmed. And it was bizarre because I didn’t even know where to look. But I think that’s exactly one of these interfacing moments between SEOs and developers, because if you come to this tool and you see like performance, impressions, clicks, what’s happening, then it might be a lot to take in at first.

But I think this is exactly where SEOs can guide the developers or even just provide the data that they need for a specific conversation to underline that specific conversation. And I think this is what needs to happen.

I remember working with one specific SEO a long time back and she guided me through a bunch of the decision-making processes that I didn’t even know existed and that was very, very helpful. And I think data collection, as you say, like if you look at the trees only in the summer months, you might be very, very scared to see all the leaves fall off because trees are supposed to have leaves all the time.

CRYSTAL CARTER: I think that the overwhelmed and underwhelmed thing is something that I’ve encountered sometimes. Sometimes when SEOs go to a Dev, they say, “right, we want to make all of the title tags do this and this and that and that” and they go, “well, that only took me a minute to implement”, Why is that really important?”, “Does that really matter?”, and it’s like from an SEO perspective, it’s like, “yeah, that makes a big deal or that can make a big difference.”

I’ve spoken to developers, and I’ve been like, “I need you to add this particular bit of schema markup” and they’re like, “well, I just copied and pasted it”, and I’m like, “well, you know, that’s fine. That’s great. I’m glad that it didn’t take you long to implement”, but it does have a big impact on things like how Google crawls it and things.

So, something that’s super simple that a lot of developers miss and then something that I always check every time there’s a new, we launch a new website is the sitemap. Like literally putting a sitemap on the website.

Sometimes I explain it to people, like, you know, if I went to a restaurant and I said, what’s on the menu? If they give me a menu, then I can figure out what’s on the menu. Or if I don’t have a sitemap, then it’s like just going to the restaurant and then just being like, “have a look around and you just see what other people are eating”, which is essentially what you’re asking Google to do. You’re asking them to guess whether or not there’s a Caesar salad on the menu. And like, they’ll probably figure it out. Google’s very sophisticated but it’s better if you give them a menu.

MARTIN SPLITT: I like that. Yeah. Again, beautiful analogy. That’s, that’s lovely.

Tools for Testing Sites During Development

(16:27) MARTIN SPLITT: But going to the testing and the tooling, you mentioned a few tools and you mentioned Search Console. Search Console, the bigger challenge is that I as a developer can only use it once the site has gone live and Google has had a look at it.

Can I use things like crawlers? Which one did you mention? ScreamingFrog, and all the others. Can I use those in development as well? Like before the site goes public?

CRYSTAL CARTER: Yeah. So, in a staging setting, you can use ScreamingFrog to sort of understand if you’ve got, if you’ve got gaps with like, with page structure things.

So, for instance, H1s are super important. I think people very often underestimate that. That’s another one that I very often see. So, people very often don’t put an H1 on the homepage and I’m like, that is an easy win. Like please put an H1 on your homepage.

You can use ScreamingFrog to see a lot of different things. There are many, many, many, many, many different layers and many different configurations of your ScreamingFrog setup. So, you can see a lot of the structural things like headings and title tags and meta descriptions and URL structure. And you can see all of those sorts of things.

So then, and then you can also see like the navigation and various other elements. And ScreamingFrog is really useful with helping sort of understanding how that, like the crawled up through different pages. And this goes back to indexation, which is about your website in the real world. So again, another metaphor, I speak in a lot of metaphors, but sometimes I think of it like the developer builds a plane and the pilot flies it.

And so, the SEO sort of flies it. And like in the real world, the way that it interacts with, you know, very different things are different. So, that’s something that’s really useful for understanding how the site is performing and how it’s crawlable and how it’s readable online before you go live with it in a migration setting. It’s also useful. There’s a couple of different Chrome extensions that are really useful for sort of understanding what the page was before and what the page is now and versus, what it’s going to be in the future.

I was working with a client the other day and they were talking about changing their homepage, which isn’t a full migration, but changing a homepage can change a lot because of most websites, the homepage is the most visited page. So, if you change the number of links on that page, then that can change the crawl depth and that can change the performance overall.

And so, there’s a couple of different tools. There’s a tool that I use called SEO Pro Extension, which is really, really good, so I use that a lot. Also, a tool that I use particularly with migrations, if you’re thinking like, let’s say you’ve developed something, and the client says it’s not as good as it was before. But that website is gone. Something called Wayback Machine is really good. I’ve used that a few times to understand why a site before was working and why it’s not now.

So, there was a site that we had where they used to have a most recent content feed showing on the home page and that helped with crawl depth and help with retetion of new content and that sort of thing. And then when we moved to the new website, it didn’t have that. So when we moved, using Wayback Machine, I was like, we need to put that back on so that goes back, so that gives us more tools.

Moving The Needle Efficiently

(20:29) CRYSTAL CARTER: We always need a super-wizzy, technical fix, and sometimes it’s not necessarily the case that you need something super fancy. I know there’s a lot of AI at the moment and there’s a lot of automation, and lots of things like that. But sometimes you can do something pretty straightforward that will fix it.

So for instance, I’ve seen it before where, from an SEO point of view, we’re looking around and we’re going, “oh, there’s a bunch of 404s”, and “oh, we need to fix this”, developer needs to sort something out or something. It’s like, well, if you’ve got loads and lots of 404s, let’s say most of the pages on your website have seven links, and there’s 475 404s to this one URL. It’s probably in your menu. It’s probably in your menu. You’ve probably got a 404 in your menu. You probably just need to change the link on the menu and sometimes people think, “oh, we need to do this whole thing and fix that”.

It’s like, you might literally just need to change one little thing that isn’t even a dev thing, for instance. So, I think that, thinking about what is really genuinely required from a developer point of view is really, really useful.

And also thinking about how complex the solution might be. So for instance, in the situation you were talking about where you built it one way and the SEO wants a bunch of other things, if your tech stack is resistant to the implementation that you want, then there might be an external tool that you can use that solves the solution or that gets you where you need to go, or there might be another way that you can do it.

So for instance, I had a situation where I wanted an RSS. We were trying to build an RSS directly on the website and we ended up using a third-party tool and it works fine. It does exactly what I needed to do. Or I could have spent a month trying to get someone to build one from scratch. But why? But why? I go to third-party tool, and it works perfectly fine. I don’t have any third-party lag for JavaScript. It’s literally just one little line and it’s totally fine, and I had enough.

I find other times where, for instance, structure data is something where everybody’s going JSON, JSON, JSON, and JSON is fantastic. But if the website already has a microdata setup, then you might be able to move the needle close, like more quickly, by just updating the microdata if it’s already in place. So, you know, I think it’s useful from an SEO point of view to think about not only what moves the needle, but also what moves the needle efficiently, and from a tech point of view and from an SEO point of view.

MARTIN SPLITT: And I really like that statement because I wish a lot of the SEOs that I had to work with in the past would acknowledge that. And oftentimes I feel like there is a bit of dogmatism in the way that some people operate as in like, as you say, you identify the thing that moves the needle and moves the needle efficiently, like what is, what is easy to do, but like has lots of impact, and we discussed that in a previous episode as well. But the thing is oftentimes it seems that people, SEO specifically, go from half knowledge of someone on the internet said, or it used to be like that 10 years ago, and then just ask for a solution for something that isn’t even a problem in the first place.

JavaScript is one topic that invites this kind of situations, it seems. It’s like there’s still a lot of people wondering around, like, “oh, no, we need to implement dynamic rendering or server-side rendering for this client-side rendered application”, because unless we do that, it won’t show up in search.

And then I’m like, but if I Google for a thing on your page, then it shows up, so it’s already there and I see that it has traffic in Google Search Console. It gets the impressions; it gets the clicks. Why are we doing this? “Oh, because Google doesn’t understand client-side rendered JavaScript applications”, and I’m like, “but the data clearly shows that it does. It’s there.” I’m not saying that it’s true for all the situations and all the cases and all the pages. Yes, for some pages, it still matters. For some, it still makes a lot of sense.

If you see a problem, then this might be a solution to that problem if the client-side rendering really is the issue that you’re dealing with. But oftentimes, it just isn’t and you spend a lot of time, a lot of effort, a lot of money on implementing something that invites more trouble for solving nothing. Why does that happen?

CRYSTAL CARTER: I think sometimes people will hear a buzzword, or they’ll hear, “oh, yeah, we really need to sort out this and that,” and so I think sometimes people get excited about a new thing. And I mean, I can hold my hand up. There’s definitely been a time when I’ve done that.

Improving Communication Between SEOs & DEVs

(26:15) CRYSTAL CARTER: It’s great. But the other thing I think would be really, really useful, which I would appreciate as an SEO, speaking with Devs, is that if you don’t know what I’m talking about, tell me that you don’t know what I’m talking about.

MARTIN SPLITT: Right. Yes. 100% yes. Yes. Yes, please.

CRYSTAL CARTER: And also, if you need me to give it to you in a different way, please let me know. There’s a lot of tools that will help you to do that. So, I use a lot of screen recording tools.

So, Loom is one that I use a lot and I think Slack now has an integration where you can just record your screen really, really quickly and send it in a Slack message, and that makes a really big difference.

Chrome Developer Tools is fantastic. I do tons of PowerPoints where I’m just like, “this is here, and that is like this, and this is like that, and that is there”, and sometimes if you can see it and if you can show them the code, then even if you don’t know the exact words, they can figure out what you’re talking about. But it’s also useful to learn some of the words as an SEO.

So, learning what is and isn’t a variable, learning about what’s going on with your server, how is it deployed, how is all of that working. It really helps from an SEO point of view for you to get things moved on action quicker if you can give the developers more information.

So for instance, there’s a couple of sites where I have access to the folders and things and I don’t change things very often, but I can route around. I’ve had clients where they still had a static sitemap, and I was generating the static sitmap, and there’s smaller sites or whatever. And if that’s something that’s taking dev resource, you can ask them, “can I have access, please?” and then you can learn how to do it, and you can do it. Like creating a static sitemap is a really simple operation. Uploading it is really simple, but waiting around for one can be quite a pain.

So, if you can do it as an SEO, then that’s really, really great. So there’s some things where you can ask for access to certain parts of the stack so that you can give them better information. But again, that’s about building trust. So, if you have the conversations with your developers, before things get heated, before things are broken, before you start moving around everything, then it really helps.

And I mean, even if you’re working with remote teams, we work with a few remote developers. We have developers in-house, but we also have developers that we work with, that they work with for other clients or developers that work in other countries.  And we use Slack and email, and stuff. I will literally send emojis and hooray gifts and that sort of thing. Like if they fix something, I’m like, “oh, hooray, thank you so much”. Say thank you. Thank you, gets you so far.

MARTIN SPLITT: Same for developers towards SEOs, by the way. If I made it a point whenever I was, something was pointed out to me where we could do better, than we just did. Then, we saw the business impact and then it’s like, thank you very much for bringing this to our attention and thank you a lot for guiding me through the process.

Because oftentimes I didn’t know why I was doing something or how exactly it’s expected to be, and where I would verify if it’s done correctly. Then having someone to guide me through that was great and I was grateful for it, so say thank you.

CRYSTAL CARTER: Right, absolutely and if you work really well, then as a developer, that’s adding another string to your bow, then it’s something that it just keeps, it makes everything better. So yeah, I think that it’s really important to build good relationships in that way.

MARTIN SPLITT: Absolutely.

Recap

(20:33) MARTIN SPLITT: So I think it’s important to communicate if you don’t understand something, be it you as an SEO or you as a developer, if you’re not sure about something, just ask. Find the tools that the other people are using, just ask your developers what tools are you using, ask the SEOs, what tools should I be using to check when I’m building this or implementing this or fixing this, phrasing it as opportunities of improvement, is probably much, much better than phrasing it as a problem or a challenge.

And if we just work together and finding the right solutions together, I think we are doing each other big, big favors. I guess that’s, that sums it up quite nicely.

CRYSTAL CARTER: Absolutely. Absolutely.

MARTIN SPLITT: Thank you so much for joining me for this conversation, Crystal. This has been really, really exciting and interesting, and I do hope that everyone out there got something out of it as well. I certainly did, and I am looking forward to see what other cool things you will be sharing with the community and us in the future.

And again, thanks a lot for joining and take care, have a great time.



Sign up for SEO & Web Developers today!

SEO & DEVS: Harmony in Tech

(1:05) MARTIN SPLITT: Ruth, I’m super excited to have you here. I saw you at a I think it was React next summit, where you gave a talk on SEO for developers. And specifically, I think you focused on React JS, was that right?

RUTH MESFUN: Yeah. In regards to mobile first indexing? Yeah.

MARTIN SPLITT: Right. Yes. That was super cool. And I was so elated when I saw that because I see so very few non SEO people talk about SEO, especially in developer circles. So, it was very refreshing to see you do that.

When Tech SEO and Development Collide

(1:39) MARTIN SPLITT: What was the experience you had giving that talk? Did a bunch of people say, “I didn’t know that”, and that was interesting and exciting, or were you met with suspicion or what happened? Did you get any feedback on that?

RUTH MESFUN: I didn’t have any feedback in regard to suspicion. A bunch of feedback was mainly like, “I didn’t know it was that easy”, “I already know this stuff kind of thing”, but they didn’t realise that actually connected with SEO. So, it was great to essentially build a bridge, if that makes sense.

MARTIN SPLITT: It makes perfect sense, because this is exactly why this video series exists. Because I think this bridge needs to be built, and it hasn’t been built not only specifically to specific topics like mobile first indexing or client-side rendering, server-side rendering, all that kind of stuff.

MARTIN SPLITT: But I think also in general, between our two professions or the two sides of the coin, one being SEO and the other one being development or engineering, there isn’t as much of a bridge.

MARTIN SPLITT: I breached into this space in 2018 when I joined Google, and it was tricky to even get developers interested in SEO. So, what got you interested in SEO?

RUTH MESFUN: It was actually really funny. So at a previous job I was in, we were hearing about this mobile first indexing, but didn’t really get into. And we’re like, okay, whatever.
And we had other projects to do until someone said, “Wait, I think that mobile first indexing or mobile first is going to mess up our index ranking because we don’t do mobile first”, and we have like a separate page for mobile.

RUTH MESFUN: When we were looking into it, we’re like, oh my God, yes. And then at the time, Google’s deadline was September and it was already end of July. And we’re like, we got to get this done. That was the reason why.

RUTH MESFUN: Especially since, where I was working was like a marketplace, essentially. So, we didn’t realise how heavily reliant we were on Google searches. So, yeah, our users would search for us on Google and most of the time, and that’s how they got to our site. We thought that it was just like word of mouth or, honestly, I didn’t even think about how they came to our site.

MARTIN SPLITT: Then having a big change in the way that Google and other search engines work then probably becomes a surprise priority.

RUTH MESFUN: Yeah, it was definitely a surprise priority for our team.

How DEVs Approach SEO

(4:40) MARTIN SPLITT: I mean, I’ve worked as a developer for over a decade at this point, and I’ve experienced that where out of the blue, someone from the marketing department comes in and say, we have an SEO problem that we need to fix, and then oftentimes they have a really hard time even formulating it.

MARTIN SPLITT: So, the fact that you started with knowing that you were looking for mobile first indexing is already very nice because oftentimes it just, “we have an SEO problem”. It’s like, “what is it?”, “We don’t know, but we have an SEO problem.”

MARTIN SPLITT: It’s like, oh, great, and then you have to figure out you need to figure out what you don’t know. Right. It’s like, “how do I search for we have an SEO problem”, “How am I going to get a meaningful search query for this?”

MARTIN SPLITT: But where did you then take to or what kind of resources did you look to in terms of figuring out what you need to do and what is the supposed best practice and what’s the solution to the challenge you were facing? How did you go about this journey of figuring out what you need to do next?

RUTH MESFUN: I really like front end in general, so I naturally gravitated to, I’ll do research on SEO for my team and be one of the “experts”. I’m going to put quotation to “experts” because no way I’m an expert at SEO. But to be well informed, to explain it to my team and whatnot. And honestly, the webmaster’s videos, I watched almost all of Google’s SEO videos.

RUTH MESFUN: Because I was like, all right, well they’re the ones who are setting this whole mobile first indexing thing, so they must be like the experts if they’re the ones doing it. So, I watched the videos, which was great. So even like y’all’s, quarterly, or I think it used to be monthly videos of what’s going on and what’s the updates. I’d watch those and then all the best practices that Google put for mobile first as well. I read those up and had a couple of resources in regard to the difference between desktop first versus mobile first. Because I think a couple of the rules or guidelines changed a little bit because it was mobile first now. But honestly, I just went straight to Google for everything because since Google was the one who was stating that they were going to make it mobile first indexing only, I figured they were the most expert in SEO for what we were looking for.

MARTIN SPLITT: Interesting. I mean, it’s very flattering to hear that you watched all the videos and you probably are a fan of Google search news at this point. John is going to be really excited about that as well.

Google’s SEO Resources for DEVs

(7:51) MARTIN SPLITT: But it’s quite interesting that you went straight to, well, the source as far as it goes there because a bunch of people are not, and especially developers oftentimes are like, “how hard can this be?”, “We don’t really need to do any research”, “We’ll just fudge our way through it.” So, it’s really, really cool to hear that you went with that.

MARTIN SPLITT: Did you have any experience of looking at third party sources that said other things or did we have any holes where you’re like, there’s information missing?

RUTH MESFUN: That’s actually the main reason why honestly, I went straight to the source. It’s boring as that might sound of like, “Oh, go to if you literally Google Mobile first indexing and you find webmasters, Google click that,” the reason why was because there was a lot of misinformation with third parties.

RUTH MESFUN: So for instance, I had a product manager who came up and was like, “Oh no, we can’t do accordions or this or this or this, because that’s going to hide the data and it’s not going to show..” andI didn’t read that on the mobile first indexing. That doesn’t make sense. “Oh I saw it on this article..”

RUTH MESFUN: So, I read the article and I was like, well, this article seems like it’s a couple of years old and this looks like they are talking about desktop and not mobile-first. So, this might be out of date, and I think some people ran with that article essentially and wrote their own articles of what the complications of mobile first.

RUTH MESFUN: And I was like, no, it’s still they’re trying to make sure that they’re more forgiving because it’s mobile first and there’s such a compact screen now that it doesn’t make sense that they’re going to say, “no accordions, no this..” It’s more of like, as long as you’re doing server-side renderings, this is populating data, like all this stuff, it’s more forgiving because it’s mobile-first. And so looking through and going back to the source, which was Google, I was able to tell them, debunk that statement or that resource, essentially.

Debunking Outdated Info

(10:15) MARTIN SPLITT: It but that’s really, really nice, because oftentimes information used to be correct and then things change. Or people looked at one specific aspect and then generalise that too much. That does happen. That happens all the time. That happens in development, too, where people are like, you cannot test, I don’t know, angular code. And it’s like, actually, you can. You just have to know how

MARTIN SPLITT: It’s good to hear that we could debunk some of that stuff. That’s nice. But to be honest, I would just wish, because if you think about it, and if you look at what you discovered and what people have said, a lot of it, there are some aspects that are kind of rocket science, but a bunch of it is relatively easy to grasp concepts and best practices, and yet most developers don’t really pay attention to it or don’t care about SEO.

MARTIN SPLITT: Do you have any idea where that could come from? Like, why don’t they just know these things? Because I think all of us know how to make a link, a semantic link, and what semantic HTML is supposed to look like, and what the latest JavaScript feature is, and where it’s useful and how it works and what’s the syntax for it. But these kind of basic concepts seem to be missing in the developer world.

RUTH MESFUN: So, a couple of things. I think there’s like two or three points in regards to that. One, I don’t think every essentially, developer knows about JavaScript and semantics and structures and whatnot.I would assume that most or if not all, front end engineers should, but not all software developers.

Measuring Impact

(12:12) RUTH MESFUN: And then the second thing is, honestly, I didn’t realise the importance of SEO until we completed our SEO project to be mobile-first, and then our product manager and actually the marketing team sent it to our product manager. And the product manager told us, like, “Oh, we had a huge increase of views on our site, which converted into an increase in sales or revenue.” And when they showed us the graph, it literally made it a nice incline right at the time we shipped our project, essentially, or turned on the feature flag.

RUTH MESFUN: So, it was used, and we’re like, “Oh, this is important. It was great.” And I don’t think it was just because of the SEO, to be honest. I think a lot of the things we did was made our pages more performant, made it more user friendly, made it more accessible.  And those are actually the big three items or key items when it comes to SEO and mobile-first indexing.

MARTIN SPLITT: Exactly. There’s like two things that I want to tag onto. One is it’s very interesting you say that we didn’t just do things for SEO purposes, we did things for the user and that was rewarded in search engines, which is exactly what we want.

MARTIN SPLITT: A search engine tries to find the best possible experience and the best possible answer to a query from a user and present sites that are good for the user to fulfill whatever intention they had with a query, they entered into the search engine. So, making it better for the user is usually also equal to making it better for search engines.

MARTIN SPLITT: And the other thing is, was that the first time this kind of information like, “hey, here’s the thing you did, here’s the impact”, was that the first kind of opportunity where they brought back impact information to the changes you made? Or is that something that only sales normally does? Like, “Oh, you’ve deployed this new feature and it has gotten us this amount of customers that we didn’t have”, or like this amount of revenue that we didn’t have before, or does that happen more often? Or does it happen more often, but not with SEO? Do you usually get to see the impact of your work?

Why Seeing Results Matters to DEVs

(14:54) RUTH MESFUN: Yes, so for all of our projects, we always get to see the impact afterwards. It’s not rewarding if we don’t. At least for me, it’s not rewarding. Regardless of if it’s revenue or ease of use because of that feature or increase of review ratings or whatnot. But for the SEO one, honestly, I did not expect, I don’t know why I didn’t think of it, but I honestly didn’t expect that we were going to get a result so quickly or any real result.

RUTH MESFUN: I just thought, “Oh, this is going to help with SEO”, “That’s going to increase traffic eventually”, or at the minimum case, keep it at the same, which was actually our goal, was like, let’s not deprecate or decrease our index rating, was like our actual goal.

RUTH MESFUN:So, the fact that it not only like, we not only kept it, or we didn’t get it deprecated or decrease our ranking, it looked like it had a positive effect In regards to our users.

Interactions Between SEO and DEVs Matters

(16:18) MARTIN SPLITT: I’m not blaming you for not expecting or anticipating that, but it’s something that I find interesting. So the SEO team doesn’t usually let me rephrase the question. How often before did the SEO team interact with the engineering side of things?

RUTH MESFUN: Not that much.

MARTIN SPLITT: Not that much. Okay, that’s interesting. That seems to be like the underlying systemic issue between developers and SEOs that there is this weird gap and there is not that much collaboration or information sharing and that’s really, really unfortunate because oftentimes SEOs tell me that they are kind of fighting the development team, like, “oh, they want to roll out this thing and they screw us up and then we have to clean up after them for like a month”, and I’m like, “but did you talk to them beforehand?”, “Well, they didn’t talk to us beforehand”. And I’m like, so no one wants to talk to anyone at any capacity or time? Which is like super unfortunate.

MARTIN SPLITT: And I feel like this is close to the root cause of the issue where developers don’t care that much about SEO or don’t even know about SEO. Right.

RUTH MESFUN: I think that it’s mostly of a combination of the developers don’t know about SEO or don’t understand the value or the importance.

RUTH MESFUN: And then I would also say there’s a third thing of not realising how easy to do either SEO practices or run through if the feature you’re building or developing might be performant or not performant, which would actually cause a decrease in SEO and a decrease in performance in your site, which is not good.

MARTIN SPLITT: Fair enough. Yeah.

RUTH MESFUN: So, I think those are the combinations. If it’s something that deals with in my opinion, if it’s something that deals with main pages on the site that is going to be searchable on Google, right. Then that’s something that should, like, during the roadmap or design doc or like the SEO manager or expert should come in and look into and give their feedback on it. Because it’s just so hard as a developer that you build this feature and then you have to come back to fix it. You want to hopefully be able to complete the first iteration of it before having to fix bugs, ideally.

SEO Tools for DEVs

(19:13) RUTH MESFUN: And then I think the second thing is in regards to it, is there’s like a couple of tools that developers can actually utilise to see if that feature is going to be performant or not. Or at least use it while you’re building this feature. And then eventually you’ll develop a muscle where you could kind of feel if this is going to be a performant feature. So, Lighthouse was super useful on that.

RUTH MESFUN: The web platform team built a script around Lighthouse. So, whenever you built a feature, and it has, like, a feature flag, you can run the script like 500 times with that feature flag on or off and off to see the difference of performance between what’s already on prod versus what you’re going to push through, essentially.

RUTH MESFUN: And so we’re able to see “oh, this is going to make things better. LCP is lower. This is great.”

MARTIN SPLITT: It’s True. Yeah. I think it’s important to integrate that in your workflow as developers, so that it kind of becomes a natural part of your work and you see the impact as often as possible. Right?

RUTH MESFUN: Yeah, exactly. I think it’s called bundle phobia. So whenever introducing new packages or if someone’s like, “oh, I love this graph package, for instance, of building graphs or whatnot”, I always go to a bundlepedia or bundle phobia to see how large the package sizes. Because if it too large, right? Even if it is a great package. That’s going to actually decrease our performance and it will increase load and it won’t give a great user experience, which can also mess with our index rating or SEO score.

RUTH MESFUN: And it’s like, “is it worth that?”

MARTIN SPLITT: That’s a little rocket science.

Bundle Size and Rocket Science

(21:42) MARTIN SPLITT: I like that. And I think, like, rocket science in this case is actually a very apt comparison because in rocket science, you have this issue that you want more thrust, so you need to add more fuel.  But more fuel means more weight, and more weight means you need more thrust.

MARTIN SPLITT: And then there’s like this sweet spot where, adding more fuel actually gives you more thrust and not so much weight that it’s like, offsetting negatively. But eventually just adding fuel just means that the thrust you gain from the extra fuel is not as big as it needs to be to actually offset the fuel that you added. And then you get negative increase or negative benefit from it, and you actually lose performance.

MARTIN SPLITT: And it’s similar to that with packages like, “oh, we need graphs”, and then you’re like, “okay, we need a thing to make graphs now”.

MARTIN SPLITT: So, there’s this one, package A, and then there’s the other package B. Both of them allow us to make graphs, but one adds so much more weight to the page that needs to go through the wire and only adds this little feature of graphs where the other one is smaller and also adds this little feature. So, you should go for that one, but that’s the smaller one.

MARTIN SPLITT: Package B that is smaller does not necessarily make it here for developers. Like, the other one might be the more comfortable for developers and then developers gravitate towards the wrong choice.

RUTH MESFUN: That’s actually what happened with us. It was like, we saw this package A had all the bells and whistles. Package A was also ten times the size, and web platform was like, no, we’re not doing this.

RUTH MESFUN: We did package B. It was still a little large, but not as large as Package. And we were like, performance still. We weren’t feeling comfortable. So then we just built the graph, ourself because it was a bar graph. We were like, “it’s just a bar graph. We don’t need all of this”. And no package means lighter. So this is great.

Performance Culture

(23:47) MARTIN SPLITT: Yes. Good performance culture right there. Because I fell into this trap so many times where it’s like, “oh but this library is really nice and it makes everything go so fast and easy”, but then you see like, “oh, but it’s actually dragging down our performance,” And unless there’s a performance culture where someone keeps you accountable for that, its kind of just happens, and then the website just grows and bloats. So that’s really cool. That’s really nice.

MARTIN SPLITT: You said something about low hanging fruit that you didn’t know about. Is that something that you would have hoped for or expected the SEO team to reach out to you that they like because they probably knew about these low hanging fruit, but they didn’t necessarily communicate them, or maybe they didn’t know about them.

MARTIN SPLITT: Would you want SEO teams to be more proactive when it comes to, like, “oh, there’s like this small change that you can make that has this huge impact and this positive impact”, is that something that you would expect help from your SEO experts with?

RUTH MESFUN: Yeah, I think that would be super helpful on if we hear what the low hanging fruit is, and we can tell you if that is. Actually really simple and easy or not. So most of the time it is. It’s like, “oh, okay, I just need to update, and I just need to add lazy loading for all the images.“ Right? That’s really easy to do.

MARTIN SPLITT: That’s true. That’s easy to do. Lazy loading is a perfect example of that. We are trying to give guidance to SEOs in our documentation for low hanging fruits, but it’s tricky because low hanging fruits for one project and one tech stack might not necessarily be low hanging fruit for the others.

MARTIN SPLITT: So, again, I think there needs to be a dialogue, right? I think it’s perfectly fine if an SEO comes like, “hey, this thing would have a big impact. How hard is it to do this?” And then you are the experts on the engineering side, so you can evaluate if it’s a low hanging fruit or not. So, again, there needs to be a dialogue, I guess, right?

RUTH MESFUN: Yeah. I also think that though, I don’t know if this is something that every team can do, but I think it was really helpful that I was really excited about SEO. I’m usually excited for SEO and accessibility.

SEO and DEV Liaison: A New Role

(26:12) RUTH MESFUN: Yeah. So, because of that, I was almost like a liaison kind of thing of being able to connect, like, “oh, what are the SEO best practices?”, and be able to translate it to the team, and they’d be able to go to me and since I already have a strong relationship with my teammates, it was like the trust was already there. And then what they did afterwards was they actually added, like, an SEO expert within the team, because we dealt with all the essentially all of our pages were pages that were searchable for Google.

RUTH MESFUN: So, they’re like, “oh, you need kind of like an SEO expert”. So they actually added an SEO member to our team. So, he was essentially our go to person for questions.

MARTIN SPLITT: I think that’s really cool, and I would love to see that more often, because I think this liaison that you built and then the SEO expert in your team, that’s a very essential thing. And I think it requires, to a certain degree, I’m not sure about your SEO expert that you got in your team. It is helpful if that person is at least technically inclined or has an interest in development and engineering. I guess it works if they don’t, but I don’t know how it was in your case. Did they also know bits and pieces about development not necessarily being a developer themselves?

RUTH MESFUN: I don’t think that he necessarily knew pieces of development. It’s kind of like a product manager, a non-technical product manager might not know all the technical aspect. They rely on us, but we’ll say, “this is what I want”, or “this is why we need this”, and “this is why this is important”. Right? And then it’s the developer who pushes back saying, “I think this is going to be like a higher complexity”, or “can we do it this way to achieve the same goal?”

MARTIN SPLITT: I see. Yeah. So that’s interesting because I always assumed that for this to work, they have to have at least some technical knowledge. But I guess if you look at it from a product manager’s perspective, it doesn’t have to be it’s perfectly fine if yeah, okay. That’s interesting. That’s really, really cool. That’s really interesting.

Summary

(28:48) MARTIN SPLITT: The other thing that I was wondering is. You said like, it was interesting and it’s like rewarding to me to see the impact of my work and to find out about these low hanging fruits. So what you’re saying is, just to make sure that I understood that correctly, you’re saying is developers generally are interested in the impact of their work in terms of SEO and doing SEO work for the benefits that you can reap by doing it.

RUTH MESFUN: Yeah, I’ll do it based on essentially I’m not going to generalise it, but I’ll say based on myself and my team and the teams I’ve worked in in the past and currently actually is we are very invested in our users. We are user driven, user-centric, crazy about our users and wanting them to get whatever need. Our goal is, essentially, is allow our users to easily use our apps, our page, and do the thing that they wanted to do on our site. Right?

RUTH MESFUN: And so essentially, if that’s not happening, we’re not doing a good job and we feel bad about it. We’re like, “oh, we want them to access this”. This is important. What was the point? I’m very result driven and I know the teams I’ve been in have been result driven and in a place of the love for the user.

MARTIN SPLITT: That’s really nice, I like that statement. So, I do hope that there’s a lot more developers like you and your team who are doing it for the love of the user, which I think is the right attitude to things, and I think actually SEOs. Fundamentally are also doing it for the love of the user, except that they work towards or through a search engine, which I think we are doing it through front end technology.

MARTIN SPLITT: So different means for the same end goal. So I think we share that end goal and I would hope that we would connect more to reach this goal together. So, yeah, let’s hope that this series and these conversations do help to shape the path and more teams to be like this, keeping fingers crossed.

MARTIN SPLITT: Awesome. Excellent. Ruth, this has been really cool, really interesting. I learned a bunch of new stuff. For instance, that having an SEO expert on your team, even if they don’t necessarily are technical, is super helpful and can help make these things more visible and share insights into what could be done to improve SEO, and then leaving it to the engineering team to figure out how easy or how low hanging this specific thing is.

MARTIN SPLITT: Thanks a lot for your time. Thanks a lot for being here. And thanks everyone who’s watching the video out there. I do hope you got something out of it as well. And see you soon for another episode. Bye.



Sign up for SEO & Web Developers today!

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!