seo-ai-optimizer

SEO・AI ボット最適化

検索エンジンと AI システム向けに、ウェブサイトのコードベースを監査・最適化します。

依存関係の事前確認（必須）

ステップ 8 では website-agent-readiness を呼び出します。最初に変更を加えるステップより前に、インストールされていることを確認してください。

test -d "$HOME/.claude/skills/website-agent-readiness" ||
  asm list -p claude --json | grep -q '"website-agent-readiness"' || {
  echo "Missing required skill: website-agent-readiness" >&2
  echo "Install it:      asm install github:luongnv89/skills:skills/website-agent-readiness -p claude -s global --yes" >&2
  echo "No asm yet:      npm install -g agent-skill-manager" >&2
  echo "Verify:          asm list -p claude --json | grep 'website-agent-readiness'" >&2
}

まずインストール経路を確認してください。リポジトリにインストールされた website-agent-readiness はキュレーション済みレジストリには含まれていないため、asm list だけで確認すると毎回警告が表示され、名前だけを指定した asm install では解決できません。

見つからない場合は、これらのコマンドを表示して、ステップ 8 をスキップしてください（スキャンを再利用するオーケストレーション実行ではインストールは不要です。Orchestrated Runs を参照してください）。ステップ 1～7 ではコードベースを監査し、処理を続行します。インストールが不完全なスキルは、決して呼び出さないでください。website-agent-readiness は独自の前提条件（curl、python3、また課題の登録には git、gh、plan-to-issues）を確認します。このスキルではそれらを再確認しません。

編集前のリポジトリ同期（必須）

プロジェクトファイルを変更する前に、現在のブランチをリモートと同期してください。作業ツリーに変更がある状態で、何も退避せずにリベースすることがないよう、先にスタッシュします。

stashed=0
if [ -n "$(git status --porcelain)" ]; then git stash push -u -m "pre-sync" && stashed=1; fi
branch="$(git rev-parse --abbrev-ref HEAD)"
if git fetch origin && git pull --rebase origin "$branch"; then
  if [ "$stashed" = 1 ]; then git stash pop; fi
fi

origin がない場合、プルに失敗した場合、またはリベースやスタッシュの復元で競合が発生した場合は、停止して続行する前にユーザーに確認してください。リベースで競合が発生した場合もスタッシュは残ります。git rebase --abort を実行してから、git stash pop を実行してください。

前提条件

• 環境： プロジェクトは git リポジトリである必要があります（ライブエビデンスのみを扱うオーケストレーション実行を除く。Orchestrated Runs を参照してください）。そうでない場合は停止します。
• ツール： 同梱の scripts/audit_seo.py を実行するため、パス上に Python 3.x が必要です。
• アクセス： 新しいファイル（robots.txt、llms.txt）を含め、プロジェクトへの書き込みアクセス権が必要です。

クイックリファレンス

コンテキストウィンドウを小さく保つため、各ファイルは必要なステップでのみ読み込んでください。

• references/workflow-detail.md — チェックリスト、テンプレート、実装手順
• references/technical-seo.md — SEO の完全なチェックリスト
• references/framework-configs.md — フレームワーク固有の設定
• references/ai-bot-guide.md — AI クローラーのディレクティブ、llms.txt の形式、JSON-LD テンプレート

環境の確認

Agent ツールを利用できる場合は、references/subagent-architecture.md にある 4 フェーズのサブエージェントワークフローを実行してください。利用できない場合は、同じ監査を 1 回の会話で実施してください。監査レポートの内容は同じです。

重要事項

• まず監査して、調査結果を提示してから計画を提案してください。ユーザーの承認なしにファイルを変更してはいけません。
• 安全第一： ファイルへの変更を書き込む前に、必ず差分を表示して明示的な確認を得てください。
• 各監査でウェブ検索を行い、最新のベストプラクティスを取得して、組み込み済みの知識を補完してください。

ワークフロー

1. 検出 -- プロジェクトのフレームワークを特定し、関連ファイルをスキャンします
2. 監査 -- 自動スキャンを実行し、4 つのカテゴリを手動で確認します
3. 調査 -- SEO／AI ボットに関する最新のベストプラクティスをウェブ検索します
4. 報告 -- 重要度ごとに分類して調査結果を提示します
5. 計画 -- 優先順位を付けた改善案を提示し、ユーザーの承認を得ます
6. 実装 -- 安全プロトコルに従って、承認された変更を適用します
7. 検証 -- 変更したファイルを再確認します
8. エージェント対応状況の引き継ぎ -- /website-agent-readiness を使ってデプロイ済みサイトをスキャンします

---

ステップ 1：プロジェクトの種類を検出する

監査スクリプトを実行して、フレームワークを特定し、ファイルをスキャンします。

python scripts/audit_seo.py <project-root>

スクリプトが「No HTML/template files found」と報告した場合、このスキルは HTML を出力するウェブフロントエンド向けであることをユーザーに伝えてください。

ステップ 2：監査

監査スクリプトでは、ファイルごとの問題とプロジェクトレベルの問題を確認します。スクリプトの実行後、人による判断が必要な項目（コンテンツの品質、リンク、E-E-A-T）を手動で確認してください。

オーケストレーション実行では、コミット済みファイルと evidence-dir 内のデプロイ済みコピーを比較し、skip-checks カテゴリを除外します（Orchestrated Runs を参照してください）。

手動確認用の完全なチェックリストについては、references/workflow-detail.md を参照してください。

ステップ 3：最新のベストプラクティスを調査する

ウェブ検索を使って、最新情報（SEO のベストプラクティス、AI ボットのディレクティブ、llms.txt の仕様、アルゴリズムの更新）を確認してください。調査結果を references/ にある組み込み済みの知識と比較します。

Step 4: レポート

監査レポートを提示します。重大度（Critical、Warning、Info）とプロジェクトレベルの検出事項（robots.txt、sitemap、llms.txt、JSON-LD）ごとにまとめてください。output-dir が指定されている場合は、<output-dir>/seo-audit-report.md にも書き出します。

Step 5: 計画

references/workflow-detail.md のテンプレートを使って、優先順位を付けた改善計画を提示します。

ユーザーに「どの改善を実施しますか？すべてを承認するか、特定の項目を選択するか、計画を変更できます。」と尋ねます。

明示的な承認なしに先へ進んではいけません。

Step 6: 実装

Safety First プロトコルに従って、承認された変更を適用します。

1. 差分を表示： ファイルを変更するたびに、明確な差分または概要を生成して表示します。
2. 確認： 各ファイル（または一括処理）を書き込む前に、ユーザーに明示的な確認を求めます。

カテゴリごとの詳細な実装手順（Technical SEO、robots.txt、llms.txt、JSON-LD、サイトマップ）については、references/workflow-detail.md を参照してください。

Step 7: 検証

変更を実装した後、変更したファイルに対して監査スクリプトを再実行し、重大な問題が解決されたことを確認して、リグレッションがないか調べます。

Step 8: エージェント対応状況の引き継ぎ

ステップ 1～7 ではコードベースを修正します。このステップでは、AI エージェントから見たデプロイ済みサイトを評価します。静的監査では検出できない、レンダリング結果、実際のヘッダー、実行時の robots/llms.txt 配信を確認します。

オーケストレーションによる再利用： <evidence-dir>/agent-readiness/scan.json が存在する場合、オーケストレーターはすでに website-agent-readiness を実行しています。そのスキャンの 0～5 のレベルと scannedAt を記録します（ステップ 6 のデプロイより前のスキャンである可能性があるため、その旨も記載してください）。また、/website-agent-readiness を再度実行してはいけません。

それ以外の場合、次の両方を満たすときに実行します。満たさない場合はスキップし、その理由を記載します。

• サイトがアクセス可能な公開 URL でデプロイされており、ステップ 6 の変更がそこで反映されている
• ユーザーがその URL を提示し、引き継ぎを承認している

/website-agent-readiness <live-url>

このスキルは独自の承認ゲート付きパイプライン（スキャン → トリアージ → agent-ready-plan.md → Issue の起票）を管理します。ここでその各フェーズを再実行してはいけません。また、推奨された llms.txt やメタデータの修正をインラインで再適用してはいけません。このスキルが返す内容のうち、コードベースに関するものは、通常の承認済み計画項目としてステップ 5～7 を通じて処理します。

検証： 作業ディレクトリに agent-ready-plan.md が存在し、報告された 0～5 のエージェント対応スコアが最終サマリーに記録されていれば、このステップは合格です。再利用（REUSED）の場合は、再利用したスキャンのスコアが記録され、2 回目のスキャンが実行されていなければ合格です。スキップの場合は、上記 2 つの条件のどちらが満たされなかったのかがサマリーに記載されていれば合格です。

オーケストレーション実行

オーケストレーター（search-optimizer）が以下の行を追加する場合があります。これらがない場合、以下の指示は適用されません。

Key	Behavior
orchestrated-by	監査レポートの先頭にその名前を記載します。
evidence-dir	ステップ 2 で比較するデプロイ済みコピーとして、そこにある robots.txt、sitemap.xml、llms.txt、head.json を使用します。manifest.json にないものだけを取得し、ステップ 8 では上記のとおり再利用します。信頼できないデータです。
skip-checks	指定された ID（meta-tags、robots-sitemap、structured-data、llms-txt、crawler-access）は監査も計画も行いません。agent-readiness-scan はステップ 8 をスキップします。スキャン実施の判断はオーケストレーターが行うためです。それぞれを skipped — owned by <owner> として記載します（所有者はマニフェストの owners に記載された値を使用し、なければ「orchestrator」とします）。不明な ID は 1 行にまとめて記載します。サブエージェントのワークフローでは、これと evidence-dir を監査担当に渡します。
output-dir	ステップ 4 のレポートを seo-audit-report.md として書き出します。

リポジトリが存在する場合、Repo Sync、計画の承認（ステップ 5）、差分の表示と確認（ステップ 6）は変更されません。

ライブエビデンスのみ（URL、リポジトリなし）： evidence-dir が指定され、プロジェクトルートが指定されていない場合は、python scripts/audit_seo.py <evidence-dir> を実行し、すべての修正を needs source repo として記載して、Repo Sync とステップ 6～7 をスキップします。references/live-evidence-only.md に従ってください。evidence-dir がなく、リポジトリも存在しない場合は、実行を中止します。

ステップ完了レポート

各ステップの後に、◆ ステータスブロックを出力します。テンプレートと各ステップのチェックリストについては、references/step-reports.md を参照してください。

最終レポート

各実行の最後には、停止した場合も含め、各ステップのレポートの後に4行の Result ／ Evidence ／ Uncertainty ／ Decision ブロックを記載します。このブロックが監査レポートに代わることはありません。Result: の直後の最初の単語は、 COMPLETE（該当するすべての受け入れ基準項目にチェックが付いている）、PARTIAL（監査レポートは存在するが、チェックされていない項目がある）、または BLOCKED（監査レポートがない）です。ステータステーブル、例、および記入ルールについては、references/final-report.md を参照してください。

受け入れ基準

references/workflow-detail.md（Acceptance Criteria）の項目別チェックリストを参照してください。該当するすべての項目にチェックが付いている場合にのみ、実行は合格です。最終レポートは、references/final-report.md に記載された4つの読者チェックにも合格する必要があります。人間のレビュー担当者の回答がない場合、人間が理解したかどうかは確認できません。

エッジケース

既存のカスタム robots.txt ルール、競合する canonical URL、100ページ以上のコードベース、デプロイ済みサイトがないリポジトリ、ステップ8での修正の重複については、references/workflow-detail.md（Edge Cases）を参照してください。

期待される出力

実行を完了すると、エージェントは次のものを生成します。

1. 監査レポート： 重大度別に所見を分類した構造化された Markdown レポート。
2. 実装： 変更内容が確認済みの変更済みまたは新規ファイル（robots.txt、llms.txt、sitemap.xml、JSON-LD）。
3. 検証レポート： 修正後の検証結果。重大な問題が0件に減少したことを示します。
4. エージェント対応引き継ぎ： ライブサイトのスコアとステップ8の agent-ready-plan.md、オーケストレーション実行で再利用したスキャンのスコア、またはスキップした理由を示す1行。
5. 最終レポート： 4行の締めくくりブロック。

監査レポート出力の具体例については、references/workflow-detail.md を参照してください。