S3E6 Charlie Williams, Getting SEO Recommendations Implemented

Keira Davidson (00:24):

Hi, and welcome to the TechSEO Podcast. Today I’m joined by Charlie, and we’re going to talk about all things SEO recommendations, and getting them implemented. It’s great to have you joining us today, Charlie, do you fancy given a bit of background information about yourself?

Charlie Williams (00:44):

Yeah, sure, and thanks very much for having me, it’s lovely to be joining you. So, I’m Charlie, I work as an SEO and content strategy consultant, I have my own consultancy called Chock Digital, though it’s just me, sounds grander than it actually is. I’ve been working in SEO for over a dozen years now, but started my own consultancy several years ago. Before that I worked for a couple of agencies, including SEOptimise and Screaming Frog. My work today is very much dedicated on that consultancy side of SEO, and it’s all about content, and technical SEO, and sort of splits into two bits, I suppose. Helping people become better at doing SEO, so that’s training or improving processes for my clients, and then the other side is helping solve SEO problems. That split between the content side, so people wanting to know which bits of their content are doing well, or which ones aren’t, what they need to be doing in their market, what their audience wants to know. Then the technical side, why is Google having problems crawling a site, and things like that?

Keira Davidson (01:51):

That’s definitely really exciting, and I guess, because you see both sides of it, it’s probably super rewarding as you might get the technical implementations fixed and resolved. Then you focus on the content, and then you start getting all these like really big wins.

Charlie Williams (02:12):

Yeah, absolutely, that’s a great way of putting it. It’s nice to be able to help people and all the onsite stuff. But yeah, it’s the way they work together, because normally if someone’s having a problem with their technical side, there’s often something from that you learn about how the content’s being done, which you can help with there and vice versa. What I find quite often is doing a lot of technical work, I help people using and understanding the data they get from search console, in terms of indexing and the coverage report. Of course, a lot of those things in that coverage report under the excluded tab are technical issues, but sometimes they’re actually content quality issues caused by technical problems, and things like that. So yeah, I find the crossover is really quite common.

Keira Davidson (02:58):

Do you find that when you… Because obviously, you do consulting, do you find that when you’re dealing with… Do you deal with the client directly, or do you deal as in getting recommendations done, or are you able to work with developers?

Charlie Williams (03:13):

That’s a great question, it varies, it really varies depending on the business. So, some of my larger clients at the moment that I’m doing projects for, there’s a mix. A couple of them I’m able to speak directly with the development team, which is great, because I’m able to kind of forge that relationship and understand where they’re coming from and how their process works. Then in other ones, especially with larger businesses, I’m working with the marketing team, and the heads of marketing, and the heads of digital, and things like that. That means there’s then a process to then get tickets raised and to [inaudible 00:03:46] the dev team. I’ve had some good video chats with some of them on specific issues, and that’s often the way to kind of approach these things, and that’s really beneficial. But in that case, you have to learn how to raise a ticket with your marketing team that then the development team can then work on.

Keira Davidson (04:01):

So, would you say then with the ones where you go straight to the developers compared to the ones where you go to the marketing team to then the developers, do you find timelines, because of the process, it varies a lot?

Charlie Williams (04:21):

Yes, absolutely. Of course, different teams work in different ways. A lot of teams work in an agile fashion using sprints, scrums, or whatever process they like to use. So, there’s that variance there, but I do find that when you can speak directly with the developers, you can sort of tune into that process they have internally a little better, for sure.

Keira Davidson (04:43):

Yeah, and from my side of things, it’s always good to get the developers on board, and to work with them, and sort of fitting into the processes and the methodologies that they use, because I personally find that it results in you getting the fixes that you need doing ultimately.

Charlie Williams (05:04):

Yeah, a lot of the time, if you’re dealing, as the subject or these podcast is about, technical SEO issues, the developers that you’re best friends. They’re the ones who are actually going to be able to do things, and they’re the ones who can tell you what’s possible and what’s not, so you’re not wasting everyone’s time by doing huge recommendation for things that are never going to happen. I’ve often said that sort of my secret way of getting things done within a project is coffee or beer, it’s taking out the development team, and sitting down with them, and finding out the problems they face, and understanding how they want to work. Sometimes, especially if you’re helping improve internal processes, the barriers in language between the marketing team and development team. If I can come in and help smooth some of that out, that often goes a long way to making everyone happy, well, long after I’ve actually left the project.

Keira Davidson (05:54):

Do you know what? You’re not the first person who I’ve heard say coffee or beers goes a long way in trying to get things resolved.

Charlie Williams (06:04):

I bet, it’s a really, really just, well, polite way of going about things actually, sort of getting down to sit down with people and talk about it. Because sometimes, especially in larger businesses, I’ve worked in house as well, there can be sometimes this feeling of not us versus them, but very much different teams with their own agendas. I think the cool thing about SEO is that you have to get in everyone’s business, we just come in and cause trouble everywhere. I have to come and annoy the PR team by saying, “I need more links,” [inaudible 00:06:33] with links, but you can do.

Charlie Williams (06:34):

I have to come and annoy the product team and the marketing team by saying, “Your content’s not good enough.” I have to come and Badger the technical team, the development team, by saying, “This needs to be faster, this isn’t a very good site response, this is causing duplications,” whatever it happens to be. So, I’m an equal opportunity annoyer, I will annoy every member of the departments that I can. Sort of sitting down with people and talking to them, finding out what you can do, rather than just making any assumptions, huge win.

Keira Davidson (07:05):

Yeah, definitely, you’ve got them engaged, you’ve got them on board, and you’re all working towards that final end goal together, and it’s not a battle.

Charlie Williams (07:16):

Yeah, definitely, it’s very easy for everyone to become siloed, even with the best possible intentions. Because we’ve all got our own individual goals, and different priorities, and SEO is often this… Everything affects SEO, so when you can bring people together and say, “Look, what you’re doing, creating this content, is causing a problem here, but it’s also causing duplication here, which you then the development team can fix,” or whatever the example is. It’s great when you can sort of show that everyone can contribute to this without having to change their jobs, without having to do something massively different, just by understanding some of the things that happen. That’s when I think you can get really good results.

Keira Davidson (07:52):

Yeah, I guess if they were to massively change their jobs or their role to try and fit into it, into what’s needed, long-term that’s just not going to work, because people will go back to what they know. So, it is probably quite important to try and not make these big changes, for it to be a long-term sort of sustainable process.

Charlie Williams (08:15):

That’s a really great point, I think absolutely, if you try and change everything for everyone else, they’re just going to resent it. I think if you’ve worked in SEO for a while, you will have… All seen situations where you meet people who kind of go, “SEO, what keyword do I have to stuff in to ruin my article? Or what do I have to change on the website? Or what tags do I have to do?” It’s kind of this chore, it’s kind of there’s somebody coming and just nagging them and saying, “Do this.”

Charlie Williams (08:43):

Whereas, I always try and frame things in one, bite size improvements, but two, just within the very simple context of we are looking to do this to improve things for our users or for search engines. This lets our user do improvement X, or this makes it easier for search engines to improvement Y, and then you give them a reason for it. It makes them more successful, because you’re doing something that’s going to make them look better to their bosses, and so on. So yeah, that kind of feeling of forcing people to do something, I agree, that’s never going to be a long-term thing.

Keira Davidson (09:18):

That’s a really good point, especially bearing in mind that all the changes that you may be wanting or asking for, it’s really important to revert back to how’s this going to impact search engines and users? Because ultimately, the end goal is to enhance both of those, and if that isn’t achieved, is the implementation really needed?

Charlie Williams (09:44):

Yeah, exactly, if we’re trying to make a technical change just for the sake of ticking a box, and it’s not something we are really doing because we know our users need this more, or we know search engines are having trouble with this, or potentially could be. Then yeah, it doesn’t really seem like it’s a high priority ticket, does it?

Keira Davidson (10:02):

Exactly, so other than basically trying to get the developers together for coffee or a beer, do you have any other good tips on how to get implementations done?

Charlie Williams (10:17):

I will try my best, absolutely. So, I think the key thing for me is actually breaking things down into individual improvements, or reviews, or aspects. What I mean by that is I used to do large technical SEO audits for my clients, I would often start a project off with one of these, not every time, but a lot of the time. I would produce these very large documents where I’ve checked everything, and I’ve documented everything that I think you should do to improve. While there was a summary at the beginning, these would become very large documents, sometimes 10 to 15,000 words. I think back to university, and I struggle to write a 2000 word article for a thing. I’m just churning that out in an hour, whatever, I was like, “Wow, this is ridiculous.” So, I’m producing these huge documents, and there’s supporting spreadsheets with pass, fails, or with tabs with here’s all the pages that have this problem, all the pages have this problem, and things like that. It’s a huge amount of information, and I’d pass it onto clients, and they would be impressed.

Charlie Williams (11:21):

They’d be like, “That’s great, look at all this information we’ve got for our money, this is good value.” You just knew on following up conversations that they’ve read the summary, and looked at one or two tabs of the data, and that’s it. You’re kind of going, “Well, you’re paying me, that’s good. But I don’t really feel like I’m making the right kind of impact.” So, the big change I made about 18 months ago, was I stopped doing them, I just stopped doing them. I mean, one, they were a lot of work to go through, and I just started breaking things down., Both in terms of sales process, but also in terms of just the work I was doing. If somebody came to me just wanting a full technical review, I wouldn’t give them a full technical review document. I would be, “Right. Okay, here’s the first document where we are looking at your current indexing situation, again, using that search console thing what’s happening when we do look at the index in your site, what are the problems we’re facing there?”

Charlie Williams (12:14):

Then I do a crawling review, and if I try and crawl your site, what happens here? Then we’ve got a schema review, or a mobile review, or a page speeding review. The kind of individual components are up to any SEO, because for every SEO there’s a different way of approaching things. However, the key thing was to break it down into those individual parts. I think a lot of people liked that when I was trying to sell SEO to them, because they can understand what each thing was going to deliver for them, much more than this big nebulous idea of a technical audit. It also made my life easier, because I was just focusing on one thing at a time, and then it was much easier to get by on implementations, because we’d agreed that we were going to look at page speed, or whatever it was. Here’s the recommendations, everyone’s already signed in, so let’s start looking at the fixes, so that’s my first recommendation is breaking things down that way.

Keira Davidson (13:07):

Yeah, I think that’s a really good one to bear in mind. It’s great, it’s all fun and well delivering these massive technical audits, but also, delivering the information in bite sizes can help with getting it done, as in getting it all sorted. You can slowly work your way through instead of overwhelming the different teams, so I definitely agree, that is a big one to bear in mind.

Charlie Williams (13:34):

Yeah, absolutely, and it also really helps I think with the second thing that I’ve learned, especially over the last several years of doing this as an independent consultant, and that is when it comes to making recommendations for implementations, you can tweak some things there. So, if you’re doing smaller documents, you’ve got smaller recommendations anyway, just a smaller number, which is really helpful, focusing on one thing at time. But when it comes to implementation, there’s a couple of things you can do, you can make sure your document is in a format that the development team really wants. So, if you are dealing with the developers is one thing, another thing for the marketers, but what document format works best for this team? Do they want it in a long written document?

Charlie Williams (14:17):

Do they want it in a presentation format, quite visual, with supporting data, or do they actually just want it straight up just the data with a summary thing at the beginning with a line for each job, and your prioritization, and things like that? Then the second thing about the implementation is understanding if you are doing the implementation part beyond just the recommendations, how can you help make sure the implementation is done? Sort of the stewardship of those implementations is still part of your job. How would you make sure they’re done? Is it that you need to actually write the individual JIRA tickets, if you’re using JIRA, or whatever the system is? Do you need to really have a call for each individual point, so that you can talk people through exactly what to do? It can vary, but actually have a plan of how you’re going to guide that implementation in place, if that’s part of your job.

Keira Davidson (15:11):

That’s a really good point to make, and do you know for this sort of plan, would you sort of outline it initially when the project comes on board, or when the development work needs completing, to make sure that all teams are on the same page?

Charlie Williams (15:28):

I think you can do, I think it’s really important to get all teams on the same page where you know that’s going to have an impact on your ability to get these things implemented, or even if you’re just making recommendations to make sure that you’ve got the best chance of everyone understanding the impact of what you’re doing. That’s going to be your end goal, and I think that’s quite crucial, so whatever works well for that, I’m all for, definitely.

Keira Davidson (15:53):

Yeah, especially trying to use the systems that they use is the way forward. Do you typically find that depending on the size of the organization depends on the way they prefer the information to be delivered?

Charlie Williams (16:11):

I’ve not found that, I mean, I imagine there’s probably some patterns towards it, but for me, it’s always been such a varied thing. I think an awful lot of people use something like JIRA, or something like that, because they’re wanting to use a documented ticketing system, rather just relying on emails, and the equivalents of those. I’ve also used things like [inaudible 00:16:31] quite regularly, where they want to… The equivalent of a ticket, once it’s agreed, is to raise a new card, and then guide it through the stages of the implementation. So yeah, there’s a few different things, but I haven’t seen any hard and fast rules. I think mostly what depends is… The size of the business will affect it more in terms of who you are dealing with, and how many people you’ve got to convince, or how many people have got to be included in each stage, and things like that. That’s what I think the biggest difference is.

Keira Davidson (17:04):

Yeah, that brings me on then to ask, so you know if you’re dealing with a corporation where you have to get sign off for implementations from let’s say the directors, or the CEO of the company, how would you approach that?

Charlie Williams (17:24):

Yeah, that’s always a bit of a difficulty if you’ve not been dealing with them from the beginning, for sure, so they haven’t got to know you. So, what I like to do is approach things in a couple of ways to make it easy for them to understand what we’re trying to do and the potential value of it. So, one is actually the recommendations you do, so making sure you’ve got that in a format that the majority of people can understand and can kind of get on board with, that’s a good thing. But I also think it happens even before that, when you start planning your review work, or your retainer, or your project, or whatever you’re doing. So, selling SEO can be quite tricky, because you can’t actually buy physical units of SEO, or something like that, and selling services is more difficult than a product, isn’t it? Because you can’t physically pick up a service, and understand it, and look at it, and it kind of makes some decisions that way, there’s not statistics about it, like technical specifications.

Charlie Williams (18:23):

So, when it comes to selling in your recommendations or your service to begin with, there’s a few core things I found really helpful to do to make it easy for people to grasp what we’re trying to do. So, one is that process we talked about a few moments ago, about the idea of every recommendation being this lets our users do this, or this makes sure search engines can do this, so we can reach more users. So, that kind of framing of every recommendation I think is really, really key, and then when it comes to explaining everything about high level about why you’ve been this auditing work when introducing the recommendations as a whole, there’s a few good things we can do. We can give a really good explanation of what we want to do, not everyone knows SEO, not everyone understands why we’re doing it or the benefits. So, giving concrete definitions of what we’re doing, at least with this particular set of recommendations, or this audit, or whatever it is, that can really help.

Charlie Williams (19:15):

Just put it in normal English terms at the beginning, what we are looking to do, so [inaudible 00:19:19] on board. Wherever possible, you want to try and get a few quick wins in before you start asking for more difficult stuff. So, what we’re doing there is we’re improving the trust people have in us, and we’ve already seen some positive results because of this. Doesn’t have to be more traffic, because we know we have to wait a bit of time often for SEO to kick in. But they’ve seen it’s easy to work with, the recommendations made sense, it was easy to implement, [inaudible 00:19:43] all the data we wanted, and we can see that X, Y, or Z has started to improve as a result. So, getting a few bits of that before we start doing more difficult ones, I think gives you that trust, that when you start making more difficult recommendations, they believe that it’ll be worth the effort. Then finally, wherever possible, I like to alter the amount of risk that’s implied with the job.

Charlie Williams (20:06):

So, it’s not always that easy with technical SEO, but imagine something like site speed. If you sort of have come in with some really strong recommendations about site speed, and people aren’t too sure about it, it’s much easier to get buy in if you say, “This makes a site better for users full stop, it’s not just about SEO. Even if this gave us no SEO improvement whatsoever, this would actually improve the experience of everybody who visits the website.” It’s very hard for anybody then to argue with that as being something they shouldn’t consider doing. Whereas, if you come in and say, “This might give us a small tweak, it’s a small SEO improvement in the scale of things, but if we’ve got an even match with somebody else, it’s a good tie breaker.” That is not really a good argument for site speed, but saying, “This makes it better for everybody who visits the website, no matter what channel they’ve used,” that is a much more compelling argument.

Keira Davidson (21:01):

That is a really good point as well. I’ve personally found, as soon as I mentioned that it’s going to benefit user experience, going to just benefit their journey, the clients are more on board with it, because they realize the impact, and the potential uplift it could have.

Charlie Williams (21:19):

Yeah, definitely, when in doubt, just crib off other disciplines that people understand a little bit more. I bring up UX all the time, absolutely, because people know UX is really important. If anything the last year has taught us, obviously, about this kind of real emphasis on digital is that there is a lot of competition, and there is a lot of stuff that people expect from their online experiences. So, when you can put things in that context of UX, it really does help. Not always easy with technical SEO, but even sort of other things can do it. If you’ve got something in your system that’s producing duplicate content, or crawl traps, or anything like that, you can just say, “Well, from a user experience, if they came across this, what would you think? You’d think it wasn’t a good experience, we should nip this in the bud,” or you can say, “What if you imagine Google’s your user, it’s a user who can rank you afterwards, do you want them to see this? No, of course not.”

Keira Davidson (22:12):

You’ve made a really good point there about referring Google to being a user, that is such a good point to make, because sometimes people or clients don’t really care about Google. They know that they have to do well and sort of please Google, but they forget that it ultimately matters, and that considerations need to be thought around search engines as well as the user.

Charlie Williams (22:41):

Yeah, it does make it easy to think of Google as a user. I mean, another technical thing that comes up of course is something like in websites that target multiple countries. People wanting to do auto redirecting, basing on IP addresses, and stuff like that. You kind of go, “Well, think about Google’s a user, Google comes from a computer in the US, so it’ll always see the US stuff. Do you really want to force them only able to see that part of your website?” Yeah, that framing, that’s a good shout, that framing can be a really useful little tool in your toolbox for helping convince people of the glory of your SEO recommendations.

Keira Davidson (23:19):

I’ve really enjoyed speaking with you today, thank you so much. It’s been really interesting to speak with you about this topic, and you’ve given me some great thoughts and insight to bear in mind in future, when I’m speaking with the different teams, so thank you.

Charlie Williams (23:39):

Thank you for having me here, and I’m glad it’s been interesting.

Join the discussion