Googleのリンク、canonical、ページネーション、sitemap、Search Consoleリンクレポートと、W3Cのリンク目的に関する公式資料を2026年7月29日に再確認しました。内部リンクは発見性・移動・情報構造の改善に役立ちますが、順位、滞在時間、問い合わせ数の上昇を単独で保証する施策ではありません。
内部リンクで最初に決めるべきなのは本数ではなく、「誰が、どのページから、何を解決するために移動するか」です。 indexさせたい重要ページと読者の主要タスクを先に決め、グローバルナビ、カテゴリ、パンくず、本文、関連記事、ページネーションを役割別に配置します。
内部リンクは、読者の次の行動と重要ページへの到達経路を設計する
Googleが通常たどれる <a href> を使い、リンク先を予測できる簡潔なアンカーテキストにします。重要ページは少なくとも一つの別ページから到達できる状態にし、壊れリンク、孤立ページ、非canonical URL、JavaScript操作だけの導線を優先して直します。
| 内部リンクとは | 同じWebサイト内のページや情報をつなぐリンク。読者の移動、ページ発見、情報構造の理解を支える |
|---|---|
| 最優先 | 重要なindex対象ページへ、少なくとも一つのクロール可能な到達経路を用意する |
| 良い実装 | <a href="/path/">リンク先を説明する文言</a> |
| 避けたい状態 | 孤立、404・5xx、リダイレクトチェーン、非canonical URL、検索フォームやボタンだけの導線 |
| 本数の考え方 | 理想値は固定しない。読者に必要か、重複していないか、画面が過密でないかで判断する |
| 確認日 | 2026年7月29日 |
内部リンクとは？SEOだけではない4つの役割
同じWebサイト内の別ページ、同一ページ内の見出し、画像や資料などへ移動するリンクです。外部サイトへ向かう外部リンクとは異なり、サイト内の情報同士を接続します。
Googleはリンクを、新しいページを発見する経路と、ページの関連性を理解する手掛かりとして利用します。ただし、内部リンクの価値は検索エンジン向けだけではありません。読者が現在地を理解し、比較、設定、申込み、問い合わせなど次の行動へ進めることが、設計の中心です。
読者の次の疑問を解決する
定義を読んだ人には比較、料金を見た人には契約条件、設定中の人にはトラブル対処など、現在の文脈に続くページを案内します。
重要ページを発見できるようにする
検索フォーム、クリック後のJavaScript、無限スクロールだけに頼らず、indexさせたいページへ通常のリンク経路を用意します。
ページ間の関係と重要度を示す
メニュー、カテゴリ、パンくず、本文リンクの接続は、サイト内で何が上位概念で、どのページが関連するかを伝えます。
リンク目的を理解できるようにする
リンクテキスト単独、または同じ文・段落などプログラムで判断できる文脈から、移動先と起きることが分かるようにします。
内部リンクの種類ごとに役割と掲載範囲を決める
すべての重要ページをヘッダーやトップページへ並べると、選択肢が増えすぎ、階層と文脈が分かりにくくなります。サイト全体、階層、本文、読了後、一覧の続きを分け、同じリンクを機械的に重ねないことが大切です。
| リンク種別 | 主な場所 | 役割と設計ポイント |
|---|---|---|
| グローバル | ヘッダー・主要メニュー | サイト全体で繰り返し必要な主要領域へ案内。組織図ではなく利用者の主要タスクに絞る |
| 階層 | カテゴリ・パンくず | 上位分類、現在地、兄弟ページの関係を示す。URLのフォルダ数と完全一致させること自体を目的にしない |
| 文脈 | 本文・表・手順 | 用語、根拠、比較、次の操作など、その段落を理解または実行するために必要なページへつなぐ |
| 補助 | 関連記事・次の記事・フッター | 読了後の選択肢、連続コンテンツ、会社・法務情報を補う。自動関連記事は鮮度と重複を管理する |
| 一覧 | ページネーション | 各ページに固有URLを持たせ、次ページなどをa hrefで順番につなぐ。ボタンだけに依存しない |
読者タスクに沿った階層
ホーム → カテゴリ → 詳細 → 比較・申込みのように、現在地と次の行動を自然にたどれます。各ページの役割が重複しません。
全ページへ同じリンクを大量掲載
ヘッダー、本文、関連記事、フッターに同じ行き先を繰り返すと、重要度も文脈もぼやけます。共通導線と個別導線を分けます。
内部リンクの正しい貼り方：a hrefとアンカーテキストを基本にする
Googleが通常クロールできるのは、実際のURLを href に持つ a 要素です。見た目がボタンでも、ページ移動ならリンクを使い、開閉・送信・状態変更などの操作にはbuttonを使います。
移動先を予測できるリンク
<a href="/server/redirect/"> リダイレクトの設定手順 </a>
リンクだけを読んでも、どのページへ移動するかを推測できます。
JavaScript操作だけの導線
<span onclick="goToPage()"> 詳しくはこちら </span>
a要素と解決可能なhrefへ変更し、アンカーもリンク先を説明する文言にします。
簡潔で説明的なアンカーにする
「こちら」「記事」「詳しく」だけを繰り返さず、「内部リンク監査の手順」「料金プランの比較」のようにリンク先の内容を示します。
周辺文も含めて自然な文脈を作る
アンカーへキーワードを詰め込まず、前後の文章を含めて、なぜそのページが次に必要なのかを説明します。
画像リンクには内容を示すaltを付ける
画像だけがリンクの場合、altがアンカーテキストの役割を担います。同じ行き先の画像とテキストが隣接するなら、一つのリンクにまとめます。
内部リンクを一律に別タブで開かない
必要な場合は、新しいタブ・ウィンドウが開くことを事前に伝えます。通常のサイト内移動は同じタブの方が戻る操作を予測しやすくなります。
内部リンクは何本が最適か
固定の理想本数はありません。 読者の理解が中断される、同じ行き先が何度も現れる、無関係な人気記事が並ぶ、画面がリンクで埋まる場合は過剰です。反対に、重要ページが孤立している、次の手順が分からない、比較や根拠へ進めない場合は不足しています。
canonical・sitemap・nofollowと内部リンクを混同しない
内部リンク先は、原則として表示したい最終canonical URLへ直接そろえます。旧URLやパラメータ付きURLをリダイレクト経由で残すと、監査・計測・保守が複雑になります。
| 方法 | canonicalへのシグナル | 内部リンク設計での扱い |
|---|---|---|
| リダイレクト | 強い | 廃止URLを最終URLへ統合するときに使用。サイト内リンクは転送元ではなく転送先へ更新する |
| rel=canonical | 強い | 重複・類似ページの代表URLを示す。内部リンク、hreflang、sitemapと矛盾させない |
| XML sitemap | 弱い | 重要URLの発見を助けるが、孤立ページや利用者の移動経路を解決しない |
| 内部リンク | URLの一貫性を補強 | 同じページへ複数形式でリンクせず、採用するcanonical URLへ統一する |
XML sitemapは内部リンクの代わりにならない
sitemapはURL発見を支援しますが、掲載したURLが必ずクロール・indexされるわけではありません。読者がたどる経路や、ページ同士の関係も作りません。重要ページはメニュー、カテゴリ、本文、関連記事などから到達できるようにします。
ページネーションは固有URLと連続リンクを持たせる
「もっと見る」ボタンや無限スクロールは利用者に便利でも、Googleのクローラは通常ボタンをクリックしません。各ページへ固有URLを用意し、次ページを <a href> で順番につなぎます。ページ番号をURLフラグメントだけで表現しないようにします。
nofollowで通常のサイト構造を調整しない
重要度を操作する目的で内部リンクへ一律にnofollowを付けるのではなく、不要なリンクは削除し、必要なリンクは通常のリンクとして設置します。フィルタ・並べ替え・セッションIDなどURLが大量生成される領域は、URL設計、robots.txt、canonical、noindexを目的別に整理してください。
内部リンク監査は、重要ページ台帳と全件クロールから始める
Search Consoleのリンクレポートは、Googleが発見したリンクのサンプルです。canonical単位でまとめられ、重複が統合され、表は最大1,000行に制限されるため、現在の全リンクを示す正解表ではありません。自サイトのクロール、CMS、URL検査、解析、実ブラウザ操作と照合します。
すぐ原因を調べるFinding
- 重要なindex対象ページにクロール可能なinlinkがなく、孤立している
- リンク先が404、5xx、リダイレクトループ、無関係なページになっている
- canonical、内部リンク、sitemapが別のURL形式を示している
- 主要タスクが検索フォームやJavaScript操作だけでしか到達できない
数だけで修正しないFinding
- 内部リンク数は少ないが、必要な読者経路は完成している
- 階層は深いが、明確なカテゴリと一覧から到達できる
- クリックは少ないが、法務・復旧・例外時に必要である
- 競合サイトよりリンク数やアンカー表現が少ないだけである
| 確認元 | 主に分かること | 注意点 |
|---|---|---|
| 自サイトクロール | リンク元・先、アンカー、状態コード、深さ、inlink・outlink、canonical | ログイン領域、JavaScript描画、robots制限などクロール条件を記録する |
| CMS・URL台帳 | 公開状態、ページ役割、所有者、更新日、統合・削除予定 | 非公開や廃止予定ページを新しいリンク先に選ばない |
| Search Console | Googleが発見した内部リンクの傾向、URL検査、index状況 | リンクレポートはサンプルであり全件一覧ではない |
| アクセス解析 | クリック、遷移後の行動、タスク完了、問い合わせ | クリック増加だけを成功とせず、次の行動まで確認する |
| 実ブラウザ操作 | モバイル、キーボード、フォーカス、戻る操作、リンク目的 | 自動クロールでは分からない操作性と文脈を確認する |
内部リンクを7段階で改善する実践手順
リンクを大量追加する前に、ページ役割、URL状態、読者タスクをそろえます。変更は小さなページ群から試し、リンク切れ、クリック、index、検索流入を確認してから展開します。
canonical・index対象URLの台帳を作る
URL、ページ種別、title、canonical、状態コード、index方針、所有者、更新日、重要度を整理します。統合・削除・リダイレクト予定のページは新規リンク先にしません。
読者タスクと重要ページを対応付ける
調べる、比較する、選ぶ、申し込む、設定する、復旧するなど主要タスクを定義し、各段階の代表ページと次の疑問を決めます。
同じ条件でサイトをクロールする
リンク元、リンク先、アンカー、rel、状態コード、深さ、inlink・outlinkを取得します。JavaScriptサイトはレンダリング後HTMLも確認します。
問題を原因別に分類する
孤立、壊れ、リダイレクト経由、非canonical、noindex先、無関係、曖昧アンカー、過密、動的導線、ページネーション欠落へ分けます。
役割に合う場所へリンクを実装する
全体導線はメニュー、階層はカテゴリ・パンくず、理解の補足は本文、読了後の選択肢は関連記事へ配置します。
ステージングで操作とクロールを再確認する
主要ブラウザ、390px前後のモバイル、キーボード、リンク一覧、戻る操作を確認し、再クロールで新しい404や重複がないか比較します。
公開後に小さく評価して展開する
変更日、対象ページ、リンク元・先、仮説を記録します。クリック、タスク完了、クロール、index、検索流入を観察し、同時変更や季節性を分けます。
内部リンクの効果測定は、発見・移動・品質・検索を分ける
一つの指標だけで成否を決めません。クリック率が上がっても読者のタスクを中断している場合があり、index数が増えても不要ページが増えただけの場合があります。変更前の基準、対象ページ群、期間、同時変更を記録します。
発見・クロール
孤立ページ、壊れリンク、チェーン、クロール可能なinlink、サーバーログ、URL検査を確認します。クロール回数の増加自体を成果にしません。
利用者の移動
リンククリック、遷移先での次の行動、戻る、タスク完了、離脱、ユーザーテストを確認します。
リンク品質
アンカーで目的を予測できるか、名称が一貫するか、キーボードフォーカス、画像alt、モバイルの押しやすさを確認します。
検索と事業
対象ページ群のindex、Google選択canonical、検索表示・クリック、自然検索の入口、問い合わせ・購入を観察します。
| 記録項目 | 例 |
|---|---|
| 変更前 | 孤立数、404数、対象リンクのクリック、対象ページのindex・検索流入・問い合わせ |
| 変更内容 | リンク元、リンク先、設置場所、アンカー、公開日、対象ページ群、仮説 |
| 公開後 | 再クロール結果、実操作、クリック後の行動、Google選択canonical、検索・事業指標 |
| 交絡要因 | 本文更新、タイトル変更、外部リンク、季節性、広告、アルゴリズム更新、サイト障害 |
確認した公式資料
次の一次資料を2026年7月29日に確認しました。検索エンジン向けの発見・構造と、利用者向けのリンク目的・操作性を別々に扱わず、一つのリンクで両方を満たす設計が基本です。
内部リンクのよくある質問
内部リンクは1ページに何本が最適ですか？
万能な本数はありません。読者の次の疑問、現在地、主要タスクに必要なリンクを配置し、同じ行き先の反復、無関係なリンク、画面の過密を減らします。ページ種別ごとの警告上限は作れますが、順位基準としては扱いません。
重要ページはすべてトップページからリンクすべきですか？
必ずしも必要ありません。全サイト共通の主要領域はトップやメニューから、カテゴリ固有の詳細ページはカテゴリや関連本文から到達させます。重要ページが少なくとも一つのクロール可能な経路を持つことを確認します。
「詳しくはこちら」は使ってはいけませんか？
同じ文や段落から目的を明確に判断できる場合は直ちに問題とは限りません。ただし、リンク一覧やキーボード移動では区別しにくいため、可能なら「内部リンク監査の手順」のようにリンク先を説明します。
XML sitemapがあれば孤立ページでも問題ありませんか？
sitemapは検索エンジンによるURL発見を助けますが、利用者の経路やページ間の関係を作りません。掲載URLのクロール・indexも保証されません。重要ページはナビゲーションまたは関連ページから到達できるようにします。
内部リンクへnofollowを付けて重要度を調整できますか？
通常の情報構造をnofollowで調整するのではなく、不要なリンクを削除し、必要なページへ自然にリンクします。クロール制御が必要な例外は、URL設計、robots.txt、canonical、noindexを目的別に確認します。
Search Consoleだけで内部リンク監査はできますか？
できません。リンクレポートはGoogleが発見したリンクのサンプルで、現行HTMLの完全な全件一覧ではありません。重要ページ台帳、自サイトクロール、CMS、URL検査、解析、実ブラウザ操作と組み合わせます。
まとめ：内部リンクは「読者が迷わず次へ進める構造」として設計する
重要ページと読者タスクを先に決め、全体、階層、文脈、補助、一覧のリンクを役割別に配置してください。実装は a href と最終canonical URLを基本にし、アンカーだけでも移動先を予測できる表現にします。
改善では、孤立、壊れ、リダイレクト経由、非canonical、動的導線を優先し、Search Consoleのサンプルだけに依存しません。変更前後のクロール、実操作、クリック、index、検索、事業結果を分けて測ることで、リンクを増やすだけの施策から脱却できます。