AIで内部リンク候補を整理する方法｜関連記事をつなぐ考え方

AIで内部リンクを整理するときは、似たキーワードの記事を自動でつなぐのではなく、読者が今の記事を読んだあとに必要とする次の情報から候補を選びます。リンク数を増やすことを成果にせず、リンク元の文脈、リンク先の役割、読者の次の行動を一組で確認してください。候補一覧だけで終わらず、追加する場所と、リンクしない理由も記録すると、後から見直せます。

最初に用意する記事Inventory

AIへ記事一覧を渡す前に、対象範囲を絞って正本データを確認します。少なくとも次をそろえます。

表は横にスクロールできます

Field	内容	用途
Article ID / Status	一意IDと公開状態	未公開・保留記事を公開リンク候補にしない
Title / URL	現行タイトルと実在route	タイトルからURLを生成しない
Reader Job	読者が完了する作業	同じ単語ではなく次Actionを比較
Workflow	関連する作業の前後関係	手順上の近接候補を探す
Type / Target Query	ページの役割と検索目的	比較、手順、料金などの違いを把握
Existing links	本文・Reader Journey・Relatedのリンク	重複を避ける

StatusやURL、Relationが空欄なら、タイトルや本文から推測して埋めないでください。正本が確認できない行は「要確認」にします。下書きやEditorial Reviewのページが含まれるときは、公開リンク先として扱わず候補から抑制します。

Link元から読者の次Actionを決める

リンク元ページの全体を一文に要約し、読者がここで何を得て、次にどの疑問を持つかを書きます。たとえばキーワード整理の記事なら、候補語を検索意図と担当ページへ割り当てたあと、競合SERPを調べる、構成を作る、既存記事を直すといった次の作業が候補です。同じ「SEO」を扱うだけのツール紹介は、読者が次に求める情報がなければ関連リンクではありません。

表は横にスクロールできます

Link元の読者が終えた作業	次に残る疑問	候補となるページ役割
Query候補を整理した	SERPでは何が答えられているか	競合・SERP分析
検索意図を確定した	読者の疑問をどう構成へ並べるか	記事構成
既存記事の不足を見つけた	どこを残し、どこを更新するか	SEOリライト
AIの候補を得た	どの情報が事実か	公式Evidenceを扱う案内

表の候補は例です。実際にはContent DB上のPublishedかつruntimeにあるURLだけを採用します。Job Hub、Tool Detail、Finderなどの共通導線が既にレンダリングされる場合は、それも既存リンクとして重複をチェックします。

AIには候補と理由を出させる

Inventoryの対象記事だけを渡し、候補URLと根拠を表にします。AIに本文全体を推測させず、各候補について「読者が何の次に移るのか」「どの段落がリンク元か」「何を理解できるページか」を説明させます。

Link元のArticle ID / URL：

Reader Jobと読了時点の状態：

Link先候補（Article ID、Status、正確なURL、Job、Workflow）：

本文の該当section：

既存のReader Journey / Related link：

それぞれの候補について、読者の次Actionとどうつながるかを説明してください。候補のStatusがPublishedでない、URLが空欄、Jobが推定、同じhrefがすでにある場合は抑制し、理由を返してください。別のURLを作らないでください。リンクが不要なら「追加候補なし」としてください。

AI出力をそのまま挿入せず、Article IDと実在route、Status、重複、リンク先の読者価値を人が確認します。リンク先の内容とanchor textが合っているかも、リンク元・リンク先を読み比べて判断してください。

Anchorと配置を決める

Google Search Centralは、リンク先の内容が分かる簡潔で関連性のあるanchor textを使い、文脈上必要な内部resourceへつなぐ考え方を案内しています。文字列を並べてキーワードを詰めたり、「こちら」だけで遷移先を説明しない形は避けます。リンクの前後の文章から、読者が移動後に得る情報を理解できるかを読みます。

配置は、該当する説明を読んだ直後など、リンクする理由が分かる位置を優先します。Related cardやReader Journeyが同じ遷移先を既に提供している場合は、役割と視認性を比較し、本文に追加することで重複しないかを確認します。いくつものlinkを一文に連結せず、各リンクに短い文脈を与えます。

Candidate review table

表は横にスクロールできます

Source	Candidate	Reader next step	Link sentence / placement	Existing duplicate	Decision
G701	G704	SERPから共通・独自論点を把握	Query整理の次工程を説明する文	既存本文・Relatedを確認	Add / Keep / Suppress
G701	G703	論点から記事構成を作る	構成作成が必要な読者向け	既存本文・Relatedを確認	Add / Keep / Suppress
任意	正本で解決したURL	次Actionを明示	anchorをリンク先と一致させる	href完全一致で照合	Add / Keep / Suppress

このサンプルは候補の書き方であり、現在の公開状態やArticle relationを示すものではありません。実運用では正本から最新値を読みます。URLを手入力やslug推定で補完せず、候補のprimary relationが空なら無理に埋めないでください。

追加リンクの優先順位をつける

候補が多いときは、リンクを出す位置だけでなく、読者にとっての必要性を比べます。必須の次工程、条件が合う読者だけに必要な補足、単にテーマが近いページを分け、最後の種類は無理に追加しません。

表は横にスクロールできます

優先	判断	例
高	今の作業を完了するため次に読む必要がある	競合分析の次に構成作成へ進む
中	特定条件の読者だけに追加情報が必要	料金比較を始めたい人へ料金Guide
低	Topicが似るだけで次Actionが説明できない	同じ「AI」「SEO」語を含むだけ

関連ページが複数ある場合は、同じ次Actionを分散させず、一つの主要リンクと必要な条件付き補足に整理します。見出しやカードの視認性が高い共通UIにすでに出ているなら、本文内linkを足さなくても足ります。リンクがクリックされるかの測定がないときは「回遊が改善した」と断定せず、実装前に読者へ何を提供する想定かを記録します。

孤立候補と回遊の点検

重要ページに流入リンクがあるかを調べるときは、全リンクを同じ重要度とみなさず、まず公開済みのページだけでhrefを数えます。Related card、本文contextual link、Job / Workflow導線など、入口別に分けると、同じhrefが複数componentから出ている状態を見つけやすくなります。未公開route、404、自己リンク、同一ページ内の同じ目的の重複を区別して扱います。

Googleは重要ページへ他のページから到達できるリンクを用意することを推奨していますが、各ページに置くべき理想的なリンク数を定めているわけではありません。孤立を見つけても、単にリンク数を増やすのではなく、どの公開ページからどんな読者の次Actionとしてつなげるか決めます。自然な入口がないなら、情報設計上の課題として記録し、無関係な記事からリンクを足さないでください。

公開前の検証

1. Link元・Link先が現在Publishedか確認する。

2. URLがContent DBの正本と一致し、runtimeで実在することを確認する。

3. 同じhrefが本文、Reader Journey、Relatedに重複していないか確認する。

4. anchorだけ読んでも遷移先が分かるか確認する。

5. リンクを置いた文脈が、読者の次Actionを説明しているか確認する。

6. Link先で読者が実際に必要な情報を得られるか確認する。

7. 追加しなかった候補と理由も残す。

公開後、記事やrelationが増えたタイミングで候補を再評価できますが、全サイトのリンクを頻繁に組み替える必要はありません。更新時には同じ判定表を使い、すでに適切な導線を維持したまま、変わった部分だけ見直します。

AIものさしの判断

内部リンクの完了は、linkが追加されたことではなく、読者が必要な次Actionへ安全に進めることです。正本のURL・公開状態と、リンク元・先のReader Jobを照合し、理由が説明できる候補だけを文脈へ置きます。候補を選べない場合やrelationが不足している場合は、作り話のURLを足さず「未解決」と残してください。