内部リンクの目的を6つに分ける
内部リンクは、読者と検索エンジンに同じHTMLを提供する一つの導線ですが、評価目的は分けて考えます。クリックされないリンクがすべて不要とは限らず、全ページ共通リンクがすべて重要とも限りません。目的を明示すると、追加・削除・測定の判断が一貫します。
読者の次の疑問を解決する
現在の内容を理解した読者が次に必要とする比較、手順、定義、申込み、問い合わせへつなぎます。本文を読む前に結論を中断するリンクや、無関係な人気記事は置きません。
例：料金説明 → 契約期間と更新条件
ページを発見できるようにする
Googleは通常、hrefを持つa要素からURLを取得します。重要ページを検索フォーム、ボタンのクリック、無限スクロールだけに依存させず、別のクロール可能なページからリンクします。
例：<a href="/guides/migration/">移行手順</a>
情報の関係と重要度を示す
メニュー、カテゴリ、パンくず、本文リンクの接続は、ページ間の関係を伝えます。GoogleはECサイトについて、URL階層よりページ間のリンクを使って構造と相対的重要度を理解すると説明しています。
例：ホーム → カテゴリ → 詳細
リンク目的を理解できるようにする
WCAG 2.2では、リンクテキスト単独またはプログラムで判断できる文脈から目的が分かることを求めます。「こちら」だけを並べず、リンク先と起きることを説明します。
例：URL変更時のリダイレクト手順
更新・削除に追随する
記事統合、URL変更、商品終了、カテゴリ再編時は内部リンクも更新します。自サイト内リンクを古いURLのリダイレクト経由に残さず、最終canonical URLへ直接向けます。
例：旧URL → 最終URLへ直接更新
意図しないURL増殖を防ぐ
フィルタ、並べ替え、計測パラメータ、セッションIDへ無制限にリンクするとクロール対象が増えます。利用者に必要な状態とindex対象を分け、リンク生成規則を管理します。
例：?sort=price と canonical の方針を分ける
リンク種別ごとに役割と掲載範囲を決める
すべてのページからすべての重要ページへリンクすると、ナビゲーションが過密になり、読者が選べなくなります。サイト全体の現在地、階層内の移動、本文の文脈、一覧の続きを分け、同じリンクをヘッダー・本文・関連記事・フッターへ機械的に重ねません。
グローバル
ヘッダー・主要メニュー
サイト全体で繰り返し必要な主要領域へ導きます。項目数を組織図に合わせず、利用者の主要タスクに絞ります。モバイルメニュー、キーボード、現在地も確認します。
階層
カテゴリ・パンくず
上位分類、現在地、兄弟ページの関係を示します。パンくずはページの位置を説明し、戻り先を提供します。URLのフォルダ数と完全一致させること自体を目的にしません。
文脈
本文・表・手順内
用語、根拠、比較、次の手順など、その段落を理解するために必要なページへリンクします。リンク先の結論をアンカーと周辺文から予測できるようにします。
補助
関連記事・次へ・フッター
本文を読み終えた後の選択肢、連続コンテンツ、法務・会社情報を補います。自動関連記事はカテゴリ一致だけでなく、ページ役割、鮮度、公開状態、重複、上限を管理します。
一覧
ページネーション
Googlebotは通常ボタンをクリックしないため、次ページや各ページに固有URLとa hrefを用意します。無限スクロールや「もっと見る」は、クロール可能なページ分割を別に持たせます。
HTML sitemapとXML sitemapは内部リンク設計を代替しない
HTML sitemapは利用者がページを探す補助ナビゲーションです。XML sitemapは検索エンジンへURLを知らせるファイルです。Googleは、重要ページがナビゲーションやページ内リンクから到達できる状態を「適切に内部リンクされている」と説明しています。XML sitemapに載せても、孤立した読者経路や分かりにくい構造は直りません。
a hrefとアンカーテキストを実装ルールにする
Googleが通常クロールできるリンクは、実際のURLをhrefに持つa要素です。アンカーテキストは、簡潔で説明的で、リンク元とリンク先の両方に関連する表現にします。キーワード数ではなく、リンクだけを読んでも行き先を予測できるかで確認します。
| 対象 | 例 | 判断 |
|---|---|---|
| テキストリンク | <a href="/server/redirect/">リダイレクトの設定手順</a> | リンク先の内容と行動を簡潔に説明する。「こちら」「記事」「詳しく」だけを繰り返さない。 |
| JavaScript導線 | <span onclick="goToPage()">次へ</span> | a要素と解決可能なhrefへ変更する。ボタンは送信、開閉、状態変更などページ移動以外の操作に使う。 |
| 画像リンク | <a href="/plans/"><img alt="料金プランを比較"></a> | 画像だけがリンク内容なら、altがアンカーテキストの役割を担う。隣接する同一リンクの画像とテキストは一つのaにまとめる。 |
| 別タブ | target="_blank" | 内部リンクで一律に使わない。必要な場合は新しいタブ・ウィンドウが開くことを事前に伝え、rel属性と操作性を確認する。 |
同じリンク先には一貫した説明を使う
文脈に応じた自然な言い換えは可能ですが、同じページを異なる意味の名前で呼ぶと読者を迷わせます。反対に、異なるリンク先へ同じ「詳しくはこちら」を並べると、リンク一覧やキーボード移動で区別しにくくなります。
本数の理想値はない
Googleは1ページの理想リンク数はないと明記しています。本文を理解する前に離脱させる、同じリンクを重ねる、無関係なページを大量に置く、画面をリンクで埋める場合は過剰です。必要な経路が不足している場合は追加します。
内部リンク監査は、全件クロールと重要ページ台帳から始める
Search Consoleのリンクレポートは、Googleが長期間に発見したリンクをcanonical URL単位でまとめたサンプルです。最大1,000行の表が省略されることもあり、現在の全リンクやnofollowの有無を示す完全な台帳ではありません。自サイトのクロール結果、CMS、解析、URL検査と組み合わせます。
優先度が高いFinding
- 重要なindex対象ページへクロール可能なリンクがなく孤立している
- リンク先が404・5xx・リダイレクトループ・無関係なページになっている
- canonical、内部リンク、sitemapが別のURL形式を示している
- 主要タスクが検索フォームやJavaScript操作だけでしか到達できない
数だけで決めないFinding
- 内部リンク数が少ないが、必要な読者経路は完成している
- 深さが大きいが、明確なカテゴリと一覧から到達できる
- クリックが少ないが、法務・アクセシビリティ・例外時に必要である
- 競合サイトとアンカーやリンク数が異なるだけである
監査前にcanonicalとindex対象を決める
重複URL、パラメータ、http・https、www有無、末尾スラッシュ、言語版を別ページとして数えると、孤立・リンク数・深さの結果が歪みます。表示したいcanonical URLとindex対象、redirect・noindex・robotsの方針を確定し、同じ条件でクロールしてください。ログイン必須、確認画面、検索結果など非公開ページを一律にリンク追加しません。
内部リンクを7段階で改善する
リンクを大量追加する前に、読者タスク、ページ役割、技術状態をそろえます。変更を小さなページ群で試し、リンク切れ、ナビゲーション、クリック、indexへの影響を確認してから展開します。
- 1
canonical・index対象URLの台帳を作る
URL、page type、title、canonical、状態コード、index方針、所有者、更新日、重要度を整理します。統合・削除・リダイレクト予定のページを新規リンク先に選びません。
- 2
読者タスクと重要ページを対応付ける
調べる、比較する、選ぶ、申し込む、設定する、復旧するなど主要タスクを定義し、各段階の代表ページと次の疑問を決めます。検索流入が多いページだけを重要としません。
- 3
同条件でサイトをクロールする
リンク元、リンク先、アンカー、rel、位置、状態コード、深さ、inlink・outlinkを取得します。JavaScript描画が必要なサイトはレンダリング後HTMLも確認し、Search Consoleサンプルと差を調べます。
- 4
問題を原因別に分ける
孤立、壊れ、リダイレクト経由、非canonical、noindex先、無関係、曖昧アンカー、過密、動的導線、ページネーション欠落へ分類します。重要ページと主要タスクを先に直します。
- 5
役割に合う場所へリンクを実装する
全体導線はメニュー、階層はカテゴリ・パンくず、理解の補足は本文、読了後の選択肢は関連記事へ配置します。a href、最終URL、説明的なアンカー、フォーカス表示、タップ領域を確認します。
- 6
ステージングで操作とクロールを再確認する
Chrome・Edge・Safari、390px、キーボード、リンク一覧、戻る操作を確認します。再クロールで新しい孤立、404、チェーン、重複、リンク先間違いがないことを比較します。
- 7
公開後に小さく評価して展開する
変更日、対象ページ、リンク元、リンク先、仮説を記録します。クリック、タスク完了、クロール、index、検索流入を観察し、季節性や同時変更を分けます。期待どおりでなければリンク位置・文脈・行き先を再評価します。
自動内部リンクは候補提示に使い、公開判断を自動化しすぎない
キーワード一致だけで全記事へリンクすると、誤った意味、古いページ、同一アンカーの反復、過剰リンクが発生します。公開状態、canonical、ページ役割、文脈、上限、除外語、優先度を規則にし、編集者がリンク先と文章を確認します。URL変更・削除時に一括更新できる台帳も用意します。
効果測定は、発見・移動・品質・検索を分ける
一つの指標だけで内部リンクの成否を決めません。クリック率が上がってもタスクを中断している場合があり、index数が増えても不要ページが増えただけの場合があります。変更前の基準、対象ページ群、期間、他の変更を記録します。
発見・クロール
孤立ページ数、壊れリンク、リダイレクトチェーン、クロール可能なinlink、サーバーログのGooglebotアクセス、URL検査の取得結果を確認します。クロール回数の増加自体を成果にしません。
利用者の移動
リンククリック、遷移先での戻る・次の行動、タスク完了、離脱、ユーザーテストを確認します。全リンクへイベントを付ける前に、計測目的、命名、同意、保存期間、個人情報を整理します。
リンク品質
アンカーだけで目的を予測できるか、同じ行き先の名前が一貫するか、異なる行き先を区別できるか、キーボードフォーカス、画像alt、別タブ予告、モバイルの押しやすさを確認します。
検索と事業
対象ページ群のindex、Google選択canonical、検索表示・クリック、自然検索の入口、問い合わせ・購入などを観察します。順位変化を内部リンクだけの効果と断定せず、本文更新、外部リンク、季節、アルゴリズム更新を併記します。
Search Consoleの内部リンク数は監査の正解表ではない
リンクレポートはcanonical単位で集約され、重複をまとめ、過去に発見されたリンクを含み、表が省略されるサンプルです。数が少ないページを機械的に増やしたり、数が多いページを重要と断定したりしません。現行HTMLのクロール、ページ役割、利用者経路、URL検査、解析と照合します。
公式資料と確認日
次の一次資料を2026年7月25日に確認しました。Google向けの発見・構造と、利用者向けのリンク目的・操作を分けず、同じリンクで両方を満たしてください。
内部リンクのよくある質問
内部リンクは1ページに何本が最適ですか？
万能な本数はありません。Googleも理想数はないと説明しています。読者の次の疑問、現在地、主要タスクに必要なリンクを配置し、同じ行き先の反復、無関係なリンク、画面の過密を減らします。ページ種別ごとに上限警告を設けることはできますが、順位基準として扱いません。
重要ページはすべてトップページからリンクすべきですか？
必ずしも必要ありません。全サイト共通の主要領域はトップやメニューから、特定カテゴリの詳細はカテゴリや関連本文から到達させます。すべてをトップへ載せると選択肢が増え、階層と文脈が分かりにくくなります。重要ページが少なくとも一つのクロール可能な経路を持つことを確認します。
「詳しくはこちら」は使ってはいけませんか？
リンクと同じ文や段落から目的を明確に判断できる場合は直ちに不適合とは限りません。ただし、リンク一覧やキーボード移動では区別しにくいため、可能なら「内部リンク監査の手順」のようにリンク先を説明します。同じ画面へ複数の「こちら」を並べません。
XML sitemapがあれば孤立ページでも問題ありませんか？
XML sitemapは検索エンジンによるURL発見を助けますが、利用者の経路やページ間の関係を作りません。Googleもsitemap掲載がクロール・indexを保証しないと説明しています。重要ページはナビゲーションまたは関連ページから到達できるようにします。
内部リンクへnofollowを付けて重要度を調整できますか？
通常の情報構造をnofollowで調整するのではなく、不要なリンクを削除し、必要なページへ自然にリンクします。faceted navigationなどクロール制御が必要な例外では、URL設計、robots.txt、canonical、nofollowの効果と限界を個別に確認します。
Search Consoleだけで内部リンク監査はできますか？
できません。リンクレポートはGoogleが発見したリンクのサンプルで、現行HTMLの完全な全件一覧ではありません。canonical・index対象の台帳、自サイトクロール、CMS、URL検査、解析、実ブラウザ操作と組み合わせます。
次に確認する記事
結論：内部リンクは、読者が迷わず次へ進めるサイト構造として設計する
重要ページと読者タスクを先に決め、全体、階層、文脈、補助のリンクを役割別に配置してください。a hrefと最終canonical URLを使い、アンカーだけでも目的が伝わる表現にします。改善では、孤立、壊れ、リダイレクト経由、誤canonical、動的導線を優先し、Search Consoleのサンプルだけに依存しません。変更前後のクロール、実操作、クリック、index、検索、事業結果を分けて測り、内部リンクだけで成果を保証しないことが重要です。
執筆・検証
Finite Field 編集部
Google Searchの発見・構造、アクセシビリティ、編集、解析を分けて確認し、内部リンクの目的と測定条件が追跡できるよう編集しています。仕様やSearch Consoleの変更時は出典と監査手順を更新します。
情報設計・サイト改善
重要ページと内部リンクの優先順位を整理できない場合はご相談ください
canonical・index対象の棚卸し、サイトクロール、孤立・壊れ・リダイレクト、メニュー・パンくず・本文・関連記事、アンカー、ページネーション、測定計画を支援します。リンク数を増やす前に、変更しない導線と直すべき経路を分けて提案します。
内部リンク設計とサイト構造改善を相談する相談前に、対象ドメイン、CMS、ページ数、重要ページ、Search Console・解析の利用可否、最近のURL変更を共有いただくと整理しやすくなります。