AI時代のSEO

自社名の言及とリンクを分けて残す、AI検索の引用URL台帳

AI検索の引用URLを、自社名への発言とクリック可能なリンクに分け、観測先・最終到達先・回答範囲を残して正規化と重複排除を進める実務手順を、五列の判定表とともに解説します。

株式会社adding LLMO編集部#llmo#seo
この記事の目次を開く

AI検索の引用URLは、自社名が書かれた「発言」と、自社サイトへ移動できる「リンク」を別々に判定します。さらにリンクは、回答画面で見えたリンク先と、転送後の最終URLを上書きせずに残します。これで、言及されたのにリンクがない回答と、社名の近くにはなくても自社ページが参照された回答を混同しません。

ただし、URLの表記が違うだけで同じページへ着く場合まで別件にすると、集計は膨らみます。見た目が似ているURLを早々に統合しても、別ページだった証跡を失います。この境界は、観測値を保存する列と、重複整理に使う列を分ければ扱えます。

AI検索の引用URLを五つの列に分ける

運用上の提案として、一回の観測を「発言・引用・リンク先・最終URL・回答範囲」の五列で一行にします。質問群やプロンプトの設計は別の管理対象です。この台帳には、回答を観測した後に確認できた内容だけを入れます。

列残す内容判定の要点
発言自社名や自社サービスについて回答が述べた箇所クリックできるかとは無関係に記録する
引用回答中に表示された出典表示の有無と対応箇所単なる社名表記を引用扱いしない
リンク先回答画面で観測したURL転送後のURLで置き換えない
最終URL実際に到達したURL重複整理の候補キーにする
回答範囲その引用が支えている回答の見出しや段落回答全体を支えると決めつけない

「発言」は回答内容の記録で、「引用」は出典表示の記録です。「リンク先」はUIから得た証跡で、「最終URL」は遷移結果です。似た語を隣に置くのは、どれか一つから残りを推測しないためです。

2026年9月21日時点で、Google Search Centralは、Google検索のAI OverviewとAI Modeが回答とともに関連リンク、または回答を支えるウェブサイトへのリンクを表示すると説明しています。同時に、両機能で使うモデルや手法が異なる場合があり、回答とリンクの組み合わせは変動し得るとも述べています。Google検索のAI機能に関する公式説明から導けるのは、観測した組み合わせをその時点の一行として残す必要性です。他社のAIサービスの表示仕様まで同じだとは扱いません。

言及とリンクを混ぜない判定表

観測後は、まず発言と自社リンクの有無を交差させます。社名の有無だけで「引用された」と判定せず、自社ドメインへのクリック可能なリンクがあるかを独立して確認します。

回答内の自社への発言自社サイトへのリンク台帳上の判定記録方法
あるある言及とリンクの両方発言、引用、リンク先をそれぞれ埋める
あるない言及のみ発言を残し、リンク先を「なし」とする
ないあるリンクのみ発言を「なし」とし、引用とURLを残す
ないない自社の言及・リンクなし空欄にせず「なし」を明示する
判断できない判断できない要確認推測で補わず、確認できない範囲を記す

この表なら、「社名が出た回数」と「自社ページへリンクされた回数」を後から別々に扱えます。発言のすぐ横にリンクが見えても、そのリンクが別の記述を支えているなら、回答範囲に対応箇所を残します。位置が近いことだけを根拠に、自社への発言を支える引用だと結び付けません。

引用表示が複数ある回答では、リンクごとに行を分けます。同じ発言が複数行に現れても、リンク先と回答範囲を一対一で追えるほうを優先します。一つの引用が一続きの段落を支える場合は、その範囲を一行へ残します。台帳の一行は「一つのリンクと、それが対応する回答範囲」の単位です。

観測URLと最終URLは上書きしない

回答画面で取得したリンク先を開くと、別のURLへ転送されることがあります。このときリンク先列を到達後のURLで書き換えると、回答が実際にどのURLを示していたか分からなくなります。

運用上の提案は、リンク先列へ観測した文字列をそのまま保存し、転送後の到達先だけを最終URL列へ入れることです。転送がなければ両列が同じでも構いません。確認できなければ、最終URLを推測で埋めず「未確認」とします。

2026年9月21日時点のHTTP Semantics(RFC 9110)では、301と308は対象リソースに新しい恒久URIが割り当てられ、今後の参照では提示された新URIを使うべき状態を表します。RFC 9110の301と308の定義を根拠に、恒久転送で得た新しいURIは重複整理の候補キーにできます。ただし、観測時のリンク先を消してよいという意味ではありません。旧URLが回答に出ていた事実と、新URLへ到達した事実を並べて保持します。

転送先を含めたページ側のURL設計は、AI検索を意識したcanonical設計と切り分けます。引用URL台帳は、観測したリンクと到達結果を壊さずに残すために使います。

正規化してから重複を判定する

文字列の完全一致だけでは、同じHTTP(S) URIの表記差を別件にしてしまいます。とはいえ、URL全体を小文字にする処理も危険です。どこを揃え、どこを維持するかを先に固定します。

2026年9月21日時点のRFC 9110が示すHTTP(S) URIの正規化規則に沿い、重複判定用の値には次を適用します。

  • schemeとhostを小文字へ揃える
  • 既定ポートを省く
  • OPTIONSリクエストの対象を除き、空のpathを「/」として扱う
  • 非予約文字に対する不要なパーセント符号化を解除する
  • それ以外の構成要素は大文字小文字を維持する

正規化の対象は、標準が同一と扱える表記差に限ります。pathやqueryまで一律に小文字化してはいけません。

重複整理の判断順は次のようになります。

条件集約判断元データの扱い
観測URLが異なり、正規化済み最終URLが同じ同じ到達先の候補としてまとめる各観測URLは残す
恒久転送の前後でURLが異なる新URIを候補キーにする転送元と転送先を両方残す
pathまたはqueryの大文字小文字だけが異なる自動ではまとめない別行のまま確認対象にする
最終URLを確認できない観測URLだけで確定的に統合しない未確認として保持する
回答範囲が異なるURLが同じでも観測行は残す集計時だけURL単位に束ねる

同じ内容に複数URLがあると計測値をまとめにくくなることは、2026年9月21日時点でGoogleもcanonical URLを指定する理由の一つに挙げています。Googleの重複URLとcanonicalに関する公式説明はGoogle検索向けの説明であり、他社AIの要件には一般化しません。一方、「観測URLを証跡として保持し、正規化済み最終URLを集約キーにする」という台帳設計なら、元の表示を失わずにURL単位の整理ができます。

集約後の件数を評価指標へつなぐ場合も、観測と評価は分けます。LLMOのKPI設計で扱う評価軸へ渡すのは正規化済みの集計値であり、この台帳には評価結果を逆流させません。良い・悪いという判定で観測行を消すと、後から正規化規則を見直せなくなるためです。

台帳を更新するときの確認順

回答を保存したら、発言の有無、出典表示、リンク先、遷移後の最終URL、引用が対応する回答範囲の順で埋めます。その後にURLを正規化し、同じ集約キーを持つ行を束ねます。この順番なら、重複を消してから証跡不足に気付く事態を避けられます。

更新時の判断は、次の状態へ限定します。

  • 「なし」は観測して存在しなかった状態
  • 「未確認」は確認作業が終わっていない状態
  • 「要確認」は対応範囲や同一性を決められない状態

空欄を三つの意味で使い回さないことが重要です。リンクがない回答と、リンク確認をしていない回答が混ざれば、言及とリンクを分けた意味がなくなります。

また、同じ問いを後日観測して回答やリンクが変わった場合、以前の行を更新して最新状態だけにしません。Google検索のAI機能については回答とリンクの組み合わせが変動し得ると公式に説明されているため、観測時点ごとの組み合わせを残します。目的は、異なる時点の表示を同一の事実として混ぜないことです。

観測の証跡から確定できる範囲

この台帳から確定できるのは、観測時点にどの発言があり、どの引用表示からどのURLへ進み、最終的にどこへ着き、回答のどこに対応していたかです。言及がリンクを生んだ、リンクが流入を増やした、といった因果は台帳だけでは判断しません。

2026年9月21日時点で、Google Search Centralは、ページが要件やベストプラクティスを満たしていても、Google検索のAI機能におけるクロール、インデックス登録、表示は保証されないと明記しています。Google検索のAI機能の技術要件を踏まえても、引用やリンクの獲得効果を保証する用途にはできません。

五列の証跡を埋めれば、観測ごとの扱いを確定できます。自社名が書かれていてリンクがなければ「発言あり・リンク先なし」、リンクがあって社名への発言がなければ「発言なし・リンクあり」です。正規化済み最終URLが一致する行は集計時に束ね、観測URLと回答範囲は各行に残します。これで、重複を整理した後も元の回答へ戻り、言及とリンクを個別に再確認できます。