The autonomous SEO loop.

There is a category of business that is enormously valuable, deeply local, and almost entirely invisible to the current wave of AI-native company-building: the local service business. Tree services, landscapers, HVAC contractors, plumbers, roofers, dog daycares, trailer dealers. They are the businesses that keep neighborhoods functioning, and they are sitting on more first-party customer signal per dollar of revenue than any tech company on earth.

This post is the second in a series about building self-learning operating models for those businesses. The first introduced the customer intelligence loop — the foundational layer of a self-learning local business. This one is more practical: I'm going to give you the complete playbook for building the first loop I'm running on my own site, localprosolutions.com, end to end.

This is a fully autonomous SEO system. It does its own keyword research, builds new pages, tracks rankings, manages the Google Business Profile, monitors competitors, and decides what to do next — without anyone prompting it. It is built once and runs continuously. The architecture is the same one I'll be cloning to client sites once the lighthouse is stable.

If you are a developer, an agency owner, or a local business operator with technical depth: you can build this. The code isn't the hard part. The hard part is the discipline of letting the system run, reading its action log every week, and tuning its planner prompts based on real outcomes.

What follows is the complete specification. Copy it, adapt it, ship it.

§ 01What this is

A fully autonomous SEO system that runs continuously on a single local service business website. It does its own keyword research, builds new pages, tracks rankings, manages the Google Business Profile, monitors competitors, and decides what to do next — without anyone prompting it.

It is built once for localprosolutions.com as the lighthouse implementation. Once it works there, the same architecture clones to client sites.

What "fully autonomous" means here

• The system publishes content without human review (gated by automatic safety checks, not human approval)
• It schedules its own work based on what's most valuable to do next
• It learns from outcomes — rankings, traffic, leads — and adjusts its own playbook
• A human only intervenes when a safety gate fires or a quarterly strategic review is due

What it is not

• A content mill that publishes 100 thin pages a week (those get deindexed within months)
• A black box (every decision is logged with reasoning in an append-only table)
• A replacement for actual local expertise — it amplifies that expertise, doesn't replace it

§ 02The core mental model

The system is one agent loop that runs forever, with four phases:

• Perceive — pull the current state of the SEO world: rankings, GSC data, GBP insights, competitor changes, site health
• Decide — given that state, what's the single highest-leverage action to take right now?
• Act — do the thing. Publish a page, post to GBP, refresh decaying content, add internal links, fix a tech issue
• Learn — log the action with reasoning, then measure what happened so the next decision is better

Everything else in this document is plumbing around that loop.

§ 03Prerequisites & accounts

Before any code is written, these accounts must exist. None of them are optional.

§ 04The tool stack

The principle: the AI is only as useful as the tools it can reach. Every tool here either has a native MCP server or a documented API that gets wrapped in one. The tools change. The protocol doesn't.

Build & operate environment

• Claude Code — the agent runtime. Reads SKILL files, calls MCP tools, executes work.
• GitHub — code, content, prompts, policies, all versioned together.
• Vercel — hosts the site, runs the cron jobs that wake the agent.

Data & state

• Supabase — single source of truth. Every keyword, page, rank, action, experiment lives here.
• Notion (optional) — human-readable mirror for when an owner wants to look at the system without SQL.

Reach surfaces (via MCP)

• DataForSEO MCP — keyword volume, difficulty, SERP, on-page audits
• Local Falcon MCP — geo-gridded local rank tracking
• Ahrefs MCP — backlink and competitor intelligence
• GSC MCP — owned query data
• GBP MCP — post, respond, manage services
• GitHub MCP — commit content, open PRs
• Vercel MCP — trigger deploys, check builds
• Supabase MCP — read/write state
• Gmail / Slack MCPs — alerts and digests

Get everything connected.

Every account is reachable. Every MCP is wired into Claude Code. Every credential lives in one secure place.

0.1 — Initialize the project repo

mkdir lps-seo-agent
cd lps-seo-agent
git init
gh repo create lps-seo-agent --private --source=. --remote=origin

0.2 — Folder structure

lps-seo-agent/
├── site/                    # The Astro site
│   ├── src/
│   │   ├── content/         # Markdown — pages, blog, cities
│   │   ├── layouts/         # Astro layouts (schema baked in)
│   │   ├── components/
│   │   └── pages/
│   ├── astro.config.mjs
│   └── package.json
├── agent/                   # The agent
│   ├── skills/              # Individual skill files
│   ├── lib/                 # Shared utilities, MCP clients
│   ├── prompts/             # System prompts
│   └── CLAUDE.md            # Master instruction file
├── infra/
│   ├── supabase/            # Schema migrations
│   └── vercel/              # Cron config
├── .env.example
└── README.md

0.3 — Connect MCPs to Claude Code

Create .claude/mcp.json with entries for every MCP server you need. Pattern looks like:

{
  "mcpServers": {
    "dataforseo": {
      "command": "npx",
      "args": ["-y", "dataforseo-mcp-server"],
      "env": {
        "DATAFORSEO_USERNAME": "${DATAFORSEO_USERNAME}",
        "DATAFORSEO_PASSWORD": "${DATAFORSEO_PASSWORD}"
      }
    },
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server-supabase"],
      "env": { /* ... */ }
    },
    // ... github, vercel, localfalcon, gsc, gbp, etc.
  }
}

Verify each MCP connects by asking Claude Code to make a trivial call to each one before moving on.

Build the Supabase schema.

Every piece of state the agent needs lives in Supabase. Multi-tenant by client_id from day one, even for a single site — so the same schema works when you expand to clients.

The core tables

The actions table is the most important one. It's append-only by design. Every action has reasoning attached. That's how you debug, how you learn, and how you defend the work to anyone who asks "why did you publish this?"

create table actions (
  id uuid primary key default uuid_generate_v4(),
  client_id uuid references clients(id) on delete cascade,
  action_type text not null,           -- 'publish_page'|'gbp_post'|'refresh'|...
  target_table text,
  target_id uuid,
  reasoning text not null,             -- WHY the agent did this
  inputs jsonb,                        -- what state it saw
  outputs jsonb,                       -- what it produced
  gate_results jsonb,                  -- which safety gates fired
  outcome jsonb,                       -- measured after the fact
  status text default 'completed',
  created_at timestamptz default now()
);

An Astro site, deliberately static.

The site is intentionally a static Astro project. Four reasons:

1. Astro outputs plain HTML — perfect for crawling, no SPA rendering blockers
2. Markdown content with frontmatter is trivial for the agent to generate and edit
3. Schema markup is baked into layouts, not bolted on per page
4. Vercel auto-deploys on every commit — "publish" = "git commit"

Each piece of content is a markdown file in a typed collection. Services, cities, blog posts. The frontmatter is enforced by Astro's content collections, which means the agent can't publish a malformed page — it would fail the build.

Content collections (typed schemas)

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const services = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    description: z.string(),
    targetKeyword: z.string(),
    serviceAreas: z.array(z.string()).optional(),
    pricing: z.object({ from: z.number() }).optional(),
    faqs: z.array(z.object({ q: z.string(), a: z.string() })).optional(),
    publishedAt: z.date()
  })
});

// ... cities, blog collections follow same pattern

export const collections = { services, cities, blog };

Schema markup baked in

Every layout — ServiceLayout.astro, CityLayout.astro, BlogLayout.astro — emits structured data automatically based on the frontmatter. The agent doesn't need to remember to add schema. It can't not have schema.

Each skill is a self-contained capability.

This is the heart of the system. Each skill is a single SKILL.md file telling Claude Code exactly how to do one job. Skills live in agent/skills/. The agent never freelances. It runs skills.

The master instruction file — agent/CLAUDE.md — lists every available skill and the operating principles that apply to all of them.

The full skill inventory

Fourteen skills, each ~100-300 lines of natural-language instruction. Together they cover the entire loop.

The agent runs on triggers, not continuously.

Vercel Cron is the nervous system. A simple vercel.json defines four scheduled endpoints:

{
  "crons": [
    { "path": "/api/agent/daily",   "schedule": "0 13 * * *" },
    { "path": "/api/agent/weekly",  "schedule": "0 14 * * 1" },
    { "path": "/api/agent/monthly", "schedule": "0 15 1 * *" },
    { "path": "/api/agent/digest",  "schedule": "0 1 * * 1" }
  ]
}

• Daily — perceive-state, track-rankings, plan-next-action → execute one action
• Weekly — keyword-research, competitor-delta, plan a 3-5 action queue for the week
• Monthly — audit-site, internal-linking-pass, refresh-decaying-page for any decaying winners
• Digest — weekly-digest report goes out Sunday night

Beyond per-publish gates: global guardrails.

Even with safety gates on every publish, the system needs standing constraints. These are the protections that keep "fully autonomous" from becoming "fully unsupervised."

Cost caps

• DataForSEO — hard cap $50/month per site. Tracked in actions.inputs.api_cost. Abort runs that would exceed.
• Claude API — hard cap $30/month per site. Same pattern.
• Email alert at 80% of monthly cap.

Frequency caps

• Maximum 1 published page per day, 4 per week, 12 per month.
• Maximum 3 GBP posts per week.
• Maximum 1 site-wide internal linking pass per month.

Rollback triggers

• Site-wide traffic drop >15% within 7 days of a publish → auto-rollback (git revert + log).
• Site de-indexed → freeze all publishing, alert immediately.
• GSC manual action → freeze all publishing, alert immediately.

Outcomes feed back into the loop.

The system has to prove it's working — to you, to clients, and to itself. The feedback loop is the difference between automation and learning.

After every completed action, three outcome measurements get scheduled:

• +7 days — rank delta on the target keyword
• +30 days — traffic delta on the target page
• +90 days — lead delta (calls attributable to that page via CallRail)

Those outcomes write back to actions.outcome. The planner reads recent outcomes when deciding the next action. Actions that worked get amplified. Actions that didn't get parked. That is the learning mechanism, made concrete.

Rank tracking is a means, not an end. The system optimizes for what shows up in the bank account.

§ 12Build sequence, week by week

After week 8, the lighthouse is live. Every subsequent week, the agent gets smarter because the actions table is growing.

§ 13Appendix — what to expect

Where things will break

I am building this in public, which means I expect it to fail in ways I can't predict yet. The known risks:

• Google will sniff out low-effort AI content fast. Mitigation: every page needs verifiable local signals — real pricing, named neighborhoods, real photos from GBP. The client_facts table is what separates this from a content mill.
• Fully autonomous publishing is a liability surface. Even with no human review, the safety gates are non-negotiable. YMYL topics get flagged. Pages contradicting existing pages get blocked. The "fully autonomous" promise is preserved because of the agent-internal gates, not despite them.
• Local SEO is fundamentally a GBP game. For local service businesses, GBP optimization moves the needle more than 100 blog posts. The system treats GBP work as first-class, not a side feature.
• Rank tracking is a vanity metric. Clients (and you) will churn if you show "ranked #3" while the phone isn't ringing. CallRail integration is what makes the whole thing measurable.

The honest read

If you handed this playbook to a competent full-stack developer with the prerequisite accounts, they could build the lighthouse implementation in 6 to 8 weeks. The code isn't the hard part. The hard part is the discipline of watching the action log every week and tuning the planner prompts based on real outcomes.

The system gets better because you get better at noticing what it's doing well and what it's doing poorly. That's the part that can't be outsourced. That's the part that compounds.