AI検索で重複URLを減らすcanonical設計｜LLMOの技術チェック
LLMO canonical設計では、正規URLの宣言だけでなく各シグナルを一致させることが重要です。AI検索の土台として重複、自己参照、JavaScript実装を確認する手順を解説します。
この記事の目次を開く
LLMO canonical設計の結論は、代表URLを一つ決め、rel="canonical"、リダイレクト、サイトマップ、内部リンクが同じURLを示す状態にすることです。正規ページには自己参照canonicalを置き、できればJavaScript実行前のHTMLで配信します。宣言タグを一行追加しただけでは、矛盾するシグナルも重複URLも消えません。
AI検索でもcanonicalの基本は通常検索と共通です。Google検索のAI機能に関する公式ガイドは、AI OverviewsやAI Modeの補助リンクになる条件として、ページが通常のGoogle検索にインデックスされ、スニペット表示の対象になれることを挙げ、追加の技術要件はないと説明しています。canonicalの役割は、検索インデックスへどのURLを代表として伝えるかを整えることにあります。
難所はタグの書式より、実際にどのURLが代表として扱われているかです。希望するURLを宣言していてもGoogleが別URLを選ぶことがあります。何をそろえ、どこまで確認すれば「実装した」から「統合を観測できた」へ進めるのでしょうか。
LLMO canonicalがAI検索の土台になる理由
同じ内容へ、末尾スラッシュの有無、計測パラメータ、並び替え条件など複数のURLで到達できることがあります。利用者に必要なURLは残しつつ、検索上の代表を定めるのがcanonicalizationです。
Googleの重複URLを統合する公式ガイドは、その目的として検索結果に出したいURLの指定、類似・重複ページが持つシグナルの統合、計測の簡素化、重複ページへのクロール時間の抑制を挙げています。2026年8月13日に再確認した同資料（資料の更新日は2026年7月10日）では、影響の強い順にリダイレクトとrel="canonical"を強いシグナル、サイトマップへの掲載を弱いシグナルと位置づけ、複数の手法は重ねられるとしています。
canonicalは、希望する代表URLを伝えるシグナルとして扱われます。Googleが別のURLを選ぶ場合があり、AI回答の引用元を指定する機能もありません。同じ公式ガイドは、要件を満たしてもクロール、インデックス、表示は保証されないと明記しています。掲載条件は、公開済みのAI Overviewsに引用されるにはでも整理しています。
先に「残すURL」と「統合するURL」を分類する
診断は全URLへ同じタグを機械的に入れる作業ではありません。URL群を次の三つに分けます。
- 独立して残すページ：検索意図や主要内容が異なり、単独で検索結果に出す価値がある
- 表示は残す重複・類似ページ：利用者はアクセスできるが、検索上は代表URLへ統合したい
- 廃止するページ：利用者にも旧URLを使わせず、恒久的に新URLへ移したい
二つ目にはrel="canonical"、三つ目には恒久リダイレクトが基本候補です。内容が十分に異なるページを、評価を集めたいという理由だけで別ページへcanonical指定してはいけません。Googleの公式資料でも、canonical要素は重複または非常によく似たページの代表を示す方法として説明されています。
分類が曖昧なままでは、テンプレートへ誤った規則が広がります。URLの発生条件と役割を表にし、規則として代表を決めます。
シグナル矛盾を一組ずつ見つける
たとえばページAのHTMLはページBをcanonicalに指定しているのに、サイトマップにはAだけが載り、サイト内リンクもAへ集中している状態です。タグだけを見れば正しくても、サイト全体では「Bが代表」と「Aが代表」が競合しています。
最低限、同じURL群について次を横断します。
- HTTPステータスとリダイレクト先
- HTMLの
rel="canonical"とHTTPレスポンスのLinkヘッダー - XMLサイトマップに載せるURL
- ナビゲーション、パンくず、関連記事などの内部リンク先
hreflangで組む言語・地域URLと、そのcanonical先- HTTP／HTTPS、www有無、末尾スラッシュ、大文字小文字、パラメータの扱い
判断基準は単純です。廃止URLは代表へリダイレクトし、表示を残す類似URLは代表へcanonicalを向け、サイトマップと通常の内部リンクには原則として代表URLを使います。Googleも、手法ごとに異なるcanonicalを指定しないこと、内部リンクでは重複URLよりcanonical URLへリンクすることを推奨しています。
JavaScriptサイトでは宣言が実行後のDOMにだけ現れていないかも確認します。JavaScriptサイトのLLMO対策に沿って、初期HTML、レンダリング後のDOM、HTTP状態を同じURLで比較すると、正規化シグナルが途切れる層を切り分けられます。
代表URLへリンク先をそろえるだけでなく、どの記事からどの判断へ案内するかはLLMOの内部リンク設計で分けて整理しています。canonicalは重複URLの統合、内部リンクは読者と検索システムが関連情報へ到達する経路として、それぞれの役割を混同しません。
robots.txtで重複URLをブロックして解決しようとすると、Googleがページ本文やcanonical宣言を取得できません。公式ガイドはrobots.txtをcanonicalizationに使わないよう案内しています。サイト内の重複をまとめる目的でnoindexを使うことも推奨されず、rel="canonical"が選択肢になります。
自己参照canonicalは代表URLの基準点になる
正規ページ自身にも、自分の絶対URLを指す自己参照canonicalを置きます。
<head>
<link rel="canonical" href="https://example.com/products/widget" />
</head>
自己参照があると、意図するホスト名、プロトコル、パス表記を明示できます。Googleも自己参照要素を推奨し、相対URLより、環境の取り違えを避けやすい絶対URLを勧めています。
ただし、全ページに同じ固定URLを出力すれば逆効果です。テンプレートで現在のURLを組み立てる場合は、計測パラメータを残していないか、プレビュー用ホスト名が混ざらないか、ページネーションや多言語URLで規則が崩れないかを代表サンプルで確認します。<head>外に出たcanonical要素は受理されないため、HTMLの構造も検査対象です。
JavaScript実装は「ソース」と「描画後」を分けて診断する
SPAやクライアントサイドルーティングでは、画面遷移後にcanonicalを書き換える実装があります。ブラウザの開発者ツールで最終DOMだけを見ると正しく見えても、サーバーが返したHTMLには別URLがあり、JavaScriptが後から変更しているかもしれません。
2026年8月13日時点のGoogle公式ガイドは、クライアントサイドレンダリングではHTMLソースにcanonicalを指定し、JavaScriptで変更しない方法が最も明確だと案内しています。HTMLで設定できずJavaScriptだけで設定するなら、HTML側には矛盾するcanonicalを置かず、JavaScriptから適切に注入します。
検査では次の三つを同じURLで比べます。
curlやネットワーク応答で取得した配信直後のHTML- ブラウザでJavaScript実行後に生成されたDOM
- Search ConsoleのURL検査でGoogleが取得したHTMLとcanonical情報
値が違えば、CMS、SSR、CDN、フロントエンドのどの層が書き換えたかを追います。HTTPのLinkヘッダーとHTML要素は不一致が起きやすく、Googleも一方を選ぶことを勧めています。PDFなど非HTML文書ではHTTPヘッダーを使えます。
Search Consoleで宣言と選択を分けて確認する
公開後はソースコードの確認だけで完了にしません。Search ConsoleのURL検査には「ユーザーが指定した正規URL」と「Googleが選択した正規URL」があります。前者は実装した希望、後者はGoogleが類似ページ群から選んだ結果です。
URL検査ツールの公式ヘルプによると、Googleが選んだ正規URLを判断できるのはインデックス済みデータであり、ライブテストはテスト対象が最終的にcanonicalとして選ばれるかを予測しません。ライブテストが成功しただけで統合済みとは判断できない点が重要です。
確認は代表URLだけでなく、代表へ寄せたい重複URLでも行います。
- 代表URL：自己参照の宣言になり、Googleの選択も同じか
- 重複URL：宣言先が代表URLで、Googleの選択も代表URLか
- 取得HTML：意図したcanonicalが一つだけあり、JavaScript実装と矛盾しないか
- 周辺シグナル：サイトマップ、内部リンク、リダイレクトが代表URLを支持するか
選択が一致しないときはタグを再送するだけでなく、内容の類似性、内部リンク、リダイレクト、サイトマップ、HTTPS、hreflangまで戻って矛盾を探します。変更直後の検査結果は以前のクロール時点を示す場合があるため、取得日時も記録して再クロール後に比較します。
実装前後のチェックリスト
- 代表URLをURL群ごとに一つ決めた
- 独立ページ、表示を残す類似ページ、廃止ページを分類した
- 正規ページはHTTP 200を返し、自己参照canonicalを持つ
- canonicalは絶対URLで、
<head>内に一つだけある - リダイレクト、サイトマップ、内部リンク、
hreflangが矛盾しない - robots.txtや
noindexを重複統合の代用にしていない - 配信HTML、描画後DOM、Google取得HTMLを比較した
- Search Consoleで宣言した正規URLとGoogleが選んだ正規URLを確認した
すべてにチェックが付いた状態は、正規URLの判断を妨げる技術的な矛盾を減らし、観測可能にできたことを示します。AI回答への引用や検索順位、流入は、その後も保証されません。
canonical設計の完了条件
冒頭の問いへの答えは、「タグがある」では足りません。代表URLに自己参照canonicalがあり、重複URLからの指定、リダイレクト、サイトマップ、内部リンクが同じ代表を示し、配信HTMLと描画後DOMにも食い違いがないこと。そのうえでSearch Console上のGoogle選択canonicalまで確認できれば、実装と観測を分けた診断になります。
GoogleのAI機能も通常検索のインデックスを土台にしています。重複した入口を整理し、どのページを代表として理解してほしいかを一貫して伝える原則は、AI検索でも変わりません。LLMO canonical設計の完了条件は、各シグナルが同じ代表URLを指し、Search Consoleで宣言とGoogleの選択を分けて確認できることです。これは引用、順位、流入を約束する施策ではなく、検索システムがページを選べる状態を整える技術作業です。