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!

GET IN CONTACT TODAY AND LET OUR TEAM OF ECOMMERCE SPECIALISTS SET YOU ON THE ROAD TO ACHIEVING ELITE DIGITAL EXPERIENCES AND GROWTH