An Agency Workflow for Approving SEO Changes Across Client Sites

The single-site approval question — should a human review this change? — has a settled answer: yes, always, for anything that can move rankings or break pages. The agency version is harder because approval authority itself varies by client: one wants to see every comma, one says 'just don't break anything', and one has a legal team. The workflow below handles all three without forking into three processes.

The worked scenario

Three client domains. Client A (e-commerce, cautious): every change needs their marketing manager's sign-off. Client B (SaaS, delegating): agency approves internally up to content changes; client sees a weekly digest. Client C (regulated, legal-involved): anything user-visible routes through their compliance queue with a 5-day SLA. One agency team ships work to all three every week.

The workflow

1. Every proposed change is a reviewable diff — current state, proposed state, affected URLs, client tag. No diff, no proposal; 'we'll improve the metadata' is not reviewable
2. Classify by risk, not effort: R1 metadata/alt-text, R2 content and internal links, R3 robots, redirects, canonicals, structured data. The class is set by what the change can break, and the classification is logged with the change
3. Route by the client's approval matrix: each client has one page stating who approves each risk class and their SLA. Client A: all classes → client. Client B: R1-R2 → agency lead, R3 → client. Client C: R1 → agency, R2-R3 → compliance queue
4. Ship only from approved state, and stamp the shipped change with approver, timestamp and diff — per client, per change. The approval and the deployment reference each other
5. Weekly, send each client their own shipped-changes digest drawn from the log — including changes they pre-delegated. Delegation without visibility curdles into 'what have you been doing?' within a quarter

The reusable artifact: the per-client approval matrix

Where tooling fits, honestly

This workflow is tool-agnostic — a disciplined agency runs it in tickets and spreadsheets. What tooling changes is the cost: Fenn prepares each fix with a ready prompt and keeps a review queue and activity log per site, and because it doesn't change the site itself, nothing reaches a client's site through Fenn without a person approving and publishing it. Your own deploy process still needs the same gate. The boundary as ever: Fenn holds the queue and the log; the approval matrix — who signs for what, per client — is a contract between you and each client that no tool writes for you.

Verification and limits

The workflow is working when you can answer, for any client, 'what changed on our site last month, who approved each change, and what happened after?' from the log in minutes. Its limit: it governs changes you ship — client-side deployments, CMS edits by the client's own team, and platform migrations happen outside it, which is why the weekly digest asks each client to flag changes they shipped themselves. An approval log that's 90% complete misattributes every anomaly to the missing 10%.

FAQ

Doesn't per-change approval slow agencies down? — Per-change diffs with per-client routing is faster than the alternative everyone tries first: informal Slack approvals that work until the first dispute, then convert into weeks of email archaeology. The SLA column exists precisely so speed is a written expectation, not a hope.

What about bulk changes across hundreds of pages? — One diff per change TYPE with the full URL list attached, approved as one unit per client. Batching a change-type is fine; batching across clients is the failure the workflow exists to prevent.