SEO-AEO Growth Orchestrator Workflow

File: .agent/workflows/seo-aeo-orchestrator/WORKFLOW.md Workflow ID: seo-aeo-orchestrator Version: 2.0.0 Execution Mode: sequential gates with parallel content work where safe

Purpose

Turn a website or codebase into an evidence-backed SEO/AEO growth system. The workflow starts with an audit, implements approved fixes, confirms the business and keyword strategy, researches current search intent, creates foundational content, prepares external distribution, configures measurement, deploys, verifies, and offers weekly monitoring.

The workflow is designed for coding agents working directly in a repository. It must understand the project’s framework, routes, content storage, metadata implementation, sitemap/robots generation, deployment path, and authentication boundaries before editing or publishing.

Workflow entry point

{
  "workflow_input": {
    "project_path": "string — current project or repository",
    "site_url": "string — optional live URL",
    "business_type": "string — optional description of the business",
    "target_audience": "string — optional audience",
    "conversion_goal": "string — signup, demo, purchase, download, contact, or other",
    "user_keywords": ["string — optional owner-approved targets"],
    "location": "string — optional market or country",
    "foundation_page_count": "integer — 5–10, default 10",
    "research_mode": "browser | api | both | unavailable — default both",
    "existing_content": ["string — optional URLs, routes, or titles"],
    "tone": "professional | conversational | bold | empathetic | authoritative",
    "monitoring_preference": "ask | one-time | recurring | none — default ask"
  }
}

Authorization gates

The agent may inspect the codebase, run local checks, and draft recommendations without additional confirmation. Before each external or material mutation, obtain the required authorization:

• implementing code/content changes: follow the user’s request and preserve unrelated work;
• deploying or pushing to Git: confirm when the user has not already requested it;
• accessing Google Search Console or Bing Webmaster: ask the user to authenticate in the browser or provide an approved connector;
• submitting URLs or sitemaps: confirm the exact property and URLs before submission;
• creating recurring monitoring: ask whether the user wants it, even if monitoring_preference is ask.

Never claim an account is connected, a sitemap is submitted, a URL is indexed, or a deployment is live without observable evidence.

Execution architecture

PHASE 0 — DISCOVERY
  inspect codebase, framework, routes, live URL, deployment, and content model
        │
        ▼
PHASE 1 — AUDIT
  SEO/AEO/technical/conversion audit with evidence and prioritized fixes
        │
        ▼
PHASE 2 — IMPLEMENTATION
  apply approved audit fixes, then re-audit and verify build/routes
        │
        ▼
PHASE 3 — STRATEGY CONFIRMATION
  ask for business context, target keywords, audience, location, and conversion goal
        │
        ▼
PHASE 4 — SEARCH-INTENT RESEARCH
  browser + API research when available; semantic fallback when unavailable
        │
        ▼
PHASE 5 — CONTENT FOUNDATION
  landing/product improvements + 5–10 foundational pages, default 10 when justified
        │
        ├───────────────┐
        ▼               ▼
  internal content   external distribution plan
        │               │
        └───────┬───────┘
                ▼
PHASE 6 — MEASUREMENT AND PUBLISHING
  Search Console/Bing setup (gated), sitemap/URL submission, deploy, verify
                │
                ▼
PHASE 7 — MONITORING
  weekly analysis, refresh recommendations, optional recurring automation

Phase 0 — Discover the project

1. Inspect the repository without overwriting user work.
2. Identify framework, package manager, routes, page components, content files/CMS, metadata helpers, sitemap and robots generation, schema implementation, internal-link patterns, environment configuration, and deployment commands.
3. Identify whether a blog already exists. If not, determine the project’s native way to add pages and preserve its conventions.
4. Inspect the live URL when supplied and record what was actually checked.
5. Produce a short project map before making content recommendations.

…