記事が少ないうちは、「この記事からあの記事へリンクした」と覚えていられます。
しかし記事が増えると、どこからどこへリンクしたか、新しく公開した記事へ過去記事から案内したかを、人間の記憶だけで把握し続けるのは難しくなります。
私のブログでは、Codexに既存記事、正式URL、記事台帳、内部リンク台帳を確認させ、追加候補を整理してもらっています。実際にリンクを置くかどうかは、人間が本文の流れを見て判断します。
記事が増えると内部リンクを把握しにくくなった
記事を1本ずつ公開していると、新記事から関連記事へリンクを置くことは比較的簡単です。問題は、その後です。
- 過去記事から新記事へ案内できる場所がないか
- 既存記事同士で、まだ自然につなげられる組み合わせがないか
- すでにリンクがあるのか、候補のままなのか
- リンク先が本当に公開済みなのか
私のブログでも、記事台帳には公開済みと作成中の記事が並び、内部リンク台帳には設置済み、未確認、未公開記事に関する記録が混在します。記事数が少ない間は見渡せても、更新が続くと確認箇所が増えてきました。
リンクを増やす前に、現在の状態を確認する必要があります。
内部リンクを確認するときに見ていること
最初から「関連しそうな記事を全部リンクする」とは考えません。まず、Codexに次の情報を確認させます。
| 確認するもの | 見る内容 |
|---|---|
| 記事台帳 | 記事ID、記事の状態、記事フォルダ、公開済みの正式URL |
| 内部リンク台帳 | どの記事からどの記事へリンクしているか、未確認の組み合わせ |
| 記事本文 | 見出し、本文の文脈、既存リンクの位置、重複する案内 |
| サイト方針 | 記事同士をつなぐ意味があるか、読者にとって自然か |
この確認で重視しているのは、単なるキーワードの一致ではありません。リンク先を読むと、その段落の疑問が解決するか、次に読む理由があるかを見ます。
関連していることと、そこにリンクを置く意味があることは別です。
Codexには内部リンク候補の整理まで任せる
Codexに依頼する範囲は、現在のリンク状況と候補を整理するところまでです。たとえば、次のような分類で出してもらいます。
- 新記事から既存記事へ張れるリンク
- 既存記事から新記事へ追加できそうなリンク
- 既存記事から別の既存記事へ追加できそうなリンク
- 関連していても、無理にリンクしなくてよい組み合わせ
候補には、記事IDや正式URLだけでなく、「どの見出しの近くに置くか」「どんな説明文が自然か」「想定するアンカーテキスト」も添えます。これなら、候補一覧を見ながら本文の流れを確認できます。
たとえば、フォルダ構成の記事からKnowledgeやWeeklyの使い分けの記事へ案内するのは、管理情報の役割説明の直後なら意味があります。一方で、サイト構成の記事から、すべての個別作業記事へリンクを並べると、読者が次に読む理由が弱くなる可能性があります。
Codexには候補を比較できる形に整理してもらいます。
実際に内部リンクを確認する流れ
現在の確認は、次の順番で進めています。頻度や自動実行のルールを決めているわけではなく、記事を追加したときに必要な範囲を確認するための流れです。
- 公開済み記事と正式URLを確認する 記事台帳から、公開済みの記事だけを一覧にします。
- 現在のリンク状況を確認する 内部リンク台帳と各記事のHTMLを照合し、設置済み、候補、未確認、未公開記事に関する候補を分けます。
- 関連する本文を読む 記事タイトルだけで判断せず、見出しと段落の流れを確認します。
- リンク方向ごとに候補を出す 新記事→既存記事、既存記事→新記事、既存記事→既存記事を別々に整理します。
- アンカーテキストと配置文脈を確認する 「こちら」だけで終わらず、リンク先の内容が分かる短い表現を検討します。
- 採否を人間が決める 読者に必要か、段落に自然か、リンクが多すぎないかを判断します。
- 判断結果を記録する 設置したリンク、見送った候補、未確認の事項を内部リンク台帳などへ残します。
この流れで確認すると、新記事から既存記事へリンクを置いて終わりにせず、過去記事側からの導線も見直せます。
新記事からのリンクだけでなく、過去記事からの入口も確認します。
すべて自動で追加させない理由
記事タイトルや本文の類似だけなら、Codexは多くの候補を見つけられます。しかし、候補が多いことと、読者にとって役立つことは同じではありません。
実際にリンクを置く前には、次の点を人間が確認します。
- その段落でリンク先を読む理由があるか
- リンク先の内容をアンカーテキストが正しく表しているか
- 同じ記事への案内が近い範囲に重複していないか
- 記事の主題から外れて、回遊のためだけのリンクになっていないか
- 公開済みの正式URLを使っているか
未公開記事はリンク先として扱わず、公開後に正式URLを確認してから、あらためてリンク候補を見直します。公開状態とURLが確定していない段階で、既存記事へリンクを追加しないことが確認のポイントです。
候補を見つける作業と、リンクを置く作業を分けます。
内部リンクに限らず、Codexにどこまで任せて、どこで人間が判断するかという役割分担は、ブログ運営でCodexに任せない作業で整理しています。
内部リンクの判断結果を管理情報へ残す
リンクを設置したかどうかだけでなく、判断の状態も残します。私の運用では、内部リンク台帳を現在の確認先として使い、必要に応じて記事別の内部リンクメモやNext Actionsと照合します。
| 状態 | 記録する内容 |
|---|---|
| 設置済み | リンク元、リンク先、正式URL、配置した文脈 |
| 候補 | リンク元の見出し、リンク先、理由、想定アンカーテキスト |
| 見送り | 関連はあるが、その場所で読む意味が薄いなどの判断 |
| 未確認 | 本文や公開状態をまだ確認できていない組み合わせ |
記事を公開した後は、新記事の正式URLが確定してから、既存記事側の候補を整理します。リンクを追加しなかった場合も、候補を見送ったのか、まだ確認していないのかを区別しておくと、次回に同じ調査を繰り返しにくくなります。
管理情報の現在・履歴・次の作業をどう分けているかは、CodexのKnowledge・Weekly・Next Actionsの使い分けで紹介しています。内部リンクの結果をどこへ残すか考えるときの前提になります。
設置しなかった候補も、判断結果として残します。
まとめ
記事が増えた後の内部リンク管理では、記事同士を機械的につなぐことより、現在の状態を確認し、候補を人間が判断できる形にすることを重視しています。
- 記事台帳で公開済み記事と正式URLを確認する
- 内部リンク台帳と本文から、現在のリンク状況を確認する
- 新記事→既存記事、既存記事→新記事、既存記事同士に分けて候補を出す
- アンカーテキストと配置する文脈を確認する
- 候補の採否と実際のHTML変更を人間が判断する
- 設置済み、候補、見送り、未確認を管理情報へ残す
内部リンクは、増やせばよいものではありません。関連するページから重要なページへ自然に案内し、読者が次に読む意味がある場所だけを選ぶことが大切です。Google Search Centralのリンクに関する公式ガイドでも、リンク先に関連したアンカーテキストを使う考え方が案内されていますが、これだけで検索順位やPVが上がると判断しているわけではありません。
Codexで確認を軽くし、リンクを置く判断は人間が行う。