 Hi, I'm Helen, Head of SEO at Car and Classic and today we're going to look at how SEOs and developers can work better together. Now I'd spend some time explaining to you why developers and SEOs need to work better together, but it's kind of obvious really. Developers have the opportunity to make our lives so much better by quickly implementing that fix to load speed or making our lives so much worse by accidentally rolling out some code that completely de-indexes the website. But actually we can really help developers as well because we have the opportunity to give them data into usability and accessibility. It's actually quite important that we work well together. Now you're often here, people say that if you want to get on well with your developers you need to bribe them with donuts. Which is a little bit insulting and a lot expensive because who has that kind of donut money just hanging around. But actually we need to work out how we can form a really good working relationship with developers that doesn't rely solely on baked goods. Now how do we do that? Well, first off we need to start by understanding their processes because essentially if we're asking them to do things for us we need to make sure that we are communicating in a way that fits into their processes. So learn how to brief in your requirements in a way that helps them to prioritise and plan your work. So what is it that they do at the moment? Do they have a ticketing system that they use that they put all of their requirements in and allows it to be monitored as it moves through the process? Or do they have some other way that they track the work that they're doing? But make sure that you are putting in your requirements and your requests in the format that works for them. There's no point just shooting over an email to them asking them to fix something if it doesn't actually make it into their work. So what else do you need to do? You need to look at where you have briefed things in the past and it's not really worked out well. So perhaps mistakes were made, there was a misunderstanding, a problem with communication. Have a look through some of the tickets that you've submitted in the past and look to see whether there are reasons why they got rejected or misunderstood. What do you need to do to clarify things when you're briefing in work for your developers? Perhaps you can look at other teams and what they do when they are briefing in work for their developers. Maybe you can understand how they are stretching their tickets or whether there's particular terminology they use to help communicate things to the devs better. But learn from where other people are doing it better as well as where you've not done it so well in the past. And hopefully you'll come up with a really good way of helping your developers understand what work you want them to do. Look at things like their work cadence. So do they commit to doing work two weeks in advance? Do they commit to a whole month worth of work before they get going? Or do they have some slightly confusing mix of agile and waterfall that essentially means no one knows what work they're doing but it has to be done right now. Whatever way your developers have their work planned in for them, make sure that you are aware of it because that cadence is going to be really important. If you want something done and you need it done soon then you're probably going to have to see if you can get it prioritised in order for it to be in this sprint or the next sprint for example. And you want to know what kind of timeframes that they're working to. How much time is your ticket going to take? So if you've asked them to do something really complicated on the website it's going to take a lot more time, testing, resources for that to actually be rolled out. So make sure that you've got that planned in for your own schedule of work. And finally, what do you do if everything explodes on the website and you need to get it fixed right now? So say the entire website has been de-indexed somehow. Are you supposed to just put a ticket in and wait for two weeks for the next sprint for it to get fixed? That doesn't sound like a good idea. So how do you escalate when there are some real serious critical issues that you've identified? Do you have to put a ticket in to a different workstream? Do you have to talk to someone in particular about it? Do you just have to run around the office screaming a little bit until someone pays attention to you? What is the way that you get your tickets escalated at your company or at your client's company? Next, look at some training. What are the common things that your developers run into when they are being asked by the SEOs to implement work? So are there problems with pagination often that you're asking them to fix? Or are they implementing links in a way that isn't particularly SEO-friendly? Can you just train them in this kind of stuff in advance so that they are already equipped to know how to do things from an SEO perspective, rather than waiting for you to say, you did that wrong? Maybe you can put together a repository of these documents. So actually, why don't you write this kind of stuff down? So whenever you tell someone how to implement pagination in a SEO-friendly way, write it down, give the context of what it is that you asked them to do and how that was fixed, so that they can refer back to it, other members of the team can refer back to it, and actually all the SEOs are on board and making sure that they are recommending the same ways of working in the future. If you want to train your developers, they're busy, they're busy people. They might not have an hour or two hours for you to go through the intricacies of how websites are crawled by search engines. Is there an alternative way that you can train them? Look at things like how do they train each other, actually? Do they send over videos? Do they write it all down? Do they have real quick 15 minutes distilling of information? How do they train each other? How do they upskill themselves and see if you can conduct your training in a similar way? Really important to making sure that you're working well with your developers is getting some kind of SEO QA process in place. So this means things like being tagged in the tickets that are being taken through the development process. So it might be that developers aren't aware of things that could be affecting SEO, and therefore, if they can just tag you on the tickets, you can go in and check to see whether there's any SEO impact or any input that you need to have. You can also assign a point person. So perhaps there's a project manager or there's an engineering lead within the development team that you can always go to and make sure that you have an SEO that they can always come to. That way you've got a point person, a point of contact between both teams. So whenever there is any kind of confusion or discussion around tickets or priorities, they're getting one message from one person and you're not confusing the situation with lots of voices all chipping in. And make sure whatever happens you have the authority to stop something being rolled out. Make sure that you've spoken to the right stakeholders so that you have that authority to say no to something being implemented. Because it's all very well being tagged in a ticket or being told of future developments, but actually if you're not allowed to say hold on, we need to change how we're implementing this, then it's kind of useless and a waste of your time. And ultimately, you don't want something to get rolled out that is going to have a really negative impact on your organic visibility, just for it to have to get fixed or rolled back at a later date. You want to be able to say no before it's rolled out in the first place. And last up, how do you get buy-in from your development team? Well, I once gave a survey to a whole bunch of developers asking them what they needed from the SEO team to work better with them. And of the two developers that actually responded to my survey, they both said they wanted more context around the tickets that we were putting in. They want to know why we're asking for stuff, not just what it is we're asking for. So if you're asking for your developers to implement Hreflang tags on the website, make sure that you are telling them why. What is it that you're trying to end up with? What do you want from the Hreflang tags so that they understand the context and they can perhaps suggest better ways of doing things or they can make sure that wherever they are implementing SEO changes, it's not negatively affecting the website in other ways. Our job as SEOs is to safeguard organic traffic. Their job as website developers is to safeguard the entire website. So they probably want to know why we're making changes so that they can check it's not going to have any adverse effects. Make sure you understand their ways of working. So if they like to communicate through emails or instant messaging services or perhaps they like to only communicate about tickets within the ticketing system itself so they've got a nice audit trail that anyone can refer back to you, try and make sure that you're working in a similar way. So that your recommendations and your advice and your questions don't get missed. If they're only checking the tickets to see what people are commenting on or asking and you're sending the emails through then chances are that the right people aren't going to see the things that you're commenting on. Try and get yourself an SEO champion. And this is kind of good advice for any of the teams that you're working with but make sure that you have a person within the development team or your client's agency that really wants to know more about SEO, that really gets SEO and wants to improve their understanding of it. Because if you have someone who's really keen to learn more, perhaps they did SEO a bit in a previous job or they just have an interest in it, then you've got a person who's probably going to be on your side when you're asking for things like changes in ways of working or for a whole new process to be implemented. If you have a champion, someone in the development team that wants to learn more from you that you can perhaps mentor a bit in SEO, then you're going to have someone who's really keen to help you. Look at the tools and data that you have access to as SEOs that your development team doesn't and see whether there's data that they'd actually find quite valuable. Yes, they can interrogate a database but they don't necessarily have the tools to crawl a website in the same way that we do, for example. And it might be that they want to find information and understand how a search engine is perceiving something. So you can either train them in using things like Google Search Console or you can give them access to the data instead. But make sure that you are communicating with them the data that they will find useful because it's a great way of getting by in. Show them the results of their work. So if they have done something that's greatly improved core web vitals, show them. They're going to want to see all the green ticks just like we do. So maybe you can communicate and give updates regularly to the development team after they've completed a ticket of what impact it had. Maybe it improved rankings, maybe it helped with usability. What is it that their work did that had a very positive effect on SEO? And you can even go as far as giving them scores and feedback on it because they want to learn, they want to get better at their jobs and if SEO is a part of that then you kind of need to give them feedback so they know where to improve. So thank you so much for listening. I'm going to go and find myself a doughnut. Is there a doughnut shop? Have you got a doughnut shop around here?