SEO Action Plan

SEO Action Plan

Purpose

Turn evidence-backed findings into a sequenced implementation plan that a content, engineering, analytics, product, or legal owner can approve and execute. This skill plans work; it does not change a site, publish content, modify crawler controls, deploy code, or approve its own recommendations.

Use it after seo-aeo or seo-geo has produced a validated optimization-brief.json, or after a conventional SEO specialist has produced a validated seo-findings.json bundle. For a normal conversational audit without a validated artifact, provide a clearly labelled provisional action list and name the evidence needed before it becomes a formal plan.

Non-negotiable boundaries

• Do not promise inclusion, ranking, citation, referral, traffic, revenue, or conversion lift.
• Do not invent a platform requirement. In particular, do not prescribe llms.txt, special “AI schema”, chunk sizes, bot access, or a crawler-control change unless the supplied evidence and the applicable platform documentation support it.
• Separate an observed issue from its likely cause and from the proposed change.
• Never treat a crawler request or bot log as evidence of retrieval, grounding, citation, referral, or conversion.
• Do not turn a speculative or experimental finding into a normal implementation action. Keep it as a monitored experiment or decline it.
• Require human approval for production, policy, legal, accessibility, analytics, or crawler-control changes. The plan’s approval status starts as pending.

Formal-plan workflow

Read references/action-plan-protocol.md before creating action-plan.json.

1. Check the input gate. Require an immutable, validated upstream bundle. An AEO/GEO input contains optimization-brief.json, research-pack.json, and its referenced raw evidence. A conventional SEO input contains seo-findings.json and the raw evidence it names. Run:

   Let <suite-root> mean ${CLAUDE_PLUGIN_ROOT} in Claude Code. In Codex, read .seo-suite-runtime.json beside this SKILL.md when present and use its suite_root value; otherwise use the absolute repository checkout, then run:

   python "<suite-root>/scripts/validate_seo_action_plan.py" validate-plan <plan>/action-plan.json --bundle <plan>
   

   Validate a conventional input directly before packaging it when possible:

   python "<suite-root>/scripts/validate_seo_findings.py" validate-findings <findings>/seo-findings.json --bundle <findings>
   

   The runtime skill locator resolves the installed support package containing the suite-level validators and contracts; a retained repository checkout is optional.

   The plan bundle must preserve each upstream bundle below inputs/; do not edit its artifacts after validation. Use Action Plan 1.2.0 when it contains SEO Findings 1.1.0, Optimization Brief 1.1.0, or expanded action/verification types. Action Plan 1.1.0 remains valid for legacy SEO Findings 1.0.0, and 1.0.0 remains valid for legacy Optimization Brief 1.0.0-only plans.

2. Map the evidence. For every proposed action, link at least one finding and at least one resolving evidence record. Keep locale, engine, surface, target, and claim scope intact. An action may combine findings only when their scopes are compatible.

3. Choose a real owner and a reversible path. Assign the responsible team/role, required approver, effort, risk, dependencies, acceptance criteria, verification method, guardrail, and rollback method. seo-action-plan itself cannot be the implementation owner.

   Action Plan 1.2.0 requires risk_flags. Declare every applicable policy, crawler/indexing, legal/privacy, accessibility, experiment-wide, or irreversible risk. Any declared flag is high risk and requires the matching approval and rollback; do not hide sensitive work behind a generic technical or content label.

4. Use confidence honestly. high needs confirmed evidence; medium cannot rest on experimental evidence; low is an explicitly monitored hypothesis. Decline changes that lack sufficient evidence, conflict with platform documentation, or would create legal/accessibility risk.

5. Write only executable, reviewable instructions. Say what will change, what will not change, how it will be checked, and which observable signal would justify keeping or reverting it. Use a source-specific metric: search-console visibility, analytics/referrals, manual content review, recrawl, log review, or a repeatable visibility run. Do not collapse these into a universal score.

6. Validate before handoff. Use validate-plan; fix every error. A passing file proves structural traceability, not that the recommendation will work or that the upstream evidence is current.

Routing from the plan

• Content/editorial: send approved actions to seo-content; preserve the evidence and claim boundaries in the content brief.
• Technical implementation: send approved actions to seo-technical; include rollback and platform-specific crawler/control evidence.
• Structured data: send approved actions to seo-schema; require visible-content alignment and rich-result eligibility checks, never a rich-result promise.
• International targeting: send approved actions to seo-hreflang or seo-sitemap when the action’s locale or discovery scope requires it.
• Commerce and local: send product/feed actions to seo-commerce and location/profile/NAP actions to seo-local.
• Media and publishing: send video actions to seo-video and publisher/news/Discover actions to seo-news-discover.
• Agent, architecture, and authority: send task-flow/protocol actions to seo-agentic, taxonomy/internal-link/site-graph actions to seo-architecture, and backlink/mention/source-landscape actions to seo-authority.
• Measurement: send conventional search/site performance work to seo-performance and AI-answer observations to ai-visibility-monitor; keep their metric families separate.
• Prioritization and coordination: send cross-team approved work to optimise-seo or seo-plan.

Provisional action list

If a formal input bundle is unavailable, do not fabricate one. Respond with a short table or list containing:

• observation and its source/capture;
• proposed action and owner;
• evidence gap or uncertainty;
• approval needed;
• verification and rollback;
• the exact artifact or observation needed to upgrade it to a validated formal plan.

Label all such items provisional; do not write them to action-plan.json.

Output checklist

For a formal plan, return:

• action-plan.json, validated against the checked-in contract;
• a readable action summary grouped by priority and owner;
• explicit declined actions and limitations;
• a statement that approval is pending and that outcomes are not guaranteed.

Do not include raw secrets, personal data, copied customer analytics, or unlicensed content in the plan bundle.