Category: Seo and Dev

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!

Introduction

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

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

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

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

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

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

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

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

Why are SEOs and devs not on the same wavelength?

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

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

MARTIN SPLITT: Mhm.

JENN MATHEWS: Yeah. For sure. 

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

Test and learn 

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

I don’t know, do you?

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

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

SEOs are under scrutiny 

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

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

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

MARTIN SPLITT: Interesting. Yeah. 

JENN MATHEWS: Yeah. 

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

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

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

Priorities and impact

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

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

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

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

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

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

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

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

What developers can do to help 

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

JENN MATHEWS: Oh, gosh.

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

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

MARTIN SPLITT: OK

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

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

JENN MATHEWS: Yeah. 

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

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

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

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

SEOs, become allies to your developers

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

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

JENN MATHEWS: Right. 

MARTIN SPLITT: Does that makes sense?

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

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

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

Learn how to communicate with developers

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

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

MARTIN SPLITT: Fair. Mhm. 

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

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

MARTIN SPLITT: Yeah. 

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

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

JENN MATHEWS:  Yeah. 

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

JENN MATHEWS:  Always test and learn. 

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

JENN MATHEWS:  Yeah. 

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

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

JENN MATHEWS: Yeah, for sure. 

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

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

MARTIN SPLITT: Often. Quite often. 

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

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

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

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

Key takeaways 

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

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

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

JENN MATHEWS: Yeah, I like that. 

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

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

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

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

MARTIN SPLITT: You brought this upon yourself. 

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

MARTIN SPLITT: It was successful or not.

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

MARTIN SPLITT: If it works, it works. 

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

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

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

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

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

MARTIN SPLITT: Fair enough. Fair enough. 

Wrap up

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

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

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

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

JENN MATHEWS: Yeah, we might have to

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

Sign up for SEO & Web Developers today!

Intro

MARTIN SPLITT: Why do SEOs give strange recommendations to us developers sometimes?

MICHAEL KING: Why can’t the Google documentation be up to date?

MARTIN SPLITT: Why won’t all SEOs use their tools and documentation properly?

MICHAEL KING: Why is the Google documentation written so strangely?

MARTIN SPLITT: Hello, and welcome back to another episode of SEOs and Developers. Today, my guest is Michael King, who is not only running an SEO agency and has a technical background, but he’s also a rapper. So I’m really looking forward to see what we’ll be getting into today. 

MICHAEL KING: And I’m here with Googler Martin Splitt, who’s a diver, magician, and an individual who is as dynamic as his hair. Very excited to speak with him today.

Checklists, beginner SEOs, and tools

MARTIN SPLITT: (01:00) So I’m really, really excited to be joined in this episode by Mike King. And, Mike, I actually have a really good question for you. So you’re running your SEO agency. And I know that you have a technical background, so you maybe understand where I’m coming from when I say, as a developer, I have met so many SEOs who are basically barging into the development room and going to the team, like standing in front of the entire team, going, oh my god, stop everything that you’re doing. We have a massive issue. And then you’re like, so what’s the issue? We need to fix our canonicals. And you’re like, but why? Oh, you know, it’s going to break everything, and everything is going to be like we’re going to get penalties, and everything is going to shit, and we have to really get everything back up to speed. And, oh my god, this has to happen now, now, now. And I’m like, why is it that a bunch of people are operating like this? Where does that come from?

MICHAEL KING: (01:55) Well, it comes from the fact that everyone in SEO comes from a different background. Like, not too many people are as technical as someone like me or some of the other great people in the space. And so a lot of it is like, OK, I read this checklist. It tells me, OK, I need to do these things. I have a tool that tells me that everything is on fire. So I’m going to focus on the thing it says is most on fire. So what it really comes down to is differing levels of education. I think that there’s some difficulty with people understanding what priorities are or how they align with priorities and an actual business, and then also from the perspective of what it’s going to be the impact of doing any of these things. So it’s very easy for an SEO who is inexperienced to put together some sort of PDF report from a tool that they’re using that says, OK, these are the 10 things that must happen right now. But it doesn’t necessarily reflect what the impact is going to be of those things.

MARTIN SPLITT: (02:59) Right. Yeah, I’ve seen these PDF reports, and that has me wondering like, why can’t tools not just be doing the right things? Like, why are these tools generating these 30-page reports with all this stuff in it? How did we end up here? 

MICHAEL KING: (03:18) Yeah, I mean, that’s the thing like, when you build a generic tool around a series of SEO best practices, it’s not going to take into account the context of the actual website, right? So in the example that you gave with canonical tags, there may be a reason that you have so many duplicates. There may be a reason that the site needs that, right? Like, if you think about a site that has a bunch of franchises, and that content isn’t any different per franchise, it makes sense that you’re not canonicalizing those to one version of the page. Like, the business wants to have these different permutations of pages for different service areas. And there are any number of reasons why this may be of value to the actual business. So a tool is just going to say, well, the best practice is for every URL to be canonicalized so the version of it that’s very similar to it or is an exact duplicate. But it doesn’t know that that actually makes sense for that business. So I think that there’s an opportunity, I think this is generally true that technology for SEO is very much behind, of course, what Google is doing. But it’s also behind what it can actually do, right? I think that there needs to be some sort of layer that’s added to these SEO tools, where it’s like, I’m this type of business. We have this type of concern. These are our priorities. All right, now spit out something that is prioritized or takes into account what makes sense for this business. And so when you don’t have that, you need an expert that’s able to interpret it from a business-use-case perspective, from a perspective of, what can we technically do? And again, because you don’t have enough people in SEO that are able to interpret things that way, you get these reports straight out of the tool that’s like, again, everything is on fire. And so that’s what our job is, is to interpret that to the frame of what the business actually needs to do. 

Why does context matter for automation? 

MARTIN SPLITT: (05:18) All right, OK, I get that. So one takeaway from me, don’t be mad at me here is that from a developer’s perspective, I always thought this stuff can probably be automated away, right? We don’t really need that many actual people doing it. But it sounds like that’s not the case, right? There’s a bunch of stuff that depends on the context, and the tools can’t capture this, right?

MICHAEL KING: (05:43) Well, I’ll put that back on you. Like, at this point, we’ve also got tools that can automatically write code. We don’t need developers, right? It’s the same sort of thing. You know what I mean? Like, of course, we need developers. Like, there still needs to be that interpretation of, what are we trying to do here, and how do we account for the nuances of what we’re trying to do? So to your point, yes, I agree that a lot of SEO can be automated, but there are things that let’s say, for instance, we’re talking about an internal linking structure. That could be entirely automated. But if you don’t have the right rules in place, it could go crazy really quickly, right? Like, let’s say you even got it to the point where you’ve identified all the pages that own individual keywords. So let’s say you’ve got your whole keyword list, and you’re like, OK, there’s a mapping of keyword to URL. And then, you have something that crawls the site and looks for the instances of those keywords so that you can automatically build a keyword-relevant internal linking structure. But that could easily go crazy, where you have every word on the page has internal links on it now. And now it’s like a completely bad user experience, and there’s any number of filters that could be tripped as a result of that. And so you still always need that human interpretation so that we’re doing things right, and it just doesn’t go haywire.

MARTIN SPLITT: (07:08) Yeah, yeah, I see that. No, that makes perfect sense. 

Do tools give outdated recommendations? 

MARTIN SPLITT: (07:11) And another thing that I’m surprised by, let’s put it that way, is that there’s a lot of the guidelines you said, like, the best practices and the guidelines are there, and the tools are going along with them. But a bunch of the tools seem to be making proposals or suggestions that I think are either not quite there or actually completely wrong and outdated and no longer are a thing. How does that happen?

MICHAEL KING: (07:46) Yeah, you’ve got things like text-to-code ratio, or W3C compliance that are still, I mean, I’m embarrassed to see that type of stuff still, because it’s like, was that ever really a concern? Or was it just something that some SEO at some point was like, hey, I think this is a thing, and then every tool just has it as a result? But, yeah, I think no one’s really gone back and looked and taken a critical look at things and said, hey, what do we actually need to be looking at? What do we actually need to have rules around? I think it’s largely been like, you have to have feature parity with other tools. And so they’re just copying what they saw Moz do or what they saw SEMrush do, or whoever, and this just continued to persist. But I think that there needs to be. I think SEO as an industry probably just needs a product manager to stand up and be like, yo, let’s stop doing these dumb things.

MARTIN SPLITT: (08:48) Oh, man. I mean, I understand that that kind of cruft accumulates over time, but we have so much in terms of updates and documentation and reading material and guidance out there that we are trying to update whenever something changes. But yet, the tools are still spouting things. And for instance, the W3C thing that has been a tricky one because, obviously, writing compliant, semantic, and correct HTML is great because that makes it easier for us to understand what you’re trying to accomplish there in terms of the semantics of the content. But if you make mistakes, it’s not that we stop understanding the page and be like, oh, we don’t know what that is. We are out of here. We are still trying to make sense of it. We just might need to, like, we might lose confidence on the way, right? It’s like. This might be a headline, but we’re not sure.

MICHAEL KING: (09:40) Right, but realistically, if that was actually a requirement, I’m going to guess that over 90% of the web just wouldn’t load, you know? Because what is truly compliant across the web? And so to that end, obviously, you guys, the crawling capability is fantastic. And you’re rendering the full page anyway, so if my browser works, it’s likely that your crawler will work. And so just the fact that we’re still, like, even considering that is difficult. But at the same time, there are things that you do that achieve compliance that do help. So I agree with what you’re saying, but it’s not the metric that we should be looking at to determine it.

Documentation drift and doing your own research 

MICHAEL KING: (10:27) I think that there’s a lot of instances where, if we’re talking about documentation, where the documentation may be out of phase with where you are as an organisation. And I think you can say that not just from what’s public facing, I’m sure that’s happening internally as well. And so the reality of it is that it’s very difficult to look at that documentation as the single source of truth because things are changing so quickly. And so even if all the SEO tools were like, OK, let’s follow Google’s documentation perfectly, it still wouldn’t necessarily be the ideal state for how these tools would tell you things.

MARTIN SPLITT: (11:08) OK, I’m guessing this also aims a little bit in the direction of previous/next links, where we had this thing. OK, yeah. So what happened there was unfortunate. And you’re right; the docs are not always in phase. We are doing our best to work with the teams and help them to keep their documentation updated, but it does every now and then happen. In this case, a bunch of engineers in search of quality figured out, hey, hold on. We actually don’t really need the rel=”next” and rel=”prev” links anymore to figure out that there is pagination going on. We can figure that out from other things on the page by themselves. So they just removed the code. And then we were in this, and now, we go into our position, come to our side of the force, and what do you do? Do you either update the docs to like just quietly remove that part because it is no longer relevant? Or do you go like, hey, by the way, this is no longer necessary? And, truthfully speaking, it hasn’t been necessary in the last six months, knowing very well that people are reading the documentation, making recommendations based on it to other people, and these people then invest work and time and money into making that happen. And the alternative would just be to let it live there in the documentation. Even though it’s wrong, it doesn’t hurt. So we went with the full frontal way of going like, OK, here’s the thing this has been removed a while ago. We are sorry about that, but now our docs are updated. And I think none of the choices are easy or necessarily perfectly good, but it’s just what happened. So I think we are trying to keep the docs updated as much as possible.

MICHAEL KING: (12:50) Yeah and I get that it’s hard. Again, you have a large team, which is like an offshoot of another even larger team. You’re both moving quite quickly. I get it. It’s just very difficult from this side, where you’re making recommendations to people. And then you’ve got an engineer who’s second-guessing you. And then they find something in the documentation that’s out of date, and they’re like, no, you’re wrong. You don’t know what you’re talking about. Google says this right here. So it just makes our job a lot more difficult. So I get what you’re saying, but you also got to come to our side and see what we’re dealing with because I’m just Mike King. You guys are Google, right?

MARTIN SPLITT: (13:31) Yeah, no, no worries. That’s exactly why we are so transparent and say like, hey, by the way, this has been removed. We’re sorry, but the docs are now updated, because we understand that we have to make sure, to our best knowledge and to our best ability, that the docs are a source of truth. 

Who is the documentation written for?

MARTIN SPLITT: (13:37) Nonetheless, it is tricky, because of what you just said, like, oh, the engineer finds this piece of documentation and argues their way around it, it’s so hard to write these docs to the right audience.

MICHAEL KING: (14:03) Right. Yeah, and that’s the thing it seems like from what I’ve read and I’ve read most of it, from what I can tell it’s like, the writer’s aiming for the middle, but that doesn’t really support the use case, right? Like, it doesn’t necessarily align with the people that are actually going to use this. At the same time, I get that there’s a very wide audience of “webmasters” how many small businesspeople are really digging into documentation like this? So why are we necessarily writing for them? Or should it be the type of thing where we have a section that’s more for the advanced user or more for the enterprise user, where you’re able to speak to these use cases in more specific ways? There are a lot of situations in the documentation where there are just too many edge cases for you to say the things that are being said. Like, there’s something that came out more recently where it’s like, hey if you see a traffic trend or a click trend that looks like this, that means this is what happened. I’ve seen plenty of trends that looked like all four of those things that are shown in the documentation that wasn’t the thing that the documentation says it is. So now, I’ll have a client that’ll come to me and say, well, we saw this, and the documentation showed us a screenshot of this, so this must be why. And so they may not be so receptive to what’s actually going to need to happen in order to recover. So that’s the thing it just doesn’t really solve the problem in the way that we would hope it does.

MARTIN SPLITT: (15:38) And I understand that, and I understand that it’s tricky. And we learned that, and that’s why we relaunched our documentation at some point in the past. I think it was in November 2020 we relaunched or February 2021. I can’t remember when exactly we launched the new Dev site. But we are trying to group it differently because we realised that even though with the new grouping, we’re still seeing feedback to very technical things, like robots.txt, coming from small business owners being like, I don’t even know what any of this means. Ahh! And we’re like, OK, but this is a very technical thing. Like, how did you end up here? Why did you end up here? And what are you trying to accomplish? So it’s really, really tricky, and we have to try to write for the broad use case and then the edge cases. That’s a tricky place. Where do they live?

We read documentation feedback. Give us feedback! 

MARTIN SPLITT: (16:27) I did that for JavaScript. I have this extra fixed JavaScript issues page with all the edge cases where things might go wrong. But it’s tricky. It’s not easy to catch all these things. And that’s why giving us feedback on the docs and in the docs, there is an opportunity to give us feedback right there. We read this. It’s really weird because we can’t give a response back as easily. Like, you don’t know that we read it, but we do read it. And it’s quite interesting. Like, a lot of it is really useful, constructive, helpful feedback that allows us to improve our documentation. A bunch of it is people saying like, aw, you guys suck. And I guess that’s the reality of the internet– wherever you give people the opportunity to say things, they might say things that you might not want to hear, but that’s OK. If they think we suck, that’s, you know, I’m sorry.

MICHAEL KING: (17:15) Well, I do want to give some props because, especially around the JavaScript thing, I really appreciate what you did with that because that was very much something that we were very early on discovering at my agency. Like, we wrote a blog post a number of years ago, probably, like, 10 years at this point, called “Googlebot is Chrome,” where we introduced the SEO world to the idea of headless browsing. And I also wrote some subsequent stuff around that about how this could be done. And I appreciated that you especially came out and were like, no, here’s how we do it. Here are some specific things to know because it was a lot of speculation on our part and a lot of testing. But I appreciate that you were able to say like, no, no, here’s the way that we do it, and then we can refine it across the industry. So that’s what I mean. Like, there are definitely instances where the documentation has been incredibly valuable in shedding light on how we need to be thinking about things because, for a long time, we may have been going in the wrong direction entirely. So yeah, there’s definitely some value to it. I just think that there are instances where things are very vague or don’t really speak to the problem and create more problems for SEOs.

Why documentation causes misunderstanding

MARTIN SPLITT: (18:35) So with the create more problems, that’s exactly what we want to improve on and what we want to constantly get better at. And also, thank you very much for the positive feedback. And for the other bit, like, it’s very generic or very strangely written, that one is a tricky one because it is what you said it. You said it yourself– SEOs come from a wide variety of backgrounds. And they have a wide variety of different focuses, and they look at the same thing from very different angles, like the W3C validator thing. If you ask me like, so does our HTML need to be written well? My answer would be, yes, it has to be written well. But I don’t mean specifically compliant with W3C specs, which is what some people might hear who are coming from that angle. Someone else might be like, oh, so it doesn’t have to be compliant, but it needs to be well done? OK, fair enough. And it’s not just documentation where this is hard. I find that also with the tooling, it is incredibly hard to do that from the tooling that we provide. PageSpeed Insights, for instance, or Lighthouse, gives you a score. That’s so dangerous. I know, but some people need that score. 

MICHAEL KING: (19:45) But let’s dig into that a little bit. So one of the common things that I hear, and I heard it at a conference the other day. They’re like, oh, I ran it three times. Why is it different? People don’t understand that network conditions impact all of these scores here. And so if there was some sort of callout, maybe there is. Maybe it’s in a tooltip that no one clicks on, but I think there’s some value in helping them understand that because you’ll see your score is, like, 45 right now. Now, suddenly, it’s 52. And you’re like; these tools don’t work. I don’t trust these tools. And then also, let’s talk a little bit about the difference between a click in GSE versus a session in GA. Most people don’t know. Like, it was very widely misunderstood that those are not the same things. And so I ended up writing a blog post, going into very great detail. I did some patent diving and looked at some of your documentation and showed people, no, here’s why they are measured differently. One of these comes from logs. One of these comes from clickstream, and so on. And so if that information surfaced a bit better and again, I’m not saying you don’t have it. There was a section in there that talks about the differences to some degree like, what is average position versus what is a ranking? Things like that. These are things that are just not obvious to people that I think could be surfaced a bit better, so these questions don’t come up as much. 

Challenges with trust and supporting each other

MARTIN SPLITT: (21:09) That’s very, very good feedback. That’s exactly what we’re trying to do. And I know that especially the Lighthouse team, for instance, tries to be ridiculously transparent. Like, you can figure out how the score is being calculated and evaluate, and as well as how that changes over time because the same score might actually change even if everything else is the same. Over time, you might actually see different scores because the way that the different metrics are weighted is changing. It’s challenging, though.

MICHAEL KING: (21:39) Of course, of course. I think the bigger challenge, though, is that, again, sometimes a developer will come into the project. They’ll look into the documentation. And they’re like; this doesn’t match up with what the SEO has told me. And then they just don’t trust them. And then there’s also some messaging that I recall from a year or two ago, where there was a video talking about how you should choose an SEO. Obviously, that created a bit of a firestorm in our space because it felt like Google saying, this is the way that we need to be. Here are the expectations you should have. I wish there was one where y’all were like, hey, here are the expectations you should have of our documentation.

MARTIN SPLITT: (22:25) Yeah, I understand. I understand. Yeah, see, and this is exactly what happens because I like two things, particularly what you just said. Number one, this video created a firestorm amongst SEOs. It was not even meant for them. It was not even meant for their customers, necessarily. It was meant for small businesses that are like, I am running a kid’s clothing store in a back street in Zurich. And I have zero budget. I’m basically running it out of my basement, and people WhatsApp me or Facebook message me or FaceTime me or Hangout me or write me a text message or whatever to pick up their order or something like that. But I want to be taking part in the online world of e-commerce. How can I do that? And it was meant for this audience. Like, if you get an SEO, look for these very obvious red flags and things that might not be up for what you are trying to accomplish. And because of the wide variety of people, that is what happened. Like, it was misunderstood and misrepresented, and it wasn’t necessarily presenting itself very well. And the other thing was trust. We said like, a developer comes in and doesn’t trust what the SEO says based on what is in the documentation. And that seems to be the core of all this. I just realised, thanks to you, SEOs, and also developers, probably, as well, come from so many different backgrounds. And it’s unfortunate that we choose to use this, like, the trajectory that we come from, like, I’m coming from here. You’re coming from here. Instead of looking at the entire spectrum in between and learning from each other’s perspective, it seems to be more like, I come from this angle, and I see this. You come from this angle. You see this. You must be wrong.

MICHAEL KING: (24:33) Right. Yeah, I don’t think it should be that us-versus-them dynamic that we currently have. And I think that there’s so much beauty in the fact that SEOs come from so many different backgrounds. Like we said in our introduction, I rap. That’s what I did before I did SEO full-time. And there’s so many people that you meet with so many interesting perspectives on so many things, and I wish, when we work with engineers, we were able to come to the table better and be like, look. I want to know everything about what it is that you’re doing. And what can I learn here? How can we work together more effectively? And that’s very much my approach. I don’t try to come into it like; this is the way we must do it because it’s the way I think. I more try to come to it from the perspective of, like, hey, I know a little bit about what it is that you do, probably more than you might expect. But I want to learn this from your perspective, and I want to help support what you’re trying to do. One of the things that we do at the beginning of any of our audits, there’s this thing it’s like the prime directive from some agile thing that we read, where it’s something like, we’re just assuming that everyone did their best with what they knew and the whole thing. So that we’re coming from the perspective of a level playing field, where it’s like, I’m not just hating on your work. I’m just trying to say like, hey, from the perspective where I sit, these are the things that can be improved so that we can make things perform better. And at the same time, I need to understand your limitations. I need to understand what you need in a user story for this to work for you. I need to know what sort of supporting data and documentation you need to see in order for you to get this on your prioritisation schedule. And I think a lot of SEOs aren’t really thinking that way because a lot of how things are presented both in our space and from that us-versus-them dynamic is like, all right, well, you’re going to bring all this great stuff to the table. And no one’s going to do anything with it because they don’t trust you. And it’s all just humans working together, so what do we need to do so that we can all come to a space of trust and make this work and make it, so everyone gets bonuses at the end of the year?

MARTIN SPLITT: (26:54) That’s a nice way of looking at it. From a developer’s perspective, what I can say is that what I observed myself as well is that, as developers, we are used to know that we don’t know something, and then we have to get better at figuring it out. There are still a lot of developers who are like, I know everything, which is unfortunate. But usually, developers are curious creatures, and we are like, oh, I don’t know how that works or how that is supposed to be. And then we research, and then we prototype, and then we have something that solves the problem. We are problem solvers. So when someone comes in, and often, SEOs come in, and I think it’s also because there is such a wide variety of people’s backgrounds in SEO, they might feel inclined to say, oh, it’s like this, even though they are not sure about it, or they don’t know it. So they cling on to their PDF reports. They’re like; this report says this is a problem without necessarily thinking about it. And I would love to see more SEOs admitting, hm, I actually don’t know. Let’s find out together, or let’s test this together. Let’s do some research together.

Knowing, not knowing, and doing researching

MICHAEL KING: (28:01) Well, that is easier to do when you’re in-house. It’s harder to do when you’re a consultant because they don’t expect you to know everything when you’re in-house. They expect you to know enough and work through it. Whereas when you’re a consultant, they want you to have the answer, even if there isn’t a definitive answer. But as far as developers, I like to think of them on a spectrum. And I think I’ve mentioned this to you via email before. I think of it as the Anderson-Alderson spectrum, where Anderson is Thomas Anderson, like Neo from “The Matrix,” who hated his job, and didn’t want anything to do with anybody. And then you’ve got Elliot Alderson, “Mr Robot,” who was the guy that was working all hours of the night, just kind of doing work without anyone telling him, being super proactive. And so there are those developers like you’re saying, this side of the Anderson scale, it’s like, I know everything. You don’t know anything, and they present that way very much, even when they are typically more intellectually curious amongst their peers. And obviously, those people are very difficult to work with, and you’ve got to have documentation for everything. And again, that’s the person that’s going to find the Google documentation that says that you’re wrong, and that’s that. Yeah, exactly. Whereas on the Alderson side, I had a guy who’s a developer working with a client at one point. We were presenting the site audit on-site with them, walking through everything. And he was committing code, fixing things, as we were talking and asking questions. And probably, that’s not the best way to do development work. Of course, you need to run it through your whole process. But it was really good to see how receptive he was to what we were doing, and he was very collaborative. That’s the ideal situation: someone who’s going to ask questions, someone who’s going to help you clarify things so you can make the recommendation far more pointed and actually make it happen. And obviously, those are the extremes. But obviously, something in the middle is where things work best, where it’s like, hey, SEO, you understand that you don’t know everything about this website because you didn’t build it. And, hey, engineer, you understand you don’t know everything about SEO because those requirements are not in your day-to-day. So let’s all get together and figure out how to make this work and trust each other, and that’s it.

MARTIN SPLITT: (30:37) Sounds easier said than done, but I think, yeah, to sum it up, SEOs should value the difference of perspective from different people and be receptive to doing their own research. And also, developers need to be more trusting towards SEOs and take them on the journey with them and work together to figure things out together. And I think that would probably make things easier for everyone.

MICHAEL KING: (31:05) Yeah, I’ll tell you that no SEO is trying to ruin your website. Like, they’re not actively trying to mess things up for you. Their remit is helping it improve its visibility, and drive traffic, ultimately driving conversions. So the reality of the situation is it’s an antagonistic relationship because the whole job, or a lot of the job, is telling an engineer that they’ve done something wrong. And again, we need to reframe that so it’s a better working relationship.

MARTIN SPLITT: (31:39) Yeah, interesting. So let’s hope that people out there watching this conversation are finding their way of reframing it and actually getting onto a table and collaborating with each other rather than trying to prove each other wrong. Because I think if we try to just prove each other wrong, we’re not getting anywhere, and we have the same goal. We want better websites.

Conclusion

MARTIN SPLITT: (32:02) Awesome. Mike, thank you so much for being here with me and taking the time to talk this out. And I think I am full of new ideas, and I will definitely try to make our documentation better together with our lovely team and our fantastic tech writer, Lizzie Harvey, and all the others. And yeah, thanks a lot.

MICHAEL KING: (32:20) Thanks for having me, Martin. This has been great. And I, again, just want to really thank you guys for all the things you’ve been doing. I’ve been doing SEO for 15 years, and it’s been a dramatic improvement in how you’ve engaged with the community, the documentation you’re doing, the tools, and so on. So I definitely appreciate the progress and look forward to where this continues to go.

MARTIN SPLITT: (32:43) Thank you. Thanks a lot for the nice feedback. And thanks to everyone watching this. I hope that you had a good time. Stay safe and healthy, and bye-bye.

Sign up for SEO & Web Developers today!

Do devs listen to SEOs recommendations?

(1:13) MARTIN: So, Bartosz, there is a thing that I want to talk to you about, and that is that I do hear, and I do observe that SEOs are often struggling actually to get developers to do stuff. Is that an experience that you share? It’s like you make recommendations, you give them input, and then it just doesn’t happen? Or is that not something that you would say is a particular problem?

BARTOSZ: I think that you might have touched on a very sensitive topic in the industry, and I know where you’re coming from with that. So, in general, this is a problem. Some agencies solved this problem and kind of went, past it. We cannot complain at all about our relationship with devs. At the same time, there are so many ways that things are done in the web development and the SEO space that doesn’t help.

Why we shouldn’t throw PDF reports over the fence

(2:10) BARTOSZ: For example, PDF audits are one of the things, just to name, I think, the elephant in the room. So if you’re going to create a PDF audit explaining how to fix core vitals, not knowing their stack, not knowing their technology, not knowing their resources`. How many devs are there in the team? Is it a Shopify-based platform, or is it a custom CMS? And in our experience, when you create a PDF audit, and the dev is going to run into a problem, they’ll skip that because there’s no fallback into what has to be done. So this can be unpacked in so many ways.

MARTIN: But I know exactly what you mean. So I come from a developer background, and I have worked with SEOs on both sides, both as a Google developer advocate, basically helping SEOs to do the right things and identify problems and solve problems. And both– also from the perspective of the developer working in the team. And the thing with the PDF report really struck a chord with me. Because I remember being a developer. I had so many different things on my plate already. And then, out of the blue, in the middle of a sprint, someone from the SEO department descended upon me and said, “Martin, here is a PDF with all the things that are wrong.” Bye. And then they just flew off. And I’m like, uh, OK. It says we are using JavaScript, which is very accurate because what we are actually building right now is a VR application that runs on your phone in the browser. You have to use JavaScript to do that. And the recommendation is to not use JavaScript? So that’s not really a thing we can do because then we don’t have VR capabilities. And because then that’s our product, we kind of have to build our product to have our product with the technologies that enable the features of our product. So a lot of these things are so unhelpful and so not reflective of the circumstances in which I, as a developer, work in.

Why do SEOs advise against JavaScript?

(4:21) BARTOSZ: So you work for Google. So I can ask you before we get into how to solve this problem, let me ask you a question. Is Google OK with JavaScript?

MARTIN: Yeah. We are OK with JavaScript.

BARTOSZ: So if I have a news website that’s 100% CSR, you’re going to be OK with that?

MARTIN: We’re going to be OK with it. It might take a little longer than you would like us sometimes because we have to actually render everything. And if you are rendering specifically badly designed, then that might take us a while. But in general, if you are doing things right, and if you’re doing things following the best practices and making sure that you test your setup up, we would be fine with that, yeah.

BARTOSZ: So I don’t want to argue with that statement. Obviously, this is not this kind of video. But just what I’m trying to say is there are so many complexities on all these fronts. So we have clients coming in with a news website that’s 100% JavaScript. And there is this kind of demon in the industry that all the SEOs would say that JavaScript is evil and that JavaScript is so bad. But on the other side of things, there is Google saying we’re OK with JavaScript. And there is this kind of reality when there are a lot of websites packed with JavaScript, and Google is not picking them up properly. They’re not getting rendered for, like, all these other problems. So then we hop on the call with a dev team of our client. And they’re like, but Martin said that JavaScript doc is OK. Why do we need to do why do you want us to do server-side rendering? How do you answer? You know what I mean. This makes us look like SEO wizards. So these are the problems that require a lot of knowledge. We don’t struggle with them as much anymore because we have so much research. We have our experiments, whatever. But if you think about that to a level when he or she can handle those questions, it is going to take years. And it is, for us, it slows down growth. And at the same time, if we’re going to look at the whole internet asking all of the SEO agencies to be as advanced as we are when we only do technical SEO and we specialize in JavaScript SEO is difficult. And so this is a crack, and I don’t have any solutions, and I’m not blaming Google or anything like that. I’m just saying that this is a change that’s happening, but it requires time. So there are some maybe more than some moments when it basically requires goodwill from both ends. So if devs want to understand it, and we want to explain it, we’ll make it happen.

MARTIN: I think there are lots of touchpoints where you can actually create this understanding and this cooperation. Because, as you said, there are lots of complexities and lots of background and lots of considerations. So if you are asking me, and this is also tricky for us Googlers, because if you’re asking me a question like is JavaScript OK? Then, in general, yes. Is it the best idea? No, not necessarily. If you can do it without JavaScript, do it without JavaScript. Server-side rendering is a recommendation that we give out as well. We need to make that more prominent in our docs. I’ve taken that point. But I really like the point where you said like, oh, so SEOs have this challenge that when you get a new SEO to join your team, they need to spend so much time on actually getting the knowledge that they need to work. Developers have the exact same challenge. Because the entire industry, the entire ecosystem, just keeps moving and keeps changing. So someone who becomes a developer today sees everyone else working with so many tools and so many things. And there is a tendency to skip the understanding. Because most developers who have been around a couple of years have started with some tool, learned the things that this tool does well and these things that this tool does not so well. And then they might be like, oh, you’re building a news website. I think in that case, with the interactivity that you described to me, we might be able to just do this better with server-side rendering. Whereas, if you want a highly engaging social network, you might actually want to use a client-side rendering for all the interactivity that is embedded, and that is not necessarily impairing your performance in search. So they learn these tools, and they learn the trade-offs, and then they make better decisions as they grow. But then people come in and might skip the entire learning process and go like, oh, everyone uses this framework, so I’ll build everything in this framework. Because if everyone uses it, it must be fantastic, without understanding the decision-making process behind it. And I think which is then exacerbated is the problem that if an SEO who cargo cults recommendations that they read or heard somewhere without understanding the background and the complexities they are encompassing to a developer who does the same thing, then there must be a clash. Because now they are running into territory where they think they know what they are doing when they actually don’t really know what they are doing. Would you say that might be a challenge that we are seeing playing out?

Complexities and differences between technical SEO and content marketing

(10:25) BARTOSZ: So let me unpack that one by one. There are a few statements within that. So, for example, the way you described the news website, you and I have known you for a few years. I know you’re not going to take that the wrong way. So most of our clients wouldn’t understand what you said. So if you’re talking to the key stakeholders, I’m assuming maybe not the CEO, but you know CMO, someone who’s making that decision along the lines, you will have this conversation. This is one of the problems that we were doing back in the days when you would hop on a call with five people from our client’s company. And we would start talking to dev, and you would lose everyone else. So simplifying that as much as possible is just it has to happen, so then everyone is kind of included in this conversation. But secondly, what you mentioned about dev teams is that this is so dynamic. This is also how SEO looks like. Maybe some SEO agencies didn’t realize it. I don’t think too many. So if someone is coming to us with a question, can you do a JavaScript SEO, web performance, and a little bit of content marketing? So this is extremely difficult to pack in one agency and do all these things well. So I think that we slowly need to normalize using a technical SEO agency, for one thing, using a content marketing agency for something else, and just trying to branch out so then everyone understands their goals. And then onboarding that one person is easier because that junior SEO, she only has to learn like JavaScript SEO, web performance, whatever, crawler budget, understand those technical aspects. At the same time, some agencies want those people to also do link-building and all these other aspects. So just like with devs, it got so complex. Sometimes I’m looking at job offers for devs, and I’m like, what does it even mean? 

MARTIN: Basically, one job offer is an entire IT department. I love it.

BARTOSZ: Basically, you need to divide organizations into aware in the web space and those that are not aware. And then if we’re going to so if someone is aware of how SEO works like it looks like what’s the difference between CSR and SSR, I’m assuming a lot of even high-level people in some organizations like for example, Germany is pushing a lot of people in the management position to know a lot about development, which I love. Talking to companies from Germany, most of the time, they’re just so aware of that. Some other companies would come to you and say, so if we’re going to fix this problem with rendering or with web performance, how much traffic can we expect and when? And that’s the main topic of discussion. And this is something I have daily, two-three times a day, that I have to answer. And this is usually showing me that there are so many ways to answer this question. Like, I never do that the same way. But anyhow, this is showing me that maybe they need a little bit more help understanding what has to be done and why it’s done. Sometimes it’s just beyond our scope of work, let’s call it that, that we cannot push them.

Web performance metrics and reaching stakeholders needs and wants

(13:35) BARTOSZ: So now that we have that, let’s assume we have someone that’s aware of or willing to learn about why we’re doing that, about– that “why” is kind of important here. Because if they only do that for traffic, and that’s the only KPI they look at, it’s very difficult sometimes not to skip a lot of important metrics. If you look at that, you can have a ton of traffic, and this is still going to be a terrible website in theory.

MARTIN: So are you saying that sometimes you literally have to rethink an organization’s KPIs?

BARTOSZ: Yeah. Very often, we would have just to give you an example. We have a call with a massive company, and they would be asking us what do we have to do to rank for the term “houses”? And just this question lets you unpack so many problems with the whole organization. And then we usually don’t want to offend anyone. You don’t want to get their ego involved in that. But at the same time, you want to explain that. And so that’s one. Let’s assume we have the stakeholders sold on the idea of what we want to do. They understand that. That’s amazing. That’s usually when things start to go well.

MARTIN: That is great. Because that also unlocks the possibility to basically have them on board with whatever the dev team will be doing about it. These things have basically been invisible to me. But as a developer, I just noticed that the stakeholders, the key stakeholders in the company that have an influence on the dev team, told me to do one thing, and then SEOs or marketing told me to do another thing. And then usually I picked the organization goals because that’s what I was measured by. So you are saying by bringing in the key stakeholders and making sure that they understand what they need to look for and adjusting their KPIs, you unlock the key to actually getting the development team on board with what you are trying to accomplish?

BARTOSZ: Yes and no. So usually, we don’t really– like as a technical SEO agency, we don’t struggle that much to get devs on board. This is not that big of a deal with us. The problem is for the stakeholders to understand what we want to do with them. Because sometimes, it’s like this is this technical SEO agency, and this is our dev team. Let them have fun with this project. And like almost literally, that’s how that might look in some cases. And this is usually a problem. But then if we know, OK, we want to get here. And this is the umbrella term. We want to have amazing web performance. We want to get rendered, indexed quickly, whatever. And they know that. I don’t even imagine how this could go wrong because the whole organization is just growing in one direction. And this is our Holy Grail, and this is happening very, very often.

MARTIN: How do you get that to happen? Because I have been in so many organizations where that did not happen.

BARTOSZ: This is a very simple answer. We did it wrong so many times. So we tried for years. Because when we started back in, I think 2013, ’14-ish, we wanted to focus only on the technical aspects of my team and me. People would make fun of us. They would be OK, there are white hat SEOs, and there are people who have traffic and all of these kinds of amazing jokes going our way that you cannot really. I can create a stand-up show for you with just the feedback we would get from the SEO community back in the day, basically moving to a technical side of things only.

MARTIN: Bonus episode right there.

Meeting with stakeholders, finding problems, and SEOs listening to devs to find solutions

(17:22) BARTOSZ: This was very weird for a second. Usually, we start with stakeholders. I’m going to condense this really quick. We talk to the stakeholders. We hop on the call before creating any offers or anything. We hop on the call and talk about what’s the KPI? What’s the problem? What are the challenges? Why are we even doing that? Why is it so important? Why do you want to fix that? Because if traffic is the only metric, we still will work with them, but we know how this might go. So we’re going to start with that. Then after the call, we look into their website. We create a statement of work. So we tell them, OK, this is what we’re going to do. This is the list of problems we’re seeing with your website. This is how we want to fix it and prioritize it. So the first month, we solve all of the most terrible aspects, like 404s or, I don’t know, 10 seconds to load a page, whatever. And with that, it’s extremely transparent. Because we tell them, OK, this project is going to take four months. We’re going to hop in, and now this is actually a spoiler alert. We’re going to hop into a PM, so like Jira or Trello with your dev team, and we’re going to make it happen.

MARTIN: OK. So you meet the dev team where they are anyway.

BARTOSZ: And we adjust to whatever solution that they go with. So if they work in sprints, we try to join that. However, this is, we had to kind of morph into this team that joins them without any interruptions. So this is the only way. We are aware that, like in a medium or large company, the dev team is seriously the most important part of the business. So then we tell them, OK, this has to be fixed. But we have to understand their tech stack. We have to understand all these boring aspects boring, like, we loved it. But usually, during that call with stakeholders, they don’t really want to talk about it, or they don’t know. Very often, stakeholders have no idea what kind of tech stack they are running.

MARTIN: To be fair, they should not have to, right? That’s something unless it’s like the CTO. I don’t think the CEO needs to know which tech stack they’re on as long as they know what their core business is, how it works, and what’s the vision? What’s the mission of the organization? I think that’s exactly what you have a development team for, to define these things based on requirements coming from elsewhere.

BARTOSZ: One more conversation that we have to schedule. But let’s move forward with that. Then we hop into Jira, Trello, whatever. We give them tasks. And they come back to us. Like, we cannot really do that. We have a custom solution around this one that doesn’t allow whatever. So then and again, we have a team that’s extremely technical. This is something we have been building for a few years. And they hop on the call. We either sometimes, when they really don’t get that, and this is an edge case, we write a snippet of code just to show them how to optimize the CSS or whatever. But most of the time, we just go and talk to them. And they would like devs, in my opinion, they’re very hardworking people. And they would tell us. We cannot do this. We have so many limitations. And we try to work within those limitations. If we hit the wall, we go back to stakeholders and say, maybe we could try to, and devs appreciate that. Because someone is really it’s not only them coming to stakeholders for budget, for more resources, whatever. But we’re going to come in and say, OK, guys, this is going to be difficult with so many places where you cut corners.

MARTIN: So you would say that you would also have to somehow support developers to get the right resources and to get the right environment to work in sometimes? That’s interesting.

BARTOSZ: Sometimes. Sometimes. This is going to sound funny. But sometimes we have clients who have 50 devs, and not in a country where there would be cheaper, but 50 devs in a very high-earning city somewhere in the world. And they would listen to us rather than to them because they are like, oh, we’re paying your invoice. We want to get the most bang for our buck. So because of that and they would tell us that openly we want to really move this project forward. And that’s why they would change things around in the dev team. And I guess you have to know that out of all people. Sometimes when you work in a team, you come to your manager, and you say, OK, this is a problem every day. They won’t listen to you until someone from the outside is going to come in and say, like, dude.

MARTIN: I’ve been there. I’ve done that. I’ve been on both sides of this. I’ve been the consultant that came in and basically just sat down with the development team, listened to them for a day, and then presented what I heard to the stakeholders. And they’re like, oh, these are really valuable insights. And I always thought, I’m billing you for this, but you could have just listened to your developers.

BARTOSZ: Exactly. And I guess every single dev listening to or watching this video series right now is going to have the story of this way, of this kind.

MARTIN: I’ve been on the developer side of that, too. It was like, hey, we need to do this. Oh, I don’t think so. And then I was like, OK. And then the consultant came in and said the same thing.

BARTOSZ: And also, just to elaborate on this story, we have usually once a quarter we have someone reaching out to us. Usually, the dev teams we know, saying “Partners, when we need an audit around core vitals”. But don’t go too deep. We just want them to hear what we told them from someone else. And they’re willing to spend the budget just to have a backup document just to say. We need to fix this.

Always ask questions

(23:36) MARTIN: But that is so smart. I really like that. Because so many developers are like, ugh, I don’t want to work with these people because they just tell them what we told them already, and they charge them for it. Why don’t developers more often leverage these external voices like they do in your case, where it’s like, Bartosz, I need this audit. I know the result of the audit, but please tell them what we already told them because they don’t listen. That is smart. I like that.

BARTOSZ: If there’s any SEO agency listening to that, or SEO like someone frustrated with dev teams. 100% honest. We don’t struggle with devs. Talking to them openly, speaking their language, and you might have to get a little bit of technical, or maybe just have one or two people on your team who can get the message across.

MARTIN: Oh, and just to add on to your last point, and that goes to all the SEOs out there listening, struggling with developers, lose your ego. It is not a problem to ask us developers questions. It’s like if you think that you need to know everything, no, you don’t. You’re not a developer. It’s OK. Developers don’t know about SEO. You don’t have to know everything about development. So if you don’t understand why they can’t do what you ask them to do, remember that developers are intrinsically motivated by or to solve problems. That’s what they love. That’s what they want to do. So if you give them something to solve, they’ll be excited to solve it. And then they hit the limitations, the limits of what they can do in the tech stack in the environment that they are in. And then they tell you, I can’t do that because of XYZ. If you don’t understand XYZ, that is OK. Ask clarifying questions until you get there because you, and I think, Bartosz, you said that very nicely, you may have to simplify that message that comes from the developers so that other people who are not developers in the organization that you work with understand why it doesn’t work.

BARTOSZ: Let me just build on that. And this is something that all the SEOs are going to love. We had that vision years back that we had to learn all of the frameworks. We have to know front and back and whatever. It was so stressful. Like, I was learning all these like, I was trying to know it all. But this is something leave it to devs. What we have to do as technical SEOs, we have to have an in-depth, massive understanding of how rendering works, how a browser works, how Google is rendering and what they render, like, rules around that. Chrome DevTools has to be your go-to place. And you need to understand what’s happening, and once you understand that, you add a little bit of documentation from different frameworks, from different technologies, but don’t learn how to write all of this code. Obviously, basics are OK, but basics. This is what they pay you to do. They don’t want you to know what they know. So you have to know this is complex enough. Understanding how a browser works step by step is something you can do for the rest of your life and never have enough of learning. Just wanted to add now we were talking from the SEO standpoint with the ego. If you own the company, if you’re on a dev team, go through a lot of agencies. Talk to them. Hop on the call with them. Ask them questions. See if you understand what they’re trying to do. If you’re talking to an agency that’s going to tell you nothing about the scope of work, what they’re going to do, and how they’re going to do that, this would raise a red flag. If you go with your car to have it fixed, and they won’t tell you what they did, I would be worried about driving this car. So basically, go through that. Talk to as many people. As soon as you feel the vibe, “OK, these guys, they understand what we want to accomplish” and get this conversation going.

MARTIN: And the same the other way is absolutely true. Developers really don’t like it when someone comes like, hey, you need to do this. And then they ask you why? And then they don’t get a proper answer. You can do the same thing with developers. If you say, hey, I want you to implement the canonicals. And then they say, we can’t do that. Then ask them why. If they say our solution doesn’t allow it. Then it’s like, why does it not allow you, like, does it not allow you to add anything to the head? Oh, it does, but not the canonicals. Why not the canonical? It might be just a knowledge gap on their side, or it might be an actual hard technical limitation of the environment and the stack and the platform they’re working with. But they need to be able to explain this to you in simple terms. If they are like, oh, it’s algorithmically impossible, that’s just a developer’s way of saying, bugger off. Ask questions. Don’t think like, “oh, they said something that I don’t understand, so I must stop questioning here”. No. If they can’t express it in simple terms so that you understand what they mean, they haven’t done the work themselves either. So hold them accountable, but be ready to be held accountable, too.

BARTOSZ: Yeah. Just wanted to hop on. We don’t know the stuff very, very often. We have five calls per day with five different stacks. Some we never heard about. So if we don’t know something, we’re very open about it. We have no idea what we have WAMP PWA recently. I was like, I never heard of WAMP. We just went and read the documentation, came back, and scheduled a call. Like, now we can talk in the same language. Again, this is an ego thing. You don’t assume that you need to know stuff. I’m very open about things I don’t know. There are tons of them.

MARTIN: I mean, even I was asked recently at a core vitals session, I was asked questions that I don’t know the answer to. I won’t give you a random non-answer or try to mettle my way through. I just say I don’t know, but I can check.

BARTOSZ: Yeah. And one thing that I feel is a deal-breaker between devs and SEOs a lot of times, and we back in the day were guilty of that as well, is devs will ask you a question of, why shouldn’t we just point canonicals to a page that’s most important, so we sculpt we push the most important page with different canonicals because this is just like a link. They would have all these ideas as well, like both SEOs and devs, on how to cheat the search engine. Yeah. SEO, you have to explain that step by step. But if we’re talking about SEOs and devs, we need to leave all of the conspiracy theories or urban legends behind. Just fall back on documentation, and that’s it. Because as soon as open the door into, if we point some canonicals here, or if we do this, or if we do that, some things might happen. We heard about it. We tested that. This is going to put you in the shoes of those snake oil salesmen. So be technical. If you’re talking to devs, be technical. Drop all of those. Even if you deeply believe this is the case, I think this opens the door to what we as SEOs want to run away from.

MARTIN: Another thing is if you are not very technical, that is perfectly OK. But then don’t try to find solutions because you are in a territory where you are not necessarily experienced. And if you are not just basically present the problem, and then work with the development team to solve that, don’t try to come up with a solution because it’s likely that your solution will not work in the tech stack or the environment that your development team works in. And then if you are getting attached to that solution, you’re like, but why can’t we just do it like this? It might not get through to the development team the right way, and it might feel like you are just obsessed with something rather than actually trying to solve the problem. And that’s what development teams need to do. So you want to be on their side, and you want to it’s OK to go the way together like basically, to research options, to experiment with things together. But trying to come up with a turnkey solution for development teams usually backfires.

The start of technical SEO and web developers working together

(32:30) BARTOSZ: Just one thing that I hope is going to clean the air a little bit. Technical SEO is fairly new. It’s maybe three, four, or five years old. Obviously, some will argue that this was because I was doing technical SEO in 1993. But it’s fairly new in the way that this is getting so popular. It’s getting so needed. It’s almost essential. So this is a brand new field. And if you look at that and drop all of the histories, this is going to get really exciting. Because now, I would assume that devs and SEOs will only get closer throughout the next few years. Because obviously, we’re all seeing the need for technical SEO.

MARTIN: I think that would clear the air. And for all of those who are scared and confused now on the SEO side, don’t be. You get to choose if you want to get into technical SEO or not. Technical SEO is a field of its own. It is complex. It is big. It is broad. It is new. It is fresh. But I think content still is an important field, and all the other things, all the other aspects inside SEO, will not become irrelevant or anything. It will continue to be a broad field. You get to pick your niche. But if you want to go technical, do it right. I think that’s a very, very nice way of looking at it.

BARTOSZ: And go technical.

MARTIN: Go technical. Awesome. Thank you so much, Bartosz, for joining me in this conversation. I think this was really interesting and insightful. And I hope to see more from you guys and also to hear what the community is saying about these things as well looking forward. Stay safe, stay healthy, everybody.

Sign up for SEO & Web Developers today!

Is SEO just another constraint?

(0:59) MARTIN: So you are saying that for you as a web developer, SEO is just another constraint. What do you mean by that?

SURMA: I mean, as web developers, as far as web development goes, we and I are pretending to be a representative of all web developers, which I’m clearly not. But the usual struggle involves stuff like, how many browsers do I support, or how far back in the browser versions do I go? Do I support IE11? Do I not support IE11? How do I polyfill certain things? Do I polyfill them, or do I use progressive enhancement? What kind of implications do both of these choices have? Do we actually make design fully responsive? Do we do a separate mobile site? Like, there are all these choices that I already have to make. Four and then now frameworks come along and are like; we’re just going to do most of the stuff on the client-side because we want to write a single-page app. And then you either have to say, do I set up something for server-side rendering or static rendering and build time, or do I go all-in on the single-page app, and just everything happens on the client? What do search engines think about that? And then search engines come in like, well, you should be doing this, and you should not be doing that because that gets penalised. And actually, we don’t even understand what you’re doing here because search engines are running Chrome 12 or something. And it’s just like it’s yet another constraint that I have to balance and make decisions on whether following their restrictions is more important or following my business restrictions, my marketing restrictions, or my project management restrictions. And I feel like some people are frustrated about that sometimes.

MARTIN: I remember when I was a web developer, there’s also this entire user first no, mobile-first, no, content first, no this first, no, that first. That’s probably also going in the same direction, and I understand the frustration. And I see that there are lots of requirements, and sometimes these requirements might even contradict each other. But I think as developers, we should understand what SEOs are trying to help us with and what search engines, separately from what we are building and doing, are actually trying to accomplish. And then we would see that it’s basically all of these requirements are important, but maybe some of them are more important than others, and they are important in different stages, I would say. So, for instance, you mentioned mobile-first versus or a responsive design versus having separate versions, right? I would say that’s a decision that you need to make relatively early on, right? In the technology process before you, yeah, whereas then should I use this feature, should I polyfill this feature, should I not use this feature because I need to support an old browser that doesn’t support it, and the polyfill is tricky, that’s something that probably happens a little later in development, right?

SURMA: Yeah, I think I agree with that. It depends on how much flexibility you’re given as a developer. I think we all may or may not have lived through the experience of working with a designer who insists on a pixel perfect design, which is just not something that works on the web, but sometimes, you’re given a task, and your job is to complete it and not have an opinion. I don’t want to go down. It depends on the route. But in the end, we won’t get whatever we end up talking about. We probably won’t find a definitive answer. Like context matters, and everyone has different constraints. And I think that’s really what it’s about that you need to just be aware of the constraints that you have and make decisions in the context of your situation.

SEO – friend, not foe

(04:41) SURMA: You mentioned something that I find quite interesting. You said SEOs are trying to help us with something because often they’re kind of like villains, almost like the people who just try to get you to the top of the rankings, whether you deserve it or not. But in the end, I feel like there is help going on. Both search engines, as well as the people that want you to do well in the search results, actually are trying to make your site better in the end. Like no search engine actually wants to give you results that are bad. That just doesn’t make sense. In the end, search engines are trying to put the best results on top. And if an SEO helps you get on top, then ideally, what that means is your site has gotten better. 

MARTIN: Yes, exactly. And I love that you are saying, like, oh yeah, you have to look at the context. You have to understand the constraints. And that’s actually something that a good SEO will help you with because if you look at it from a purely SEO standpoint, depending on what you’re building and how you’re building it, you might have different priorities. So, for instance, if you’re saying, oh, this is a test version of a landing page. We just want to see if the customer segment is even interested in what we are potentially building later on, and you don’t want to build for the bin, right? You don’t want to build something that then, later on, you find out doesn’t actually work because there’s no interest in it. So then, for these things, SEO might be relatively important because you definitely want people to find that so that you get enough data on making decisions later on. But you might not be so constrained in terms of oh, yeah, this has to be client-side versus server-side. We don’t really have to make this super fast. We just have to get this into people’s faces, especially through search engines, so that we get some meaningful data to make decisions later on, versus you’re building and improving on an existing product, and that should belong evitable.

Building better websites for everyone

(6:33) MARTIN: So, a good SEO helps you understand what kind of requirements you should take into account. And SEO is a gigantic field, and they should pick the bits and pieces that actually matter for your specific context. So you said like, oh, we want to build a single page application. Maybe. Maybe you do, maybe you don’t. Maybe it’s fine to build a client-side rendering, but maybe consider doing some bits and pieces of server-side rendering because you reap some performance benefits there. And that also influences SEO because, as you say, search engines want to find the good things. So making your site better includes making it faster but also making it accessible because if you think about it, search engines are computers interacting with your website, working through your website and trying to understand what your website says. So they have basic accessibility needs. They don’t necessarily interact with things. They don’t click on stuff. And yet they need to work with your content. So it should be accessible to them. And SEOs will point these things out.

SURMA: That’s really interesting that you bring that up because I was just thinking about both performance, like loading performance, for example, and accessibility. So, on the one hand, it’s kind of accepted that loading performance is important. But now that, for example, we have Core Web Vitals. And one of the core ones of their core statements is that they don’t want to just put a number on a metric or something that’s measurable. They want to measure things that are important to user experience. And so the Core Web Vitals that we currently have, which is just three metrics, LCP, CLS, and FID, right. All of these are statistically correlated to users enjoying the site more or staying on your site longer. And that means if you optimise for those, you actually will get something out of that. You will get users that stay longer. And now that search is looking into those, it means optimising for those metrics not only gets you higher in the rankings potentially but also the people that do see your site will most likely stay longer or engage with it more because we know that these metrics correlate with user behaviour. And I think that’s a really interesting approach, wherein, in the end, actually search engines are helping you do the right thing. And now I’m wondering which I don’t even know like accessibility is something, which we keep talking about, and we know it’s important. And yet it feels like it always falls off the truck. In many projects, it’s an afterthought, and many people know that it needs to be something that needs to be considered from the very beginning of a project because it’s hard to shoehorn in at the end. It needs to be something that works from the start. Has any search engine ever done anything in this space to help developers be better with accessibility?

MARTIN: We are more or less going in that direction, not necessarily from a purely accessible standpoint, but as search engines need to semantically understand what the site is about, we just don’t take the text and take it as plain. We basically try to figure out, oh, so this is a section, this is a section, this is the section that is most important on the page. This is just an explainer for the previous section and so on and so forth. For that, we need the semantics that HTML gives us. And actually, these semantics are also important for accessibility oftentimes because people need to be able to navigate your content differently, maybe with a keyboard, maybe with a screen reader. And for that, the semantics on the page need to be in place from the get-go, basically. So in that direction, having better semantics does help search engines better understand your content and, as a byproduct, also help people better navigate your content who have additional navigational needs. So you could say search engines are a little involved in terms of accessibility. That does not cover accessibility as a whole. There is so much more to accessibility than just that. But at least in the core of the semantics on the web, that is taken care of here. 

Keeping up with web development trends is important for SEOs

(10:37) MARTIN: Another thing that I really found interesting is where you say, oh, you know, SEOs are often seen as just coming with all of these additional constraints and requirements. What is there that they could do differently that you would think would help you and other developers understand where they’re coming from or have a meaningful discussion about these things and turn that into a positive, constructive input?

SURMA: I don’t know if this is the answer you’re looking for, but one thing I have seen is that some SEOs need to put a bit more effort into being up to date on what is good and what is not good guidance, or more specifically, what search engines are and are not capable of processing correctly. I think– I know that you have been fighting the no, no JavaScript is the fine fight for a long time now, but I think to this day, there are still some SEOs out there who insist that anything that is in JavaScript is invisible to the search engine. I think in general, I think it goes back to the trade-off thing, where I think web developers need to realise that SEOs are trying to help you be better, and SEOs need to realise that that they can’t give advice as a either you do this, or you’re screwed kind of approach. Like, it’s a trade-off. You can say that this is one way where you can make a site better. This is another way, and this is yet another thing you can do. And all of these things will accumulate to make your site better, ideally resulting in giving you a higher rank. But it’s not like an all or nothing approach, I think. Sometimes certain constraints just outweigh other constraints, and you then make a decision to go with plan A rather than plan B or stick to what you currently got. We have recently seen a lot of shifts from purely client-side up to like this hybrid approach, where the app is rendered on the server-side or even at build time but then turns into a single page app once loaded onto the client, and that has upsides, and it has downsides. Like we know that statically rendered content is very good for your first render, your largest loading time, that all goes down. But now we have this additional blob of JavaScript state that is somehow inserted into the document, and then often, the full dynamic client-side re-render happens, which can create an iffy user experience at times. And all these things are working for or against you in certain aspects. And I think that’s just something that the SEOs need to be mindful of as well, that the developer cannot just follow everything that they say because they’re different; they’re not the only deciding force on a project. I’m not saying that all SEOs behave like this, of course, because I’m honestly quite inexperienced in working with an SEO directly. But just based on stories that I hear and people that I see on Twitter, it’s all a trade-off. And I think people need just to realise that everyone is in 90% of the cases trying to do the best they can and do their job well. And just keep that in mind. And then probably find a solution that works for both or is a compromise.

Change your perspective

(13:57) MARTIN: Yeah. No, that makes perfect sense. And I wish that both SEOs and developers would look at it from a different perspective. Like both SEOs and developers want to build something that people are using, right? You don’t want to build something and no one uses it. That’s neither going to pay your bills very long. Nor is it making you happy to see like, oh, yeah, we built something that helps many people. That’s true for me. When I was a developer, I wanted to build things that have an impact, and that means that they need to be used by someone. And if we are building something that we genuinely are convinced is a good thing, then that should be reflected by the fact that search engines would agree on that and say like, oh, yeah, this is a good solution to this problem or this challenge that people might face and thus want to showcase your solution basically. But for that, there needs to be something that search engines can grasp and understand and look at and put into their index accordingly. So basically, they need to understand what is the page about, what it offers the users, is it fast, is it slow, is it mobile-friendly, all these kinds of things. And SEOs are then the ones who are– because you as a developer are focused on making it work in all the browsers that it needs to work in, making it fast, using all the best practices, using tree shaking, bundle splitting, all that kind of stuff. And then SEOs come in and help you make sure that search engines understand what you’re building and can access what you’re building and that you are following the few best practices that you might not necessarily be aware of yet. But you are right. For that, SEOs need to follow up-to-date best practice guidance, and not all of them do. Well, at the beginning of 2021, I ran a poll in one of the virtual events, asking if people were aware that the Google bot is now using an evergreen Chrome. So we are updating the Chromium instance that is used to render pages. And I think like 60% of the people were like, oh, I didn’t know that even though we announced that in 2019 at Google I/O in May.

SURMA: How was that?

MARTIN: That was amazing. I mean, launching this has been a great initiative. But I’m surprised that I think we have gotten developers to notice that, but not necessarily all SEOs have noticed. And it’s things that are not necessarily easy or not even your job as a developer, where SEOs can really help you or at least make the right connections for you. For instance, I know you build squoosh. The app, right?

SURMA: Well, not just me, but I was part of the team that built it.

MARTIN: Right. You were part of the team who built squoosh app. And I think squoosh.app is awesome. For those who don’t know it, it’s a web app that allows you to experiment with different image compression settings and then basically get the image that you put into the application in your browser. It’s all working from the browser. You don’t have to install anything. And basically, get like the best settings for the best gains in terms of file size, right? That’s roughly what it does.

SURMA: Yeah. It’s an image compressor, and you can fiddle with all the settings and can try out the next generation codecs now that are coming to the web. But yeah, you have more control than I think any other image compression app that I know.

MARTIN: And it’s really, really cool, and I really admire the work that the engineering put into this, that all the developers put into this to make this work so smoothly, so quickly, so nice. It implements lots of best practices. But for a search engine, if you were to sell that as a product, this might not be very good. And that’s because if you look at it, it’s an interface that allows me to drag and drop an image into it, and then it does a bunch of stuff in terms of user interface controls to fine-tune settings. But if I was robot access that page, it’s a bunch of HTML controls, but not that much content, right?

SURMA: Agreed. 

MARTIN: So would you want to have to sit down and figure out how you would describe this and how you probably don’t want to do all that work by yourself. You want to focus on building cool stuff with the new image algorithms and fine-tuning how to make the settings work better or more accessible, or easier to understand, right? That’s where you want to focus on.

SURMA: Yeah. And I think I actually would like to get help from someone who knows whether this site like I wouldn’t have been able to say if like I think our loading performance is excellent because we spend lots of time on making it good and trying to pioneer some techniques. But I wouldn’t have been able to tell you whether it gets a good ranking from a search bot or a bad ranking, to be honest. I mean, the name is unique enough that it’s very Google-able, so I think even if it didn’t do so well, people would probably find it. But in the end, it’s actually a very interesting example because you’re completely right. The opening page, because it’s about images, it mostly consists of images. The only text we have on the landing page is the name and the file size of the demo images, and the licensing link. So there’s not much going on for a bot to understand what the site does, especially because something this specific, there’s not even much to do with semantic markup, as you said. Right, OK, cool, there’s an image and an input tag. You can drag and drop an image. But even that, even the drag and drop is actually only communicated via the user interface, not via the markup. And so yeah, that’s a really interesting example. Like, I would have no idea how to optimise. I would have probably said like meta description tag. I don’t know. And then John Miller told me that apparently, we don’t pay attention to the meta description tag anymore.

MARTIN: Well, we do. It’s the keywords that we don’t.

SURMA: Oh, the keywords are the one. OK, I take that back. Yeah, exactly. So I think you’re right that it’s very easy for developers to sometimes also guess what is good for SEO and what is bad and actually get input from someone who put in the time to learn what is actually going on. Keep up to date with the most recent updates. As you say, people apparently don’t even know that Google bot is now evergreen Chrome, which is amazing. So there are probably a lot of SEOs who go around saying like, no, no, no, no, you can’t use Shadow Dom or something like that, even if they know the JavaScript actually works. I agree. Get someone who knows.

Making things on the web is a team sport.

(20:26) SURMA: I mean, I’ve been saying that even as a very enthusiastic experimenter and web developer, one single person cannot really understand and use the entire web platform. It’s now so incredibly widespread in the areas that cover. So you can do web audio, web assembly, web use B, MIDI, and all these things. Like, you will not have experience in all of these things. And some of these holes, like WebGL itself, is a huge rabbit holes to fall into. So, pick some stuff. Get good at it. And for things you don’t know, get help because otherwise, you’re going to work on half-knowledge that might end up very likely going to end up making actually counterproductive for what you’re trying to achieve.

Sign up for SEO & Web Developers today!