How to Create SOPs for Your SEO Agency: A Step-by-Step Guide

Your best technical SEO left in March and took two years of undocumented process with him. The link building method that worked, the way you structured audits, the exact order you checked things in a technical review — all of it lived in his head. The new hire took six weeks to get to half his speed, and you spent most of those six weeks answering the same questions over Slack. That’s not a hiring problem. That’s an SOP problem.

An SOP is just a written-down way of doing something, specific enough that someone else can follow it without asking you. Most agency owners know they need them. Almost none have actually written one. This guide covers how to build SOPs that get used, not ones that sit in a folder nobody opens.

Key Takeaways

• An SOP only works if someone who has never done the task before can follow it and get a result close to what you’d produce yourself.
• Start with the three or four tasks that get repeated most and cause the most confusion when someone new does them, not the ones that feel most important.
• A good SOP includes the exact steps, the tools used, screenshots or examples, and the common mistakes to avoid, not just a general description of the process.
• SOPs go stale fast, so build a short review habit into your calendar rather than treating documentation as a one-off project.

Start with the tasks that break when you’re not there

Don’t start by trying to document everything. That’s how SOP projects die in week one. Instead, ask yourself: what happened last time you were on holiday, or the last time you handed a task to someone new? Those are your first candidates.

For most agencies, that shortlist looks something like this: onboarding a new client, running a technical audit, writing the monthly report, doing outreach for link building, and running the weekly team meeting. Notice these aren’t strategy decisions. They’re repeatable operational tasks — the kind of thing that should look the same whether you do it or your account manager does it.

If you’re not sure where to start, look at your own calendar from the last month. Anything you did more than three times, in roughly the same way, each time, is worth documenting. Anything you explained to a team member more than once is worth documenting immediately, because that’s a sign the knowledge only exists in conversation.

Write the SOP as if you’re training someone on their first day

The test for a good SOP is simple: could someone with no background on this client follow it and produce work close to what you’d produce? If the answer is no, the SOP is too vague.

Compare these two versions of the same instruction. Version one: “Check the client’s site for technical issues and note anything important.” Version two: “Run a Screaming Frog crawl, export the response codes tab, flag any 4xx or 5xx errors on pages with organic traffic in the last 90 days, then check Core Web Vitals in Search Console and note any URLs in the ‘poor’ category.” The second version is longer, but it’s the one a new hire can actually execute without messaging you five times.

Every SOP should include four things: the trigger (when does this task happen), the steps (in order, specific, with tool names), the output (what does “done” look like), and the common mistakes (what usually goes wrong and how to catch it). Skip the common mistakes section and you’ll find your team repeating the same errors you already know about.

If you already have a client kickoff process, this is a good place to test the approach. Look at how a written agenda removes ambiguity in what to cover in an SEO client kickoff call — that’s an SOP in action, not just a checklist.

Build the SOP with the person who’ll actually use it

Here’s a mistake that’s easy to make: writing the SOP alone, from memory, then handing it to your team as a finished document. It usually misses the steps that feel obvious to you but aren’t obvious to anyone else, because you’ve done the task a hundred times and stopped noticing the small decisions you make along the way.

A better method is to sit with the person who’ll be running the task and have them do it while you narrate what you’re checking and why. Record the screen if you can. Then write the SOP from that recording, not from memory. You’ll catch details you’d otherwise skip — the fact that you always check mobile page speed before desktop, or that you never approve a piece of content without checking the internal links first.

If you already have someone on the team, get their feedback on the draft before you finalise it. Have them follow it exactly as written for one full cycle. Wherever they get stuck or have to ask a question, that’s a gap in the document, not a gap in their competence.

Where documentation fits with onboarding a new client

SOPs aren’t just for internal training. The same discipline applies to how you bring on a new client. If your process for a new client changes depending on who’s running the call or what mood you’re in that day, the client notices. They might not say anything, but inconsistency in the first month is one of the fastest ways to make a new relationship feel amateur.

Look at your folder structure, your welcome pack, your intake form. If you haven’t standardised how you set up a client folder structure, every new account gets built slightly differently, and six months later nobody can find anything without asking the person who set it up. The same goes for the wording in your onboarding materials — vague language in the wrong place is often the reason a new client gets nervous in week two, something covered in detail in the welcome pack mistake that makes clients nervous early on.

SOPs also protect you at the front of the funnel, before a client has even signed. If your outreach process lives in one person’s head and that person is out sick for a week, new client conversations stall. Documenting the exact structure that works, like the approach in how to write cold outreach emails that actually win a new client, means anyone on the team can run outreach without waiting on you.

Store SOPs somewhere they’ll actually get opened

A brilliant SOP that lives in a Google Drive folder called “Misc” might as well not exist. The format matters less than the habit of using it, but a few things make SOPs more likely to get opened: keep each one to a single document rather than scattering steps across five tabs, name files so the task is obvious at a glance, and put them somewhere that’s part of the existing workflow, not a separate system nobody remembers to check.

If your team already checks a shared folder before starting any client task, that’s where SOPs belong. If they don’t have a habit like that yet, build one. Tie it to something they already do daily, like the weekly team meeting, where you can flag any SOP that’s out of date or missing a step someone hit that week.

Review and update, or the SOPs go stale

An SOP written eighteen months ago for a tool you’ve since replaced is worse than no SOP at all, because it teaches the wrong process with total confidence. Set a review date on every SOP when you create it, three or six months out depending on how often the process changes. Technical processes tied to tools like Screaming Frog or Search Console need more frequent review than something like your content approval steps, which tend to stay stable once they’re right.

A simple trick: whenever someone on your team hits a step in an SOP that’s wrong or missing, have them flag it right there rather than just working around it and moving on. Over time this turns your SOPs into living documents that reflect how the agency actually works, not how it worked the day someone wrote it down.

What to do once the basics are documented

Once you’ve got onboarding, reporting, and delivery covered, the next layer is the stuff that protects you when things go wrong, not just when things go right. What happens when a client asks for extra work that’s outside scope. What happens when a client wants to cancel. What happens when you need to let a client go because the relationship isn’t working. Each of those situations goes better with a process already written down, because you’re not making decisions under pressure with a client watching.

The scope creep one is worth doing early, because it costs you money every month it’s missing. If you don’t have a clear way to handle a client asking for “just one more thing,” you can end up delivering hours of unpaid work without ever making a decision to do so. There’s a full process for handling this in how to stop giving away free work through scope creep.

Frequently Asked Questions

How many SOPs does a small SEO agency actually need?

Most agencies with 2-10 staff need somewhere between 10 and 20 core SOPs to cover the tasks that repeat weekly or monthly. Start with the five that cause the most confusion when someone new does them, and add more as gaps appear rather than trying to document everything up front.

Who should write the SOPs, the owner or the team?

The person doing the task most often should write the first draft, because they know the real steps, not the idealised version. The owner or manager should review it for consistency with how the agency wants things done, but writing it alone from memory usually misses details only the person doing the work would notice.

What’s the difference between an SOP and a checklist?

A checklist is a list of things to confirm before something is considered done. An SOP is the full process, including the steps, the tools, the order, and the common mistakes to avoid. A good SOP often includes a checklist at the end, but a checklist on its own doesn’t teach someone how to do the task.

How often should SOPs be updated?

Set a review date when you first write each one, typically three to six months depending on how often the process or tools involved change. The real trigger for an update is whenever someone on your team hits a step that’s wrong or missing, rather than waiting for a scheduled review to catch it.

If you’d rather not build these documents from a blank page, the Starter Kit includes editable SOP templates for the tasks covered in this guide, ready to customise and use the same day.