Most SEO programs are one resignation away from starting over. The rankings are real, the traffic is real, but the reasoning that produced them lives in one person’s head: which pages get refreshed and why, what the internal linking rules are, which queries matter, what “done” looks like for a brief. When that person leaves, or the agency contract ends, or the work moves in-house, the new owner inherits a spreadsheet and a login. Six months later the numbers have drifted and nobody can say exactly when it started.
This is a documentation problem, not a talent problem. And it gets sharper, not softer, as more of the work gets automated.
Why automation raises the stakes
An automated workflow does exactly what it was configured to do, forever, whether or not that is still the right thing. When a human runs an undocumented process, they notice drift. They see that a template stopped making sense, that a rule is producing odd output, that the site changed shape. An agent or a scheduled job does not notice. It reproduces the original assumptions at scale, and the errors compound quietly.
So the more you automate, the more the written definition of the process becomes the actual process. Google’s helpful content guidance is explicit that content should be produced for people first, and the practical way that survives contact with automation is to have written down what “for people first” means for your site specifically, in terms someone else can apply.
Document the decisions, not the clicks
The most common failure is writing the wrong document. Teams produce a forty-page manual of screenshots showing where to click in Search Console, which is obsolete the next time the interface changes and which teaches nothing.
What actually needs writing down is the layer above the clicks:
- Inputs. What has to exist before the work can start, and where it comes from.
- Decisions. The judgement calls, and the rule or threshold behind each one.
- Standards. What a finished output has to satisfy before it ships.
- Owners. Who decides, who does, who checks.
- Failure signals. What tells you the process has stopped working.
Screenshots go stale in a quarter. Those five things stay true for years.
Step 1: Map the process before you write it up
Almost everyone writes the SOP first and discovers halfway through that they do not agree on what the process is. Map it before you narrate it.
The mapping tool worth borrowing here comes from manufacturing rather than marketing. A SIPOC map lists Suppliers, Inputs, Process, Outputs, and Customers on one page, which forces you to name where each input comes from and who receives each output. Applied to a content workflow, it exposes the gaps fast: the brief has no named owner, the keyword list has no defined refresh cadence, nobody receives the published URL, so nothing gets checked afterwards.
Process improvement disciplines have been solving exactly this problem for decades, and the vocabulary is worth having. If SIPOC, control plans, and root cause analysis are unfamiliar, a free Lean Six Sigma White Belt course covers the core toolkit in an afternoon, and the concepts transfer to content operations without much translation.
Step 2: Write the standard, not just the steps
A list of steps tells someone what to do. It does not tell them whether they did it well. That gap is where quality decays after a handoff, because the new owner completes every step and still produces worse output than their predecessor.
For each output your process produces, write down what it has to satisfy. For a content brief, that might be: a named primary query with current search data attached, the three pages currently answering it, the specific gap you intend to fill, the internal links in and out, and the schema type. A brief missing any of those is not finished, regardless of how much time went into it.
The test of a good standard is that two different people applying it to the same input produce recognisably similar work. If your standard cannot do that, it is a preference, not a standard, and it will not survive you.
Step 3: Pitch it at the person who will inherit it
Write for someone competent who does not share your context. Not a beginner, and not yourself.
That means expanding the internal shorthand, saying why a rule exists rather than only stating it, and naming the things you have decided not to do. The rules that get abandoned first after a handoff are the ones with no stated reason, because a new owner cannot tell the difference between a hard-won constraint and an arbitrary habit. “We do not publish comparison pages without a named tester” is followed. “No comparison pages” is quietly dropped in month two.
Step 4: Define what a deviation looks like
Documentation that only describes the happy path fails at the first surprise. Alongside the process, record what abnormal looks like and what happens next: which metric, checked how often, by whom, and what the response is when it moves.
This is the part almost nobody writes, and it is the part that determines whether a problem gets caught in a week or a quarter. A useful control plan is short. Impressions and clicks reviewed weekly in Search Console against the previous four weeks. AI citation checks monthly on your top twenty commercial queries. Any page losing a defined share of clicks over two consecutive weeks gets escalated rather than absorbed.
Step 5: Diagnose slips properly
When something does slip, the reflex is to jump to the most available explanation: an algorithm update, a competitor, the season. Sometimes that is right. Often it is a change your own team made and nobody connected to the outcome.
Structured root cause analysis is boring and it works. The 5 Whys technique, run properly with evidence at each step rather than speculation, tends to land on something concrete and fixable: a template change that stripped a schema block, a redirect that lost its target, a brief standard that quietly loosened when a new writer joined. Recording the finding matters as much as the fix, because the same class of failure recurs, and a documented process that accumulates its own failure history gets genuinely harder to break over time.
Step 6: Keep it alive or accept that it is fiction
Documentation nobody reads is worse than none, because it produces false confidence. Two habits keep it honest.
Review it on a fixed cadence, quarterly is usually enough, and change it when the process changes rather than when the review falls due. Then have someone who did not write it actually run from it once. Nothing exposes an unwritten assumption faster than watching a colleague follow your instructions literally and arrive somewhere you did not expect.
Where to start
If none of this exists yet, do not begin with a manual. Pick the single process whose loss would hurt most, usually the one that produces published pages, and give it one page covering inputs, decisions, standards, owners, and failure signals. One honest page that reflects what you actually do beats a polished document describing a workflow nobody follows.
Then do the same for the next process, and stop when the list of things that would break on your last day is empty. That list, not the length of the manual, is the thing you are managing.