internal-link-audit

内部リンク監査

サイトの内部リンクを監査し、根拠を明示した改善計画を作成します。次の3つの問いに答えてください。

1. 内部リンク経由では到達しにくい、または到達できない重要なページはどれですか？
2. どの内部リンクがリンク切れ、リダイレクト、説明不足、またはその他の点で非効率ですか？
3. サイト構造をより明確にするには、どのような文脈に即したリンクやハブの関係が必要ですか？

内部リンクをノルマとして扱わないでください。リンク元、リンク先、ユーザーの導線に関連性がある場合に限り、リンクを推奨してください。

ルールの根拠

分析および最終出力では、次の根拠の分類を明確に区別してください。

• Semrush が裏付けるガイダンス： 内部リンクは、検索エンジンによるページの発見、階層や文脈の伝達、オーソリティの分配に役立ちます。Semrush は、説明的なアンカーテキスト、関連性のあるハブ・アンド・スポーク構造、新しいコンテンツへの文脈に即した被リンクを推奨しています。
• MCP の契約要件： プロジェクトに基づく調査結果には、公式 Semrush MCP が返すレポートとフィールドのみを使用します。製品 UI の機能名は MCP レポート名ではありません。
• 業界のヒューリスティック： ビジネス上の重要度、ユーザーへの影響の見込み、または改善にかかる労力に基づく優先順位付けは、提供されたファーストパーティデータの裏付けがない限り、アナリストの判断です。
• ユーザーが設定するデフォルト値： 上限、サンプル数、優先度の重み付けは、サイトの規模、目標、利用可能なデータに応じて調整する必要があります。これらを普遍的な SEO のルールとして扱わないでください。

入力

次の項目を一度に尋ねてください。

• ルートドメイン
• ビジネス上、特に重要なページまたはページの種類
• 既知の移行、リデザイン、またはサイト構造上の制約
• ユーザーがプロジェクトに基づく完全な監査を希望するか、提供されたエクスポートデータまたは手作業によるサンプル監査を希望するか

Semrush API キーを貼り付けるようユーザーに求めないでください。公式 MCP が Semrush の認証を使用します。

公式 Semrush MCP のワークフロー

パラメーターがすでに判明している場合を除き、各レポートの前にディスカバリーとスキーマの取得を行ってください。

1. projects を呼び出します。
2. list_projects を検出し、そのスキーマを取得して実行したうえで、指定されたドメインと完全に一致するものを照合します。siteaudit が有効になっていることを確認してください。
3. site_audit を呼び出します。
4. プロジェクト ID を指定して snapshots を検出・実行します。最新の完了済みスナップショットを選択し、その snapshot_id と終了日を保持します。
5. クロールのステータス、クロール済みページ数、問題の件数、リダイレクト数、クロール深度の分布を取得するために info を実行します。
6. 有効な問題 ID とその定義を取得するために meta_issues を実行します。これはカタログであり、すべての問題がサイトに存在することを示す証拠ではありません。
7. 現在の問題件数を info.defects から読み取ります。関連する問題のうち、件数がゼロでないものごとに、プロジェクト ID、問題 ID、スナップショット ID、上限を指定して issue_details を実行します。必要に応じてページネーションを行ってください。
8. クロール済み URL を正確に指定してページ単位で確認する必要がある場合に限り、page_list を使用してから page_info を使用します。

テスト済みの公開 MCP が提供するのは、問題別の Site Audit レポートであり、文字どおりの内部リンクのテーマ別レポートではありません。実際の契約テストで検出された関連する問題 ID には、内部リンク切れ、サイトマップまたは Google Analytics に含まれる孤立ページ、ページのクロール深度、内部リンクが1つしかないページ、リダイレクトチェーン、恒久的および一時的なリダイレクト、nofollow の内部リンク、アンカーテキストのないリンク、説明的でないアンカーテキストが含まれていました。これらの ID を恒久的な契約としてハードコードせず、常に最新のカタログを再検出してください。

プロジェクトへのアクセスは読み取り専用です。プロジェクトの作成、クロール設定の変更、Analytics の接続、新しい監査の実施を約束してはいけません。一致するプロジェクトまたは完了済みのスナップショットがない場合は、その制約を明示し、フォールバックの手順を使用してください。

アクセスと根拠に関するガードレール

• 実行前に、Semrush のクエリで API ユニットを消費する場合があることをユーザーに伝えてください。問題を特定できる最小の結果セットから始め、ユーザーが網羅的な行を求める場合に拡張してください。
• issue_details の結果が空の場合、選択したスナップショットに、その問題に該当する返却済みの発生箇所がないことを意味します。これをツールの失敗と見なしたり、例を捏造したりしないでください。
• プロジェクトがない、Site Audit ツールが有効でない、スナップショットがない、フィールドが利用できない、または実行エラーが発生した場合、そのデータ分岐だけを終了してください。何を確認できないのか説明してください。
• サンプル、サイトマップのみ、または手動で提供された URL リストから、サイト全体の網羅状況を推測しないでください。
• 実行したレポートに該当フィールドが実際に含まれていない限り、Site Audit がオーガニックトラフィック、コンバージョン、キーワード検索ボリューム、アンカーテキストの分布、または完全な被リンクグラフを返すと主張しないでください。

フォールバックの優先順位

利用可能な中で最も強力な情報源を使い、出力内でその情報源を明記してください。

1. Site Audit の完了済みスナップショットがある既存の Semrush プロジェクト。
2. ユーザーが提供した Semrush Site Audit エクスポート。
3. クローラーのエクスポートとサイトマップ、および提供されている場合は Analytics または Search Console のランディングページデータ。
4. サイトマップと、ユーザーの重要なページを中心とした手動サンプル。
5. ユーザーが提供した URL リスト。

提供されたデータがサイト全体を網羅していると実証できない限り、レベル 3～5 はサンプルとして明記してください。

ワークフロー

1. 網羅状況とアーキテクチャを把握する

以下を記録してください。

• ドメインと選択したスナップショットの日付。
• 監査のステータスとクロールされたページ数。
• 利用可能な階層の分布。
• ユーザーから提供された重要なページ。
• データソースと網羅状況の制限。

アーキテクチャの推測は、観測したナビゲーション、URL、サイトマップ、または提供されたドキュメントのみに基づいてください。階層がフラットだからといって、それだけで検索エンジンがサイトを理解できないと証明されるわけではありません。

2. 孤立ページや内部リンクが少ないページを見つける

孤立ページとは、特定に使用したデータセット内に、クロール可能な内部リンクからの流入がないページです。Site Audit では、サイトマップまたは連携した Analytics データに基づく別個の孤立ページ関連の問題が表示される場合があります。それぞれの対象範囲は異なるため、情報源を報告してください。

返された URL ごとに、そのページを次のいずれにするべきか判断してください。

• 文脈上関連するページまたは適切なハブページからリンクする。
• 現行の相当ページに統合する、またはリダイレクトする。
• 検索対象から意図的に除外する。
• コンテンツ、トラフィック、コンバージョン、被リンクを確認したうえで削除する。

Semrush の編集ガイドラインでは、新しいコンテンツを公開する際、文脈に即した流入リンクを 2～3 本設けることが推奨されています。これは編集上の目安として扱い、既存のすべての URL に対する自動的な失敗基準や、ランキング改善の保証として扱わないでください。

ファーストパーティデータまたは実行した Semrush のデータでトラフィックが実際に確認できない限り、そのページを「トラフィックの多い孤立ページ」と呼ばないでください。

3. リンク切れとリダイレクトを確認する

issue_details から返されたすべての発生箇所について、情報がある場合は、ソース URL、リンク先 URL、HTTP ステータスまたは問題の詳細、問題 ID、スナップショットの日付を保持してください。

以下のいずれかを推奨してください。

• ソースのリンクを正しい有効なリンク先に更新する。
• 真の代替先があり、より広範な被リンク参照からも必要性が認められる場合は、古いリンク先をリダイレクトする。
• 有用なリンク先がない場合は、リンクを削除する。
• 回避可能なリダイレクトチェーンを経由している内部リンクは、最終 URL に更新する。

恒久的な移転には 301 または 308、一時的な移転には 302 または 307 を使用してください。一時的なリダイレクトはリンクエクイティを本質的に引き継がないと主張しないでください。

4. クロール深度を確認する

分布には info.depths を使用し、影響を受ける URL の特定には、info.defects にある現在の深度関連の問題と issue_details を使用してください。Semrush Site Audit は、クリック数が 3 回を超えるページにフラグを付ける場合がありますが、これは製品上のチェックであり、普遍的なランキングの法則ではありません。

ユーザーがそのページを重要だと特定している場合、または提供されたファーストパーティデータで需要やビジネス上の価値が確認できる場合は、深度の変更を優先してください。キーワード検索ボリュームの基準を設けたり、重要なページすべてにホームページからのリンクを必須としたりしないでください。

5. レビューアンカーと nofollow の問題

現在も該当箇所がある場合は、アンカーの欠落、説明的でないアンカー、内部 nofollow リンクについて、検出された問題を使用してください。

• 遷移先を自然な言葉で説明する、簡潔なアンカーテキストを優先してください。
• 説明的な表現によってユーザーが遷移先を理解しやすくなる場合は、「ここをクリック」のような一般的なテキストを避けてください。
• 完全一致の内部アンカーは、完全一致であるという理由だけで問題として指摘しないでください。繰り返し、文脈、読みやすさを確認してください。
• データソースに情報がない場合、遷移先のアンカー分布全体について断定しないでください。
• 内部 nofollow は個別に確認してください。この属性が価値の伝達を全面的に妨げると断定したり、削除を自動的に指示したりしないでください。

6. 文脈に沿ったハブとリンクを推奨する

確認できたトピック上の関係性、ナビゲーション、提供されたコンテンツデータから、ハブとスポークの構成機会を特定してください。ハブはユーザーにとって有意義なトピックを整理するものであり、内部リンク数が最も多い URL が自動的にハブになるわけではありません。

提案するリンクごとに、以下を明記してください。

• ソース URL
• 遷移先 URL
• その関係が有用である理由
• 説明的なアンカーの提案
• 根拠のソース
• 確信度

サイドウェイリンクの固定数、すべてのハブからのホームページへのリンク、またはクラスターごとの新しいピラーページを必須にしないでください。

出力

最初に、根拠の概要を示してください。

根拠の分類	ソース	対象範囲	スナップショットまたは日付	制限事項
Semrush Site Audit	プロジェクトとスナップショット	クロール全体または設定済みクロール	日付	クロール制限と連携機能
ユーザーデータ	アナリティクス／エクスポート／サイトマップ	実際の対象範囲を記載	日付	欠落フィールドまたは日付範囲
手動での確認	確認した URL	サンプル	日付	サイト全体を対象としていない
モデルによる推論	アーキテクチャ／リンクの推奨	推定に基づく	日付	人による検証が必要

次に、優先順位を付けた修正表を示してください。

優先度	問題	ソース URL	遷移先または影響を受ける URL	根拠	推奨アクション	確信度

確認できたビジネス上の重要度、深刻度、規模、作業量に基づいて優先順位を付けてください。ユーザーからビジネスデータやパフォーマンスデータが提供されていない場合は、その旨を記し、優先度が予想トラフィックや収益への影響を示すかのように扱わないでください。

最後に、次の項目を記載してください。

1. 今すぐ修正： 重要なページやナビゲーションに影響する、確認済みの不具合。
2. 次に改善： 十分な根拠がある、文脈に沿ったリンクやアーキテクチャの改善機会。
3. まず検証： サンプルに基づくもの、推定によるもの、または連携機能に依存する所見。
4. 利用できない根拠： 監査でアクセスできなかったレポートやフィールド。

参考資料

Semrush の方法論：

• 内部リンク：完全ガイドと戦略
• よくある内部リンクのミス 9 選
• 孤立ページ：見つけ方と修正方法
• ウェブサイトのアーキテクチャ：SEO のベストプラクティス

技術面の主な参考資料：

• Google 検索セントラル：リダイレクトと Google 検索