Author: Erika Magpili

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!