Welcome to the seventh episode of Open Dialog, the podcast for collaborative SEOs and digital marketers. In each and every episode, we’ll be speaking with the best and brightest minds in SEO, digital marketing and beyond to find out how we can work more effectively, efficiently and productively with other teams, departments and clients.
In episode 7, DeepCrawl’s Sam Marsden spoke with Chris Green who is the Head of Marketing Innovation at Footprint Digital and formerly Head of Search at StrategiQ.
A visual summary of this episode has been sketched out by the supremely talented Katja Budnikov for your viewing pleasure. The full-sized image can be found here.
You gave a talk at SearchNorwich about migrations. Is it true you’ve worked on over 100 migrations?
That's kind of a conservative number just because I was told that any larger it felt implausible. But yeah, I think over the 10 or so years that I've been doing this, I've worked on lots of migrations from new site launches; one platform moving to the other; even down to HTTP to HTTPS and similar.
So just kind of launching and migrating websites has always been a fairly large part of my job. There's a thing or two that I can share on that. I've seen a few things that are enough to put you off your dinner and things that went well. So you see a lot. You get to work with lots of third parties, which is always interesting.
What does your team at StrategiQ look like and who are you working with when you start these migrations?
At StrategiQ, I'm actually lucky. We're really lucky in that the clients that we work with on primarily on the SEO side of things, we’ve have development retainers with sort of between 80 - 90% of them.
So, you know, this whole proverbial kind of nightmare scenario where none of your recommendations ever make it to the site - we don't really suffer from. Usually I work in the same room as the developer that would be doing it. So quite an enviable position, unfortunately not what a lot of people can say. I mean it's not always been the case with me as well.
My previous agency was more of a sort of a specialist search agency. So less directly involved with development. So working with external agencies was more common. But I still work with clients who have their own developers, or their own branding agencies and bits and pieces like that.
But I mean, our kind of layout - we were kind of going for this full service, integrated marketing kind of approach. So we have a team of developers, a team of designers, and then we've got our sort of marketing team, which crosses the spectrum. But we've got about three or four people specifically in organic search. And then we have two others in the paid search space.
So we've got a fairly strong search marketing team and a strong development team. The vast majority of which are kind of battered into sort of SEO site standards. So what we develop and launch is relatively sound and built around that.
But you know, again, we talk about that dreaded scenario where your recommendations aren't ever getting put into place. We're quite used to working with that as well. So, finding the less optimal, but often easier to implement solutions, is something that we're more than familiar with, because sadly it happens too often.
So when you're starting the planning of a migration, what do the conversations look like with the other teams?
So primarily, we kick off a project, and the way that we always try and do - certainly from a search perspective - is marketing or search has involvement right at the project kickoff and everyone does in that team.
So we've got representation from development, from design and marketing. And there's a kind of a key focus on, “What do we need to achieve? So why are we doing what we're doing?” Which, broadly speaking, is often variations of more traffic, more leads, more business, etc.
But very often, the actual focus, and how we achieve that, might differ. We kind of get all of the buy-in up front. We run through sort of this discovery phase which has kind of multiple approaches. So looking at the kind of target market, looking at the customers, looking at the competition, keywords, benchmark, current performance. Not just organic search, but that's a primary area.
Look at tracking - where we are on that. And from that, we just set a kind of a journey throughout the production process basically, which takes those findings and basically gives our key personas. Who's going to be using the website? And then obviously, from an SEO perspective, what keywords do we need to target? How does that need to impact the site?
And then goes into development for implementation, which is the tough part. Or ‘realizing the dream’ as it were. And throughout the design development process, we have marketing checkpoints. So we review when our wireframes are complete, when visuals are complete.
And then when it goes up on staging, we start running kind of simulations and reviewing the staging site from about, sort of 70 - 80% completion, depending on the size of the build. Which is then when we've mapped the 301 redirects and then just get our pre-launch checks in order.
You know, we make sure that the sites are as tight as they can be before they launch. Then it's presented to the client. And then there are usually kind of an iterative phase of changes and then we launch it.
Then post-launch, which is when all the fun stuff really happens in a weird sort of way. It's when we kind of understand how Google and the market are kind of perceiving the new website. We make sure that the standards are still tight and then we suss out the online marketing. So, you know, a new website is only but a small part in the process.
From a migration perspective, it depends on what the goals are. But broadly speaking, the goal for every site, site migration or launch, we don't go and take any steps backwards. We want to make sure it's an onward process. But apart from that, the kind of wishlist - what keywords do you want to target - will all kind of come from there, really.
In your talk, you said ”If you're being told that organic traffic is going to drop by about 15% post-migration then you're basically doing a bad job.”
Broadly speaking, I think we hear it a lot. And I've worked with people, I've worked with third party agencies. I've also encountered other businesses on the other side of it, where part of the expectation, the second process at the start, is almost this acceptance that you could expect the 10 - 15% drop in traffic, just because it's almost like a migration cost.
From my perspective, having done it as many times as I have done, that doesn't have to be the case. It depends what the goal is, though. I've worked with websites and brands who've had a 3000+ page websites with quite kind of rich content areas. And part of the creative agencies remit has been to sort of streamline the website.
Now streamline can mean one or two things. But as an SEO, when I hear the word ‘streamline’, I usually get a bit worried. Because I think of the creative agency, not particular, wanting to take it from a 3000 page site to a 30 page site, at which point we kind of waved a red flag and said, “No, you're going to lose quite a significant portion of traffic.” So if the expectation of the client is, “We'll launch this new website and not only will our rankings and traffic stay where they are, they will grow,” then that expectation needs to, you know, chart the direction of the site build, relaunch process.
I think that the presentation that I gave in Norwich, I think one of the other things we said is “It's okay to lose traffic, if everyone is aware of where you're losing traffic.” And as a business, you don't want that or that's not that kind of critical. And I find that stakeholders in projects can struggle with that. Very often the higher up the hierarchy you go, the more sometimes people aren’t willing to accept a loss in traffic, because traffic is always a good thing, right? But you know, it's fine if it's a market that’s not useful to you, or if it's some products or some services that you want to jettison, then you can do that, if you do it right. As long as everybody's aware.
So yeah, there's loads of examples on that. But the vast majority of site migrations, if you're kind of sympathetic and you benchmark really well, what works at the point when you start a project, you kind of build the sitemap with that in mind. I guess the only point of warning there is, if you're in that sort of unenviable position of having to launch a new website when the original website is actually doing very well anyway - you know what they say, “When you're at the top, there's only one way you can go.”
And they are some of the worst or most tense migrations I've ever done, because you're launching a brand new website or a site that has no visibility. One way that you could go is you could get better. But when you've got a site that's already at the top of its vertical, that's a very tense experience. And in those scenarios, you can sometimes limit the ambition of the new site by being very kind of conservative or wanting to protect rankings.
But with how tricky sometimes can be, means that you're going to find that most decent SEOs err on the side of caution more often than not, they intend to start sentences and meetings with “it depends”. Well I always try not to, but when you get asked a direct question by a CEO of a company, it's like I need to answer this question about “it depends”, but that's easier said than done.
How accepting are clients of potentially losing traffic that isn’t relevant to their site?
Generally - yeah. I think those kinds of decisions or conversations are always best sort of backed up by the data, where possible anyway. And again, assuming that you've got analytics already set up and you've got a decent amount of historical data, you can usually show them, or you can kind of give an idea or a projection based on their current levels of traffic; where the business is going; what the current conversion rate is.
And the ones that you can kind of put a monetary value to, are often the ones that are easiest to find. Because, not only can you give them an idea of what the potential cost of being lost is, but what the cost to retain that is. And then it just becomes a commercial conversation.
The vast majority of clients I work with, that when you can get into those kinds of commercial terms, it makes sense. It's just like any other decision-making. Where it is a real challenge though, is when you've got lots of stakeholders, or the analytics, or just any kind of tracking data that you've got, is less reliable. You kind of have to try and sell them more on your intuition and experience, rather than evidence as it were, which can always be problematic.
Especially when you've got five, six, seven plus stakeholders in a process, you'll always find someone in there that will pick issue with it. And then it comes down to sort of the hippo, the highest paid person's opinion and how you can kind of convince that person. But broadly speaking, if we do it in a mature way and you set the expectations up front, it goes well. The worst conversations to have are the ones where, in a project, any potential drops haven't been outlined at that point. Because then you've got nothing to fall back on and actually, as a practitioner, that's your fault.
One of the examples I've got where it happened with the best intention actually is, we had a particular client who we tried to retain their sitemap as per the old one, but they never liked a certain traffic-driving area. And they said, “Well, can we drop this section from the website when we launched the new one?” to which my response was, “We can do, but if we don't have that content within the site map or we're reducing it, we have to offset that with greater levels of link-building, marketing efforts, PR and stuff - post-launch,” which they bought into.
But two or three months after launch, they pulled the marketing budget for various reasons, which meant that those rankings dropped and never came back. So that's always frustrating to see. Now obviously we made that clear that that would happen upfront, which meant that the client wasn't annoyed with us at all and they were actually quite accepting of it. But yeah, you got to tee them up before the event. Otherwise you've got a mess on your hands.
To what extent do the developers you work with understand SEO? Is there an education process involved?
A lot of the developers I've worked with here, I've worked with for years. So we've got quite a healthy understanding of what each other does and the pressures of each of our jobs. Because ultimately a developer, their KPIs or targets or what they're judged against, aren't always the same as an SEO or digital marketer. And I would argue that they shouldn't always be.
I've heard the argument that, “Well, if a developer is doing their job properly, SEO will work.” Which in some ways could be true, or would be nice if that was always the case, but it seldom is. I often say that the vast majority of things that a developer needs to work on in the final stages of a project, aren’t the SEO snags quite often. And that causes a bit of tension.
I mean, the way that we tend to do it though, is we have a fairly robust list of pre-launch checks and standards. Which someone who isn't a developer, checks. Obviously we encourage our development team to be as good as they can do. But I'm a firm believer of you don't proof your own work, and that's not just for content or reports, it works with web too.
But yeah, we've had conversations and internal training sessions about how to use headings, and you know, breadcrumbs do need to be there. Page titles, canonicals, pagination or not so much, but you know, all of these kinds of technical standards, we have as an agreed kind of list. So that, at an absolute base level, the team kind of know it.
And where they either don't know it, or there might be a knowledge gap, we put in checkpoints to identify it. Because with the best intentions, there's a lot to remember. So you do need someone just going back and checking it. But what the key thing is, it's a message that I constantly try and drum into people, I sort of say it with a tongue in cheek, you know, make friends with developers. And I don't just mean that in a kind of a cynical way of trying to gain them, but it's getting them bought into why you're doing what you are doing and what the goals are.
And more importantly, if you do need to give feedback on any elements of the work, which isn't ideal, is do it in a way that's kind of respectful of them and what they're working on, and just knowledgeable of what they're trying to do.
I kind of often kind of quote the Dalai Lama - not regularly! I'm paraphrasing now, but you’ve got to create the positive vision to get the best kind of reaction from it. You know, share with everyone the vision of what you're trying to do. And the vast majority of people get it. I mean it is a two-way street. If you're kind of telling the developers that “I'm really worried about these factors, therefore you need to be.” But likewise, you need to be respectful of limitations within the site, what is physically possible and not giving them convoluted recommendations that actually aren't going to make a difference.
You know, in the 11th hour of a project, saying: “This site cannot possibly launch, ould this page freeze in the wrong place? Or this heading shouldn't be a heading, it should just be styled up.” That's not a site breaking issue that's going to stop a launch.
And again, if you're being respectful to the developers, don't flag stuff as a problem unless it is actually a problem. Because otherwise you can railroad an entire development project and pointing fingers at the 11th hour, especially when you're working with third parties, you never want to get into that scenario if you can help it.
Do you have more difficult conversations with clients than your developers?
Yeah, so a lot of the websites that we kind of build, or that I'm involved with directly, are WordPress or Magento. So they're relatively known quantities. You know, they're not massive bespoke systems or they're not enterprise systems or the things that usually create the vast amount of issues.
So again, we're kind of lucky that, if you've got a variant of a blog or a variant of an eCommerce site, we are pretty used to those. It’s that whole “setting client expectations early.” The challenging part most often, certainly working with clients, is usually sort of scope creep or breakdown in communication. Or, if once I believe the expectations are set, but the other side isn't aligned with that. And I'm being very diplomatic because again, it can go in either direction.
You can get the ‘client from hell’, but they don't appear out of nowhere. And again, I'm a firm believer - I've done this for long enough that - you can turn almost any client into an ally and work with them. And as an agency, you should do. But if in the early stages of a project you commit to a load of stuff that you can't do, or you don't make it clear what is or isn't possible, then you’re due to have an issue or a setback at the end of the day anyway.
But one of the biggest preventable problems that we often get is, if you are inspecting a project and you're talking about the commercials at the start, what is in the scope. If there's any ambiguity about content, about migrating content or - more importantly - writing of new content, that's where you're going to have issues later on.
Usually it's that conversation 60 - 70% into a project where one party turns to the other saying, “I thought you were writing the content?” And again, recovering from that, getting that back is quite tricky. We have clients who say we're more than happy to write the content, and we support that, and we do whatever we can. But the most successful projects that launch on time, on budget, are the ones where we write the content with kind of a close relationship with the client.
Because, if I'm going to be really sweeping and maybe overly bold, from the SEO onsite equation, if you've got a good quality website that Google can crawl easily, the only thing that's going to sabotage you is your lack of content. And what we don't let happen is sitemaps be sabotaged by lack of content.
That's always a tricky conversation to have. It's harder to have with third parties if the third party is the one producing the content. Or even if you’re working with a design agency who have kind of created the sitemap and you're allowed to work within its confines. That's when you do have to have the difficult conversation of saying, “Look, Mr or Mrs Client, this website is not going to work for these reasons, because you haven't had the foresight in the early stages.” Yeah, and that can make you unpopular as an SEO.
Can you explain what you mean when you said “SEO’s don’t tend to be the most popular people on projects”?
The biggest way that an SEO can make themselves unpopular - and in fairness - anybody or job title has this capacity. But because typically SEOs get involved too late in the process, they will come in at the 11th hour with the remit of “We're about to launch this website, we can't lose rankings.” Now, at that stage in the project, is probably too late anyway.
However, the SEO will go in, will review what's gone on before, and then will deliver their summary. And the worst way that you can deliver that, is in a slightly bitter or angry kind of fashion. Just saying, “This is poor, this isn’t gonna work. This is terrible. This is shoddy.” There are loads of ways that you can kind of do it, but you can make yourself very unpopular that way. Which makes sense, right?
If you’re effectively slagging off someone else's work, that's never going to be. But actually, even on the less extreme examples, sweating the small stuff. So, because SEO is quite an unknown quantity in so many ways, and there's a lot of stuff we don't know with 100% knowledge or accuracy. Sometimes more often than not. In fact, if an SEO is charged with the remit that no traffic can be lost, they'll go ultra-conservative on all of the recommendations. So, down to social media icons and missing alt text, or it could even be that the robots.txt file doesn't have the sitemap declaration, or bits like that.
Now these are all things that, in an ideal world, should be in place, but it depends. You've got to pick and choose your battles in the sense of, there’s your advisories. Actually, a lot of the tools in the market do this. “These are your warning messages. These are things that are not optimal.” But then you also need to make it really, really clear. “These are the kind of high priority or critical ones.”
Because again, if you want to make yourself unpopular, it's going to be - a senior developer is making some very small fixes that they're just not convinced are going to work. Because the other fact is, you can review many websites ranking incredibly well within a niche, technically they're far from perfect. So if you're the one that in the 11th hour saying: “Hold the launch, this website is going to tank because these really inconsequential areas are present.” That’s a very big key to making themselves unpopular.
So it's a difficult one though. Because equally, involving a User Experience Specialist in a project right at the end, is far too late. And I would argue that involving an SEO at that point is also too late. So, we're very good at creating these scenarios where an SEO has to upset people in some way, shape or form, because otherwise it will go wrong. But there are many ways of doing it. I'm a bit of a big hippie in that sense, that I would much rather we all come to the same consensus and all agree, rather than just stamping your feet until you get your own way.
Have you got any examples of when it's gone really badly working with clients?
Yes. Although thankfully, some of the biggest issues that I’ve encountered here, are long in the past. Which is obviously good for me. So I think one of the worst actually, being within eCommerce platforms - Magento in particular - and filtered navigation. Filtering the category grid or refining the category grid based on product type, size, colour, price, etc.
We had a developer and they were launching a new platform. They decided they wanted a slightly more sort of “user-friendly” way of implementing this. They picked a method that was AJAX-based. But this was all, crikey, four or five years ago actually. So obviously how we would handle that then is slightly different to now anyway.
But long story short, they hadn't listened to the recommendations where basically “This is going to be handled wrong, do not deploy” was the short answer. So it was one of those kind of elements, they'd put it on a staging, they’d installed a new extension, they'd activated it, the clients said they were happy and then they went, “Oh, actually, you better check with our SEO agency,” which I was one of them at the time. They then Ignored the recommendations and deployed it without telling us. I mean, I was blissfully unaware that they were ignoring me.
And it was only a week or so later when we noticed this sort of fairly dramatic spike in pages being crawled and indexed. But we saw that Google was, well, I mean, I think in the end of it, a site that had about three and a half thousand products, it was about a quarter of a million pages, within a few weeks of being indexed, and it just continued to grow. And unfortunately when they listened to us, was when rankings then tanked, which they did and that's when the extension was disabled and we created a better method to move forward.
But that took months and months to clear up. And sadly, you know, in the real disaster, we as an SEO agency were taken off the project a few months afterwards, cause a new eCommerce Manager came in. And it was only a couple of weeks later, did the rankings start to recover from the original issue.
So, that was kind of a lose-lose situation on everyone's part really. The client lost the revenue and the sales for the time that the issued had happen. And we lost the client because of it. So looking back, certainly at me and how I was then, “Is there a way of making that point a bit clearer? Is there any way of illustrating the case better?” I don't know, but you have to ask yourself those questions after the event, rather than necessarily assume that it was all someone else's fault.
But, yeah, I haven't seen many go much worse than that. I mean, you always get the, “Oh, by the way, we've launched the website, could you do the 301’s now?” That's the classic, which happens quite often.
And the others: “Oh, we launched our new website. Why have our rankings dropped?” “Oh, you didn't unblock it with robots,” or worse, “You've left the staging password in place.” We see those from time to time. And again, we have our internal process here. We have three different people do that same check on every launch.
[Sam]: I suppose that's quite good for you though, because you can be like some sort of SEO magician and suddenly...fix it!
[Chris]: Yeah, I mean, I see more of those as kind of sales or pre-sales. So the client gets in touch saying - you know, I call it the “Help me out, be one moment”. It usually is and you kind of look pretty epic by deleting one character from the robot's text file and then the site comes back.
But broadly speaking, we don't lord it up as, you know, as you said, that wizardry kind of point. We’re usually fairly open and honest to say “This is just what duty of care looks like” but it is cool. I mean, I enjoy those projects where you can make a huge amount of impact with relatively low effort. But sadly, when you build the website correctly, that's not the case.
I think one of the other things I kind of tell a lot of people in this process is just, “A technically sound website is just not enough to rank alone.” Say you've got to pull your own website, everyone's decided a platform is aging and it needs updating. There's almost an inherent assumption that building a new version of it will make it rank better? Google doesn't really care if users are still getting what they want out of it. If the content is still good for the key terms that they’re ranking for, a handful of technical problems - even low to medium level - aren't going to hold it back massively.
So it's something that we set, you know, our standard of launching a website is: “There will be no errors on this site,” because why should there be? It's brand new, it's like buying a brand new car, you don't accept scratches, dents, etc. But that by itself isn't enough and very often you have to stress to clients or other third party agencies is just, “Have you actually solved the problem why you weren't ranking in the first place?” Which could be content, could be you didn’t add the right key terms, could be the site structure is horrible or many different elements.
So fixing technical problems only makes you rank if the technical problems were stopping you from doing so. Which on smaller websites is less often the case.
Would you say it's mainly having the experience to know when SEO issues need to be prioritized and when to let it go?
Yeah. It's a tricky one, because there is a reasonably well-documented kind of best practice in the space and it's very often you can say when something is either 100% right or not. It’s that grey area that does definitely cause the issue. I think on a site launch or a migration, you look at what's there currently. So, “What is our benchmark and are we any better or worse than that?”
So from a content perspective - and there is a level of subjectivity, experience and expertise here - but look at the content. Is that content any more or less optimal for the key terms that you're targeting? It's fair to say if you're cutting 50 - 75% of content, you're risking it. Now you don't know for certain that that will cause a direct issue.
Most of the time, in my experience it does. But I mean, the whole kind of ranking mix is just a little too opaque for us to really understand that. If you're kind of miles ahead anyway and you've got a really strong link profile, you could probably get away from it. But my question in that instance is: “Do we need to risk it?”
So if you've got a benchmark, how far are you from that benchmark? Are you better than, or worse than? And that's a good point to steer by, because that means that your point of reference is project-based. Because actually, ultimately a lot of recommendations and the severity or importance of certain things, is dependent on that scenario. Hence the phrase: “It depends,” obviously.
But a lot of the time it is experience and when you start talking about the quality of code, heading structures, crawl budget and all of these other kinds of things is, we see Google deal with really bad websites and they rank quite well more often than not.
So it's one of those ones where - say for example - someone's heading structure was broken or there were five or six H1’s on the page or something. The feedback to that ultimately would be, “This is not optimal, optimal looks like this example, why can we not get it to here?” If there's a legitimate reason, it's then a case of, “Well, fundamentally, one H1 on that page, please, it doesn't matter if the HTML file will accept that.” We know that multiple H1s dilutes, kind of, the value of them. So again, why risk it?
Now, obviously there are times when, no matter how compelling your argument there, it isn’t often enough, in which case it more turns to expectation management. It turns to “Okay well, this isn't advisable. You know, we've warned you, however, if we do notice a problem, we may need to roll back or make these changes post-launch.”
Now that scenario is really tricky because, obviously the more things you change, the more variables you introduce. If rankings do drop, finding what the cause for that is, is incredibly tough. And very often I've found that you end up fixing all of those things and more in a kind of mad dash to try and recover any lost ground.
But a good benchmark is, you know, with the current site are you any better or worse? If you're losing content, you're most probably going in the wrong direction. If the site map is becoming too complex or you're pushing key content too far away from the homepage that, broadly speaking, does have a problem. Then if you start slowing down - obviously page speed’s massively important - and making the website slower is often a problem. It doesn't take a genius to work that out.
Examples of that going wrong are quite frequent, so you can often put the fear of God into stakeholders with well-documented examples. Just, only do it when you really need to. Because again, you’ll get into a ‘cry wolf’ scenario and then they stop listening to you altogether, which isn’t great.
What does your content team look like and how do you get them interested in considering SEO in their work?
So it's kind of a few areas there. Our content team here, is we have sort of a key Content Manager and a couple of key content/SEO bods in the office. And then we work with trusted content writers in different niches and industries. Because very often you want someone who knows an area, just so that you know that the content is on point and relevant. The language and the feel of it sort of fits the industry.
But we tend to employ our content team with a desire of them having at least a knowledge or an appreciation of SEO.
Do the content writers sit under your remit of search, within the company?
No, not specifically. We kind of try and position it so they have an appreciation of it but what we don't want is “SEO content writers” because that’s literally just the worse content ever.
I tell you what the biggest ingredient for success in good content that helps SEO is, it's just a strong brief. And by which I don't even mean a really kind of exhaustive list of target key terms, you want the content writer to know what the area that they're appealing for. If there are some crucial key terms that you do need mentioned, you want to tell them what those are. But the brief and the framework or the structure of the piece needs to be strong enough that they can write about it and they'll hit the right boxes as they go.
Sometimes for longer content, for long-tail content or if you're targeting answer boxes or little snippets or whatnot. Very often you would suggest a series of questions or say, “We have noticed this question gets asked a lot. Please answer that question.” But the last thing you ever want to do is to say to a content writer, particularly one that you don't work within the same room, sometimes is: “Please make sure you use all of these key terms we want to target.” It just becomes this kind of robotic, just horrid.
[Sam]: Something that wouldn't have ranked since 15 odd years ago.
[Chris]: Yeah. We sometimes see it working, but I kind of remind clients' content teams, various people is actually, when you're actually looking for the target key terms, what ranks currently, you need to be better than that. So if you are in a position where your niche is terrible and it's still using tactic circa 5 -10 years ago, then actually sometimes keyword stuffing, manipulate internal linking and various other things can still work. And in some cases, are required to work.
I mean that, in fairness, within the last year or so that's becoming less of a thing. But who's best in class? You know, especially when we're looking at long tail content, or this guide needs to make us the market leader in this key term. This is our ultimate top of the funnel content, you've got to look at what's the best example as it is and you've got to work out if you can beat it.
We have had examples recently where we've said, “We, at this moment in time, don't believe we can easily surpass the content that's currently there. Do we need to come back once we've produced something to talk about or something of merit?” And that depends on the budget and how badly you want to rank for a certain term.
But there is a large point of this, you know, I hate this term because it can be used a bit flippantly, but “do good content”. That isn't the be-all and end-all, but it is such a significant part of it. And so it should be, you know? Call me kind of naive or however you want to call it, but I'd much rather rank with content that is really good, than get lucky or manipulate my way to ranking with something that isn't that great. Because, I quite like knowing that what I've done is pretty good, or what work we produce for a client will stand up on its own, irrespective of Google in a way and that's always the goal without a question.
What recommendations do you have for SEOs looking to better work with other teams?
The first one is: “Get your voice heard sooner” and sometimes that isn't you as an SEO, particularly if you're like an SEO consultant or an SEO exec or manager in a business or an agency, you often won't be there at the start.
But make sure you're there as early as you can, is a critical point. Because if you're sat around the table when the project has kicked off, you know a lot more about it, a lot more about the goals, objectives, the commercial - which really helps. It makes sure that all of your recommendations are more personal and important to the actual goal. Rather than just recommending sort of fairly irrelevant key terms because they look achievable or that they have enough volume. So that's kind of a key one and you know, broadly speaking, the sooner you can get in there, the better.
The second one I would say, is just ensuring that this regularity of small, often touchpoints. Some projects can over-rely on an SEO’s input, which I would argue can make worse websites sometimes. A web designer, web developer, UX person - they're all vastly different skill sets. You need all of them ideally to make the best sites.
So kind of, for an SEO to know where their opinion is needed and where it isn't. And more importantly, but out when it isn't that important. Don't just weigh in because you have an opinion. A lot of SEOs that I have worked with, have seen a lot of websites, we all know what good looks like. But again, it's just be respectful of everyone's own kind of remit within a project.
As an SEO, I'm not very fond of when a developer tells me that my recommendation isn't going to be that important. Because it's like, “Well, that's kind of my decision with my kind of skilled expertise.” But equally, if you go in and tell a developer, “Well, I probably wouldn’t have built it like that,” unless there's an SEO impacting element on there, they're probably not going to like it. So know where is your opinion, and where it's not.
But then finally, it’s develop a healthy appreciation of everyone else's skills and everyone else's goals, and that's more of a broad kind of just working with people well kind of skill. Is if you know what motivates everybody else within a project, you can work better with them. You've got to be emotionally aware sometimes, and equally, sometimes you need to know when you need to use those as levers to get them to actually do what you want.
I still think the vast majority of projects like this, most SEO problems, even if they manifest themselves as tech SEO problems, they're not technical in nature. They've come from a person or a people problem, or a decision-making issue, or a poor business decision right at the start. So I think the sooner that an SEO in these kinds of projects and situations can understand the wider forces at play, rather than just what Google thinks of the website they're looking at, then actually the easier that you can manage the whole process.
Especially when there's third parties, because third parties always lead to conflict of interest, especially when the agency that you're working with is doing design or so often is SEO or you know, you have overlapping services. That’s always causing unnecessary tension that you just need to work it out. But be respectful and understand what drives people and then ultimately, just guide the client by what is best for them. And just make it as plain as you can to them.
You mentioned that UX can become over-reliant on SEOs. What exactly do you mean by that? That it becomes less about what’s best for the user, and what the client wants?
So, best examples usually are when, usually larger companies, where they may have launched a site one, two, three years ago and it's gone badly. Actually a lot of the websites I work in are sort of following botched migrations. And that whole thing of once bitten, twice shy, so they'll approach a new project being like, “Oh. We've since learned that our SEO wasn't good enough, we need good SEOs now.” Which is kind of fair.
But what I would argue, is that in some instances, that can be the SEO is responsible for designing this site map. Full stop. The SEO is the one who comes and defines all of the key elements needed within the templates and the visuals and it could be, the SEO is the one that’s briefing in every single piece of content.
And you’re kind of right when you say that: “Well the problem there is the SEO’s motivation,” as much as it can be what's good for the users, what’s good content, etc. But the primary driver from an SEO perspective is generating traffic via organic search, which absolutely has its place in every website that needs traffic from organic search.
However, it can alienate audiences, or it can do a multitude of things that are negative. You may miss some opportunities. You lose innovation. You can lose respect. You can lose credibility. There's so many different kinds of factors that there's a reason why there are very few people who can successfully map out a website, do the keyword research, design the visuals and build it and then launch it and market it.
You know, there aren't many people who can do all that really well and that's because they're just fundamentally different things. So it's people's fear from past experiences that can often overly create an alliance on that, “oh wait, actually, if we have our SEO involved through the whole process, we won't have that problem again.” You might not, but you might have some other more significant ones that may be harder to recover from later.
So it's just maintaining a balance and just being aware. You know, building a website is complicated. It's a lot harder than most people think. It's a lot harder than a lot of SEOs tend to think for sure, which is quite amusing. But you need lots of different people, draw on that experience in its breadth and its depth where you can.
Could you explain the phrase you coined ‘unconscious incompetence’? What does it mean and how can we avoid it?
I guess the cut and thrust of what we're sort of talking about there - so unconscious in competencies was based on something that Maslow wrote. But the idea in the post and how I positioned it is, it's possible for you to be incompetent or bad at your job, without even comprehending or being aware that that's a thing.
And broadly speaking, you start off in unconscious and competence. So you don't know that you're not very good, because you haven't learnt about it. You don't know what you don't.
[Sam]: Kind of blissful ignorance.
[Chris]: Yeah. And virtually everyone starts their learning journey there. I mean, the word incompetence in here often puts people's backs up because it has a very negative connotation. But when you start your learning journey, you start to get better, you kind of go into a conscious incompetence. So you start to become aware of what you have to learn and you become knowing of your lack of knowledge. Which is again, a healthy stage and that's what you use to structure your learning and development.
And then you become sort of, consciously competent. So you have to work hard, but you become good at what you do. Because you're learning, you're furthering yourself, you're challenging, you're double-checking.
And then the next stage is kind of like an unconscious competence where you're just good at it. It's when your knowledge turns into, almost like muscle memory, or experience, or intuition, or gut feel, or however you want to frame it.
Now, what I'm kind of suggesting in that piece, an SEO in unconscious competence has a risk. Mainly because, ranking makeup for Google is so opaque, things change. Documentation that they provide is sometimes wrong and you can get misled, and all of these elements. You risk becoming incompetent or poor at your job, without even realizing what's happening.
A part of the blog came out of, I guess, my own journey over the last couple of years, where I've been less the practitioner and more of heading up teams and training and working with staff. And my own, I guess concern or worry maybe, that I might be coming unconsciously and competent about things, you know. That ability to not test and validate your ideas, and what works, and what doesn't work. I mean even, you know what I've said earlier, you know, where “Don't have more than one H1 on the page.”
I mean, I'm thinking about it, I haven't actively tested what detriment that might have if we did have a sudden need to. Mainly because that's a test where you’d expect a negative outcome and finding the right platform or site to actually test something like that on, is a challenge. Cause not many people are gonna willingly put themselves open to that.
But you're testing and validating your approach. And all of the elements that I teach - the SEO execs here, the workshops that I do, the talks I do - who's checking and validating that? So I don’t want to be like necessarily seen as table banging. Cause I'm not suggesting that everyone else is unknowingly stupid and I’m not. It's probably more, a little bit of the case that, maybe I could be too? But I actually think that the SEOs, or SEO as an industry perhaps, isn't that worried about that.
I think the appetite to test, to check - there are certainly people within the community who do it more often than not. And actually we're in a very kind of fortunate state that a lot of the SEO and marketing toolkits out there seem quite heavily invested in that. Because if nothing else, it's quite good content marketing too.
But there's often the infrastructures, data and ways of testing that most normal people can't do. But the knowledge share, and the openness around some of this stuff isn't as good as it maybe could be, or people just don't. The curiosity - if someone does an anecdotal study of 10 websites for example, and has a finding, there's no peer review. There's no following two projects by other people looking to prove or disprove, it's not an academic kind of field, really. Although we do have academics in it.
All I'm saying is, people just need to check their work a bit more, which can be tough. You don't want to tell a client that you're not sure what you're doing, because that doesn't help you sometimes, but just regular checkpoint. I mean, the moment you assume that you can't learn anything more, is when you're really at risk. Because you get surprised, you know?
I see people that have been in the industry for one, two, three years and some of the stuff that they’re coming up with is fantastic. I wish that I was doing that, you know that young into it. But the beautiful thing about it is, your kind of tenure within the space isn't always a positive, if anything it can weigh you down.
How do you make sure that your knowledge stays up to scratch?
Ultimately I still do a lot of day-to-day, but nowhere near as much as I used to. But there is a bit of a conscious decision to remove myself completely from delivery, I'd get rusty, I guess is the simple sentence.
There is a certain degree of learning, monitoring, watching what everyone else is doing. Not because I'm untrusting or I think it's going to go wrong. So for example, to some people this might seem like a very common practice, but not everyone does it and it's just a question.
If you do optimize a particular page with some new keywords, or you go and make some alterations on rank tracking software, you can just add a note on that particular keyword on that day, to say what it is you've done. And then it's kind of, “Okay, monitor it, following that happening what is the direction of change of that particular ranking relative to the others?” You know, if there hasn't been a change that's affected everything, was the resulting change positive or negative? No, it's not the most perfect way of testing it, but it actually makes sure that we are looking at it.
The other side is, looking at something for longer than just a few days or maybe a week after change. Because we all see it - you make a few changes to a page, it kind of jumps up. But then it actually could potentially sink back down again, or go worse. And don't just necessarily assume that the first ranking move you see after an optimization changes, is a given, is what it is.
So that's like a really kind of simple one. But again, it's just making sure that the team do that from a standard, if nothing else, so I can kind of check-in and see that. Cause that is kind of important. I think that, at a broader level, what you can learn from other websites and what they do. So, looking at some of the more SEO visibility tools and software out there, you've got the benefit of analyzing what's happened to a website through a terrible migration without it being one of your own. You’re looking at the changes and you're using the power of hindsight to see what has happened.
I did quite a lot with just digging into WHSmith recently when their website dropped down and there was quite a lot of stuff that you could kind of see. There was an over reliance on third party search tools and a few other bits and pieces that didn't help them and it did cause kind of problems. Again, you've got the benefit of hindsight. You've got to be careful you don't mix up correlation causation, but just keep an open mind. Stay hungry and just a healthy level of skepticism, don't assume that just because it's in line with what you'd expect, that it's doing what is expected. I think we can mistake mixed signals quite heavily.
[Sam]: I do like that though, taking lessons from high profile catastrophic websites. That's quite good.
[Chris]: It can be good. The only thing I have learned from doing that is, sometimes sites of that kind of size or visibility, often can react and change very, very differently to smaller ones. So it does help you see at scale what can happen and again, it creates some really juicy case studies that most people are fearful to commit to. But monitoring some of the smaller ones as well can be useful too.
[Sam]: Yeah, I'm just touching on the SEO tests. That's something that we're really keen to do more of at DeepCrawl. It's just a matter of putting aside the time and kind of resources for it. There's all these competing priorities and unfortunately, that's something that kind of gets pushed to the side, but yeah, it's so valuable and I love seeing all of the results of different tests on Twitter. But yeah, there definitely aren't enough people doing that.
[Chris]: No, there’s not. And actually, if I had the chance, I'd be doing more as well. But again, the hardest part we found is actually finding suitable test subjects as it were. Split testing and SEO is something that's been talked about quite heavily on and off for the last few years. But you know, finding a test sample of pages that have over a thousand visits to it, that people are willing to do a test on, is challenging.
I know Inaudible recently moved the bar along by changing their statistical models so you can do it on smaller traffic samples. But until that side of things has kind of trickled down to the rest of the industry, or until we’ve started utilizing kind of machine learning a bit better to help the testing process, it's still a bit of finger in the wind, which isn’t great.
Is there a product or a service that you use to make your working life easier?
I think the one that's changed the way I work most significantly, recently is SISTRIX and that's in the visibility side of things. So actually, it tracks Google results, the granularity of the detail that you can get - I can kind of pick up vast majority of websites and get quite a good view on what's happened to that website over the last, potentially 10 year just by kind of interrogating the data.
And the more you do it, the quicker it gets, and you kind of begin to learn a lot about all websites in general and kind of how good it would react to change and so on. And for me, just having that data really quickly is probably one of the biggest things that I benefited from.
It's not the only one of its kind out there. You’ve got SEMrush, Search Metrics and a few others. They all do kind of variations of a theme, but I've just sort of had a particular affinity to this one and it does what I need it to. There is such a thing as having too much data, but if you can present it in a way that it can inform your decision making and can help you unpick a botch migration in a matter of minutes then it's going to change your approach. You will see things that others will miss.
[Sam]: That's a great set of tools. But, I think you're kind of maybe missing one from that bunch there. Is there maybe a more technically focused platform that you'd also care to mention as well?
[Chris]: What, a crawling based platform?
[Sam]: I'm not putting any ideas in your head.
[Chris]: I'm a multi-crawler kind of guy!
[Sam]: There is the need for multiple crawlers, definitely.
This is your shameless plug. Is there anything that you'd like to promote?
I think there's two actually, based on some work I've done with one of my colleagues, Simon, over the last couple years.
Well the first one is more of one of his projects, but it's really cool and just check it out because he gets such a buzz from people using it. He recently wrote a connector for Data Studio which pulls in Google Trends data, which is very cool and it's called G Trends.
There's a link on the StrategiQ blog, but effectively, you enter in your email address, and it sets up a service that just sends you an API key. You authorize the connector in Data Studio and you can pull in Trends’ data, you can also blend different trend connectors to kind of create blended trend sources, date sources, which has become kind of a staple of a lot of our own internal reporting.
And actually, we’re working out how to do this, but just give API access that can be used from sheets as well, which adds another dimension to keyword research, put it that way. So that's really cool, it's free, go use it. We have nearly a thousand users now, which is pretty cool. You know, give something away that's pretty cool for free and people like it, who knows?
The other one, it's still being worked on in the background. We had a bit of a fanfare of it at the start of the year. But it's actually a platform that we're building called Spark, which is built off Cloudflare's edge workers. And essentially it's, I don't know where we are on the concept of sort of a meta CMS, but it's a way of managing the content and code of the site, above the server level, so in the cloud, if you call it that. Probably, on the edge is a better word term.
But essentially that's a platform that we need to put more focus and work into. So Simon Cox just recently released a blog around how he uses Spark to inject lazy loading images to a site from the edge, without any code change on the website, which is quite beneficial.
I've written a blog and started there about how to inject old tags based on file names. So images, so you know, a bit rough and ready, but again, how do you add old tags when there are none. But the potential where that platform could go is a fairly low barrier to entry, split testing platform. We don't know where it's going to go, but anyone who wants to test it or get involved. It's still kind of pre beta at the moment, so we're not even charging yet, but it's just a case of, we think it's pretty cool.
We think it's a way of testing some of these elements and putting to bed some myths. And we got a lot of interest when we launched it and it's gone a little bit quiet cause some of the internal demands. But it's something that anyone that wants to drop me a message to talk about it or whatever, I'm more than happy to.
Is this something similar to what Dan Taylor has been talking about?
Yeah. Very, very close actually, I spoke to Dan a fair bit on and off, I think he beat us to the post by about six weeks. But yeah, they're pretty much the same in principle. I think Dan brought more kind of features and functionality straight away. And Spark has a little bit more in the way of a UI and the split testing side of things. But he's talking about it at Brighton, or talked at Brighton, by the time this will go live. So I'm sure he will have shared some really cool stuff about that as well. We try and keep a quite good relationship with him because again, we're all trying to do the same thing at the end of the day.
[Sam]: I really liked the name Spark, but have you given any more thought to the name like, Meta CMS doesn't sound quite as good as, Dan was describing it as SEO on the edge, which sounds like far more kind of sexy and dangerous.
[Chris]: So, till someone asks you just to say what is it? Well it’s SEO changes made on the edge and it’s “Oh”. But yeah, we are all quite excited by it actually. I think the industry settled down quite quickly cause it's almost business as usual just by a slightly different means.
But no, it is exciting. I think actually, the whole kind of, not just for SEO what it can do, you combine that kind of platform with kind of machine learning, with analytics, with kind of crawling technology. It's not a million miles away to suggest that you could have an edge platform that optimizes the website as it goes based on real time data that's fed in. So, I don't know if any SEOs are fearful of their jobs, but that would be one route to make SEOs jobless. Just don’t blame me.
[Sam]: We'll blame you when we're all out of work.
[Chris]: Well I don’t know. That could be quite good for DeepCrawl?
[Sam]: Yeah, it could work out actually. I'll definitely be checking out both of those. Particularly the Data Studio with bringing in Google Trends. I think, is it your colleague Hannah? I keep on shouting out her keyword cannibalization dashboard. Really, really appreciate that. Are you familiar with this?
[Chris]: Yeah, I work with Hannah quite a lot on that and other Data Studio things. I think where, there's almost a joke now, not just in this office, but with a load of other people that we sort of speak to and work with is, you know, you can kind of make a data studio out of anything.
But it’s that dashboard and a few other things that we're building, we’re using Data Studio almost more in a slightly kind of, not really a software kind of age. But we sort of report on keyword research and other things using Data Studio with just the visualizations or kind of filters and just making things more palatable. And seeing a lot of potential in that platform to do kind of really complex things, really easy. I mean, obviously you've done a lot of work on it yourself. So we're all really excited with what else you can bring from that.
Be the first to hear about new episodes
A massive thank you to Chris for being such a great guest and teaching us so much about his wide and varied experiences working agency side. You can find more episodes of Open Dialog here on the DeepCrawl Blog and make sure to be the first to find out about new episodes by joining our mailing list.
Join our mailing list