It's Tuesday morning and your new SEO hire is staring at a 47-page Confluence document titled "SEO Process v3 (FINAL_revised_use this one)." By Thursday, they've quietly built their own Google Doc workflow and the SOP is dead.
It's Tuesday morning and your new SEO hire is staring at a 47-page Confluence document titled "SEO Process v3 (FINAL_revised_use this one)." Half the screenshots reference an Ahrefs dashboard that was redesigned last year. The publishing checklist links to a Trello board nobody opens anymore. The "How we do keyword research" section was written by a contractor who left in 2023. By Thursday, your hire has quietly built their own Google Doc workflow and the SOP is dead.
This is the normal life cycle of an SEO SOP. Someone writes it during a project lull, the team uses it for three weeks, the tools change, the priorities change, and within a quarter it's archaeology. The problem isn't that your team is undisciplined. The problem is that most SEO SOPs are written like reference manuals when they need to be written like flight checklists.
A good SEO SOP is short, structured, scoped to one specific job, and lives where the work actually happens. It tells you what to do, in what order, with what inputs, and what counts as done. Below is a working template you can copy, plus the patterns that separate SOPs that survive contact with a real SEO team from the ones that quietly rot.
A standard operating procedure for an SEO team has one job: produce the same quality of output regardless of who is doing the work. Not "document everything we know about SEO." Not "train new hires." Those are separate documents. The SOP exists so that when your strongest writer leaves on a Tuesday, the Wednesday publish doesn't fall apart.
Research on operational documentation consistently shows that the failure mode is scope creep. The first version is tight. By version five, it has absorbed every edge case, every regional exception, every special handling rule a manager has ever asked for. It becomes unusable for the daily work it was supposed to enable, and people stop reading it.
Your SEO SOP should fit on one screen of a laptop. If it doesn't, you've written a manual, not an SOP. Manuals are fine. They belong in your wiki, with a link from the SOP.
Most SEO work falls into a small number of recurring jobs. You don't need one SOP for "SEO." You need a small set of focused SOPs, each scoped to one job:
Five tight SOPs beat one 80-page master document every time. Each one can be improved independently, each one has a clear owner, and each one can be opened mid-task without scrolling past 12 sections of irrelevant context.
Every SOP your team writes should follow the same skeleton. Consistency matters more than cleverness here. When someone opens an SOP, they should know where to find what they need within five seconds.
Three lines, no more. Purpose: one sentence on what this SOP is for and when to run it. Owner: a single name, not a team. Last reviewed: a date, with a quarterly review cadence built into the calendar.
What does the person running this SOP need before they start? List it explicitly. For a brief SOP, that might be: a target query, an intent classification, a competitive set of top-10 URLs, and the internal link cluster. If those inputs aren't ready, the SOP can't run, and the SOP should say so out loud.
Numbered, sequential, written as imperatives. "Open Search Console. Filter to the last 28 days. Export the query report." Not "You may wish to consider exporting the query report from Search Console." The reader is mid-task and needs commands, not prose.
Each step should fit on one or two lines. If a step needs more explanation, link to a runbook in your wiki. Don't inline it in the SOP.
Explicit, checkable, no judgment calls. "Brief includes target query, three competitor URLs, H2 outline, internal link plan, and meta description draft. Saved to /briefs/ folder. Owner assigned in tracker." Done is done. If you can't tell whether you're done, the SOP failed.
What do you do when something is off? Who do you ping, where, and with what context? A senior SEO might know to escalate ambiguous intent to the content lead. A new hire won't. Write it down.
Here's what a real publish SOP looks like when written this way. This is the SOP your team runs every time a piece moves from "draft approved" to "live."
Purpose: take an approved post from draft to published, with all on-page SEO elements in place.
Owner: SEO manager.
Last reviewed: Q2.
Inputs: approved draft in CMS, target query from brief, meta title and description from brief, hero image, internal link list from brief.
Steps:
Definition of done: post is live, schema validates in Rich Results Test, URL is submitted to Search Console, and the publish entry is logged in the editorial tracker with date and target query.
Escalation: if schema fails to validate, ping the engineering channel with the URL and the validator error. If the post needs a structural change post-publish, flag it in the editorial standup, not in the SOP.
That's the entire SOP. It fits on one screen. A new hire can run it on day three without supervision. A senior SEO can run it in ten minutes without thinking.
Three failure modes account for most dead SOPs. If you can avoid them, your SOPs will outlive the next reorg.
The moment you embed a screenshot of the Search Console interface, your SOP has a half-life of about six months. Google redesigns the UI, the screenshot becomes wrong, and now your SOP is actively misleading. Write the SOP at one level of abstraction above the tool. "Filter to the last 28 days in Search Console" survives a UI redesign. A screenshot doesn't.
Your senior SEO knows that for hreflang implementations, you do step 4 differently. That knowledge belongs in a hreflang runbook, not in the main SOP. The base SOP covers the common case. Edge cases get their own focused documents linked from the relevant step.
SOPs without owners belong to no one, which means no one updates them. An SOP with "Last reviewed: Q2 2024" tells you exactly how much to trust it. An SOP with no date is a trap. Build the review cadence into your operations calendar. Every SOP gets eyes on it at least once a quarter.
This is where most teams get it wrong. They put SOPs in a wiki, then never open the wiki when they're doing the work. The work happens in Google Docs, in the CMS, in the keyword research tool. The SOP is two clicks and a search away. So nobody uses it.
The fix is to put the SOP where the work happens. The publish SOP should be a checklist inside your CMS workflow, not a wiki page. The keyword research SOP should be a template in your brief tracker, not a Confluence doc. Treat the SOP as a structural part of the workflow, not as documentation that describes the workflow.
Some teams use structured document platforms like HERO to keep SOPs alongside the documents the SOPs operate on, so the brief, the SOP that produced the brief, and the publish checklist all live in one structured project. Others use a combination of CMS-native checklists and a lightweight wiki for the runbooks the SOPs link to. The specific tool matters less than the principle: the SOP must be where the work is, or it will not be used.
Writing the SOP is the easy part. Getting your team to actually use it is the hard part. The most reliable rollout pattern looks like this:
Week one: the owner writes the first draft and runs it themselves on three real pieces of work. Anything that broke gets fixed in the draft.
Week two: two other team members run the SOP, with the owner observing. Every place a team member asks "what does this mean?" or "what do I do here?" is a gap in the SOP, not a gap in the team member. Fix the SOP.
Week three: the SOP becomes the default. The owner stops being involved unless escalated. The team uses the SOP as written.
End of quarter: review. What edge cases came up? What steps got skipped? What tools changed? Revise.
An SOP that survives this rollout pattern will outlive most of the people who wrote it. An SOP that gets published to the wiki and announced in standup is dead before it's read.
An SOP that nobody uses is invisible. Build in a way to see whether the SOP is actually running. A few patterns that work:
You don't need an SOP compliance dashboard. You need a habit of looking at whether the work product matches what the SOP says the work product should be.
One screen. If your SOP runs longer than what fits on a laptop screen without scrolling past the header, you've written a manual. Break it apart into focused SOPs by job. The publish SOP is one document. The keyword research SOP is another. They can link to each other, but each one should be small enough that a team member can read it during the task without losing context.
Use whatever your team will actually open during the work. The format matters far less than the location. A wiki page that nobody opens is worse than a sticky note above the monitor. Some teams get the best results from embedding the SOP directly into the tool where the work happens, as a checklist inside the CMS or as a template in the brief tracker.
Quarterly review at minimum, with immediate updates whenever a tool, process, or owner changes. Build the review into your operations calendar so it doesn't depend on someone remembering. Every SOP should have a "last reviewed" date visible at the top, so anyone running it knows how much to trust it.
A single named person, not a team. Teams don't own anything. The owner is responsible for the SOP being current, for handling escalations the SOP doesn't cover, and for reviewing it on cadence. When the owner leaves the team, the SOP gets a new owner before the offboarding meeting ends.
An SOP is the high-level sequence of steps for a recurring job. A runbook is the detailed how-to for a specific tool or task that an SOP might reference. The keyword research SOP says "pull the top 10 ranking URLs for the target query." A runbook explains exactly how to do that in your specific tool stack. Keep them separate so the SOP stays short.
Write the base SOP for the common case, then create regional supplements for the exceptions. Don't try to capture every regional variant in the main SOP. A UK supplement that addresses hreflang and ccTLD considerations is easier to maintain and easier to read than a 30-step SOP that tries to handle every market in one document.
HERO is a structured document platform built for the documents your team actually has to ship and maintain, contracts, SOPs, technical specs, internal policies, with native support for defined terms, cross-references, and version control. If your SOPs keep dying in the wiki, see what it looks like to have them live where the work happens. Book a demo.