seo-site-health-audit

SEO サイトヘルス監査

Ahrefs Site Audit（または同等のクローラー）で見つかった技術的な SEO の問題を、問題の件数や重大度ラベルではなく、ランキングとトラフィックへの影響に基づいて優先順位付けします。特定の技術スタックには依存しません。ビジネスへの影響に対応付けた、優先順位付きの修正バックログを作成します。

---

使用する場面

• Ahrefs Site Audit またはその他のサイト全体のクロールを実行した後
• 技術的な問題の長いリストを確認し、優先順位を付ける必要がある場合
• 技術 SEO スプリントの範囲を決める場合
• リリース前、または移行後の技術的な検証
• 四半期ごとの技術的な健全性チェック
• 開発者の作業時間が限られており、最も効果の高い修正を選ぶ必要がある場合

使用しない場面

• クロール自体の実行（クローラーツールを直接使用してください）
• 特定のトラフィック減少の原因究明（seo-traffic-diagnosis を使用してください）
• 単一ページの監査（seo-onpage を使用してください）
• 技術戦略やスキーマ設計のみを行う場合（seo-technical を使用してください）

---

必要な入力

• Ahrefs Site Audit（または同等のもの）によるクロール結果
• Search Console のカバレッジと Core Web Vitals のデータ
• プロパティのオーガニックトラフィックの状況（トラフィックを獲得しているページ）
• ステークホルダーが対応に使える時間と、開発者の作業可能量
• クロールを Ahrefs 経由で取得する場合に限り、Ahrefs MCP が接続されていることの確認。同等のクローラーから提供されたエクスポートがあれば、最初の入力はそれだけで満たされます。

---

フレームワーク：重大度ではなく SEO への影響で優先順位を付ける

クローラーは問題に「重大」「警告」「通知」のラベルを付けます。これらのラベルは参考になりますが、それだけでは十分ではありません。どちらも「重大」とラベル付けされた問題でも、プロパティへの実際の影響は大きく異なる場合があります。

3 つの軸で優先順位を付けます。

軸 1：ページ単位のトラフィックへの影響

その問題は、オーガニックトラフィックに大きく貢献しているページに影響しますか。それとも、そうでないページに影響しますか。

トラフィックがゼロのタグアーカイブにある「重大」な問題より、トラフィック上位 10 ページのランディングページにある「警告」の方が優先度は高くなります。

影響を受ける URL を分類します。

• Tier 1： オーガニックトラフィックが多い順に上位 10% のページ
• Tier 2： ランキングはしているものの、まだ大きなトラフィックを獲得していないページ（検索結果の 2～3 ページ目）
• Tier 3： 存在するものの、意味のあるランキングを獲得していないページ

多くの場合、Tier 1 の修正は Tier 3 の修正の 10 倍の価値があります。

軸 2：影響の仕組み

その問題は実際にランキングやトラフィックを動かしますか。「重大」な問題の中には、見た目の問題や理論上の問題もあります。

各問題を HIGH、MEDIUM、LOW のいずれかに分類します。references/issue-impact-table.md に、問題の種類ごとのグレードと各グレードの定義が記載されています。都度判断するのではなく、そこで問題を確認し、指定されたグレードを使用してください。

参照資料が扱う問題の種類は、確認する順に、インデックス登録可能性、クロール可能性、レンダリング可能性、Core Web Vitals、構造化データ、内部リンクの整合性、hreflang、ページ上の要素、画像、セキュリティと信頼性です。また、専用の作業を行う価値がほとんどない問題を対象とした、保留またはスキップのリストも記載されています。

グレードは問題の種類ごとに異なります。インデックス登録可能性の項目はほとんどが HIGH ですが、内部リンクの整合性は項目ごとに MEDIUM から LOW まであります。種類全体ではなく、項目ごとにグレードを確認してください。

Tier 1 の URL にある HIGH グレードの問題から先に修正します。

軸 3：作業量

5 分で修正できる問題もあれば、複数のスプリントを要するプロジェクトもあります。

• S（小）： 設定変更、単一テンプレートの編集、サイトマップの再生成
• M（中）： テーマまたはコンポーネントの変更、リダイレクトマップの作業、テンプレートレベルの修正
• L（大）： アーキテクチャの変更、プラットフォームの移行、フレームワークの移行、スキーマの全面的な見直し

---

トリアージマトリクス

3つの軸を組み合わせて優先度スコアを算出します。

ここでのメカニズムとは、問題影響度テーブルで各問題に付与される HIGH／MEDIUM／LOW の評価です。3つの評価すべてに行があります。参照テーブルでは多くの問題タイプが MEDIUM と評価されているため、Tier 1 ページにおける MEDIUM の問題にも優先度区分が必要です。

Tier	メカニズム	工数	優先度
Tier 1	HIGH	S	P0（今週中に対応）
Tier 1	HIGH	M	P1（今スプリント中に対応）
Tier 1	HIGH	L	P2（プロジェクトとして計画）
Tier 1	MEDIUM	S	P1
Tier 1	MEDIUM	M	P2
Tier 1	MEDIUM	L	P3
Tier 1	LOW	S	P3（都合のよいときにまとめて対応）
Tier 1	LOW	M-L	根拠が得られるまで保留
Tier 2	HIGH	S	P1
Tier 2	HIGH	M-L	P2
Tier 2	MEDIUM	S	P2
Tier 2	MEDIUM	M-L	P3
Tier 3	HIGH	S	P3
Tier 3	その他すべて	すべて	保留

MEDIUM の行には、次のルールが適用されます。同じ Tier と工数の HIGH の問題より、MEDIUM の問題は優先度を1段階下げます。参照テーブルで LOW-MEDIUM と評価される問題については、URL が Tier 1 の場合は MEDIUM の行を、それ以外の場合は LOW の行を適用します。

P0-P1 の作業には、チームの注意を優先的に割り当てます。P2 はロードマップに追加します。P3 は定期メンテナンスでまとめて対応します。保留は、優先度を下げる判断を正直に示すものです。

---

ワークフロー

1. クロール結果を取得します。 Ahrefs Site Audit、Search Console、Core Web Vitals を使用します。
2. URL を Tier 分けします。 オーガニックトラフィックデータを使用します。影響を受ける URL をすべて Tier 1、2、3 のいずれかに分類します。
3. 各問題をメカニズム別に分類します。 references/issue-impact-table.md で HIGH、MEDIUM、LOW の評価を確認します。
4. 修正タイプごとに工数を見積もります。 類似する修正をまとめて工数を見積もります。
5. トリアージマトリクスを適用します。 P0-P3 または保留に分類します。
6. 修正をクラスター化します。 工数を共有する修正をまとめます。1つのテンプレート変更で何百もの問題を解決できる場合があります。
7. バックログを作成します。 まず P0、次に P1 の順に並べます。修正内容、担当者、予想される影響を追加します。
8. 測定方法を追加します。 修正が機能したことを確認できる指標は何でしょうか。リリース前に定義します。
9. 引き継ぎます。 出力内容を開発バックログと seo-audit-orchestration に反映します。
10. 修正後に再クロールします。 問題が解決したことを確認し、バックログを更新します。

---

注目すべき効果の大きいクラスター

次のパターンは、修正すると大きな効果が得られることがよくあります。

• リダイレクトチェーンを一括で整理します。 サイトマップの更新と内部リンクの更新だけで、何千もの「リダイレクトチェーン」の問題を一度に解決できます。
• テンプレートに意図せず noindex が設定されています。 コードを1行変更するだけで、何百、何千ものページを再インデックスできます。
• サイトマップの鮮度を保つパイプラインです。 サイトマップ再生成ジョブが壊れると、Search Console に正しい URL が認識されるかどうかに依存するすべての問題に影響します。
• ファセットナビゲーションの canonical に一貫性がありません。 テンプレートレベルの canonical 修正で、eコマースのカテゴリーツリー全体にわたる重複コンテンツの問題を解決できます。
• robots.txt を復旧します。 本番環境の robots.txt を元に戻すと、サイト全体の低下を数日で回復できる場合があります。
• Hreflang ブロックを修正します。 テンプレートを1つ変更するだけで、多言語サイト全体の hreflang の問題を解決できます。
• アセットパイプラインで画像を最適化します。 ビルドプロセスを修正すると、何千もの個別アセットの問題を解決できます。

これらのパターンを見つけたら、個々の問題が小さく見えても優先してください。クラスター全体で大きな効果が得られます。

---

失敗パターン

• 重大度を盲信する。 「critical」というラベルが付いたものをすべて本当に重大だと扱います。そうでないものも多くあります。メカニズムとトラフィックへの影響に基づいてトリアージします。
• 問題の件数を数える。 トラフィックやランキングへの影響を示さずに「1,200件の問題を修正した」と報告しても、エンジニアリングの信頼性を損なうだけです。
• ティア分けを省略する。 Tier 1の問題5件より先にTier 3の問題100件を修正するのは、忙しさを演出するだけの作業です。
• 単一の問題だけを修正する。 問題の大半はまとまって発生します。同じ根本原因を持つ800件のリダイレクトチェーンがあるのに、そのうち1件だけを修正するのは、作業単位として適切ではありません。
• 再クロールしない。 検証なしに「修正済み」としても、疑念が残ります。大規模な修正の後は必ず再クロールしてください。
• Search Consoleを無視する。 Ahrefsが把握するのは、そのクローラーが見つけたものです。Search Consoleには、Googleが実際に認識し、インデックスに登録した内容が反映されます。両方を使ってください。
• Core Web Vitalsをチェックリストのように扱う。 CWVはフィールドデータであり、ラボデータではありません。合成スコアではなく、実際のユーザー体験を最適化してください。
• 見栄えのために影響の小さい問題を修正する。 トラフィックが増えない技術レポートがきれいになっても、誰の役にも立ちません。
• 測定しない。 修正を始める前に、その修正が成功したことを証明する指標を定めてください。

---

出力形式

次の内容を含む、サイト健全性トリアージ文書を作成します。

1. 概要。 問題の総数、優先して修正する上位3つのクラスター、期待される影響、またはデータ利用可否ルールに従って不足情報を明記します。
2. URLのティア分け。 URLの分類方法とティアごとの件数。
3. 問題の分類。 メカニズムのカテゴリ別、ティア別、優先度区分別の件数。
4. 優先順位付きバックログ。 P0〜P3の順に記載します。各項目に、問題、影響を受けるURL、修正内容、工数、期待される影響、担当者を含めます。
5. 修正クラスター。 共通の修正方法を持つ問題をグループ化します。効果の高いものを先頭にします。
6. 測定計画。 修正またはクラスターごとに、成功を証明する内容を示します。
7. 方法論。 使用したクローラー、日付、対象範囲、注意事項。

長さ：5〜12ページとバックログのスプレッドシート。

---

必要なデータを利用できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、正式に認められる出力は、不足している情報を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載してください。成果物を完成させるために必要な数値を捏造、推定、または補間することは、いかなる場合も認められません。不足情報を明記すれば、それで完全な回答となります。

---

参照ファイル

• references/issue-impact-table.md - よくあるクローラーの問題をメカニズムの評価と一般的な修正工数に対応付けた一覧表に加え、クラスターの兆候と保留またはスキップする問題の一覧を記載しています。すべての問題評価の正本となるファイルです。上記のトリアージマトリックスでは、評価、ティア、工数を組み合わせて優先度区分を決定します。