Giving a coding agent SEO tasks: approve, do, prove

Short answer. Give the agent a shared task list, not a chat window. Every finding (audit error, lost index, traffic drop) becomes a task with what, why and a verification rule. The agent reads the list over MCP, starts only tasks a human approved, writes a note with the commit or measurement when done, and logs what it was asked. Nothing runs from a vague prompt, and every change can be traced back.

The problem with “fix my SEO”

An agent given a dashboard and a vague prompt does three bad things: it guesses, it repeats work, and it leaves no trail. Three weeks later nobody knows why a canonical changed or whether the fix worked.

seops’s task list (we call it AITM, AI task management) replaces the prompt with a protocol. It has four rules.

Rule 1: every finding is a task with a verification line

Audits, index checks, speed runs and the weekly summary don’t produce reports to read; they open tasks. Each task carries:

• What: the page, query, rule or file.
• Why: the number, its source and its period (“499 responses 35 → 12, Cloudflare, 7 days”).
• Verification: which tool shows which value when it’s done (“get_indexing: /pricing indexed”).
• Owner: user (settings, approvals, payments, access) or ai (analysis, drafts, code).

A task without a verification line is a wish, not a task. The agent is told to write one before it opens anything.

Rule 2: the agent starts only what you approved

Tasks owned by ai sit in the list until you press Approve in the panel. The MCP instructions sent with every connection say so explicitly; the agent reads list_tasks with status: active, filters for approvedAt, sets the task to doing, and leaves everything else alone. A scheduled task (scheduledAt in the future) waits.

This is the whole safety model, and it’s deliberately boring. The server has no tool that changes a panel, Cloudflare or GA4 setting. The agent can read everything and write only to the list, the prompt history and content drafts.

Rule 3: close with proof, not with “done”

When the agent finishes it calls update_task with status: done and a note that contains the evidence: a commit hash, the measured value, the URL that now returns 200. If the verification line cannot be satisfied yet (a deploy is pending, Google needs two days), the task stays doing with a dated note.

Here is a real note from the panel, written by the agent after fixing a backup job:

Code live (analytics 2ffe86f). Export “virtual table” error now falls back to the query API. Test: FTS5 fixture → dump → restore, row counts and MATCH identical. Live data: codes 1,203, codes_fts 1,203. Verification pending: tonight’s 00:30 backup shows arizakodu “ok”.

That is what a closed task should read like.

Rule 4: log what you were asked

Every run ends with log_prompt: the user’s request as written, a one-line technical version, the agent’s summary, the task IDs and commits. The prompt history page is how you audit the agent and how the next session picks up context without re-reading the chat.

Setting it up

1. Connect https://app.seops.app/mcp in Claude, ChatGPT, Gemini CLI or Claude Code (sign in with Google).
2. In the panel open Tracking › Tasks › AI tasks and approve one ai task, or press Let your AI agent do it next to a problem.
3. Ask the agent: “Work through my approved seops tasks.” It will read the list, do the work, close with proof and log the prompt.

The same list works for you: tasks owned by user are the settings and approvals only you can do, each with its menu path.

What it changes

• The agent stops asking “what should I do?” and starts asking “which of these may I do?”
• Repeated findings update an existing task’s note instead of opening a duplicate (dedupe keys).
• Verification lines turn “I think it’s fixed” into a value in a report.

Preguntas