Rosemary says: “My additional insight is to effectively communicate technical audits to the developers, so I'll be sharing how to do that effectively.

One way I found to have worked is to structure audits to contain a user story, an acceptance criterion, and a testing strategy.”

Wow, okay, so there's a lot in there. Shall we start with how you actually structure your own audits to begin with?

“First of all, in the Google Doc (I use a Google Doc), I start by prioritising tasks; prioritising the issues at hand based on the business goal or objective.

There's an overview section that summarises everything in place so that, even if the key stakeholders don't have time to go through everything in detail, there's a summary of what they need to anticipate.”

What's included in the summary, roughly?

“It’s the fixes/the recommendations I'm recommending in detail to the developers. It should just be a summary of it: an overview.”

Okay, got you. It's not predetermined, the format of your summary, it depends on what's included in the document itself and then you provide an overview of that as a summary to begin with.

“Yeah, exactly.”

What are the key elements included in the document?

“The user story comes first, then we have the acceptance criteria and the testing strategy for each of the fixes or recommendations I'll be making to the developers.”

What do you mean by the user story?

“The user story is just a very short descriptive narrative that talks about the fix and the possible outcome that the business is supposed to benefit from it.

For example, an SEO specialist may have found out that there is an eight-step redirect loop. The user story will be structured to say that, as an SEO specialist, I want to fix this redirect loop so that search engines can index or crawl the target web page, and so that our users can have a better experience because that kind of redirect increases bounce rates.

It's just making it very brief/concise to have the expected outcome and the problem itself.”

I like the way that you start with the focus on users. It seems to me that talking about users isn't something that's necessarily central to the majority of technical audits. Is that correct? Is this something that you've introduced yourself?

“I'll say that, yes, that's correct but I learned that from my mentor, and I've been using that, and I've seen that it works better.”

Why does it work better?

“Because the developers can see the reason behind this fix from a user's point of view. Most times, we SEOs just say, ‘Do this. Do that.’ but they don't really know what the impact is going to be.

Everybody wants to please the user. Everybody in the team wants to please the users. It's like giving our own view from the user's point of view. That's why I implemented that, and I've seen that it's better. I think every SEO should do that.”

How do you try to measure the impact from a user's perspective for developers?

For instance, do you focus on dwell time on-site and how long a user takes to go through a certain funnel, to get what they're looking for, or are there some other metrics that you share with developers that tend to motivate them to want to make that change?

“It depends on the issue that I've discovered. Say, for example, I identified that there are some things making the sites very slow. I can tie that speed to bounce rates and say, once our site is faster, it will reduce the bounce rate. That's a key metric that can possibly lead to conversion.

I try to find a way to tie the whole technical SEO thing to something that would lead to the users eventually.”

So, it's the bounce rate on one of the key pages where the user makes that decision because, obviously, bounce rate isn't necessarily a negative thing all through a site. If someone lands on a blog post, then they find what they're looking for, it's not a problem if they bounce off the site. But if they bounce as part of an order sequence, then it's identifying the specific URL that they're bouncing from.

How do you know what a high bounce rate is?

“I measure with tools like Semrush, but it also depends on what your business goal is. Everybody has a different yardstick that they measure with.

Some people can say maybe 2% or 1%. There are different metrics for different entities/different businesses. For me, once I see that the timing is way too long, let's say it's taking forty or fifty seconds for a particular site to load, then I can say, ‘Oh no, this is actually what is triggering those bounce rates.’

I try to tie the metrics that we already have and the timing together. It's not like there is one yardstick for measuring bounce rates, like a 5% bounce rate. That's not how I do that.”

You don't compare your metrics against the metrics of other websites out there. You simply look at the metrics on your own website and get a feel for what's appropriate for you.

“Exactly.”

The second part of what you mentioned is acceptance criteria. What do you mean by that?

“It's just specific conditions that should be in place for the user story to be considered done.

Following the example I gave earlier about a page redirecting multiple times, I can say that I want page XYZ to redirect to B, or I want the non-secured version of this page to just go straight to B. It depends on what I've actually identified (or what any other SEO has identified) as the issue.

You can bring out specific conditions that will say that this goal has been met/the user story has been met.”

How do you identify the goal to begin with? How do you know which aspects of the user journey to be focusing on or which aspect you want to improve?

“If, for example, my company is focused on making a sale at a specific time, like Black Friday, it should actually make more sense to make sure that the first ten ranking pages – as in, our key pages – are actually up to par. At the time, that would be the main goal.

After identifying that there are issues with these key pages (say there's a speed issue or there are multiple redirects in these key pages), I'll prioritise that as the main thing to do at that time, because we are actually focused on a sale.

It depends on what the business wants to do at that time. There are long-term goals and there are short-term goals. It depends on your business and tying it down to what you need to do at any given time.”

That's a great tip there: identify the top 10 pages and focus your improvements on that because that's where the majority of your traffic is.

Do you do that simply by the number of visitors that land on those pages or is there a better way to identify which are your top 10 pages?

“It’s basically the number of visitors that land on those pages. We know the funnel, and we know we're aiming for conversions, but the key metric is the number of visitors. We don't want that to go down. The more visitors, the higher the tendency to convert eventually. I focus on the number of visitors.”

When you talk about testing strategy, what do you mean by that?

“The testing strategy is actually what validates that the acceptance criterion has been completed. It's like a two-factor authentication of what the acceptance criterion is.

For the example I gave earlier, we can just tell the developers to insert the test URL that is the impacted URL. If it returns a non-secure warning or a 404 warning, it means it wasn't done.

Testing strategy just highlights the field, what they should expect once the fix is complete, and what to expect when it's passed. It's so they know what to watch out for when they are implementing and testing to see whether it has worked.”

I'd like to get a feel for how to communicate better with developers because I think a lot of SEOs struggle with this sometimes – maybe not knowing what to say, when to say it, how to meet with them, and what kind of time scale to use such as how long before you want to implement these kinds of changes you should start communicating with developers.

Can you offer some tips about how to better communicate with developers?”

“First of all, I'll say prioritising your tasks and prioritising the fix.

We always have a long list of things to do as SEO specialists. The very first thing is to prioritise based on business goals and objectives. After doing that, the next thing is to work hand-in-hand with the developers, understand their workflow, and understand their constraints. Sometimes they are busy fixing a bug, implementing this, and implementing that. You need to know whether, in that particular timeframe, it would be okay to work with them.

After identifying that, the next thing is to structure the audit to have less technical jargon. If you must include a term that they will not be familiar with, or you're not sure, include glossaries or define those terms beforehand. Then, structure your audits to contain the user story, acceptance criteria, and testing strategy. That way, the timeline is greatly reduced. In fact, it's drastically reduced.

If you're anticipating that X number of tasks should be done in one or two weeks, following this method, it should be done prior to that because the developers already know that they are anticipating a task. You did not just wake up one morning and say, ‘Do this and do that, and I want you to do this irrespective of what you already have beforehand.’

That's one of the two tips that has worked for me and I want to share with other SEO specialists.”

What about the volume of work that you're asking developers to do? You don't want to give them too much and for them not to be able to complete the task.

Should you give them enough work to last a couple of weeks/a typical sprint? How do you know how much work to give them?

“It’s the typical SEO answer: it depends. It depends on the team you're working with. How big is your team? If you're working with just one developer, of course, you should give a very long timeframe. However, if you're working with a team of ten or fifteen, a lot will be done within that time.

It also depends on the people you're working with. How efficient are they? Are they really good? If they are, then it should be done within a short period of time.

Ask them first, ‘Do you think you can do this?’ before sending it to the project management tasks. If you have a Slack channel, chat them up. ‘I want to do this. Is this okay with you? Do you think this timeframe is okay with you, pending what you have at hand?’ Based on their response, you can adjust the timeline. Should it be longer? Should it be shorter? Just work up from there.”

What do developers typically hate about SEOs and what can SEOs do to try to make sure that they don't annoy developers?

“I think what developers hate about SEOs is that SEOs always want to change what they're already doing. They don't understand the field. They don't understand, when I do this using this framework, why are you telling me to change it all of a sudden? I've worked a whole long list to come to this point, now you are telling me to just scrap it.

That's the bridge I've seen, and it all comes from the point of understanding. You can say, ‘Okay, this is the reason. Is there a better way to do it?’, instead of just cracking out the complete work.

Say you've identified that certain images are causing a page to load slowly. Instead of saying, ‘Remove all the images’ you can say, ‘Compress the images, so we still have what you implemented there, but just make it bite-sized.’ Something that would not deter the plan entirely.

It's us SEOs telling them to override what they've done, and it’s them not even understanding it or knowing the impact it has on business goals. I think those are the two major things I've faced. I know there might be others, but I think those are the common issues I've seen most SEOs complain about.”

If an SEO is struggling for time, what should they stop doing right now so they can spend more time doing what you suggest in 2025?

“Even if they are struggling for time, I would say they should prioritise their tasks/the issues/the fix. How pressing is this need?

After doing that, you should structure the audits well, so that the developers can understand and do what they need to do, without causing too much back-and-forth confusion and friction. If the audit is well simplified, there will not really be a need.

Then, the SEO manager should also do a proper follow-up – not just send a task and call it a day. If you've set a week’s deadline for this task, you should also follow up in between: ‘Hi, XYZ. I sent you this, I just want to follow up. Do you need me to jump on a call? Is everything clear?’ Those kinds of concerns further elaborate the relationship and communication, instead of just waiting for a specific deadline and saying, ‘I'm expecting this task and I've not seen it.’

That's what SEOs should do: more communication, follow-up, and prioritising tasks.”

Rosemary Osuoha is Freelance Technical SEO Specialist at HirozSEO, and you can find her over at hirozSEO.com.