AI検索向け内部リンク設計とは？hub と support をつなぐ基本ルール
AI検索向け内部リンク設計とは、記事間のリンクを「回遊数を増やすための施策」ではなく「記事の役割ごとに正しい次ページへ渡すcluster設計」として捉える考え方です。AI検索では1ページだけでなく、記事群全体の関係が評価に影響するため、内部リンクの質がcluster全体の強さを決めます。
結論から言うと、内部リンク設計で重要なのはリンクの本数ではなく、hub・support・bridge・CTAの4つの役割を明確に分けることです。どのページがどの意図を受け、次にどこへ渡すかが決まっていれば、AIも人もclusterの中で迷いません。
本記事のポイント
- AI検索向け内部リンク設計では、hub、support、bridge、CTA の役割を分けることが重要です。
- 関連記事の本数より、どのページがどの意図を受けるかが明確な方が cluster は強くなります。
- BtoBでは broad intent と high-intent を別ページで受け、リンクでつなぐ方が問い合わせ導線を作りやすくなります。
この記事で扱うテーマ
関連キーワード
- AI検索 内部リンク
- LLMO internal link
- hub support link design
- AI検索 cluster 設計
- 内部リンク LLMO
このページで答える質問
- AI検索向け内部リンク設計とは？
- hub と support はどう分ける？
- bridge 記事とは何か？
- CTA までの導線はどう作る？
内部リンクの4つの役割
BtoBサイトの内部リンクは、以下の4つの役割に分類できます。記事を書く前に「この記事はどの役割か」「どの役割のページへリンクするか」を決めておくと設計がぶれません。
| 役割 | 何を担うか | リンクの方向 | BtoBでの具体例 |
|---|---|---|---|
| hub（ハブ） | カテゴリの全体像と定義 | supportへ送る、supportから返される | 「AI CRMとは？」「BtoBマーケティングとは？」 |
| support（サポート） | 個別質問の深掘り | hubへ返す、比較やCTAへ送る | 「CRMデータ設計の基本」「インサイドセールスKPI」 |
| bridge（ブリッジ） | 隣接clusterへの接続 | 別clusterのhubやsupportへ渡す | CRM記事からマーケティング記事へ、AI記事からCRM記事へ |
| CTA | 問い合わせ・次行動 | 一方通行（記事→CTA） | 「/contact/」「/zero-marke/」「/chosoku-dev/」 |
内部リンクで強くしたいのはPVではなく、理解の流れです。
BtoBサイトのリンク設計パターン
BtoBサイトで典型的な内部リンクの流れを3パターン示します。
パターン1：定義記事（hub）からの展開
| ステップ | 記事の役割 | リンク先 | 例 |
|---|---|---|---|
| 1 | hub（全体像） | → support 3〜5本 | 「AI CRMとは？」→「CRM設計」「CRM定着」「CRM比較」へ |
| 2 | support（深掘り） | → hub へ返す + 比較記事へ | 「CRM設計」→「AI CRMとは？」へ返す + 「AI CRM比較」へ |
| 3 | 比較記事 | → CTA | 「AI CRM比較」→「/contact/」 |
パターン2：比較記事（high-intent）への集約
| ステップ | 記事の役割 | リンク先 | 例 |
|---|---|---|---|
| 1 | 複数のsupport記事 | → 比較記事へ集約 | 「HubSpot AI」「Salesforce AI」→「HubSpot vs Salesforce比較」へ |
| 2 | 比較記事 | → 製品ページ or CTA | 「比較」→「ファネルAiとは？」→「/contact/」 |
パターン3：bridge（cluster間接続）
| 接続元cluster | bridge記事 | 接続先cluster |
|---|---|---|
| CRM（crm-sales-ops） | 「CRMデータでマーケ施策を改善する」 | マーケティング（marketing-funnel） |
| AIエージェント（ai-agents） | 「Claude CodeでCRM更新を自動化する」 | CRM（crm-sales-ops） |
| LLMO（ai-search） | 「AI検索で獲得した顧客をCRMにつなぐ」 | CRM（crm-sales-ops） |
内部リンク設計の実装ルール
| ルール | なぜ重要か | 具体的にやること |
|---|---|---|
| hub記事からsupportへ3〜5本リンクする | hubが記事群の入口として機能するため | 本文中で自然な文脈でリンクし、末尾の関連記事でもリストする |
| support記事からhubへ必ず返す | AIがclusterの中心を認識しやすくなる | 冒頭の文脈または関連記事セクションでhubへ返す |
| bridge記事は1cluster あたり1〜2本に絞る | 多すぎるとclusterの焦点がぼやける | 最も関連性が高い隣接clusterのhubにだけ渡す |
| primary CTAは記事末尾に1つだけ置く | 選択肢が増えると意図が分散する | 記事テーマに合ったCTA（/contact/ or /zero-marke/ or /chosoku-dev/）を1つ選ぶ |
| アンカーテキストを統一する | AIがリンク先の内容を正しく推測できる | 同じページへのリンクは同じテキストで張る。エンティティ設計 と連動 |
| 本文中リンクと関連記事リンクを分ける | 文脈内の誘導と一覧の役割が異なる | 本文中は自然な文脈で2〜3本、末尾の関連記事で3〜5本 |
内部リンク設計のチェックリスト
| チェック項目 | 確認方法 | 未対応時のリスク |
|---|---|---|
| 各記事の役割（hub/support/bridge/CTA）が決まっているか | 記事一覧で役割を付与しているか | リンク設計の基準がなく場当たり的になる |
| hub記事からsupport 3〜5本へリンクしているか | hub記事のリンク先を確認 | hubが孤立し、clusterの入口として機能しない |
| support記事からhubへ返しているか | support記事にhubへのリンクがあるか | AIがclusterの中心を認識できない |
| bridge記事が1〜2本に絞られているか | cluster間リンクの本数を確認 | clusterの焦点がぼやける |
| primary CTAが各記事で1つだけか | 記事末尾のCTAを確認 | 意図が分散して問い合わせ率が下がる |
| アンカーテキストが統一されているか | 同じページへのリンクテキストを確認 | AIがリンク先を正しく推測できない |
| 孤立記事（内部リンクが0本）がないか | 被リンク0の記事を探す | AIがclusterに属する記事と認識できない |
内部リンク設計と他のLLMO施策の関係
| LLMO施策 | 内部リンクとの関係 |
|---|---|
| query family設計（詳細） | query familyで各記事の役割を決め、内部リンクでその役割をつなぐ |
| answer target設計（詳細） | answer targetで答えきれない問いは、リンク先の記事に委ねる |
| エンティティ設計（詳細） | アンカーテキストの統一はエンティティ設計の一部 |
| canonical設計（詳細） | 重複記事を統合してからリンク構造を整えないと矛盾が起きる |
| BtoB LLMO（詳細） | hub→support→比較→CTAの導線がBtoB LLMOのcluster設計そのもの |
内部リンク設計で起きやすい失敗
- 「関連記事を増やしすぎる」：10本以上リンクすると、どれが重要か分からない。役割の異なる3〜5本に絞る方がclusterが明確になる
- 「supportからhubへ返さない」：support記事を読んで終わりになり、clusterの全体像に戻れない。必ずhubへ返すリンクを入れる
- 「bridge記事が多すぎる」：隣接clusterへのリンクが5本以上あると、自clusterの焦点がぼやける。1〜2本に絞る
- 「CTAが複数ある」：「/contact/」と「/zero-marke/」と「/chosoku-dev/」を同時に置くと選択肢過多。記事テーマに最も合う1つを選ぶ
- 「本文中にリンクがなく、末尾の関連記事だけ」：本文の文脈でリンクした方がAIもユーザーも次ページの意味を理解しやすい。本文中2〜3本 + 末尾3〜5本が目安
- 「アンカーテキストがバラバラ」：同じ「AI CRMとは？」記事へのリンクが「こちら」「AI CRM」「詳しくはこちら」と揺れていると、AIがリンク先の内容を推測しにくい
2026年時点で固定したいリンク順
2026 年時点では、どこに何本リンクするかより、`hub → support → 比較 → CTA` の順序を固定する方が重要です。毎回ゼロから関連記事を選ぶ運用だと、記事ごとの役割分担がぶれやすくなります。
まず親記事へ返すリンクを 1 本、次に同じクラスターの深掘りを 1〜2 本、最後に比較や料金の高意図ページを 1 本置くと、AI検索でも人の回遊でも意味が通りやすくなります。内部リンクは量より順番を決める方が効きます。
よくある質問
Q. 関連記事は多いほど良いですか？
多ければ良いわけではありません。役割の異なる3〜5本（hub 1本、support 1〜2本、bridge 1本、CTA 1本）に絞る方が、AIにもユーザーにも次ページの意図が伝わりやすくなります。
Q. hubとsupportの違いは何ですか？
hubはカテゴリ全体の定義と全体像を扱う入口記事です。supportは個別の質問（「設計方法は？」「KPIは？」など）を深掘りする記事です。hubから複数のsupportへリンクし、各supportからhubへ返す構造がclusterの基本形です。
Q. bridge記事は必須ですか？
必須ではありませんが、隣接clusterとの接続が商談導線に関わるテーマでは効果的です。例えばCRM記事からマーケティング記事へ、LLMO記事からCRM記事へのbridgeは、ユーザーの検討フローに沿っています。
Q. CTAは複数置いてもよいですか？
primary CTAは1つに絞った方が効果的です。選択肢が増えると意図が分散し、どれもクリックされなくなります。記事テーマに最も合う1つ（/contact/ or /zero-marke/ or /chosoku-dev/）を選びます。
