seo

SEO Router

Use seo as the default front door and user-facing owner for every request in this suite: a narrow technical question, a content review, an AI-search investigation, a multi-team plan, or an end-to-end authorized change. The user states the outcome in ordinary language; the router screens all 27 skills, executes every applicable specialist workflow, carries intermediate evidence and decisions internally, and returns one consolidated result. It does not ask the user to coordinate the suite, duplicate specialist logic, invent findings, or merge unlike metrics into one score.

Read autonomous-orchestration-contract.md for every request before selecting or executing specialist lanes. Read routing-matrix.md before routing a request through the suite. Read decision-and-release-contract.md when the requested work can continue from evidence into implementation, release, provider mutation, or delayed outcome follow-up.

User burden boundary

• Never require the user to know whether their problem is SEO, AEO, GEO, AI-search, technical, content, authority, or measurement.
• Never ask the user to choose a specialist, artifact, schema, validator, or phase order. Infer and manage those internally.
• Ask only for material business truth, inaccessible data/access, an outcome-changing choice, cost-bearing action, or authorization that cannot be safely inferred.
• A direct specialist call remains supported for expert users, but it is never a prerequisite for complete work through seo.

Routing procedure

1. Translate the user's ordinary-language goal into the requested outcome and authorized boundary: answer, research, audit, decision, strategy, measurement, implementation, release verification, provider operation, follow-up, or end-to-end completion.
2. Inspect available site/repository/data context before asking questions. Infer the surface, locale, verticals, technical system, and affected scope; ask only for non-discoverable material facts or permissions.
3. Create the 27-skill coverage ledger from the autonomous orchestration contract. Mark every capability required, active, completed, not-applicable, blocked, or deferred-by-owner with evidence or a reason. A broad request cannot skip the screen; a narrow request still receives the screen internally.
4. Build the dependency graph and load each required specialist's full SKILL.md before executing that lane. The router—not the user—invokes or performs the next specialist workflow and transfers its evidence/artifacts.
5. For a broad request to rank higher, improve organic visibility, or optimize a site/page, establish the intended query families with seo-research, review the page's search-result presentation with seo-page and seo-content, and verify hostname-level favicon/site identity with seo-technical. Require two concurrent opportunity tracks: evidence-backed nearer-term gains and high-volume head-term/category leadership. Preserve every owner-declared relevant high-volume family as a required strategic target; current difficulty or an authority gap changes the work and sequence, not whether the target is analyzed. Do not let a broad closeout omit title, descriptive meta description, favicon, canonical/indexability, or query-to-page ownership merely because each item is individually simple. Do not let easier work replace or hide the head-term leadership track. A deliberately narrow request remains narrow.
6. For compound optimize-and-track work, use this phase order: research -> audit -> baseline measurement -> product-owner decision -> action planning -> authorized implementation -> local acceptance -> authorized release -> live delivery verification -> authorized provider operation -> delayed outcome follow-up.
7. Require each phase's real artifact or explicit limitation before starting a dependent phase. AEO/GEO work hands off a validated optimization-brief.json; conventional SEO lanes hand off a validated seo-findings.json bundle. Reuse an existing goal, issue, or Action Plan when it already records the full decision; otherwise add the short decision record defined in the decision-and-release contract. Do not let a downstream specialist silently repair missing upstream evidence or self-approve a change.
8. Continue through every safe read-only/local and explicitly authorized phase while useful work remains. Evaluate authorization separately for implementation, release, and provider mutation. When later authorization arrives, resume the same decision and candidate chain rather than restarting or substituting work.
9. Parallelize only independent lanes when the runtime permits it. Keep the final synthesis with the router, preserve disagreements instead of averaging them away, and do not expose intermediate handoff work as user homework.
10. Close critical and important findings before release; record minor findings in backlog. Review one candidate hash at most twice. Finish with one consolidated outcome and, for broad work, a compact 27-skill coverage summary.