How to Strategically Think About Technical SEO
The author's views are entirely their own (excluding the unlikely event of hypnosis) and may not always reflect the views of Moz.
We've all agreed that technical SEO is integral, and many of us know at least a little bit about the subject if we're not already practitioners. But have you considered that the way you think about technical SEO could be hindering or helping your success? Today, Ben Estes from Distilled shares the agency's tried-and-true framework for tackling technical SEO quandaries strategically.
Click on the whiteboard image above to open a high-resolution version in a new tab!
Video Transcription
Hi. Welcome to another Whiteboard Friday. My name is Ben, and I'm a principal consultant at a company called Distilled. Today I'd like to talk to you about how we think about technical SEO at Distilled. Now, technical SEO is something that a lot of people know a lot of stuff about.
You accumulate knowledge over time from a lot of different sources, and that's where a lot of the value that we deliver comes from. But not everyone can think about technical SEO from a strategic perspective, and that's the skill that I think we should talk more about.
Framing the problem
Let's start by framing the problem. So look at these charts. Now, I would argue that most people's mental model of technical SEO matches this first chart.
So in this chart, the solid black line is the actual traffic that you're getting, whereas the dotted line is the hypothetical traffic you could be getting if all of the technical problems on your site were resolved. So some people see this and say, "Well, you know, if I can just keep fixing technical things, I can keep getting more traffic to my site."
That's one way of looking at it, but I would argue that it's not the best way of looking at it, because really there are only so many technical things that can go wrong with your site. There's a finite number of problems. It's not an opportunity so much as an issue that needs to be resolved. So what I try and encourage my clients and colleagues to do is think about it in this way.
So it's the same chart and the same situation. Here's the actual traffic that you're getting and the hypothetical traffic you could be getting. But really what's happening is your technical problems are keeping you from realizing the most potential traffic that you could be capturing. In other words, there are technical issues preventing us from capturing all the traffic that we could. Now, once you've framed the problem in this way, how do you solve it?
So some people just say, "Well, I've got this big problem. I need to understand how all the things that could be wrong with this site. I'm just going to dive in. I'm going to go through page by page, and I'll finish when either I run out of pages or more realistically I run out of time or I run out of the client's budget. So what if there's a better way to actually solve that problem and know that it's been solved?
Well, that's what this framework that I'm going to present to you is about. The way that we would recommend doing that is by taking the big problem, the overall problem of technical SEO and breaking it down into subproblems and breaking those down again until you have problems that are so small that they are trivially solvable. Now, I'm going to explain to you exactly how we accomplish that, and it's going to be a little bit abstract.
The approach
So if you want something concrete to follow along with, I'd recommend checking out the blog post at this URL. That's dis.tl/tech-audit. Okay. So when you have a big problem that you're trying to break down, many people's first attempt winds up looking something like this Venn diagram. So we take one problem, break it down into three subproblems, but there's some sort of overlap between those problems.
Once there's overlap, you lose a lot of confidence. There is, are you duplicating effort across these different areas? Or did you miss something because these two things are kind of the same? Everything just gets a little hazy very quickly. So to get past that, what I've used at Distilled is this consulting concept called MECE.
Mutually exclusive and comprehensively exhaustive
MECE stands for mutually exclusive and comprehensively exhaustive. That's a lot of fancy words, so I'll show you pictorially what I mean. So instead of having a Venn diagram like this, what if each of the problems was completely independent? Now they still cover the same area. There's just no overlap between them, and that's what MECE means.
Because there is no overlap between them, they are mutually exclusive. Because they cover all of the original problem, they're comprehensively exhaustive. So what does this mean in technical SEO specifically? Now remember the problem that we're dealing with is that there are technical issues preventing us from capturing traffic that we would otherwise be able to. So what are the three ways that that could happen?
- Maybe our content isn't being indexed. There's a technical reason our content isn't being indexed.
- Our content doesn't rank as well as it could, and therefore we're losing this traffic.
- There is a technical reason our content isn't being presented as well as it could be in the SERPs.
This is things like having rich snippets, stars, things like that that could increase click-through rate. These things seem kind of trivial, but actually all of the technical problems that you can find on your site contribute to one or more of these three categories. So again, that was pretty abstract. So let's talk about an example of how that actually plays out. This is actually the first technical check in this audit at that blog post.
An example
So, for instance, we're starting by considering there is a technical reason our content isn't being indexed. Well, what are all the ways that that could happen? One of the ways is that URLs are not discoverable by crawlers, and, again, that is a whole thing in itself that can be broken down further.
So maybe it's that our XML sitemaps aren't uploaded to Google Search Console. Of course, this isn't a guarantee that we have a problem. But if there's a problem down here, there's a pretty good chance that that trickles back up to a problem up here that we're really concerned about. The beauty of this isn't just that it winds up helping us create a checklist so that we know all of the technical issues we ought to be looking at.
But it also helps us convey exactly what the meaning is of our findings and why people should care about them. So this is the template that I encourage my colleagues to use at Distilled. "We are seeing ________. This is a problem because something.You should care about that because something else." The way this works is like Mad Lib style, except we work like inside out.
So we start with this point here. We are seeing that our XML sitemaps aren't uploaded to Google Search Console. This is a problem because maybe URLs are not discoverable by crawlers. We should care about that because there is a technical reason our content isn't being indexed, and that right there is exactly the message that you deliver to your client.
So again, this is exactly the framework that we use for our technical audits at Distilled. It's given us a lot more confidence. It's given us a lot more insight into how long this process should take for our analysts and consultants, and it's also got us better outcomes particularly because it's helped us communicate better about what we found. Thank you very much. I would love if more people use this, and feel free to reach out to me personally if you have any thoughts or questions.
Thank you.
Comments
Please keep your comments TAGFEE by following the community etiquette
Comments are closed. Got a burning question? Head to our Q&A section to start a new conversation.