seo-audit

OpenSEO SEO 監査

目標

サイトの有益なオーガニックトラフィックを最も増やせる施策を見つけ、専門知識のない人でも実行できるように説明します。幅広く調査し、推奨事項は厳選します。レポートでは、質の高い検索需要を大きく取り込む、または実際の損失を防ぐための推奨事項を1〜3件、冒頭に提示します。

SEO 監査やドメインのレビュー、特に共有可能なレポートを依頼された場合に使用してください。競合や市場について専門家向けに分析する場合は、代わりに competitor-analysis または competitive-landscape を使用してください。

入力とプロジェクトのコンテキスト

• 監査対象のドメインと projectId（list_projects を使用します。一致するプロジェクトがない場合は、create_project を使用します）。
• まず get_project_context を呼び出します。このスキルには business_overview が必要です。空の場合は、サイトから事業内容を推測し、ユーザーに1つ質問して確認し、update_project_context で書き戻してから続行します。残りの項目については最後に seo-project-setup を提案し、最初から詳細なヒアリングを行わないでください。
• 30日以内の調査ログの結果は、情報収集に再利用します。推奨事項の根拠となるランキングの主張については、今回の監査中にライブチェックを行う必要があります。
• 完了時には、長期的に有用な情報を update_project_context で書き戻します（修正した business_overview と、レポートで取り上げたページを addKeyPages で追加）。また、{ appendResearchLog: { summary: "Site audit: <domain>. Verdict: <conclusion>" } } を追記します。

seo-report スキルを通じて提出し、skill: "seo-audit" を指定して保存します。このスキルを利用できない場合は、その旨を伝え、HTML の作成に進まないでください。

OpenSEO MCP ツール

• whoami：作業を始める前に接続とクレジットを確認します。OpenSEO に接続されていない場合は、作業を中止して、接続するようユーザーに依頼してください。
• run_site_audit を実行し、続けて get_audit_status を呼び出します（確認の間隔は1〜2分空けてください）。その後、get_audit_issues と get_audit_pages を呼び出します。ユーザーがパフォーマンスの詳細な分析を依頼していない限り、Lighthouse は無効のままにします。クロール結果の取得は無料です。
• get_backlinks_overview と get_domain_overview：概要把握のみに使用します。プロバイダーが示すトラフィック数とキーワード数は推定値で、観測日が一律ではありません。実測訪問数ではありません。
• get_ranked_keywords：どのクエリがどのページにトラフィックを送っているかを確認します。まず resultTypes: ["organic"] を指定してドメイン単位で1回呼び出し、比較対象の特定ページには scope: "exact_url" を使用します。限定されたドメインサンプルにページが含まれていなくても、ランキングがない証拠にはなりません。ランキング行にはそれぞれ last_updated_time があり、キーワード指標の日付はランキングの日付ではありません。
• get_serp_results：レポートに記載するすべてのランキングの主張を裏付けるライブチェックです。返される rank はすべての結果ブロックを数えるため、オーガニック（有料ではない）リスティングを自分で数え、ページごとに10件として掲載位置を報告します（例：「#10（1ページ目）」、「#11（2ページ目）」）。深度は20を指定します。ページが見つからない場合は「上位20件以内に表示されず」とします。検索に失敗した場合は不明として扱い、「上位20件以内に表示されず」とはしません。正確なクエリ、国、言語、日付、返されたオーガニックリスティングの件数、該当する URL を記録します。これらの詳細は表ではなく、エビデンス付録に記載します。
• get_search_console_performance：接続されている場合は、ファーストパーティのクリック数と表示回数を確認し、可視性の低さとクリック率の低さを区別します。アクセスできないことは網羅性の不足であり、作業を妨げるものではありません。
• get_keyword_metrics と research_keywords：候補ページが対象とするクエリの需要を調べます。通常、焦点を絞った指標の一括取得で十分です。需要の不足によって判断が変わる可能性がある場合は、1〜3個のシードを指定して調査を1回行います。
• ウェブ上の情報収集（取得、スクレイピング、検索）：対象サイトのページ、サイトマップ、クエリの上位検索結果、競合ページを確認します。

追加の検索によって優先すべき機会が変わる可能性が低くなるまで調査します。ユーザーが明示した予算を守り、予算によって実施できなかった比較を伝えてください。

ワークフロー

1. 状況を把握する

whoami を実行してプロジェクトを特定し、run_site_audit を開始します。クロール中に、被リンクの概要、ドメインの概要、ドメイン単位のランキングキーワードのサンプル、サイトマップとナビゲーションを確認します。クロールのサンプルだけでなく、サイトマップからサイトのページ群を書き出します。製品、料金、比較または代替案、ツールとテンプレート、ガイド、カテゴリ、サービス、地域など、実際にそのサイトにあるものを確認します。

クロールに不具合があるか、ほとんどデータがない場合（証明書エラー、5xx、1ページのみなど）は、何よりも先に調査します。リダイレクトと証明書のバリエーションを自分で確認し、その事業について検索します。稼働していないドメインに後継サイトが存在する場合、推奨全体を「古いドメインをリダイレクトする」に切り替えます。

2. 目標に関係するページ群をすべて調査する

購入者を呼び込む可能性のあるページ群ごとに、少なくとも2ページの主要コンテンツを読みます（ナビゲーションや共通テンプレートは無視します）。ランキングデータで最も成果の高いページと、最も成果の低いページまたは典型的なページを1つずつ確認します。各ページについて、検索者が抱いている判断事項や疑問は何か、そしてページが具体的かつ正確で、出典に基づいた情報で回答しているか、それとも共通の回答に名称、地域、キーワードを当てはめているだけかを確認します。そのクエリで上位表示されている結果が提供する情報と比較します。

SaaSでよく見られるパターンは、直接確認する価値があります。競合他社との比較ページまたは代替案ページと、競合他社の料金ページは別々のページ群であり、それぞれ異なる購入時の疑問に答えます。類似ページ同士を並べて読みます。類似ページ間で可視性にばらつきがある場合は、検索意図、コンテンツの具体性、リンク、権威性を調査します。すでに上位近くにランクインしている類似ページは、書き換えるのではなく、維持すべきページです。

候補として挙げる可能性のあるページについて、基本項目を確認します。ステータス、canonical（ページが優先バージョンとして指定しているURL）、インデックス指定、訪問者が内部リンクをたどってそのページに到達する方法を確認します。ページ群がクロールに含まれていない場合、類似ページの成果に大きな差がある場合、ツールやテンプレートのページがランクインしていることがわかった場合、またはライブ検索で予想とは異なるページが表示された場合は、調査範囲を広げます。

下書きの前ではなく、今すぐライブ検索を実施します。候補ページが対象とするクエリクラスター（主要な検索語と、購入者が実際に使用するバリエーション）を調べます。優位な比較対象と劣位の比較対象がある場合は、両方を確認します。主要な推奨事項を決める検索は、執筆前に再度実行します。2回の確認結果が食い違う場合は、後の結果を記載し、先の結果を括弧内に添えます。たとえば、「10位、1ページ目（初回確認時：検索結果の上位20件に表示なし）」のように記載します。この日の結果のばらつきは、傾向ではなく日ごとの変動です。1回のスナップショットはベースラインではありません。

3. 判断の前に候補を絞り込む

作業フォルダーにopportunities.mdを作成します（成果物ではなく、作業メモとして）。有力な候補ごとに1行を記載します。通常は5～10件とし、次のうち少なくとも3種類の機会から候補を選びます。

• 対象とする需要に対して成果が出ていない既存ページ
• 回答するページが存在しない、実際の需要。製品自身の主張に基づく機能、フレームワーク、ユースケースのクエリを含む
• 保護または修正すべき、成果の出ているページ
• アクセス、インデックス登録、リダイレクトの不備による訪問数の損失
• 既存の訪問者が次のステップに進めるよう支援する機会

列：ページ | 観察した問題 | 根拠（米国の月間検索ボリュームを含むクエリクラスター、順位とページ、または「検索結果の上位20件に表示なし」、日付） | 提案する変更 | 誰が検索し、なぜこの事業にとって重要なのか | 見込める効果 | 工数 | 主な不確実性。

追加で調べれば行の順位が変わる場合（検索ボリュームの不足、未確認の類似ページ、ライブ検索を一度も実行していないクエリなど）は、順位を決める前に調査します。

4. 選定

検索者が顧客になる可能性が高い状況で、実証された問題を直接解決し、意味のある改善が見込める、範囲の明確な変更を優先します。診断の確度が低い、大量の検索ボリュームが見込める機会が、それだけで優先されるわけではありません。実際のアクセスやインデックス登録の阻害要因、測定可能なトラフィックの減少、またはドメインの消失があれば、優先順位を上げます。

次の項目だけでは、どれも判断材料として不十分です。サンプルとして取得した1つのクエリの検索ボリューム、修正の容易さ、クローラーの警告、1位を想定した場合の仮のトラフィック数、実証されたトラフィック減少を伴わないナビゲーションやリダイレクトの修正です。こうした項目は、トップ3ではなく、確認済みの表に記載します。対象クエリですでに上位にランクインしているページの書き直しは推奨しないでください。

ショートリストの各行は、推薦案か、報告書の「他に確認した項目」テーブルのいずれかに必ず記載し、そこには具体的な理由を添えます。「営業から要望があれば後で対応」は理由になりません。「先頭候補の4分の1の需要しかなく、ページはすでに7位にランクインしている」なら理由になります。次点候補については、先頭候補が優れている理由を1文で書き、その文を報告書に記載します。

5. 効果を誠実に見積もる

• 効果の仕組みを明記します。新たにランクインするのか、既存のランキングで順位が上がるのか、現在の順位のままクリック数が増えるのかを示します。すでにランクインしているページは、すでに検索ボリュームの一部を獲得しているため、全検索ボリュームを対象にしたシナリオでは効果を過大評価します。
• 変更が対象とするクラスターに基づいて見積もり、特定の1つの検索語句だけを基準にしないでください。バリエーションを別々の利用者として合算せず、重複がある場合はその旨を記載します。
• 特に明記がない限り、需要の数値は米国のものです。架空のグローバル数値に換算しないでください。
• 検索ボリュームは訪問数ではありません。明記したクリックシェアの仮定を使用し、シナリオテーブルにその仮定を示します。1位を想定したシナリオも、仮定であり約束ではないと明記すれば使用できます。
• 現在のトラフィック基準値が不明な場合、その数値は追加訪問数ではなく、訪問数の総ポテンシャルとして記載します。重複するクエリは合算しないでください。
• 検索意図と製品の適合性から、ビジネスとの関連性を推測できます。その場合は、推測であることを明記します。コンバージョン率や売上をでっち上げてはいけません。
• 数値を示せない場合は、方向性とその理由を説明します（「主要クエリですでに3位のため、伸びしろは小さい」など）。

6. レビューしてから執筆する

まず報告書の本文を下書きします（Markdown または HTML。まだ保存しません）。下書きとショートリストをレビュー担当者に渡します。環境で実行できる場合は、2つ目のエージェントまたはモデルに依頼し、できない場合は新たに自己レビューします。レビュー担当者は、却下した候補のうち最も有力なものについて根拠を主張し、下書きがそれに答えているかを述べる必要があります。また、最有力の推薦案を裏付ける根拠が下書きに含まれていること、ステップ2で特定した重要な診断結果がすべて、推薦案またはテーブルの行として反映されていることを確認し、日付、地域、順位の表記規則を確認して、段落のように長い箇条書きや専門用語を指摘します。指摘事項を修正し、新たに加えた事実の主張は根拠と照合して確認したうえで、seo-report を通じて作成し、保存します。

出力形式

seo-report のタイトル規則を使用します。セクションは次の順に並べます。

1. 次に行う SEO 施策：箇条書きで 2～3 項目にします。最初のアクション、必要なら次のアクション、そしてすでに機能していることを記載します。この箇条書きは、スターターテンプレートの冒頭の段落と最後の「次に行うこと」セクションに置き換わるため、どちらも含めません。
2. 推奨事項：優先度順に 1～3 件を記載します。それぞれ、アクションと対象ページまたは小規模なページグループを示す h3 を付け、次の内容を含めます。
   • 実施内容：箇条書きで 2～4 項目にします。動詞で始め、変更内容を示し、対象ページへのリンクを付けます。
   • 理由：箇条書きで 2～4 項目にします。確認されたギャップ、その情報を検索する人とそれが重要な理由、想定される効果、主な不確実性を記載します。効果と確信度は一緒に記載します。
   • 小規模な根拠表を付けます（検索需要と現在の表示状況、または類似ページ間の比較、または確認されたコンテンツと提案内容の比較）。表だけで内容が分かるようにします。列見出しに地域と日付を含め、順位は「#10（1 ページ目）」または「上位 20 件に表示なし」のように記載します（「10/17」、矢印、リスティング件数は使用しません）。ボリュームの列見出しには「推定」と記載します。見出しだけでは伝えられない制約がある場合に限り、「読み方」の箇条書きを追加します。任意で、仮定に基づく 2 行のシナリオ表を付けてもかまいません。
3. ほかに確認した項目：表を 1 つだけ使用します。列は「機会 | 確認結果 | 判断」です。推奨事項にならなかったショートリストの各項目につき 1 行を設け、ステップ 4 の次点項目とその説明文から始め、さらにメンテナンス項目をまとめた行を追加します。各セルは 1 行に収めます。
4. このレポートの作成方法：seo-report にある固定のスキルリンク行（URL https://openseo.so/docs/skills/seo-audit、テキスト「OpenSEO SEO Audit skill」）、調査範囲と制約を 2 行で記載し、続けて <details><summary>根拠と方法</summary> ブロックを追加します。既定では閉じた状態にし、クロール対象のサンプル、確認したページ群、ライブチェックの全表（クエリ、ボリューム、順位、取得したオーガニック検索結果数、時刻）、計算、情報源を含めます。内容だけで自己完結するようにします。ローカルファイルパスは根拠として扱いません。

1 件の推奨事項と確認項目表のひな形（seo-report の CSS は変更せず、すべての h2 に id と目次レールの項目を付けます）。

<h2 id="recommendations">Recommendations</h2>
<h3>Make the Northwind comparison answer a switching decision</h3>
<p><strong>Do this</strong></p>
<ul>
  <li>Replace the shared table on <a href="URL" target="_blank" rel="noopener">/northwind-alternative</a> with Northwind-specific tradeoffs.</li>
  <li>Add a sourced migration section: policies, evidence, audit continuity.</li>
</ul>
<p><strong>Why</strong></p>
<ul>
  <li>Same comparison text as two siblings; only the vendor name changes.</li>
  <li>Searchers are already evaluating a switch, the closest fit to a demo.</li>
  <li>Position-one scenario: about 40–60 total US visits a month. Hypothetical, not a forecast.</li>
</ul>
<div class="tw"><table>
  <thead><tr><th>Query</th><th class="n">Est. US searches/mo</th><th>Acme position, US, Sep 18, 2026</th></tr></thead>
  <tbody><tr><td>northwind alternative</td><td class="n">50</td><td>#9 (page 1)</td></tr></tbody>
</table></div>

<h2 id="what-else-we-checked">What else we checked</h2>
<div class="tw"><table>
  <thead><tr><th>Opportunity</th><th>What we found</th><th>Decision</th></tr></thead>
  <tbody><tr><td>Software buying guide</td><td>390 est. US searches/mo; not in the first 20 results; page explains criteria, compares no vendors</td><td>Runner-up. Larger demand, but a weaker diagnosis and a full rewrite; test the comparison page first.</td></tr></tbody>
</table></div>

ガードレール

• 落ち着いた平易な文体にします。感嘆符、煽る表現、余計な言葉は使わず、文章中では全角ダッシュを使いません（seo-report のレポートタイトル規則は例外です）。重大度を示す語は、文字どおり当てはまる場合に限って使います。
• 専門用語は初出時に平易な言葉で説明します：canonical、メタディスクリプション、クローラー、301、構造化データ。
• 観察結果を原因として扱いません。類似したコンテンツと順位のばらつき、クローラーの警告、プロバイダーの結果の欠落は、ペナルティ、インデックス除外、ページの順位の理由を証明するものではありません。
• データの取得日は観察日とは異なります。順位を観察した日時を記載するか、不明と記載します。
• 被リンクや順位のデータがない場合は、「記録されたデータなし」とし、問題があるとは扱いません。
• 難易度と検索ボリュームは判断材料であり、目標ではありません。規模の小さな検索クエリでも価値の高いビジネスにとって重要な場合があり、難易度が低いからといって自動的に価値があるとは限りません。
• ツールが報告した内容と、自分で確認した内容を分け、最後のセクションで両方を明記します。