DEV Community: Abdul Salam

Don't Let an AI SEO Tool Publish Straight to Production. Put an Approval Gate in Front of It.

Abdul Salam — Tue, 20 Oct 2026 10:09:48 +0000

AI SEO platforms are getting good at the full loop: research, write, publish. The "publish" part is the one developers end up owning, usually after someone in marketing has already connected the tool to the production CMS.

I work on product at Keytomic, and I recently wrote a comparison of Distribb and Keytomic. The biggest difference between them isn't a feature. It's the workflow model:

Agent-led (Distribb): an AI agent researches, writes, publishes, and runs outreach. Humans check the output.
Approval-based (Keytomic): drafts wait for a person to approve them before anything goes live.

Whichever kind of tool your team picks, you can control the last step yourself. Here's how I'd evaluate a tool's publishing integration, and a small pattern for adding your own approval gate.

What to check in any AI tool's publishing integration

Before connecting an AI content tool to a CMS, I'd want answers to these:

Question Why it matters
Is publishing a direct CMS integration, a plugin, or a webhook/API? Determines where you can intercept content
Can auto-publish be turned off per site? You may want it on for a test blog, off for production
Does it publish as draft or as live? "Draft" in the CMS is a free approval gate
What permissions does the integration need? Avoid admin tokens when an author/editor role works
Can you export content and data if you leave? Content ownership and migration cost
What happens on edit? Does it overwrite manual changes? Prevents losing editorial fixes

For the two tools I compared: Distribb documents a WordPress plugin, webhooks, and an API. Keytomic documents direct integrations with WordPress, Shopify, Webflow, Framer, Notion, GoHighLevel, Contentful, and Next.js, plus webhooks and custom APIs. Either way, the webhook path is the one that gives you the most control.

The pattern: webhook in, review queue, then CMS

If a tool can send content to a webhook, don't point that webhook at your CMS. Point it at a small service that stores the draft and waits for approval.

AI tool ──webhook──▶ review service ──(approved)──▶ CMS API
│
└──▶ notify reviewer (Slack/email)

Here's a minimal version in Node with Express. It verifies a shared secret, stores the incoming draft, and only publishes when someone approves it.

js
// review-gate.js
import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json({ limit: "2mb" }));

const drafts = new Map(); // swap for a real DB in production
const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;
const REVIEW_TOKEN = process.env.REVIEW_TOKEN;

function safeEqual(a = "", b = "") {
const ab = Buffer.from(a);
const bb = Buffer.from(b);
return ab.length === bb.length && crypto.timingSafeEqual(ab, bb);
}

// 1. The AI tool sends drafts here instead of to the CMS
app.post("/webhooks/content", (req, res) => {
if (!safeEqual(req.get("x-webhook-secret"), WEBHOOK_SECRET)) {
return res.sendStatus(401);
}

const { title, slug, html, meta_description } = req.body;
if (!title || !slug || !html) return res.status(400).send("Missing fields");

const id = crypto.randomUUID();
drafts.set(id, {
id, title, slug, html, meta_description,
status: "pending",
receivedAt: new Date().toISOString()
});

notifyReviewer(id, title); // Slack, email, whatever your team uses
res.status(202).json({ id, status: "pending" });
});

// 2. A reviewer approves (or rejects) from an internal UI
app.post("/drafts/:id/approve", async (req, res) => {
if (!safeEqual(req.get("authorization"), Bearer ${REVIEW_TOKEN})) {
return res.sendStatus(401);
}

const draft = drafts.get(req.params.id);
if (!draft || draft.status !== "pending") return res.sendStatus(404);

await publishToCms(draft); // your CMS client
draft.status = "published";
draft.approvedBy = req.body.reviewer;
res.json(draft);
});

app.post("/drafts/:id/reject", (req, res) => {
if (!safeEqual(req.get("authorization"), Bearer ${REVIEW_TOKEN})) {
return res.sendStatus(401);
}
const draft = drafts.get(req.params.id);
if (!draft) return res.sendStatus(404);
draft.status = "rejected";
draft.reason = req.body.reason;
res.json(draft);
});

app.listen(3000);

And a WordPress publishToCms that creates the post as a draft first, so even an approved item gets a final look in the CMS preview:

js
async function publishToCms(draft) {
const auth = Buffer.from(
${process.env.WP_USER}:${process.env.WP_APP_PASSWORD}
).toString("base64");

const res = await fetch(${process.env.WP_URL}/wp-json/wp/v2/posts, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: Basic ${auth}
},
body: JSON.stringify({
title: draft.title,
slug: draft.slug,
content: draft.html,
excerpt: draft.meta_description,
status: "draft" // flip to "publish" only once you trust the pipeline
})
});

if (!res.ok) throw new Error(WordPress returned ${res.status});
return res.json();
}

Use a WordPress application password tied to an Editor or Author account, not an admin.

A few checks worth automating in the gate

Since you're already intercepting content, run cheap checks before a human ever looks at it:

Sanitize the HTML (e.g., with sanitize-html) so a tool can't inject scripts or iframes
Flag outbound links to domains you've never linked before, so link quality gets a human look
Check the slug doesn't collide with an existing URL
Require a meta description and an H1 that matches the title

The outbound-link check matters more than it looks. Some AI SEO tools include link exchanges or automated outreach, and Google's spam policies list excessive link exchanges and automated link services as potential link spam. Your gate is a good place to make sure no link ships without someone seeing it.

Wrapping up

Agent-led tools optimize for volume. Approval-based tools optimize for control. But as the developer wiring it up, you get to decide where the last checkpoint sits, regardless of which tool marketing chose.

If you're evaluating the two tools themselves (pricing units, AI visibility coverage, CMS support, link building), here's the full comparison:

👉 Distribb vs Keytomic (2026): Features, Pricing & Which to Choose

Building a Clinic Website That Turns Visits Into Bookings (Without Leaking Patient Data)

Abdul Salam — Tue, 20 Oct 2026 10:07:14 +0000

If you build or maintain websites for healthcare practices, you've probably been handed a vague brief like "we need more patients from the website."

Most of what moves that number isn't clever marketing. It's engineering: consistent data, clear booking paths, fast pages, and tracking that tells the practice what works without sending patient information to third parties.

This is the developer-side slice of a larger guide on organic patient acquisition. I'm writing from a product and growth angle, not as a lawyer or privacy officer, so treat the compliance notes as prompts for your client's compliance lead, not legal advice.

1. Keep location details in one source of truth

Local search depends heavily on accurate, consistent details. Google says local results are mainly based on relevance, distance, and prominence. The most common way practices sabotage this is having slightly different addresses, phone numbers, or hours on the website, the Google Business Profile, and directory listings.

On the site side, you can at least guarantee internal consistency. Store each location once and render everything from it: location pages, the footer, contact blocks, and structured data.

json
// data/locations.json
[
{
"id": "downtown",
"name": "Riverside Physiotherapy – Downtown",
"slug": "downtown",
"telephone": "+1-555-010-0100",
"address": {
"streetAddress": "120 Main Street, Suite 4",
"addressLocality": "Springfield",
"addressRegion": "IL",
"postalCode": "62701",
"addressCountry": "US"
},
"hours": [
{ "days": ["Monday", "Tuesday", "Wednesday", "Thursday"], "opens": "08:00", "closes": "18:00" },
{ "days": ["Friday"], "opens": "08:00", "closes": "14:00" }
],
"bookingUrl": "https://example.com/book?location=downtown"
}
]

Hand the practice manager a printout of this file and ask them to make the Business Profile and directory listings match it exactly. That's the cheapest local SEO win you'll ever ship.

2. Generate structured data from the same data

Patients increasingly ask AI assistants for a nearby provider, and those answers lean on the same signals as local search: clear pages and consistent details. MedicalClinic (or LocalBusiness) schema makes those details machine-readable.

Render it from locations.json so it can never drift from the visible page:

js
// lib/clinicSchema.js
export function clinicSchema(loc, siteUrl) {
return {
"@context": "https://schema.org",
"@type": "MedicalClinic",
"name": loc.name,
"url": ${siteUrl}/locations/${loc.slug},
"telephone": loc.telephone,
"address": { "@type": "PostalAddress", ...loc.address },
"openingHoursSpecification": loc.hours.map((h) => ({
"@type": "OpeningHoursSpecification",
"dayOfWeek": h.days,
"opens": h.opens,
"closes": h.closes
})),
"medicalSpecialty": "Physiotherapy"
};
}
html

Only mark up what's true and visible on the page. Don't add services, ratings, or availability the practice can't keep accurate.

3. Give every high-intent page one obvious next step

The pattern I see most often: service pages get steady search impressions, but the phone stays quiet. That's a conversion problem, and more content won't fix it.

Within one visit, a patient should be able to:

Understand the service
See location, hours, and availability
Know what happens after they make contact
Book, call, or send a short form

In practice, that means a component every service page must include:

html

Book a first appointment

First visits take about 45 minutes. Bring any referral letter and a list of current medications.

Book online
Call the clinic

Keep forms proportionate. A first inquiry rarely needs a date of birth, insurance number, and a free-text box inviting symptoms. Every extra field is friction, and every health detail you collect is data you now have to protect.

4. Track actions, not people

The practice needs to know which pages produce inquiries. You need to get them that answer without exposing protected health information.

HHS has published guidance on online tracking technologies under HIPAA, and the short version for developers is: analytics pixels, session replay, and call recordings on patient-facing pages can expose PHI. A condition-specific URL plus an IP address can be sensitive on its own.

So design the events to carry as little as possible:

js
// Send the action and a coarse page type. Nothing else.
document.querySelectorAll("[data-track]").forEach((el) => {
el.addEventListener("click", () => {
window.gtag?.("event", el.dataset.track, {
page_type: el.dataset.pageType // "service" | "location" | "faq"
// No form values, no condition names, no free text, no user IDs.
});
});
});

A few guardrails worth agreeing with the client's compliance lead before anything ships:

No third-party pixels on booking, intake, or authenticated pages
No form field values in events or URLs (use POST, not query strings)
Page-type labels instead of full paths for condition-specific pages
A documented list of every script on patient-facing pages and what it sends

Then pair the digital data with a low-tech check: an intake question asking how the patient found the practice. The two sources will disagree sometimes, which is useful.

5. Mobile, speed, and accessibility are acquisition work

Patients often search on phones, sometimes while in pain or stressed. Slow, cramped pages lose inquiries.

Before calling a service page done:

Test it on an actual phone, not just a resized browser
Check readable text sizes and tap target spacing
Navigate the booking flow with a keyboard only
Make sure the call and booking actions are visible without hunting

6. Build in a review date

Healthcare content should show an author, a clinical reviewer, and a review date. If you're building the CMS templates, make those fields required for patient education pages and surface the date on the page. It's a trust signal for patients, and it gives the practice a natural trigger to refresh pages that get impressions but few inquiries.

Wrapping up

None of this is exotic. It's consistent data, honest structured data, one clear next step per page, and tracking designed around privacy from the start. But together, that's most of what decides whether a practice website produces appointments or just traffic.

If you want the non-developer side (Google Business Profile, reviews, referrals, content review gates, and a 90-day plan for small teams), the full guide covers 20 organic tactics grouped by stage:

👉 20 Patient Acquisition Strategies to Get More Patients Organically

Evaluating White-Label SaaS for an Agency: A Technical Checklist (Domains, Tenant Isolation, Exports)

Abdul Salam — Tue, 20 Oct 2026 08:48:58 +0000

If you're the developer at an agency, white-label software eventually lands on your desk. Someone in sales promised clients "our own platform," and now you have to make a vendor's product look like yours without leaking anything.

SEO software is a good case study because the market is crowded and "white label" means wildly different things depending on the vendor.

Three levels of rebranding

Level What's rebranded What becomes your problem

Branded reports Logo, colors, maybe sender email on PDFs/dashboards Very little
Branded client portal Live data behind a login on your domain Auth, permissions, email deliverability, DNS
Full platform resale The whole product on your domain Support, roles, data isolation, uptime expectations

Most vendors document at least Level 1. Fewer do Level 2 cleanly. Level 3 changes your business model: you're selling software access, not just reports.

Where the vendor's brand leaks

Before signing, walk through every surface a client can touch and check whose brand appears:

Login page

Browser tab title and favicon
URL (custom domain or subdomain via CNAME?)
TLS certificate (issued for your domain, or a vendor wildcard?)
Transactional emails: sender address, reply-to, footer, unsubscribe link
Password reset flow
PDF metadata and embedded fonts
Shared dashboard links
Error pages and 404s
Help/support links inside the UI

Several vendors gate custom domains to higher plans. Never assume the entry tier includes them.

The "promise test"

Tag every feature on the vendor's list as client-visible, operator-visible, or both.

Operator-only features (bulk editing, internal dashboards, admin settings) might make your team faster, but they don't change what the client sees. If the sales promise was "clients get their own branded platform," only client-visible features count toward it.

Test tenant isolation yourself

Don't take "client access controls" on faith. In a trial:

Create two client workspaces, A and B, with distinguishable test data.
Invite a client-view user to A only.
Log in as that user and try to reach B's data: navigation, search, direct URL manipulation (swap IDs in the path or query string), shared report links, exports.
Check whether a shared dashboard link for A is guessable or enumerable.
Revoke the user and confirm sessions and shared links stop working.

If step 3 finds anything, stop the evaluation.

Model cost by billing unit, not headline price

Vendors bill on different units, which makes list prices misleading:

true_cost_per_client =
(base_subscription + add_ons + seats + reports + usage + setup_and_ops_time)
÷ active_client_sites

Using list prices checked in October 2026:

Billing model Example 5 clients 10 clients 20 clients
Per client AgencyAnalytics at $20/client/mo (annual) $100 $200 $400
Per report add-on Semrush Pro Reports at $20/report/mo, plus subscription $100 + sub $200 + sub $400 + sub
Platform add-on SE Ranking Agency Pack from $69/mo (annual), plus base plan flat, but base-plan limits may force an upgrade

Base + usage WebCEO: base fee + domain fee + project and scan charges varies with usage

That's list-price arithmetic, not a quote. Run it at your next year's client count, not today's.

Exit plan

The part everyone skips. Before signing, confirm:

Can you export raw data (not just PDFs) in a usable format?
Is there an API, and is it on your plan?
What happens to client-facing URLs if you cancel? Do you control the DNS record?
How long is data retained after cancellation?

Owning the domain and the CNAME means you can point it somewhere else later. That's leverage.

Reporting vs execution

One last distinction. Reporting and portal products brand the work; they don't produce it. If the agency's real bottleneck is research, content, and publishing, that's a separate tool, and the client-facing layer sits on top of it.

The full comparison of 10 platforms (white-label level, billing unit, and honest limitations for each) is here: https://keytomic.com/blog/best-white-label-seo-software-for-agencies

Measuring SEO Automation Like an Engineer: Levels, a Task Matrix, and an ROI Formula

Abdul Salam — Tue, 20 Oct 2026 08:46:12 +0000

Two numbers from Keyword.com's 2026 State of AI in SEO survey (97 usable responses, so treat it as directional):

87% of respondents use AI regularly or as a central part of their SEO work.
1% describe that work as fully automated.

If you've ever looked at an SEO team's stack, the gap makes sense. Keyword tool in one tab. AI writer in another. CMS in a third. Search Console next to a spreadsheet. Every tool has AI in it. None of them passes work to the next one.

That's not automation. That's a faster human in the middle of a manual pipeline.

Define the levels before you measure anything

Most "AI SEO statistics" mix four very different things. Separate them:

Level What it means Engineering analogy
AI-assisted A person prompts and reviews Autocomplete in your editor
Task automation Software runs one step A single script
Workflow automation Steps connect, handoffs disappear A CI/CD pipeline
Full automation No routine human involvement Unattended production deploys

The useful question for any new tool: which manual action disappeared? If the output just arrives faster and a human still moves it to the next step, you bought assistance.

Where teams actually are

From Semrush's early-2026 survey of 100 marketers (small sample, snapshot only):

60% use AI for keyword research
48% for content ideas
38% for briefs and outlines
34% to refresh existing content
26% for titles and meta descriptions
About 1 in 5 for full article drafts

The pattern: adoption is highest where inputs are clear, and drops as tasks get closer to judgment. Keyword.com's data explains the caution: 70% name poor output, hallucinations, or quality-control time as their biggest AI limit.

Measurement lags the most. In Semrush's separate study of 481 marketers, only 22% say SEO and AI search are fully integrated across strategy, execution, and reporting. 40% check AI visibility by typing prompts manually.

A task matrix with human checkpoints

This is an editorial framework, not survey data. Think of each human checkpoint as a required review on a PR.

Task Typical automation Human checkpoint KPI
Keyword discovery & clustering AI-assisted / rule-based Decide which page owns each keyword Keywords mapped to pages
Content briefs AI-assisted Check intent and sources Brief-to-publish time
Internal linking Rule-based Check anchor relevance Links added per page
CMS publishing Workflow-executed Approve before going live Manual posting hours removed
Indexing submission Workflow-executed Review index status URLs submitted vs indexed
Reporting Rule-based Interpret what changed Reporting hours per client
AI visibility tracking Workflow-executed Choose prompts, judge sources Mentions & citations per prompt set

Note the indexing row. Sitemaps and URL submissions are signals, not guarantees. Any tool that promises a fixed indexing time is overpromising.

The ROI formula

No study supports a universal "automation saves X%" number. So compute your own:

text
labor_saved = (baseline_hours − automated_hours) × loaded_hourly_cost
net_roi = labor_saved + avoided_tool_cost − automation_cost − added_review_cost
Baseline hours: real time per published page, including handoffs.
Loaded hourly cost: salary plus overhead.
Added review time: automation shifts work into review. Count it.

A minimal calculator:

python
def automation_roi(
pages_per_month: int,
baseline_hours_per_page: float,
automated_hours_per_page: float,
review_hours_per_page: float,
loaded_hourly_cost: float,
avoided_tool_cost: float,
automation_cost: float,
) -> dict:
labor_saved = (
(baseline_hours_per_page - automated_hours_per_page)
* pages_per_month
* loaded_hourly_cost
)
review_cost = review_hours_per_page * pages_per_month * loaded_hourly_cost
net = labor_saved + avoided_tool_cost - automation_cost - review_cost
return {
"labor_saved": round(labor_saved, 2),
"review_cost": round(review_cost, 2),
"net_monthly_roi": round(net, 2),
}

Example with your own numbers:

print(automation_roi(
pages_per_month=12,
baseline_hours_per_page=6,
automated_hours_per_page=1.5,
review_hours_per_page=1,
loaded_hourly_cost=40,
avoided_tool_cost=50,
automation_cost=99,
))

The example inputs are placeholders. Plug in your own baseline, measured honestly over a few weeks.

Then keep efficiency and outcomes separate. Hours saved and pages shipped are efficiency metrics. Indexing, rankings, and conversions are outcomes. Don't let one stand in for the other.

What not to automate

Volume amplifies whatever process sits underneath it. Weak briefs produce weak pages, faster. A team publishing 40 unreviewed pages a month hasn't removed risk; it's automated it.

Keep humans on factual claims, regulated topics, topic selection, brand positioning, and backlink decisions.

Where to start

Bottleneck is research? Automate discovery and planning first.
Bottleneck is handoffs? Connect CMS publishing, indexing, and reporting.
Bottleneck is quality? Keep approvals and fix your evidence process before adding volume.

For each change, record three things: the manual step removed, the quality checkpoint kept, and the outcome affected.

I compiled every sourced 2026 stat (with sample sizes and what each actually measured) here: https://keytomic.com/blog/seo-automation-statistics

Read, Decide, Act, Verify: What Actually Makes Software an "AI SEO Agent"

Abdul Salam — Tue, 20 Oct 2026 08:41:59 +0000

Every SEO product shipped in the last year calls itself an "agent." Most of them are tools with a chat box.

If you build on the web, you already have the vocabulary to tell the difference. An agent is a loop, not a feature. Here's the spec I use when I evaluate one, whether I'm buying it or wiring one up myself.

The loop: read → decide → act → verify

A real AI SEO agent does all four, on a repeating schedule:

Read real data: Search Console, live SERPs, crawl results. Not just whatever you paste into a prompt.
Decide what to do next based on that data.
Act: draft, publish, change a page, submit a URL.
Verify the result after acting.

A tool does one of those steps and hands the rest back to you.

The fastest test: once a problem is found, who does the work? If it's you, it's a tool.

Four classes that shouldn't share a spreadsheet

When I compared 13 products on the market, they split into four groups. Comparing across groups is how teams buy the wrong thing.

Class What it touches Examples
Content-loop agents Plans, drafts, publishes articles Keytomic, Frase, Outrank, Writesonic, RankYak, Distribb, SEObot
Technical execution Live pages, how crawlers see them Alli AI
Workflow platforms Several jobs under one login Search Atlas, BabyLoveGrowth
Visibility analytics Measures AI answers and citations, changes nothing Peec AI, Profound

An analytics product and a publishing agent are as different as a monitoring dashboard and a deploy pipeline. Both useful. Not interchangeable.

The autonomy ladder

Treat agent permissions like you'd treat a CI/CD bot. Start low, promote deliberately:

Level 1 Recommendation only → agent suggests, human does
Level 2 Draft for approval → agent writes, human merges
Level 3 Scheduled publishing → agent ships on a timer, human can cancel
Level 4 Low-risk automatic changes → e.g. internal links, metadata
Level 5 High-risk changes → always require explicit approval

If a product can't tell you which level a given action runs at, that's your answer.

Least privilege, change logs, rollback

Same rules as any service account:

Least access. Give the agent the narrowest CMS role that lets it do the job. Draft-only is a fine starting point.
Change log. Every action should be traceable: what changed, when, why.
Rollback path. Especially for anything that edits live pages at the site level. If there's no undo, it doesn't go to production.
What the agent should verify after it acts

"Published" isn't "done." After an action, check:

Page renders correctly
Page is indexable (no stray noindex, correct canonical)
Internal links resolve
Structured data matches visible content (schema that describes content the user can't see is a problem, and structured data never guarantees rich results anyway)
Publishing status in the CMS
Index status and performance in Search Console over the following weeks

One honest caveat: submitting a URL supports discovery. It does not guarantee indexing. Google describes sitemaps as hints, not commands. Be suspicious of any tool that promises a fixed indexing time.

Build vs buy

Build when your workflow is unusual and you can maintain the connectors, the approval gates, and the verification step yourself. MCP now makes it practical to connect an LLM like Claude directly to SEO data sources.

Buy when speed matters more than customization. Just apply the same spec above to whatever you buy.

What stays human

Agents remove repetitive work. They don't remove accountability. Keep a person on:

Topic selection (it depends on business goals)
Fact-checking and sources
Brand voice
The publish decision
Anything regulated, and anything that places links on third-party sites

Google's position is that AI-generated content is fine when it's accurate, useful, and original, and that scaled low-value content is spam. That's a quality bar, not a tooling question.

A 30-day test before you commit
Connect a real site with the least access required.
Baseline one article and one technical task.
Hand the agent one low-risk recurring workflow.
Log every human correction and how long approvals take.
Verify publishing status, rendering, and index status.
Compare its AI visibility reporting against the questions your buyers actually ask.

The correction log from step 4 tells you more than any feature page.

Find a detailed comparison of 12 best AI SEO Agents here: https://keytomic.com/blog/best-ai-seo-agents

Your SEO Agency Is a System. Debug It Like One.

Abdul Salam — Mon, 19 Oct 2026 12:02:46 +0000

TL;DR: An SEO agency is scaling only when revenue grows faster than delivery hours, rework, and cost. Find the bottleneck, standardize one package, automate the handoffs between tools, and keep judgment (strategy, fact-checking, final approval) with people.

You sold another retainer. Revenue is up. And you're still the one running audits, approving briefs, and answering the Friday status email.

That's not scale. That's a bigger job.

If you've ever profiled a slow app, you already know how to fix this. Agencies are pipelines, and pipelines have bottlenecks.

Calculate real capacity

Here's the working model I use. It's not an industry standard, so feed it your own time data:

python
capacity = (delivery_hours - rework_hours - blocked_hours) / avg_hours_per_client

Example (hypothetical):

400 delivery hours/month, 20 hours per client

60 hours lost to rework + blocked work

(400 - 60) / 20 = 17 clients, not 20

Those 3 "missing" clients are where margin quietly disappears.

Find the bottleneck before adding load

Work usually piles up in one of four stages:

Onboarding
Content production
Approvals
Reporting

Track where tasks wait, not just where they finish. The stage with the longest queue is your constraint, and it's rarely the one the founder assumes.

A simple fix: a blocked-work log with four columns — reason, owner, next_action, client_dependency. Most agencies log what's done. Very few log what's stuck.

Standardize before you scale

Custom work is like a codebase where every feature is a one-off. Nobody else can maintain it.

Pick one client profile (e.g. B2B SaaS with an existing blog).
Define fixed deliverables: keyword map, content calendar, technical checks, reporting.
Set a monthly volume.
Add quality gates between steps: brief_approved → draft_fact_checked → published → indexing_checked.

My threshold: don't sell a package until someone other than the founder can run its core workflow without asking for every decision.

Automate handoffs, not judgment

A typical manual agency stack:

Semrush/Ahrefs → spreadsheet → brief tool → doc → CMS (by hand)
→ indexing request (by hand) → GSC export → client report

Every arrow is a chance for delay or error. The biggest win usually comes from removing handoffs, not from producing more content.

My rule for what to automate. A task should be:

Repetitive
Reversible
Rules-based
Easy to review

Keep these human: strategy, fact-checking, and final approval. Google's guidance doesn't penalize content because AI helped make it, but low-value scaled content can still violate spam policies however it's produced.

Add escalation rules too:

Unverified claims or regulated topics → senior reviewer
Redirect, robots, or template changes → approval first
Repeated rework on one deliverable → workflow review

Monitor the right metrics

Track per client and per package, not just agency totals:

Metric What it tells you
Gross margin by account Which clients to keep, reprice, or exit
Delivery hours per client Whether scope matches price
Rework hours per deliverable Where briefs or reviews fail
Blocked days per client Which approvals stall work
Client retention Whether results hold trust

If client count goes up while margin or quality goes down, that's a regression, not growth.

Where to start

Audit the last 30 days of client work. Log revenue, delivery hours, rework hours, blocked days, and margin per account. Then fix the single biggest bottleneck. Just one.

Find the full guide here: https://keytomic.com/blog/how-to-scale-an-seo-agency