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!
