seo-aeo-audit について
seo-aeo-auditは、SEO担当者やウェブサイトチーム向けに、検索エンジンと回答エンジンでの可視性を調べるスキルです。各指摘に検証可能な根拠を求め、優先順位付きの実行計画を作成します。コンテンツ作成やページ構築は行いません。
主な機能
- 01検索・回答エンジンでの可視性監査
- 02根拠レベル別の推奨事項
- 03技術・コンテンツ・計測の確認
- 04公開サイト監査と新規サイト向けブリーフ
- 05アクセス・基準値確認用スクリプト
活用シーン
- 01流入減少や順位停滞の調査
- 02新規サイトやページのSEOブリーフ作成
- 03回答エンジンによるコンテンツ抽出性の評価
- 04根拠に基づく修正の優先順位付け
MCP 対応
接続済みのMCPを利用できます。READMEでは、一括の競合・需要データ取得先としてProwlを挙げています。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ssheleg/ seo-aeo-audit --skill seo-aeo-auditインストール後、Claude Code で/seo-aeo-auditを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
REFERENCE_INDEX.mdreferences/aeo-geo.mdagent-readiness.mdalgorithm-updates.mdarchitecture-and-equity.mdbenchmarks.mdbuild-time.mddeliverable-templates.mddemand-and-conversion.mddiscover.mdentity-and-brand.mdevidence-tiers.mdexperience-signals.mdexperiments.mdgrowth-plays.mdintent-and-content.mdlinkbuilding.mdmeasurement.mdmyths.mdonpage-checks.mdplaybooks.mdpreflight.mdprowl-mcp.mdranking-model.mdscripts.mdtechnical-checks.mdthreats-and-defense.mdtooling.mdscripts/agent_surface.pyai_panel.py詳細
seo-aeo-audit — 検索エンジンと回答エンジンでの可視性を監査し、実行計画を提示する
目的は1つです。実際のサイトを調査し、証拠を示して問題を明らかにし、優先順位を付けた変更計画を提示することです。この計画では、従来型検索(Google、Yandex、Bing)と回答エンジン(AI Overviews / AI Mode、ChatGPT、Perplexity、Claude、Copilot、Gemini、Alice AI)の両方を対象とします。
対象範囲:稼働中のサイトを監査するか、制作前のサイトについて概要を作成します。コンテンツの執筆やページの構築(またはリンクの購入)は行いません。検証済みの診断と実行可能な計画、または概要を提示して終了します。
必ず守ること
- 証拠がなければ報告しません。 すべての指摘には、観察した内容、場所(
URL、file:line、レポート名)、観察値、日付を記載します。このサイトで検証していない指摘は報告しません。「ベストプラクティスによると」は証拠ではありません。 - すべての提案に、証拠のティアを明記します(references/evidence-tiers.md を参照)。
CONFIRMED(エンジンのドキュメントで確認済み、またはこのサイトで再現済み)・STUDY(複数サイトを対象に公表されたデータ)・FIELD(単一事例の報告)・HYPOTHESIS(仮説)。HYPOTHESISがCONFIRMEDのブロッカーより高い優先順位にならないようにします。 - 処方する前に診断します。 原因が特定されるまで、修正案を計画に含めません。「スキーマを追加する」は診断ではありません。
- 神話のリストを退けます。 以下の「神話ガード」を参照してください。ここにある施策を推奨すると、クライアントの予算を無駄にします。これは単なる好みの問題ではなく、欠陥です。
- 欺瞞的な手法は決して推奨しません。 クローキング、合意を捏造するネットワーク、レビューの操作、競合他社を不正に排除する行為、クリックシグナルの偽装は、計画に含めません。このスキルでこれらに触れるのは、references/threats-and-defense.md に限り、検知して防御する対象として扱います。
- 確認できなかった項目を明記します。 GSC にログインできなかった場合、それはレポートの不足事項であり、黙って省略してはいけません。
- 測定値と推定値を決して混同しません。 1つの成果物に両方が含まれる場合(リンク構築用の CSV は常に該当します)、
source列で区別し、測定していない行のボリューム欄は 空欄にし、ゼロにしません。0は「測定した結果、需要がなかった」と読めますが、空欄は「誰も確認していない」と読めます。この違いは、とりわけ他の人が予算を使って実行する作業で重要です。 - 各計測手段の盲点を把握し、出力で明示します。 ルール1と7が規定するのは あなたが 書く内容です。あなたが確認する前に、情報を混在させたり省いたりするツールまでは見抜けません。よくあるケースが2つあります。静的な取得では、CMS が JavaScript で挿入する JSON-LD を確認できません。そのため、Yoast/RankMath/AIOSEO を使用するサイトで「スキーマが見つからない」とするのは誤った指摘です。
scripts/page_audit.pyはすべてのスキーマ一覧の横に注意書きを表示し、描画を確認した後にのみ、存在しないと報告できます。GA4 の同意モードによるモデリングでは、観測された行動と推定された行動が1つの数値にまとめて返されます。3つの有効化条件、画面に表示されるインジケーター、観測値のみを使う場合の代替方法については、references/measurement.md の J1 を参照してください。このルールは一般化できます。計測手段が何も検出しなかったことを指摘する前に、その計測手段がそもそも対象を検出できたかどうかを確認します。
ステップ 0 — モードを判定し、二度と尋ねない
まず調査し、その後に実行します。次の順に進めます。
- 監査かブリーフか。 まだ公開されていないもの(新しいサイト、セクション、ランディングページ)には、ブリーフを作成します。build-time.mdに従い、
docs/seo/brief-<YYYY-MM-DD>.mdに記述して終了します。調査結果も、神話項目もありません。 docs/seo/(またはユーザーが指定したパス)を読みます。前回の監査が存在する場合は、今回の作業を再監査とし、差分を確認して変更点から報告します。- アクセスできるものを確認します。ライブサイト、ステージング環境、
robots.txt、sitemap.xml、Search Console / Bing / アナリティクス、クロールのエクスポート、サーバーログ、接続されている MCP などです(ベンダーごとのライセンスがなくても、一括で競合データと需要データを取得できる方法については、Prowlを参照してください)。 アクセスを確認し、決めつけないでください (preflight.md)。 - 作業内容が変わる場合に限り、ユーザーとスコープを決めます。サイト全体、1つのテンプレート、1つの質問、またはリンク構築用データの抽出から選びます。これは診断ではなく成果物であり、Search Console があってもなくても実施でき、専用のファイルがあります(linkbuilding.md)。
- 状況を3行で報告します。利用できる入力、欠けている入力、スコープを示してから作業を開始します。各実行の最後に、次のアクションを必ず1つだけ提案します。
python3 "$SKILL_DIR/scripts/preflight.py" --site sc-domain:example.com --origin https://example.com
どのゲートで失敗したかを、login、quota-project、api-not-enabled、scope、permissionのように示します。それぞれ失敗の理由は異なりますが、大半は403を返します。確認する項目と、あなた自身で確認する必要がある残り半分については、preflight.mdを参照してください。
preflight が成功しても、手順を実施したことにはなりません。
$SKILL_DIRを解決し、利用する前にその場所を確認してください。Claude Code プラグインでは${CLAUDE_PLUGIN_ROOT}/skills/seo-aeo-audit、それ以外の場所ではこのファイルが置かれているディレクトリです。scripts.mdには、どちらの形式も、すべての呼び出し方法も記載されています。
No such file or directoryは、機能が存在しないという意味でも、何も言わずに作業を進めてよい理由でもありません。 これはツールにアクセスできないという意味です。そのため、本来ツールで確認する項目はすべて、証拠の序列で最下位の段階に下がり、その段階によってエビデンスのティアも上限が決まります。3行の状況報告にその旨を記載してください。監査が黙って手作業に切り替わると、結論の価値が変わってしまいます(譲れない条件 #6)。
アクセスのルール:デフォルトは読み取り専用です。このセッションで明示的な承認を得ずに、フォームの送信、インデックス登録のリクエスト、リンクの否認、ライブプロパティの変更を行ってはいけません。これらは外部に影響する操作です。
ステップ 1 — 意見を交える前にベースラインを記録する
後から行うすべての主張を測定できるよう、日付を添えて次の項目を記録します。
- 国別・デバイス別のオーガニッククリック数/表示回数/平均掲載順位(過去 12 か月分、GSC + Bing)、および該当する場合は下落または停滞の期間;
- J3b のベースライン: 検索エンジンのホストと言語・地域別のリファラル数、ブランド検索と並べた直接流入/リファラーなしの数(AEO の変更前)、テンプレートごとのインデックス数と公開数の比率、分析データで把握できるバックエンド注文の割合。Bing の確認または IndexNow キーが未設定なら、データの欠落です;
- テンプレートごとのインデックス登録 URL 数と公開 URL 数(
site:は目安にすぎず、数値は GSC の「ページ」レポートで確認します); - 売上またはコンバージョン数上位 20 ページと現在の掲載順位;
- AI サーフェスのベースライン:references/aeo-geo.md にあるブランドとカテゴリのプロンプトセットを、アクセス可能な各エンジンで実行し、回答をそのまま記録します;
- 実際にサイトをクロールする AI クローラー(サーバーログを確認し、逆引き DNS を正引きで確認してなりすましを除外)と、分析データに表示される AI リファラー;
- 更新タイムライン:原因について仮説を立てる前に、グラフ上のすべての変化の日付を references/algorithm-updates.md の情報と照合します。
ファーストパーティデータにまったくアクセスできない場合は、その旨を 3 行のステータスに記載し、サードパーティのインデックスから確認できる情報に切り替えます。すなわち、現在のランキング、規模を定めた競合群とのリンクプロファイルの比較、対象フレーズに需要があるかどうかです(prowl-mcp.md)。この場合、ベースラインの評価上限は STUDY となり、「このページがインデックスに登録されないのはなぜか」という問いには答えられません。ただし、新規立ち上げと下落のどちらなのかは判別でき、両者には正反対の対策が必要です。
サイトでトラフィックの減少が報告されている場合は、まずレポートの不具合とランキングの低下を切り分けます。GSC レポートが停止していれば、クリック数はある日付で止まったままですが、実際の下落があれば新たな減少データが引き続き記録されます(gsc_pull.py は report-stale を出力します)。アルゴリズムが原因だと診断する前に、GA4 のセッション数、サーバーログ、および有害な SERP を除外するガードを通過した独立した順位トラッカーを照合します。
ステップ 2 — 10 のトラック
対象となるトラックをすべて実行します。それぞれに、具体的な確認項目、2026 年時点で注意すべき点、記録すべき証拠をまとめた個別ファイルがあります。
| # | トラック | 回答する問い | 参照 |
|---|---|---|---|
| A | アクセスとインデックス登録の経済性 | ボットは取得・レンダリングでき、そのコストも許容範囲ですか? クロールバジェットはどこで消費されていますか? | technical-checks.md |
| B | 正規化と重複 | 正規 URL はどれで、エンジンもそれに同意していますか? hreflang も含めて確認します。 | technical-checks.md |
| C | アーキテクチャとリンクエクイティ | 重要なページはオーソリティ、階層の深さ、クロール頻度を確保できていますか? | architecture-and-equity.md |
| D | 検索意図と SERP との適合性 | 各ページは SERP に合致していますか? ページ同士でカニバリゼーションが起きていませんか? | intent-and-content.md + onpage-checks.md |
| E | コンテンツの価値 | AI には再現できない、上位表示される理由はありますか? また、ひとりの書き手が書いたように読めますか? | intent-and-content.md + ranking-model.md |
| F | 抽出可能性と AEO/GEO | アンサーエンジンは回答を取得し、読み取り、引用できますか? | aeo-geo.md |
| G | エンティティとブランドの合意 | モデルは一貫してブランドを認識し、その名前を挙げていますか? | entity-and-brand.md |
| H | エクスペリエンス、コンバージョン、アトリビューション | ユーザーはここでタスクを完了しますか、それともすぐに離脱しますか? コンバージョンにつながり、計測されていますか? | experience-signals.md + demand-and-conversion.md |
| I | リスクと脅威 | ペナルティ、ハイジャック、インジェクション、削除要請。 | threats-and-defense.md |
| J | 計測 | 施策が効果を上げたかどうか、誰かが判断できますか? | measurement.md |
| K | エージェント対応のインターフェース | マシンはここで情報を発見し、認証を受け、取引できますか? | agent-readiness.md |
トラック K は条件付きです(エージェントが購入、問い合わせ、または自動化できるサイトが対象です)。
存在は CONFIRMED、効果はほぼ HYPOTHESIS であるため、その大半は
実験項目になります(agent-readiness.md)。
Discover は 10 のトラックのいずれにも含まれず、トラック A の一部でもありません。そのチェック項目に、 レンダリングの可否を判定するものはありません。GSC の Discover レポートで重要な 流入元だと確認された場合は、11 番目の確認項目として discover.md を実施してください。
順位低下の原因を診断する前に必ず、日付の照合と更新への対応に関する プロトコルを references/algorithm-updates.md で実施してください。 「コアアップデートの影響を受けた」は調査結果ではなく、記録されている GSC の停止事例の半数は ロールアウトと同時期に発生しています。
各トラックは、診断作業と網羅性を確保するための機械的な一括確認の 2 つの部分から成ります。A/B については technical-checks.md §A3、 D/E については onpage-checks.md を参照してください。まず診断を行い、 その後、一括確認で見落としやすい問題を検出します。確認可能な影響がある項目だけを 調査結果の表に記載します。
順序が重要です。 トラック A の阻害要因(サイトを取得できない、または
レンダリング前のソースに noindex がある)があれば、ほかの調査結果はすべて無意味になります。
手動による対策は対象範囲を限定する乗数であり、決して二者択一のものではありません。
種類、影響を受ける URL パターン、対象面、重大度、範囲を記録してください。
SITEWIDE の対策が解除されるまで、あらゆる改善効果がゼロになります。解除を最優先事項にすることも変わりません。
一方、PARTIAL の対策(たとえば /spam/* に一致するもの)は、その範囲内だけをゼロにします。
/checkout で確認された認証や可用性の修正は、依然として有効で、実施され、
対策の存在を添えて報告されるべきであり、その下に埋もれさせてはいけません。
影響を受けるパターンの外にある依存作業まで止めるのは、Google が科していないペナルティをでっち上げることです。
F/G に時間をかける前に、A → B → C の順で進めてください。
エビデンスの段階 — 手軽さではなくエビデンスの強さに基づいて順序付けられており、サーバーログから手動での取得までを網羅します。各段階とその振り分けについてはtooling.mdを参照してください。実際に到達できる最も高い段階を使い、調査結果がどの段階に基づくものかを明記してください。プロパティへのアクセスがない公開情報のみの監査も有効な作業ですが、そのインデックス登録や検索クエリに関する調査結果は観測ではなく推論であり、それに応じて段階付けされます。
スキルには9つのスクリプトが含まれています — preflight.py、gsc_pull.py、page_audit.py、url_inspection.py、agent_surface.py、psi_pull.py、sitemap_audit.py、bwt_pull.py、ai_panel.pyです。それらの実行方法と、調査結果が実在するかどうかを左右する4つの落とし穴 — レンダリング後のHTMLとサーバーHTMLの違い、JSON配列の形式、切り詰めによって件数に基づく調査結果が失われること、重大度ではなくエビデンスの段階がトリアージに反映されること — についてはscripts.mdを参照してください。
ステップ 3 — トリアージ
まず、各トラックの結果を相互に照合します。 10 個のトラックが互いの結果を知らないまま 10 組の所見を出し、計画はそれらを 1 つの答えとして扱います。つまり、結果が揃ったというだけで入力を信頼する収束です。順位のないリストを並べ替えることと、その中の 2 つの項目を同時に実行できないと気づくことは同じではありません。
スコアを計算する前に、次の 4 点を確認します。
- 同時に実行できない 2 つの推奨事項。 D は 2 つのページが共食いしているため統合すべきだと述べています。C は、より深いページに評価が集まると述べています。該当する組み合わせを挙げ、どちらを優先するか、その理由を説明してください。両方を後から目にする読者には判断できません。
- 1 つの根本原因に 2 つのトラック名が付いているケース。 レンダリングを妨げられたテンプレートが、A、F、H の所見として現れます。3 つの項目に対して修正は 1 つだけで、計画を膨らませ、優先度を分散させます。
- 1 つの主張キーに対する、互換性のない 2 つの値。 行を
(subject, predicate, scope, time, instrument)をキーとする主張として比較します。互換性のない値が、同じスナップショットにおける 1 つの対象の同じ述語に対して現れた場合に限り、矛盾があります。異なる述語について、ある URL がCONFIRMEDとHYPOTHESISであっても、何についても食い違ってはいません。HTTP ステータスは確認済みである一方、ランキングの原因は仮説のままであり得ます。段階が表すのは調査手段であり、サイトではありません。また、低い段階が優先されないのは、1 つの述語の範囲内に限られます。同じキーで値が異なる場合は、裁定が必要です。2 つの調査手段が食い違う場合は、調査手段間の不一致として記述します。同じ調査手段が自らと食い違う場合は、レポートの作成前に解決します。 - 隣接するトラックの結果から所見があるはずなのに、何も返さなかったトラック。見落としと判断する前に、述語を確認してください。 E が薄いと判定したページについて、F が抽出可能性の問題を見つけなかった場合、これは互換性のある 2 つの観察結果です。薄いかどうかはコンテンツの深さを評価し、抽出可能かどうかは機械的な性質を評価します。短いページでも問題なく抽出できる場合があります。「一方が適切に調べていない」という判断が当てはまるのは、両方のトラックが同じ述語を測定し、一方の結果が空だった場合に限られます。異なる特性を無理に一致させると、実際のデータが失われます。
どちらの場合も、結果を記述してください。Cross-track: clean とするか、該当する組み合わせと裁定を記載します。実行していない場合と区別できないほど何も示さないチェックは、証拠になりません。個々のトラックがすべて正常だったため、この点が最も見落とされやすいのです。
次に、すべての所見に順位を付けます。順位のないリストを提示してはいけません。
4 つの軸。単一のスカラー値は使いません。 2 つの所見を分ける最初の軸で順序を決めます。順序は impact · irreversibility · uncertainty · coordination です。effort は記録しますが、順位付けには使いません。積の値には異議を唱えられませんが、各軸には異議を唱えられます。定義は
deliverable-templates.md
を参照してください。
出力を次の 4 つのバケットに、この順序で分類します。
- ブロッカー — インデックス登録、ペナルティ、乗っ取り、到達不能な収益ページ。
- 流出 — クロールバジェット、評価の分散、カニバリゼーション、閲覧バジェットの浪費。
- 改善機会 — 検索意図への適合、情報利得、抽出可能性、エンティティのコンセンサス。
- 実験 — エビデンス段階のロールアウトポリシーによってここに振り分けられるもの(アクションのリスク × 因果関係の裏付け。段階だけでは判断しません)。設計については references/experiments.md を参照してください。HYPOTHESIS をサイト全体に適用してはいけません。
ステップ 4 — 成果物
references/deliverable-templates.md のひな形をもとに、以下のファイルを作成します。 既存の監査レポートや計画を、断りなく上書きしてはいけません。日付を付けた新しいファイルを作成するか、先に確認してください。
docs/seo/audit-<YYYY-MM-DD>.md— 調査結果を記載します。各項目には、観察結果の出典であり、その階層の上限を決めるエビデンスの段階を付記します (tooling.md)。docs/seo/plan-<YYYY-MM-DD>.md— 変更計画です。変更ごとに、正確な対象、仕組みとその背後にある階層、期待される効果、ロールバック方法を記載します。docs/seo/experiments.md— 単一の監査を超えて継続するため、日付を付けずに追記します。計画に「実験」枠ができたら必須です。「確定」未満の項目は、すべてここに記載します。
エグゼクティブサマリーのルール:箇条書きは最大 5 項目とし、上位 3 つの阻害要因、期待される効果の規模、最初に必ず行うべきことを含めます。技術的な知識がある非専門家を対象に書き、専門用語は初出時に説明します。
ステップ 5 — 検証してからフォローアップ
- 各変更について、公開前に検証方法を明記します(GSC のページレポートで X から Y へ変化すること、URL 検査のライブテストで正規 URL が承認されたと表示されること、ログで Googlebot が
/_next/static/を取得していること、プロンプトのテストセットで 10 件中 N 件の回答がブランド名を挙げること)。 - 再確認までの期間は、実態に即して設定します。インデックス登録は 2~8 週間、正規 URL グループの分割は修正後最大 2 週間、コアアップデートの影響は 1 四半期、AI の学習への影響は数か月です。日付を約束できない場合は、その旨を伝えます。
- 再監査では、前回のレポートとの差分を取り、以前の調査結果ごとに、新しいエビデンスを添えて
fixed/partially fixed/unchanged/regressedのいずれかを付けます。
誤情報ガード — これらを計画に含めないでください
反証済みの主張 33 件のうち、特に多く問い合わせのある 14 件です。それぞれ 2026 年のエビデンスで反証されています。反証の根拠と有効な代替策を含む全リストは references/myths.md にあります。以下の短いリストにない戦術について質問に答える前に、必ず読んでください。
- ランキングや引用を促す手段としての
llms.txt· GEO 戦術としての HTML ページの Markdown ミラー · 「検索システム向けにコンテンツを分割する」 · 「AI 向け」の文章への書き換え · AI の引用を促す手段としてのスキーマの量 · リッチリザルトを目的とした FAQPage マークアップ(Google では廃止済み) · ランキング向上を目的とした AMP · 公開日の更新を鮮度シグナルとして扱うこと · 「とにかくページを増やす」 · サードパーティの有害性スコアを根拠にしたリンクの否認 · 「AI での可視性」を単一の KPI として購入すること · AEO 対策としての、自社に都合のよい「[カテゴリ] のおすすめ」まとめ記事 · 成長戦略としての AI コンテンツの大量生成 · クロールバジェットを守る目的でトラッキングパラメーター付き URL をDisallowでブロックすること(仕組みの説明は technical-checks.md A2 を参照)。
これらについてユーザーから質問されたら、エビデンスが示す内容を率直に伝え、有効な最も近い代替策を提案して先に進みます。
llms.txt と Markdown の同内容ファイルはエージェント向けであり、ランキング向けではありません:
myths.md、この 2 つにある境界。
トリガー
「AEO 監査」/「аудит по SEO и AEO」、「AI での可視性の監査」、「トラフィックが落ちた理由」、「なぜランキングされないのか」/「почему нет позиций」、「ChatGPT が自社を引用しない理由」/「почему нас не цитирует ChatGPT」、「インデックス登録の問題」/「проверь индексацию」、「SEO 変更計画」/「план правок по SEO」、「Google コアアップデート」/「апдейт гугла」、「リンク構築用キーワード」/「ключи для линкбилдинга」。
参考資料インデックス
REFERENCE_INDEX.md を読み込み、トラック、スイープ、計測、成果物に関する詳細な参考資料を確認します。