How to do a technical SEO audit

Thanks for coming out tonight. First, the usual disclaimers. I swear. I apologize to the people watching this on YouTube, this is an 18+ video. I'm going to talk about technical SEO. I do a lot of technical SEO, probably too much. And because I don't like people, and I still have to explain my recommendations to people, sometimes people say things like this about me. This was actually typed in a Slack channel by a lead dev as I was talking through an SEO audit, but the lead dev hadn't realized that his CTO, who was also on the call, was sharing his screen with me while he had Slack open. I wish I was fast enough to take a screenshot, but the CTO very quickly switched tabs. I'll come back to this later on, by the way. But yeah, I rub people the wrong way sometimes, but I see that as part and parcel of what I do, as, you know, my job as an SEO consultant. I'm going to talk about SEO audits, how I do them, and the kind of thinking that goes into crafting audits and audit reports. Who here is agency side, by the way? Quite a few hands go up. Who here does SEO audits regularly? I do. Specifically technical SEO audits? Yeah. I might not be able to teach you much, but you know, at least you get a glimpse into what goes on in this warped brain of mine. Web search engines are information retrieval systems. Information retrieval is a subdiscipline of computer science. It's interesting reading material if you're ever thus inclined. Stanford University, where the 2 Google founders were studying before they founded Google, have their entire information retrieval book for free to read online. The mathematics in it gets complicated quite quickly, but it is still worthwhile reading through at least the first few chapters just to get a bit of an idea of how they think about building search engine technology, information retrieval technology, because it will help you become a bit more aware of how search engines work, what they're capable of and what they're not capable of, and why they need help from us webmasters and SEOs to get that shit in order. So yeah, all information retrieval systems— go back to that slide— have 3 main components: a crawler, indexer, and a ranker. In Googlebot terminology, the crawler is Googlebot, the indexer is the Caffeine infrastructure. The Ranker is Google's front end, where you type stuff in and you get the results. This is how Google describe themselves. This is a fairly old slide, fairly old diagram from them, engineering-wise, so it's probably not entirely accurate anymore. But it shows you, you know, you've got the crawling infrastructure, the indexing infrastructure, and then the search front end. When I do SEO, I have a 3 pillars of SEO model. I see that my fonts didn't properly download. Sorry. Sorry, Andy. That's my fault, sorry. That's fine. You will not— oh, Jesus, this is really fucked up. You will notice that it's not a coincidence that my 3 pillars of SEO align with the 3 main processes of a search engine, where technical SEO is primarily about the crawler, relevancy, on-page optimization, is primarily about the indexer, and authority, link building, is about ranking first in Google. So there's a bit of overlap between the different tactics, but generally speaking, when we do one thing to optimize our websites, we tend to optimize for one particular component of Google search. So for me, technical SEO is primarily about crawl optimization, making sure things get crawled very fast, very efficiently by the crawler, and very quickly get parsed by the crawler. Mobile SEO signals, JavaScript, and international SEO signposting is also part of that particular Remit. On-page optimization, that's classic old-school SEO. That's just title tags, meta descriptions, good content, internal linking, etc., etc. Structured data is part of relevancy, not necessarily part of technical SEO, but I always still cover it as part of technical SEO because it's code and code is icky for people with a marketing background, and therefore all the icky stuff falls under technical SEO. And authority and ranking, that's just about making sure that you rank first and You know, spamming the shit out of Google basically before you get caught. Technical SEO audits for me, like I said, focus primarily on the crawler with quite a hefty chunk also looking at the relevancy aspect. I don't really do much link analysis as part of my technical audits. In the all bells and whistles full range audits, yes I do, but in technical SEO, how other websites link to that website is not really my problem. It's more about making sure that the website itself is fully optimized and can be crawled and indexed as efficiently as possible with as little obstacles as possible. So what is an SEO audit then? What do we mean when we use this terminology of an SEO audit? Is it a stack— sorry, is it a report that you run from Screaming Frog or DeepCrawl and you slap your own brand on it? Fuck no. I hate it that people do this and call it an audit. It really pisses me off. Anybody can run a crawl report from a tool like Screaming Frog or Sitebulb or whatever and slap their own brand on and say, hey, we've audited your website. And I cannot begin to express how annoyed that makes me feel, because that's not an audit. That has no analysis, no context, nothing to it. That's just an automated system. And automated systems, no matter how good they are, lack any sort of context, any sort of awareness, any sort of depth. Google is one of the smartest automated systems in the fucking world, and they get shit wrong all the time. So don't pretend that an SEO audit tool can, can do your job for you. It's also not a stack of papers that sits on somebody's desk gathering dust. If your audit is that, then sorry. Unfortunately, this is not something you tend to have a lot of control over once you've delivered an audit. You have a certain level of influence with how you phrase the actions coming out of the audit and try to make them as actionable and implementable as possible, but in the end, it is up to the client, up to the person, the people you deliver the audit to, to actually make shit happen. And that doesn't always happen, and that can be a real pain in the ass. I think if I'm lucky, when I deliver an audit, half my recommendations will get implemented. The other half just never happens, no matter how important they may or may not be. If it's more than half, I'm working with what I call a good client. That's— for me, an audit is the start of a process. It is identifying the opportunities, using SEO theory to find opportunities to make a website improve its organic search visibility, and it's always the start of a process. The audit is the beginning, never the end. The audit— for me, audits are primarily an end product. It's mainly what I do as a service, but I always realize that it's always the start of a process for the client. The audit needs to initiate something, needs to begin a certain process on the end of the recipient, the people who commissioned the audit, to make shit happen, to make stuff improved on the website so that they see graphs go up. That's what they all care about. They want graphs to go up— traffic, sales, everything that comes with it. I love this particular diagram. This is not mine, from a guy called James Clear. I was first pointed to this by Richard Baxter from Build Visible. And I've started including it in the introduction text of every single audit that I ever do. It's the aggregation of marginal gains, where a little improvement here and there over a long period of time will yield massive results. Anybody here follow Formula 1 racing a little bit? That's what Formula 1 does. They start with a car at the start of the season. At the end of the season, that car is 3 seconds a lap faster than when they started, because they make tiny little improvements every single race, making it slightly faster, slightly better. And at the end of the season is 3, 4 seconds faster a lap than when they started, which for a Formula 1 team can make the difference between ending up with $20 million payoff or $100 million payoff at the end of the season, depending on where they end up in the Constructors' Championship. And SEO audits and websites in general, websites in general are the same. If you do not constantly improve a website, you're on the red line. You don't even have to do anything to make it worse, just let it sit there statically, you're already making a worse website. It's going to get worse. Doing nothing is walking backwards. You have to constantly improve. You have to put the effort in, make small tweaks, make it faster, make it better, optimize conversions, optimize search, optimize social, optimize email, every single part of it, constantly, all the time. If the website just sits there doing its thing, you're going to lose, and quite painfully so. So before I even start an audit, before anything, After the paperwork usually is sorted, I ask for Search Console access. I do not touch a website before I have access to Google Search Console. I can't. This is the single most important source of data I have for SEO to analyze a website. This is the old Google Search Console. We will be saying goodbye to this in less than 2 weeks. In typical Google fashion, they've made it worse and call it an improvement. Fuck you, Google. So very shortly we only have this. Yeah, so we'll have to work with what we're given. We don't really have a choice. Even then, no, this is not an improvement. It is still the best data source you have. You know, the crawl errors report used to be my go-to for mainly technical SEO scenarios. Now we have to work with index coverage the next couple of weeks. We'll live with it. You know, you don't necessarily get the same granular data, but you know, you can make it work. If you don't get Search Console access, you can't properly audit website, in my opinion. You can do it without a lot of data. I mean, I like getting Google Analytics data, I like getting server log files, but if I don't get them, I'm fine. I can't do an audit without Search Console. I'm just, you know, a man sitting in a cave watching shadows walk by if I don't have Search Console. So yeah, the must-have is Search Console. Analytics and log files are nice to have, and I don't really need more data than that. Because in the end, it is about, you know, you don't need backend access to websites. You know, it's sometimes nice to have, but you don't really need it because the backend— Google never sees the backend. Search engines don't see the backend. They see the frontend. And the frontend you can look at yourself. You can open your browser and you can look at the frontend of the website. You can have tools like DeepCrawl, Screaming Frog, whatever you use, look at the frontend. That's what Google sees. So that's what you analyze. That's what you base your audit recommendations on. It helps to know what the backend is so you can formulate the right recommendations and put them in the right context. Because if you know what sort of platform a website is built on, you know, or learn from experience, that that can be easy to fix, and that, because it's built on that platform, can be a real fucking pain in the ass. For example, you can do an analysis on a Magento website, which has like 200 different CSS and JavaScript files that it calls in loading a single page, And you give the recommendation, reduce that, but you know, because it's Magento, it's not going to be reduced. You might as well recode the entire website and start from scratch. Magento is a fucking beast of a system, you end up with certain weaknesses inherent in it. The tools that I use to audit, I like Little Warden. Little Warden is intended initially just to keep an eye on when shit goes wrong on websites and send you a warning. It's an hourly or daily monitoring of websites. It triggers things like checking if it has robots meta tags on there, checking canonicals, checking 404s, all that stuff. But even just launching it and doing a first scan of a website, you'll tend to get pointed in certain directions that stuff might go wrong, might be wrong with the website. For example, Little Warden will check if a 404 not found, if a nonexistent URL actually gives a 404 HTTP status code. Of something else happens. It'll check if the redirect from HTTP to HTTPS is a 301 or not. It'll check if the XML sitemap is valid. So off the bat, you already have a few starting points for your audit, for your analysis. I'm a huge fan of DeepCrawl. Disclaimer: I am a member of their customer advisory board, so I get a free account. Yay! But I was a paid subscriber for multiple years before they asked me to be a member of the customer advisory board. I really, really liked it. It's a cloud-based crawler. You have to be a bit careful with the credit system, so start with a small limited crawl before you do a full crawl, otherwise you run out of credits before you know it. But the built-in reporting is second to none, and the stuff you can find with DeepCrawl is amazing. Also because you can plug it into Search Console, plug it into Analytics, plug it into Majestic or other link tools, plug it into server log files even, and do comparisons. Between the different data sources. So it's an incredibly powerful platform that combines everything. And of course, Screaming Frog is my go-to desktop-based crawler. I use this primarily for limited crawls, crawling sitemaps, crawling lists of files, et cetera, et cetera, because I don't know about you, but anything over about 10,000 URLs on my laptop starts smoking and getting a life on its own and just trying to melt through my desk. Search Console, like I said, you can't do proper analysis without Search Console, both old and new. I like GTmetrix as a performance analysis tool, how fast the website loads, primarily because the people behind GTmetrix have a commercial incentive to give you shit scores. They sell load speed optimization services. So if you get a good score on GTmetrix, you're really shit hot. It's very easy to get a bad score on GTmetrix. I mean, you got Lighthouse and PageSpeed Insights, which is based on Lighthouse, and you got WebPageTest, which has great waterfall charts and always really useful to include as well in audit reports, but GTmetrix for me is the go-to, also because of things like that. You know, how many actual requests does it take to build a page? That's a very useful piece of information to have. How many kilobytes is the actual page? Does anybody here, by the way, know what the average size is of a web page on the internet nowadays? Too much. Take a guess. 1 meg. Oh, you naive— It's 2.5 megabytes. 2.5 megabytes is the average page weight of a web page on the web nowadays. I'm old enough to have played a computer game called Doom. Remember Doom? That was 2 megabytes. The entirety of Doom is smaller than the average web page on the internet nowadays. What the fuck? I use plug-ins as well, by the way. I switched to Firefox in January. You all should switch to Firefox too, because I don't know about you, but I don't think Chrome needs 7.9 of my 8 gigabytes of RAM. Really doesn't. Once you switch to Firefox, it's like a whole new world will open up to you. Like, holy shit, it's actually fast. It's amazing. Also because the extension ecosystem of Firefox has now moved on to such an extent you don't need Chrome anymore to get all the data you need. Firefox, I love the SEO Info plugin, which is basically Almost the only plugin you need for SEO on Firefly. There's also a Chrome version, you can try it on Chrome. It's lots and lots and lots of info in there, directly in that one plugin. I also have the Wappalyzer plugin, which is similar to the Built With plugin, and tells you the kind of technologies that are used on that particular web page, and gives you a strong indication of the kind of platform that it's built on, or the plugins that they might use, etc., etc. And the link redirect trace is similar as the Ahrefs redirect path. It just shows you redirect hops, HTTP status codes, and all of that, which is really useful for analysis as well. Beyond that, I don't really use an awful lot of tools. That's pretty much it. And sometimes I have other tools depending on the context, what's necessary, but generally this is my entire tool stack for most of my technical SEO audits. So you don't, you don't need to hide yourself behind tools. The best tool you have is right there in your skull. The actual audit then, I have a checklist. The checklist, I always assume clients eventually will share that with other parties. I send it to the client complete with color codings and everything. You know, green is grand, yellow is we might need to look at that, orange is you definitely need to look at that, red is stop the fucking presses, you need to look at this right now. Like, you know, robots.txt disallows words that go woke or something like that. But because I know this is going to be shared, if I send it to a client, I always assume a competitor at some stage is going to see this, or people who think they compete with me. So I— they're fairly inscrutable. They're just little nudges for me to look at certain aspects of a site, little hints to go in certain directions for diving into a rabbit hole. I'm not giving away the entirety of my SEO audit process. With my checklist. I'm just, you know, showing that yes, I am checking your website for all these different types of elements, and will highlight what I've checked and how problematic I feel that it is. The checklist is not the report, it's just the initial thing, and it keeps me on track. It makes sure I do actually check the website for all the things I should be checking the website for. So it keeps me on track, keeps me engaged, makes sure that, you know, I don't just do a half-assed effort, basically. A key to a really, really good SEO audit is always to look at the patterns. Take a step back and look at the patterns that make up the website itself. It's all about the context in which an issue exists and the recommendations that you make. I have seen audits that other people have done— I'm not going to name them, although sometimes I'm tempted to— where there's like a 100,000-page website and one of the recommendations is there are 7 title tags on your website that are a little bit too long, you need to shorten them. I'm like, get the fuck out. I can't believe you paid money for that shit. That's not a proper recommendation. You need to put everything in the right context. If it's a 20-page website and 7 title tags are fucked up, yeah, okay. If it's a 100,000-page website, now come on, don't put that in your audit report. That's just useless. Put it in the right context. Context always matters, and you need to understand the purpose of a website before you can make those recommendations. I think there's a real risk in the SEO industry that we only look at websites through the lens of a tool or multiple tools, multiple reports. We look at a website through Search Console, through a deep crawl, through Screaming Frog, through Majestic Link Analysis. Go before you even start an audit. Just go and use the website. Dive into it, become very familiar with it, how it works, how it takes over, what you like about it, what you dislike about it. Just become a user of the website first before you become a critic of the website. And that for me always helps place the recommendations in the correct context, because it's very easy to make recommendations based on what comes out of a report, but you might be making recommendations for pages that are not really that important in the context of the wider website, that are really deeply hidden, for example. And yes, there might be absolutely terrible pages And they probably do need to improve them, but there's so much other stuff on the key pages that actually people look at all the time and that search engines should be focusing on. So if you're not a user of the website, you can't make that evaluation, you can't make that judgment. So become a user before you become an auditor of the website. Websites will run off different templates. You'll have the homepage, you'll have category pages, you'll have product or service pages, etc., etc. And you need to make sure you keep that in mind when you make those recommendations, because problems on websites tend to appear across all types, all templates of pages. And sometimes, you know, you have some odd pages floating around here and there, but generally speaking, if there's something wrong on one product page, it tends to be wrong on most, if not all, product pages. So identify which templates your website has and make sure you analyze every single one of those. Even if your crawl report from DeepCrawl or Screaming Frog doesn't necessarily highlight a problem, make sure you double-check every single template on the website on the code level as well to make sure that, okay, this page is functioning as intended, or maybe there's some things they can improve about that too. And actual writing of the report, then, if you have your checklist completed— and 10 points, by the way, and a free beer if anybody knows what movie that's from. Good man, the original, the real Ghost in the Shell. Yeah, love it. The writing of the report is of course when you create your deliverable. That's the product that you have been paid, or get paid money from your employer to deliver, so don't skimp on that. I, you know, for me writing the SEO audit report is probably nearly half the work of the audit report itself. Maybe not, maybe it depends on the size of the website, but at least a third of my time goes into writing the report, because that determines if anything is actually going to happen with that output, if someone is actually going to take that up and make stuff improve on their website. Again, always assume it will be shared beyond the confines of the organization you send it to, no matter how many NDAs you sell. I know this because I get audit reports from other agencies all the fucking time, and sometimes I wonder to myself if the people who wrote that report realize that I'm going to be reading them. And I think it might be good to keep in mind, when you write an audit report, pretend that I'm going to be the one reading it. Really, because probably I will at some stage. I mean, I might get angry with you. Make it actionable. By the way, Action Jackson is a massively underrated 1980s, early 1990s action film. Carl Weathers is one of my favorite action movie stars of all time, and I think he should have deserved an Oscar for his acting talent. He's fantastic. Beside the point. Make it actionable. Again, it comes down to context. It's very easy to make a very generic off-the-shelf recommendation and just shoot it over to the client and forget about it, but you have to put it in the right context. You have to make sure they can actually do something with that. Now I have had a few cases where I made a recommendation knowing that it is very easy for me to make and very hard for the client to implement. For example, I audited a website a year and a half ago which was entirely server-side JavaScript. entirely from start to finish. So my recommendation to them was actually just a simple email. Client, do, do, do entire service. So they were client-side rendering, and I told them go do server-side rendering because the client shouldn't be seeing any fucking JavaScript. And after you've done that, then I can audit the rest of the website, because up until that is fixed, there's no fucking point in me spending any effort auditing the rest of your website. Fortunately for them, they, you know, they decided to test stuff out with prerender.io, and then we moved on to the second stage of the audit. But sometimes it can be very hard for clients to action a certain recommendation, no matter how much you want them to. Up until today, I was one of those people who told clients to put pagination meta tags on paginated pages. Anybody been following the Twitter drama on that today? Yeah, John Mueller came out and said, oh no, we haven't paid attention to that for years. How much development time is wasted on that shit, right? Again, that can be a very easy recommendation to make, not necessarily easy to implement. If you are familiar with the systems that the website runs on, it becomes easier to gauge that a little bit. What I do find is helpful, I'll touch upon this a bit later on as well, is if you don't necessarily tell a client how to do something, but you give them some signposts. As in, if there's a WordPress website and you know there's a plugin that helps with that, maybe point them towards that, or point them towards an online tool that can help them find out certain issues. But don't necessarily tell them how to do it, just give them hints, because people who end up implementing it, the developers, don't tend to like being told what to do. If you do that, they call you a dick in a Slack channel to their CTO. Only include what actually needs improved. In my color coding system, gray, green, and yellow never make it to the final report. Orange and red are the only ones that do. Stuff that actually needs fixed, or needs fixed urgently. Stuff that might be nice to fix, the yellow, I don't even bother to put that in the report. No point in that. And again, with experience, you tend to find out what the biggest bang for your buck is going to be. I'll talk about that a little bit when we talk about prioritization, but I see massively bloated audit reports sometimes where every tiny little possible improvement point is listed, and I'm like, nobody's gonna read that shit. Nobody's gonna do anything with that. Make it concise, make it short, include only the stuff that actually needs to be improved, that will have a meaningful impact. Again, those 7 fucking title tags that are slightly over 70 characters, don't put that in your fucking audit report. No, no, nobody's going to do anything with that. That's not useful. The trivial stuff needs to stay the fuck out. If it's not going to have a big bang, a meaningful impact, don't put it in the report. Maybe put it in the Excel sheet, like I said, in the actual checklist that you can send to a client, and maybe they will ask you, oh, what about this? Yeah, you might do that, but it's not going to really move the needle. Put stuff in there that's actually going to move the needle. And prioritize. Properly. It is important to make the client understand what the biggest bang is going to be when they start making those recommendations. And in that regard, I tend to do what I call reverse prioritization. Reverse— we talked about the 3 main components of a search engine: crawling, indexing, and ranking. I prioritize the other way around. Ranking comes first because that's, that's the low-hanging fruit. That's the bang for your buck. If it's crawled and indexed but it's not ranking, Why is that? Let's fix that first. If it's being crawled but it's not being indexed, why, why not? That's the second step. And then the last step, if it's not being crawled at all, why not? Again, sometimes you have to mix things up a little bit. If the entire website isn't being crawled, that's a fairly important issue, but that won't happen very often. You know, in the part of a sales process of an SEO audit, I always emphasize to my clients there are no silver bullets anymore. You're not going to find— I'm not going to find one major change that's going to massively reverse your fortunes and that cliff upward is going to magically appear. That's not going to happen. It's going to be small incremental improvements, small little things. If they can very quickly see a result from what they implement from your audit, with stuff that starts to rank and earn traffic straight away, then they have that internal momentum, they will get that internal buy-in to implement more of your recommendations. So that's the high priority stuff, stuff that gets the quick payoff, then the stuff that takes a bit more time, and lastly the stuff that might need complete redesign of the website's information architecture, for example. That can be hard to sell, but if they've seen the improvements from the first few recommendations, then they have that internal buy-in, that internal momentum to get shit done. Try to make it concise and light on jargon. I am a huge fan of— who was it that said that? If you can't explain it simply, you don't understand it properly, I think. Einstein? I think it was Einstein, yeah, or one of the physicists. At least it's attributed to him a lot of the times. If you can't explain it simply, you don't understand it, and I really do believe that. The same is true in SEO. If you hide all this stuff behind heavy jargon and acronyms and all that crap, then You're not really sure about it yourself. And sometimes that's okay. I don't know everything there is to know about websites either, and I'm honest with my clients. I just know when something goes wrong, and I tell them, you might want to have a look at that. But I do try to explain it simply. Try to explain it to somebody who comes from a non-technical background so they at least get a general gist of it. But also don't dumb it down too much that you lose some of the nuance in it, because nuance is quite important. The context always matters, but you have to be concise. Don't write 5,000 words about one single issue, nobody's going to read that. You know, keep it as concise as you possibly can. Give examples, always provide examples, screenshots, code snippets, whatever it is, because also it makes the document come alive a little bit, makes it easier for people to read. And if you provide direct examples of pages where a problem occurs, then developers can directly look at those pages, see the problem for themselves, and then hopefully find a good way to fix it. Always explain the why. Don't just say Google likes this. Say why you think Google likes that. And yes, of course, you know, we don't always know why ourselves because Google tells us, oh, make great content. But we as SEOs tend to, especially if you understand at least the basics of how search engines work, you can at least explain, well, this is part of its crawling system. If they can't follow links, then they can't crawl pages. Or this is part of the indexing ecosystem, and if you clean up the code with H1 tags and At least Google will have very clear signals about what the headline on the page is, et cetera, et cetera. So provide a bit of context. Explain the why behind it. And if you do that, you will very quickly realize that delivering an audit in the form of PowerPoint slides just isn't going to work, because you can't do any of what I just said in fucking PowerPoint. There's not enough room on PowerPoint slides. I hate audit reports that are delivered in PowerPoint. It's just so lazy. And you just know that's just a template, that's a copy-paste job with a new website and some new screenshots thrown in, with standard content in it. No. I write my reports in Word. I try not to make them too long, they're about 20 to 30 pages, and that's about it. And I do write them nearly entirely from scratch every single time, because I made a copy-paste error from the same issue once, and I forgot to change the website name. That shit's gonna haunt you too. Don't do that. You only make that mistake once. No, write it down properly. You know, I tend to make it an easily readable, digestible document as well, so one issue per page, and sometimes it's just one or two paragraphs, sometimes it's a bit longer, some screenshots in there. Next issue. This is the problem, this is why it's a problem, and this is the recommended solution. Next problem. This is a problem, this is why it's a problem, this is the recommended solution. One after the other. And 20, 30 pages max, that should be it, unless it's a real clusterfuck of a website, but if that's the case, you can do with just one page that's saying, start over. Right, so I don't like using PowerPoint. I old-fashioned Word documents that I save as PDF so they can't fuck around with it, and then I send them to the client. And always understand your audience. There will be multiple types of people in an organization who will be reading that document. They tend to come in one of three forms: you've got the C-suite, the executives, the CEOs, CMOs, and CTOs; you've got the marketers, and you've got the tech or the dev people. people. The CTOs will never read the whole shit. They're just not going to. So you have to have an executive summary, and do call it an executive summary or something like that, highlights, because that's, that's what the eye is going to go towards, and that's the shit they're going to read. Keep that as jargon-free as possible. Don't blame anybody. Don't say your developers really fucked up, because the same developers are going to have to implement your recommendations. So don't apportion blame, just describe very briefly what the problems are and the kind of solutions that would be required, and show them the money. It can be very hard to estimate how much traffic is going to improve, but you sort of get a bit of a gauge sometimes. And I get these questions probably way too often, and I always again put them in the right context, saying, well, we don't know, it's a moving target, but I expect if you do that, you might see 1 or 2% uplift. If you do that, you might see 15, 20% uplift. in X amount of time. In my experience, etc., etc., you know, the more you do, the better you get at that, and it becomes important to do that, to at least provide a bit of context and meaning. And again, it will help build internal momentum, build that internal mandate that the marketers and the tech team need to actually make shit happen. The marketing then, the marketers, they tend to be the ones who hire you most of the time, so you have to make them look good. Even if they fucked up, make sure that they look good in the audit. Your entire job is to make marketing look good, to make them look smart, to make them look like they made the right decision in hiring you to do that audit for you, to make that report and to make stuff happen. Sometimes I work with marketers, and I pity them to a certain extent, who work in-house, who know exactly what the fuck is wrong with their website. They know. There will be no surprises in my audit report. None. But they need that, because otherwise nobody else is going to fucking listen to them. So, you make sure you align what you say with the market, right? What do you think the main problems are? I'll make sure to highlight them in my report. And sometimes you can, you can surprise them, but most of the time, you know, they tend to already have a bit of an idea. Yeah, this is what the problem is. And then they need to pay somebody else several thousand pounds to actually get shit done in their own organization. I used to be that person. I spent 15 years of my career in-house, and that's also why I will never go back in-house. Marketers sometimes have an unhealthy obsession with their competitors. I sometimes get asked, why do we need to do this? We're doing that because our competitors are doing that and they're outranking us. It's like, yeah, but that's not why they're outranking you. You shouldn't always try to imitate what everybody else is doing. There's a real risk in them. And try to educate them a little bit as well. If you have a Screaming Frog or a deep crawl output for them, show them the tool and maybe get them to use it as well. Make it part of their processes. The developers then, they can be the hardest to win over, but once you've got them on side, shit actually moves, shit actually gets done. It helps if you have some basic development awareness yourself. If you don't, at least try to understand some of the lingo. I don't think you need to be able to code to be a good SEO. I do think you need to know HTML. HTML is not a coding language, it's a markup language, and it's more or less human-readable. If you want to be really, really good at SEO, you need to be able to look at the source code of a web page, the HTML source code, and sort of have an idea of what each component does. I don't think that's really optional, if I'm entirely honest. But knowing JavaScript or Python or PHP, no, you don't need to do that. I think I'm a fairly competent technical SEO, and I haven't coded in anger for the better part of 17 years now. When you talk to developers, it helps to really impress some of the really basic concepts that they sometimes not necessarily realize can be a problem. Like, for example, that URLs are how search engines crawl, index, and rank content. URLs don't crawl and index and rank websites, nor do they rank web pages. In fact, they rank URLs. individual web addresses. And once you cram that into a web developer's head, for example, they'll never make problems with single-page apps anymore, because they know that, oh no, every single piece of content needs its own URL. Search engines— secretly, all web developers want to work for Google. Deep down, they'll all admit that they'd love to work for Google. So if you lift a bit of that veil, You tell them a little bit about this is how Google actually works, this is how they interact with your website, they tend to get excited about the prospect. If you can point them to certain documentation on the Google Developers website, that tends to help as well, because they take that as gospel and then shit actually starts to happen. And always make sure that you emphasize that by building good SEO into their website, it'll make them look good as well. They'll— because they're the ones who are building websites that are faster, that are better, that rank better and get more traffic and earn more money. and pays their fucking salary in the end. And I want to be outcome-focused. I never want to tell a developer how to do their job. I sometimes point them to certain tools and certain platforms, but I'm not religiously telling them to do it one certain way. But I tell them what the ideal outcome is going to be. This is the ideal outcome of this particular recommendation. How you get there is up to you, but get as close to that as you possibly can. And they figure it out themselves. You don't need to tell them how to do their own jobs, most of the time. If you do that, you tend to get them on side. That guy, I have a really good working relationship with him now, and the company he works for. In fact, they commissioned me to do a second audit once they updated the entire codebase of their website. And he actually is based in Portugal, and he's got an open invitation for me to come and drink beers with him when I'm there. Because after that initial hurdle, he realized that I wasn't his enemy, That I could make his job easier if he just did what the fuck I told him to. That's really all I have. If that talk wasn't impressive enough, I hope those logos impress you. Thank you very much. Thank you.