Skip to content

Cyber Sale: Save big on Moz Pro! Sign up by Dec. 6, 2024

WBF SE Os And Devs Pollitt Blog Header

How SEOs and Developers Can Work Better Together — Whiteboard Friday

Helen Pollitt

The author's views are entirely their own (excluding the unlikely event of hypnosis) and may not always reflect the views of Moz.

Table of Contents

Helen Pollitt

How SEOs and Developers Can Work Better Together — Whiteboard Friday

The author's views are entirely their own (excluding the unlikely event of hypnosis) and may not always reflect the views of Moz.

Edited by Emilie Martin

This is part one of a three-part series with Helen Pollitt on how to work better with folks within your company.

Check out the second episode on 'How SEOs and Content Writers Can Work Better Together' and the last episode on 'How SEOs and UX Designers Can Work Better Together'.

SEOs and developers need to work better together. Understand how to communicate with each other in a way that fits into each other’s processes. By doing so, you can safeguard your organic traffic while also safeguarding your entire website.

Digital whiteboard of how SEOs and developers can work better together


Click on the whiteboard image above to open a high resolution version in a new tab!

Video Transcription

Hi, I'm Helen, head of SEO at Car & 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 often hear people say that if you want to get on well with your developers, you need to bribe them with doughnuts, which is a little bit insulting and a lot expensive because who has that kind of doughnut 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. How do we do that?

Understand processes

Understand processes

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 prioritize 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 it 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 the developers. Maybe you can understand how they are structuring their tickets or whether there's a 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 prioritized in order for it to be in this sprint or the next sprint, for example. You want to know what kind of time frames 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, and resources for that to actually be rolled out.

So make sure that you've got that planned in for your own schedule of work. Finally, what 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 into a different work stream? 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?

Train colleagues in SEO

SEO training

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 they're 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 an 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 a real quick 15 minutes distilling of information?

How do they train each other? How do they upskill themselves? See if you can conduct your training in a similar way.

Get an SEO Q&A process in place

SEO QA process


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.

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.

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.

Get buy-in from your developer team

Getting buy-in


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 a website, make sure that you are telling them why. What is it that you are 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 is not negatively affecting the website in other ways.

Our job as SEOs is to safeguard organic traffic, and 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, 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 are 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 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 buy-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? 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?

Video transcription by Speechpad.com

Back to Top

With Moz Pro, you have the tools you need to get SEO right — all in one place.

Read Next

7 Psychology-Backed Reasons Why People Buy — Whiteboard Friday

7 Psychology-Backed Reasons Why People Buy — Whiteboard Friday

Nov 08, 2024
Brand Entity SEO – Whiteboard Friday

Brand Entity SEO – Whiteboard Friday

Nov 01, 2024
Elevating Your SEO Career and Team in the AI Era — Whiteboard Friday

Elevating Your SEO Career and Team in the AI Era — Whiteboard Friday

Oct 25, 2024