AIで内部リンクを分析するときは、記事本文だけで候補を考えさせるのではなく、公開URL、title、H1、検索意図、記事の役割、現在のlinkを台帳にします。AIには候補と理由を出させ、最終的な挿入位置とアンカーは人が文脈で判断します。
この記事では、source・target・anchor・reason・priorityを持つ候補CSV、孤立ページ、リンク集中、404の監査手順を解説します。
情報確認日：2026年7月18日（日本時間）
結論：単語の一致ではなく、読者の次の疑問でつなぐ
- 公開可能なURL台帳を作る
- 各記事の検索意図と役割を短く要約する
- source・target・理由をAIに提案させる
- 自然な位置とanchorを人が決める
- crawl可能性、404、孤立、集中を監査する
1．内部リンク分析用のURL台帳を作る
url,title,h1,category,intent,role,status,indexable,canonical,inlinks,outlinks
/articles/rag-basics/,RAGとは,RAGとは？...,ai,RAGの仕組みを知る,parent,publish,true,self,12,8
/articles/embedding-basics/,Embeddingとは,Embeddingとは？...,ai,ベクトル化を理解,child,publish,true,self,2,5
/articles/rag-nodejs/,Node.jsでRAG...,Node.jsで...,ai,RAGを実装,howto,draft,false,,0,0titleだけでなく、検索意図と記事の役割を付けます。役割はparent、child、howto、comparison、troubleshootingなど、サイト内で統一してください。
候補から除外するURL
- draft・private・予約公開前の記事
- noindexにするページ
- redirect元や404
- canonicalが別URLの重複ページ
- 利用者がアクセスできない管理画面
- 古く、今後削除するページ
未公開記事へ先にリンクすると読者が404へ進む可能性があります。公開順と同時更新を管理します。
2．記事同士の関係を分類する
| 関係 | source | target | 読者の次の疑問 |
|---|---|---|---|
| 概要→詳細 | RAGの基礎 | Embeddingの基礎 | 意味検索はどう動くか |
| 詳細→概要 | chunk設計 | RAGの基礎 | 全体のどこに当たるか |
| 比較→導入 | tool比較 | 選定したtoolの使い方 | 次にどう始めるか |
| 手順→解決 | install手順 | error対処 | 失敗したときどうするか |
| 記事→用語 | 実装記事 | 基礎用語 | 前提概念を確認したい |
同じ「AI」という単語があるだけでは関連性が弱すぎます。sourceを読んだ人が次に何を知りたいか、そのtargetが答えられるかを確認します。
3．AIへ候補を作らせる
次のURL台帳から内部リンク候補を作ってください。
目的:
読者が次の疑問を解決できる関連ページへ移動できるようにする。
ルール:
- status=publishかつindexable=trueだけをtargetにする
- sourceとtargetを同じURLにしない
- titleの単語一致だけで判断しない
- intentとroleの関係を理由に含める
- 1 sourceあたり最大3候補
- 既存linkと重複しない
- anchorは本文に自然に置ける説明的な候補にする
- 自動挿入しない
出力:
source,target,anchor_candidate,reason,relationship,
placement_hint,priority,status記事全文を入力できる場合も、外部AIへ送信可能な公開内容だけにします。まず台帳で候補を絞り、上位だけ本文の段落と照合すると効率的です。
内部リンク候補CSV
source,target,anchor,reason,priority,status
/articles/rag-basics/,/articles/embedding-basics/,Embeddingの仕組み,意味検索の前提を詳しく解説,high,review
/articles/local-llm-basics/,/articles/local-llm-pc-specs/,必要なPCスペック,導入前の端末判断へ進める,high,approved
/articles/ai-blog-writing/,/articles/ai-fact-check-workflow/,AI記事のファクトチェック手順,公開前の事実確認を補う,high,reviewreasonが「関連しているため」だけなら採用しません。読者にどんな追加価値があるか一文で説明できる候補を残します。
4．アンカーテキストと位置を決める
Googleの公式ガイドでは、linkは一般に<a href="...">の形でcrawl可能にし、anchor textはlink先を理解できる具体的で簡潔な表現にすることが案内されています。
| 避けたい例 | 改善例 | 理由 |
|---|---|---|
| こちら | Embeddingの仕組み | link先の内容が分かる |
| 詳しくはこちら | ローカルLLMに必要なPCスペック | 次の行動が具体的 |
| AI AI AI | AI記事のファクトチェック手順 | 不自然な詰め込みを避ける |
linkは関係する説明の近くに置きます。記事末尾の関連記事だけでなく、読者が疑問を持つ段落から自然につなぎます。一方で、同じ段落に大量のlinkを置かないようにします。
公開待ちのリンク先は、候補台帳に残す
下書きや予約の記事も設計台帳へ登録できますが、読者が開けないURLを公開本文へ出しません。リンクを付ける時点で、対象が公開済みで、パスワード保護されていないことを確認します。公開後にリンクを有効にする仕組みを使う場合も、IDやslugの対応を照合してください。
リンク元：読者が今解決した疑問
次の疑問：その後、何を判断する必要があるか
リンク先：その疑問を担当する記事ID・URL
公開状態：公開 / 予約 / 下書き
挿入位置：答えの直後など、本文内の具体的な箇所5．内部リンクを監査する
| 監査 | 見つけるもの | 対応 |
|---|---|---|
| 孤立ページ | 有効なinlinkが0 | 関連parent・siblingから候補を探す |
| リンク集中 | 一部ページだけ極端に多い | 意図と重要度が妥当か確認 |
| 404 | targetが存在しない | 更新・削除・適切なredirect |
| redirect chain | 複数段の転送 | 最終URLへ直接link |
| canonical不一致 | 非canonicalへlink | canonical URLへ統一 |
| 不明瞭anchor | 「こちら」だけ | 文脈に合う説明へ修正 |
Search ConsoleのLinks reportは確認材料になりますが、公式説明ではsampleであり完全な一覧ではありません。CMS exportや自サイトcrawlの結果と組み合わせます。
公開前チェックリスト
- targetは公開済みでHTTP 200か
- targetはindexableでcanonicalが正しいか
- sourceの段落から自然な次の疑問へ答えるか
- anchorだけでlink先を想像できるか
- 同じtargetやanchorを不自然に繰り返していないか
- 既存linkと重複していないか
- mobileでもlinkが押しやすく読みにくくならないか
- AI提案を人が承認したか
サイト設計の基本から始める場合はWordPressブログの始め方も参考になります。
よくある質問
内部リンクは多いほどよいですか？
数だけ増やす必要はありません。読者が関連情報へ進みやすく、sourceとtargetの関係を説明できるlinkを優先します。
AIに自動挿入させてもよいですか？
候補生成はできますが、自動挿入前に公開状態、HTTP status、文脈、anchor、重複を確認します。まずreview付きCSVで運用する方が安全です。
Search Consoleだけで孤立ページを見つけられますか？
完全ではありません。Links reportはsampleです。CMSの全公開URLとcrawlで得たlink graphを基準にし、Search Consoleを補助にします。
まとめ
AIによる内部リンク分析では、公開URL、検索意図、記事役割、index状態、現在のlinkを台帳化します。単語一致ではなく、読者の次の疑問を解決できるsource・targetを選んでください。
候補にはanchor、理由、位置、優先度、承認状態を持たせ、公開前にHTTP 200とcanonicalを確認します。記事clusterの設計はAIを使ったSEOキーワード調査、AI検索全体はAI検索時代のSEO・GEOを参照してください。