We’re back for another episode of hot SEO takes! This week, we’re chatting all about technical SEO audits with two fantastic guests: Patrick Hathaway, Director at Sitebulb, and Areej AbuAli, founder of Crawlina and the Women in Tech SEO community.
Here’s what we’ll cover as we dig deep into insights for executing and sharing a well-prioritized, stakeholder-friendly technical audit:
Have burning #SeoQuestions? You can always drop us a line at https://thegray.company/ask-seo-questions!
Begüm Kaya 0:10
Hello, everyone. Welcome to another episode of Opinionated SEO Opinions™, where we're going to discuss everything about leveling up technical audits. We are here today with Areej AbuAli, founder of Crawlina and the brilliant mind behind the Women in Tech SEO community. Hello, Areej!
Areej AbuAli 0:29
Great to be here!
Begüm Kaya 0:30
Yeah, thank you so much! And we are joined by Patrick Hathaway, Director of Sitebulb. Hello! That was a very quick intro, but would you like to elaborate on that, Patrick?
Patrick Hathaway 0:45
Yeah, so I'm Director of Sitebulb, which is a website auditing tool, like a crawler. I haven't done a tech SEO audit for at least five years that I've given to a client. However, since our tool is designed to produce website audits for people, I have lots of opinions about them.
Begüm Kaya 1:07
Yes, and we're all about them. Let's hear more.
Tory Gray 1:11
We're excited to have you both here today. Thank you so much.
Begüm Kaya 1:15
Yes, welcome. So I'm just going to jumpstart with the first question, which is, "as we know, there are many approaches to technical SEO audits. What would your definition be?"
Patrick Hathaway 1:29
Yeah, okay, I'll go. For me, a technical SEO audit is about the identification of technical issues or opportunities, that could have an impact on the site's ability to be crawled, indexed, rendered, or ranked. I like to treat the process as an exploration. I hate checklists and frameworks, and I'm not into that stuff. I like just sort of having a poke around and pulling at loose threads. Ideally, I'm looking for a rabbit hole to fall down. That's what a website audit is to me.
Areej AbuAli 2:04
Yeah, I like that you use the word opportunities. I was just chatting about this recently with someone, and they were going on about, "well, we identified this number of issues in a technical SEO audit." But I think, you know, that's the kind of thing that just right away brings up that negative mindset of, "we're here to tell you everything wrong with your website," when it should actually be the opposite. It's about uncovering what the opportunities are for the website that you're auditing.
Patrick Hathaway 2:30
Yeah, totally. They do come in all shapes and sizes, audits as well. You know, you can't treat any two websites identically the same. It just can't work like that, right?
Tory Gray 2:43
That actually leads us into our next question. What would you say differs in terms of the process or the prioritization around large websites versus very small websites — and all those things in between?
Areej AbuAli 2:55
I'm happy to talk about this for a bit. Like I personally prefer, in general, auditing and working on large websites. They're just more exciting. But to be honest, it's very similar, because it's never about, "oh this website has 100 million pages, and this website just has 1,000 pages."
Areej AbuAli 3:13
At the end of the day, every, single website is going to be split into a number of templates. There's going to be like 5 to 10 primary templates in any given website, and what you're auditing is that specific template. You're trying to uncover what's happening in that template. Is Google able to crawl it, index it properly, and so forth? So it's very, very similar. You know, if you're working on a large website or working on a small one, it's never going to be about, "oh, this has these number of pages." I like to kind of think about it this way on a template-by-template basis.
Patrick Hathaway 3:50
Yeah, I'm a big fan of the template approach as well. I think that one of the things that is different with bigger websites is that, you know - or at least a lot of the time - things are changing all the time. Recommendations today might not make sense in three, six months time. Whereas with small websites that are relatively static, the things that you recommend today are probably still going to be valid in three to six months time. And I think with small websites, it's perfectly possible to audit the whole thing — essentially, uncover pretty much everything that you wanted to uncover. Whereas with bigger websites, the discovery phase is so much bigger, right?
Patrick Hathaway 4:38
You have to work through crawl optimization, iterative crawling, trying to figure out how you get something that's meaningful at the end of that process. And like you say, looking at templates, but also sampling, right? So just picking a section of the website we're going to crawl. We're not going to call all of it. We're only going to crawl this chunk of it and make a bunch of decisions or recommendations on that. Roll it out to everything, then have another look. That sort of thing.
Areej AbuAli 5:09
I think I used to have that obsession or that mistake when I first started in SEO, where it was like, "how have I not been able to crawl the website at 100%?" Which, you know, I came to realize afterwards, it doesn't matter. Like a sample is more than enough. I like that in Sitebulb as well because you get the option of specifically saying, I just want to crawl a sample of the site for example.
Areej AbuAli 5:32
But yeah, the other thing as well, I feel like with larger websites you could uncover this one massive, big technical thing that has made this massive block. And once you fix that, you do see the impact right away. With smaller websites, a lot of the time, it's, "we need a lot more content than we currently have." I feel like technical hurdles and technical debts and technical legacy issues and so forth — you tend to find those more with larger websites, at least in my experience.
Tory Gray 6:11
I find them to be somewhat different, because I just feel like there's less that can go wrong the smaller the site is. So if you're starting from a baseline of "small" means 1000 pages, then maybe it's less different. But if you're talking a 10-page WordPress site, like okay, I'm not going to do a full blown technical audit. I'm just going to do a crawl and say these are the things. There's just a limit. Or are we going to do a full blown site-speed analysis or performance analysis on, again, the 10-page WordPress site? Like, how much traffic are you driving? What is going to be the win from that? I just don't think it's going to be there.
Tory Gray 6:44
Patrick Hathaway 7:22
Totally. I was gonna say that, as a consultant, you have a much bigger opportunity to have an impact when the site's bigger. And show value, right? I mean, reasonably regularly we'll get support queries that come through on site where the website is — you know it's like an in-house or owner of the website — sort of so small, that they don't even need a tool like Sitebulb. You know, like a relatively cheap piece of software that's giving them technical audit information.
Patrick Hathaway 7:58
And like you say, when you've got a site that's not very old and it's not got much content on it, there are much more impactful things that you can be doing. So you don't really need to, as long as the foundations aren't completely broken, use the free trial. Make sure it's not completely completely screwed up and then go make some more content. You know, go and focus on your brand. Go and focus on your audience. Don't worry about this for a while.
Begüm Kaya 8:31
Yeah. The smaller the website, the more chance that it's relying on a CMS or is placed on a CMS, so all the issues are much easier to target. And you usually work with the developer to handle them very quickly. It's rather easy, and yeah, lots of other things can be prioritized. And that brings us to the next question, what would be the best way to prioritize the issues and opportunities that you discover?
Patrick Hathaway 9:05
I'm a big believer in doing a lot of upfront work before you start auditing a website, so that you really understand the context. So whether you're dealing with a site where the traffic's been falling for months, or it's just gone through a site redesign, or they've entered a new market... I think then how you approach the audit and which issues you prioritize should be guided by this context. And then, beyond those sorts of considerations, I think it comes down to like the scale of the potential impact of the issues you find.
Patrick Hathaway 9:45
If you know the business focus is dealing with category pages or whatever they're called - PLPs these days - then you know sort of want to center your audit around that. But then when you're doing your audit and you notice that there's an issue with product pages that could have a massive potential impact on indexing or ranking — like a pagination issue that maybe means the page can't be discovered, or something that could have a massive impact down the line on indexing and ranking — then I sort of feel like you need to use your experience to guide you. Right, I need to prioritize this, and I need to dig into this further and figure out what's going on.
Areej AbuAli 10:31
Yeah, I like to talk a lot about prioritization. I always look at every opportunity that's uncovered in terms of impact and efforts. So exactly what Patrick is saying, like, what's the actual impact behind something? But also working very, very closely with folks who need to implement the work — in which case, from a technical SEO audit, it tends to be a development team — and understanding well, what's the effort at the back of something? You know, because sometimes it's, "whoa, this is gonna require, like, a whole new redesign," or, "we're gonna have to change this massive thing there," or so forth. And other times, it's like, okay, "you know what, this can easily be done in a day or two," or, "we can easily fit it in the upcoming sprint," or.... but also kind of understanding what their upcoming priorities are.
Areej AbuAli 11:17
So when I worked in-house, something I liked to do a lot was just fit SEO within the product roadmap. So it's like, "oh I know they're working on an initiative around filters for the upcoming quarter. Great. Let me put in all of the filters and related SEO tickets that I want in there as well." So yeah, I think like a mix between this is the actual impact from an SEO perspective, but not just that. Also exactly what Patrick was saying. This is what's going to drive revenue. This is what's going to move the needle when it comes to traffic. But also making sure you're coupling that with an effort perspective of this is how much time it's going to take to actually do the implementation.
Tory Gray 12:01
Yeah. To that point, I feel like one of the most underrated things to analyze is how much do you care about the page that it's happening on or the section that that issue is happening on? So defining that revenue opportunity for the business. Because, you know, understanding, how bad is the problem? How widely is it happening? And then, do I care about those pages at all? You know, do I care about an issue on a page that I've already no-indexed? Because I've seen this in audits, where people are saying, "oh no, this is so wrong," but they're not indexed, and I really just don't care. So there's a few different ways that we scale that across. And I think that's one way we help get to that revenue number to help quantify what matters.
Begüm Kaya 12:43
One of the things that we love talking about in this podcast is how communicating things throughout your organization is affecting things. And I love that Areej, when you touched on how SEO needs can be made and matched with the priorities of the organization in general. So I wanted to ask, how do you tailor your audit to product and development stakeholders and meet their needs?
Areej AbuAli 13:15
Yeah, I mean... you know, exactly what Patrick was saying. You have to have the conversation upfront. I feel like it's very, very easy, especially for consultants, to just go, "yeah okay, give me a week." You know, I'm gonna work on a technical audit and come back to you without actually asking a lot of those upfront conversations. Like, what are your priorities? Why is it that you feel like you need a technical SEO audit right now? What is it that you're most focused on in the next few quarters? What initiatives are you taking and what's on your product roadmap?
Areej AbuAli 13:43
So I think once you're able to kind of get answers behind these questions, you'll then be able to assess. Oh okay, so this is what they care about. This is what I need to focus on. Rather than, let me just do like a super generic, high-level technical SEO audit that just ends up bringing a lot more on their plate. And they've already got like tons of stuff on that they might not end up... it's very, very easy for none of it to end up being looked at or implemented afterwards.
Patrick Hathaway 14:13
Yeah, I think as well, like when you're dealing with development or product teams, delivering data to them in the way that they want can have a massive impact. Right? So then, you know, there's extremes of this depending on how embedded you are. Like, if you are sort of as embedded as you're talking about Areej: literally writing JIRA tickets, you know, following up with them, ensuring that they're getting included in sprints, explaining exactly what they need to do, why they need to do it, links to relevant resources about what needs to be fixed, and then sheets of data about lists of URLs, etc.
Patrick Hathaway 14:53
And like the sort of other end from that, I think, is moving away from, "here's just a big list of URLs," or, "here's just a list of, like, broken links," for instance. "Here's a list of broken links to fix. Thanks very much. See you later." You can reasonably easily identify through using your tools, right actually, there's not 40,000 broken links. There's one link on this template here that's in the navigation. Fix that, you know. Here's a couple of example URLs. You know what I'm talking about? Fix that and it will have an impact on 40,000. Right? And giving them as well, you know, the bigger impact jobs. And explaining what work is needed to have that big impact, rather than the big impact stuff being lost amongst everything else.
Tory Gray 15:44
Doing that work for them, not expecting them to sort through all of your stuff.
Patrick Hathaway 15:50
Yeah, totally, if you want them to do it. And like, that's the whole point in all this: just making it easy for them, so they're not sifting through a load of of rubbish to figure out, "right, okay actually, this is what needs to be done." Just helping them out as much as you can.
Areej AbuAli 16:06
I made a mistake before, where I shared some of the appendices files via Excel before I started using Google Sheets, and the engineering manager was like, "Areej, none of our engineers have Excel on their computers." And it was like... it just got me thinking like, oh yeah, like what was I thinking? I'm just supplying them with things via tools that I personally use, but it doesn't mean this is what they're using.
Areej AbuAli 16:37
And then the easiest thing - so they used notion for all their ticketing - was just simply, you know, pasting a list in the ticket. That for them was the easiest way. Don't give me or try to send me attachments or access to something else. So I think that's another thing as well. How do you like to work? You know, asking them for that understanding. What tools do they work with? You don't want to end up giving them additional things where they need to, kind of, log in and get access and so forth.
Patrick Hathaway 17:09
Yeah, totally, and like testing criteria as well. How do we know that this thing's even right when we've done it? So it doesn't have to come back to you to to then follow up again. You can expect, or at least somewhat hope, that what comes out is the thing that you wanted.
Areej AbuAli 17:26
And also like, what do you have access to? I was lucky to work with a client before who... so I had CMS access from there. And there used to be a mistake that happened a lot where, for example, a broken link resulting in 40,000 - la la la, exactly what you're saying - would be because of a change in the navigation or change in the footer. And so I found that I could just go in and update that link myself. That's it. Like, what is... you know... why go through the whole, "Oh, when can this one...?" If I can just fix it myself, let me just fix it myself. And that way, you just get it done with up front. Yeah, so kind of understanding what is it that you have access to and if there are some things that you're able to just jump in and do yourself — as opposed to have it stacked up in the list of things that they need to look at or do.
Areej AbuAli 18:16
But then off the back of that what I actually suggested was, well, why don't we make sure that a 404 status code URL can't even be entered in the first place in the navigation to prevent any human error from happening? And that's what - instead of wasting time fixing it every time - that's what they ended up building. So they built that within the back end of the CMS, and moving forward, we never had the issue anymore. Our navigation no longer ended up with any broken URLs, because they just embedded that. So yeah, just being a bit smarter sometimes with your recommendations: how can we put forward the recommendation that will be a long term solution, as opposed to fix a very, very specific issue?
Begüm Kaya 19:00
Patrick Hathaway 19:02
Very neat. I like that one. That's good. Yeah, I also like knowing when you can go fix stuff yourself. And again, I think that comes back to communication — like asking, "What can I have access to? What might I be able to change that I don't even know? I don't know where these templates live." Right? You know, it might just be a half-hour training session. "This is here. This is here. Don't touch that. Don't touch that please, or you'll break the whole website."
Tory Gray 19:31
Yeah, I mean, just working together with people and remembering that they are people and that they have to learn things too. And yeah, that's just such an underrated... they are humans. They have goals. They have their own things that they're trying to accomplish. There's just such a level of communication there, and empathy needed, to work with really any human being, frankly.
Begüm Kaya 19:55
That's definitely a thing. But to play the devil's advocate here, what about those clients that keep saying, "we don't have the budget to do that?" Or, they don't want to prioritize anything in the beginning. Like, how would you go about those?
Areej AbuAli 20:13
Fire them? Stop working with them? No, I'm kidding. I mean, it depends, right? Like, have they hired you for a specific reason? Was there something agreed up front? Like, what are they hoping to accomplish? Is the problem around resourcing? So for example, you come and say, "oh, we're going to need to produce this amount of stuff," or, "we're going to need a developer dedicated for this piece of work." So maybe they don't have like the budget or the resourcing for it? In which case, I guess something that we can think or consider adding... it shouldn't just come to impact and effort. It should also be around, you know, budget, resourcing, or availability, or things like that. Like working with them to understand what resources are available and aren't. Like, you can't go ahead and just suggest something that's completely out of their capacity at the minute.
Patrick Hathaway 21:06
So I believe in why. Like, not that annoying book. Although I like the, what was the TED Talk? The TED talk was good. Watch the TED talk, don't read the book. But I do believe in telling people why. Right? I think in almost all walks of life, you can get buy-in by helping people understand, at the core level, why are things important and why you're recommending it.
Patrick Hathaway 22:10
And, again, I think this comes back to the context and doing that upfront work in the beginning, but then also making sure that your client or the people you're talking to understand that context as well. Because they're the ones that need to be your cheerleader, and like, they're the ones that are going to be fighting for things to happen on your behalf inside of the organization, while you're sort of on the outside. And if they do understand the context, and they do understand the potential impact, then they're gonna be able to do that more effectively. And so I believe in - when you're producing, like, audits that are deliverables to clients, and you're not necessarily embedded within the team - I believe that framing is an important part of the audit that gets overlooked. Right? So the context research work that you did, helping to sort of tell a little story about this is where the website is, this is what the focus is, this is what's going wrong, and this is where the opportunities lie.
Patrick Hathaway 23:13
And now - when you're getting on to the recommendations - this is why I'm recommending that, because it ties into the original context and original business issues. And so, you know, the best way you can do that is when you can tie things directly, and you can say, this problem, problem X, is caused by Y and the fix is Z. And, you know, fixing that will lead to an uptick of x hundred thousand dollars. And if you can get to that business value - which you can't always do - but you certainly can say, this is the problem, and this is why it's important. Because we've already established it was important earlier in the audit deliverable. So, yeah, I believe in why. That's definitely something that I care about — or I have an opinion about at least.
Areej AbuAli 24:06
Yeah, and I think it's something we haven't mentioned yet. It's going to be very, very difficult for you to get this buy-in if you're going to them with a "here are 50 recommendations that you need to do off the back of my awesome audit" type of thing. Because then it's like, "What? We have to do all 50?" And it's very, very overwhelming. And for them, they're just thinking, time, budget, resourcing, blah, blah. It's like, "oh, we have to do all 50 or else we're not going to be in a better position than we're in now." So making sure that you are going in with, you know, ideally that one thing.
Areej AbuAli 24:42
Or if not, then at least like, "here's the top three things that we're going to have to focus on for the next quarter or so," because then it feels far more digestible. And you are likely then to easily have that conversation around getting buy-in and so forth. And if you've got — for example, if it's like the Head of Marketing or the CMO or so forth, who's helping and fighting for that resource — they're going in with saying, "okay, here's the three things we need to focus on." As opposed to, "we have this audit with 50 whole recommendations that we're going to somehow...." Like, it's very, very difficult to actually get buy-in for that kind of stuff.
Tory Gray 25:19
And to the point earlier, using their tools is important. So I feel like every SEO, especially like five years ago, handed off the 50-page audit of that list of 50 things that you need to do, and it was just huge. Did anyone even actually ever read that except them? Right? So the development team wants things in what? JIRA or notion or one of these other tools? What is the executive team one? Do they want a five-pager or a one-pager? Do they want a presentation deck? Do they just need a summary? Like, and again, going back to previous... establish that in advance, so you're quoting what you're doing as a part of this audit in advance. Speaking to those needs, and connecting those dots, Patrick, like you said. You have to explain the why and how the work that you're going to do actually ties into that accommplishment.
Patrick Hathaway 26:04
Yeah and where the roadblocks lie. If you know from an upfront conversation that nothing's ever going to happen unless you convince the C-suite, then alright that needs to be factored in. When is that meeting going to happen? When are we going to get to go through this? You know, like you say, like a presentation of the findings of the audit, so that actually something happens at the end of it all?
Areej AbuAli 26:31
Yeah. And I feel like in most of these presentations, they never want to hear, "these are the issues that we have," or so on. They just want to hear, "Okay, so what's the solution? What are we going to fix? What's the action that's coming out of that?" So focusing whatever session that is around.. we call it like in-house, answer first. So it's like going in with the answer up front. All the data and all that, you don't have to dive into any of that. They just want to hear, "Okay, what's your solution for this? What's the action behind it?"
Tory Gray 27:06
Yeah! Tailoring your communication to the audience.
Begüm Kaya 27:10
And again, marrying data and communication together.
Begüm Kaya 27:18
All right. I think we're at a good place to wrap this episode up, unless you want to go deeper into any other topic. So I will give you the opportunity to dive in anywhere you want by asking, what is your best tip for helping a technical SEO audit stand out?
Patrick Hathaway 27:39
See, I think Areej already said it. It's just putting as few recommendations as you possibly can in, and I think to some extent, that will be reflected by the size of the website you're dealing with. I don't think it's okay in, you know, a 100-page website to go, "yeah, there's one thing." Right? The expectation is not going to match. And it's going to be one thing that's going to have such a little impact, because there's not that many things, necessarily, that can have an impact in the first place. But like, if you can get away with no more than five? Yeah. Every time. Do it and just just double down on the explanations and everything that they need to do to fix those things. So yeah, for me, 100% just reducing the amount of specific recommendations — not the amount of work or the size of whatever, but the amount of recommendations that go into it at the end of it all.
Areej AbuAli 28:40
I think tying it to data, definitely, which I know Tory brought up earlier. So making sure you're actually focusing on the templates that matter. So putting all your efforts and energy in a template that's already driving over half of your traffic and revenue, as opposed to going down a whole rabbit hole of, "we're gonna have to do all of these fixes."
Areej AbuAli 29:01
But actually, a lot of these fixes might only be bringing in 5 or 10% of traffic or revenue. Which in that case, like really? Is that a priority for the business? So making sure that you understand, you know, what are the sections and the areas that we need to be focusing on? And what's the data to back that up? And so in this case, this is how I'm going to prioritize and frame what I'm looking at and what my audit delivers.
Tory Gray 29:34
I love all of these answers. And again, I'll repeat what we previously said which is just tailoring it to who you're talking to. What are their needs? Give it to them in the format that they need it. Summarize it the right way.
Patrick Hathaway 29:55
One of the things that I have an SEO opinion about is that SEOs don't need to be developers and don't need to go and learn development. And where I sort of caveat that - and I think this, again, fits in with everything that we've talked about - is that they need to be able to communicate with developers. And almost everything we've talked about today, really, when you boil it down, has been actually about communication as the skill and not necessarily all the rest of it.
Patrick Hathaway 30:26
Yeah okay, of course it's important you understand rendering issues, and, you know, indexing — all those sorts of things. But there are lots of resources out there. There are lots of tools that can help you with these sorts of things. But if you can invest time in trying to communicate better, then you'll be more effective at your job.
Tory Gray 30:49
And frankly, I mean with the focus of all SEOs need to be developers - which I agree is nonsense - but if you want to focus on something, I'd actually argue your data analysis skills are way more important than your ability to be a developer. Because that will help you prioritize, and make those decisions, and have those right conversations, and convince product, and convince engineering teams. My bias is that way. But there's room for all of us to be slightly different, right? And excelling.
Patrick Hathaway 31:22
Tory Gray 31:24
Awesome. Well, thank you guys so much for joining us today. It's been lovely and enlightening learning about all the audits and the ways we do things.
Patrick Hathaway 31:34
Thanks very much for having us.
Areej AbuAli 31:36
Yeah. Thanks for having us.
Begüm Kaya 31:38
It was a pleasure. Thank you so much for joining.
Begüm Kaya 31:41
Please go to thegray.company/ask-us-your-questions. We will be expecting all your SEO questions.
Begüm Kaya 31:54
And we'll see you next time.
Check us out and submit your questions at thegray.company/ask-seo-questions, and we'll see you next time. Thanks!