言語

カノニカル化

検索エンジンが重複 URL から代表 URL を 1 つ選び、ランキングシグナルをそこへ統合する方法を説明します。rel=canonical がヒントであってルールではない理由、シグナルをそろえる方法、検証時の限界を扱います。

初回公開：2026年6月23日 · 最終更新：2026年8月22日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

カノニカル化は、同じまたはほぼ重複するコンテンツを提供する複数の URL から、検索エンジンが代表 URL を 1 つ選び、リンク、PageRank、アンカーテキストなどのランキングシグナルをそこへ統合する仕組みです。最も重要なのは rel=canonical がルールではなくヒントだという点です。Google は重複をクラスタ化し、rel=canonical、リダイレクト、サイトマップ掲載、内部リンク、HTTPS、URL 形式などのシグナルでカノニカルを選び、宣言を上書きすることもあります。カノニカルは 301 でも noindex のようなインデックス登録ディレクティブでもありません。すべてのシグナルを同じ URL に向け、Search Console で選択されたカノニカルを確認します。

TL;DR — カノニカル化は、クラスタ化・選択・統合の 3 つです。Google はコンテンツのチェックサムやフィンガープリントで重複を検出し、クラスタ化し、その中から 1 つをカノニカルに選び、リンク、PageRank、アンカーテキストなどのランキングシグナルをそこへ統合します。rel="canonical" は強いヒントであって指示ではありません。Google はこれを上書きでき、実際に上書きすることもあります。その結果は GSC の「Duplicate, Google chose different canonical than user」に現れます。評価するシグナルは増えており、Illyes が 2020 年に述べた約 20 個から、Google の Allan Scott が 2025 年までに述べた約 40 個まで広がっています。rel=canonical の注釈、リダイレクト、サイトマップ掲載、内部リンク、HTTP より HTTPS、長い URL より短い URL などです（リダイレクトのほうが HTTPS シグナルより強いなど、重みは同じではありません）。カノニカルは 301 ではなく、noindex のようなインデックス登録ディレクティブでもありません。すべてのシグナルを 1 つの URL に向け、自己参照カノニカルを使い、Search Console の URL Inspection で選択結果を確認します。

カノニカル化の実体

Canonicalization sits between duplicate URLs and the index — deciding which one URL represents the group. 出典： /technical-seo/how-search-works/indexing/canonicalization/

Three reachable duplicate URL variants feed a canonicalization decision. A separate bundle of signals also feeds the decision: rel=canonical, redirects, sitemap inclusion, internal links, and HTTPS. The decision selects one representative canonical URL, which may be indexed and shown in search while cluster signals consolidate onto it. The other duplicate URLs remain reachable rather than being deleted.

© Patrick Stox LLC · CC BY 4.0 ·

Google の定義は明確です。“Canonicalization is the process of selecting the representative –canonical– URL of a piece of content,” (翻訳) 「カノニカル化とは、あるコンテンツを代表する「カノニカル」URL を選ぶプロセスです。」 また、“a canonical URL is the URL of a page that Google chose as the most representative from a set of duplicate pages.” (翻訳) 「カノニカル URL とは、重複ページの集合から Google が最も代表的だと選んだページの URL です。」 Evidence for this claim Google groups similar pages and selects a representative canonical URL for the cluster. Scope: Google Search canonical selection for duplicate or very similar content. Confidence: high · Verified: Google Search Central: In-depth guide to how Google Search works 私の Ahrefs のカノニカル化ガイド では、実際には 2 つの仕事があると説明しています。“Clustering creates a cluster of duplicate pages, and canonicalization chooses which version signals consolidate to and what page will be shown in search results.” (翻訳) 「クラスタ化は重複ページのクラスタを作り、カノニカル化はシグナルをどのバージョンへ統合するか、検索結果にどのページを表示するかを選びます。」

順番に、次の 3 つが起きています。

  1. 重複またはほぼ重複する URL を検出してクラスタ化する。
  2. その中から 1 つをカノニカルとして選ぶ。
  3. 選んだ URL にランキングシグナルを統合する。

この 3 つを正しく分けて考えれば、カノニカル化をめぐる混乱の大半は解消します。

なぜ重要なのか

Google は、重複を道徳的な問題ではなく、主にユーザー体験とレポートの問題だと率直に説明しています。“having the same content accessible through many different URLs can be a bad user experience… and it may make it harder for you to track how your content performs in search results.” (翻訳) 「同じコンテンツを多くの異なる URL から利用できると、ユーザー体験が悪くなり、検索結果でのコンテンツの成果を追跡しにくくなる可能性があります。」 大半の重複は悪意ではなく、パラメーター、ファセットナビゲーション、プロトコルやホストの違い、セッション ID といった通常の技術的な事故です。

本当の効果は 4 つの面に現れます。「カノニカル化は SEO に役立つ」という曖昧な一言ではなく、それぞれを正確に見ておきましょう。

  • クラスタの所属。 重複 URL は 1 つのクラスタにまとめられ、カノニカルはそのクラスタの代表になります。
  • 相対的なクロール頻度。 Google によれば、カノニカルページはより定期的にクロールされ、重複ページは頻度が下がります。これは冗長なクロールを減らす相対的な効果であり、1 ページをカノニカル化すれば直ちに別の場所の予算が空く、または無関係なページのインデックス登録が速くなる、という保証ではありません。
  • コンテンツと品質の評価。 Google は通常、カノニカルをコンテンツの品質と関連性を評価する主な情報源にします。
  • 表示される URL。 検索結果は通常カノニカルへリンクしますが、常にそうなるとは限りません。デバイス専用版など、ユーザーに適していれば Google が重複版を表示することもあります。

Google の文書は、シグナルの役割を次のように説明しています。カノニカルを宣言すると、“helps search engines to be able to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL.” (翻訳) 「検索エンジンが個々の URL（そこへ向かうリンクなど）のシグナルを、単一の優先 URL に統合できるようにする」 としています。ただし、これは対象が実際にカノニカルになることが条件です。宣言したカノニカルが、重複ページの PageRank、アンカーテキスト、ランキング価値を自動的にすべて取り込む保証ではありません。シグナルが食い違って Google が別の URL を選べば、意図した形では統合されません。

重複の一部は、それだけでスパムポリシー違反になるものではありません。カノニカル化の実務上の理由は、ユーザーにとっての分かりやすさ、よりきれいなレポート、一貫した検索 URL、シグナルの統合、重複クロールの削減です。ペナルティへの恐れが理由ではありません。制御されていない重複は発生源で直す価値があります。これはカノニカル化そのものより crawl budget と faceted navigation の問題ですが、互いに関係しています。

Google がカノニカルを選ぶ方法

Canonicalization is three jobs, not one: cluster, select, consolidate. 出典： /technical-seo/how-search-works/indexing/canonicalization/

Step one fingerprints duplicate URLs and groups them into a cluster. Step two selects one URL as canonical while the others remain reachable alternates. Step three consolidates links, PageRank, and anchor text from the cluster onto the selected canonical.

© Patrick Stox LLC · CC BY 4.0 ·

多くのガイドが曖昧に済ませる部分なので、ここでは手順を分けて説明します。

ステップ 1 — 重複の検出

Google はページのコンテンツをフィンガープリント化して重複を探します。Gary Illyes は Search Off the Record で、“A checksum is basically a hash of the content. Basically a fingerprint.” (翻訳) 「チェックサムは基本的にコンテンツのハッシュであり、フィンガープリントです。」 と説明しました。フィンガープリントが一致または近いページは、ナビゲーションやフッターなどの定型部分が大きく割り引かれたうえで、重複候補になります。

Google の現在の文書は、チェックサムの仕組みを説明せず、同じ考え方をより平易に示しています。インデックス登録中に各ページの 主要コンテンツ を比較し、同じ、または非常に似たページをクラスタ化します。Google はフィンガープリントの詳細や、どの程度定型部分を割り引くかを正確には公開していません。したがって Illyes のチェックサムという説明は、2020 年の会話に基づく方向性の説明として扱い、文書化されたアルゴリズムそのものとはみなさないでください。

ステップ 2 — クラスタ化

重複 URL は クラスタ にまとめられます。クラスタ内のすべての URL がカノニカル候補になり、最終的には 1 つだけが選ばれます。

ステップ 3 — クラスタからの選択

ここで Google が選びます。使われるシグナルの集合と、公開される個数は時間とともに増えています。2020 年に Illyes は “we employ, I think, over twenty signals, we use over twenty signals, to decide which page to pick as canonical.” (翻訳) 「カノニカルとしてどのページを選ぶかを決めるため、20 個を超えるシグナルを使っていると思う」 と述べました。2025 年には、私の Ahrefs のカノニカル化ガイド で触れたように、“According to Google’s Allan Scott, there are ~40 different canonical selection signals.” (翻訳) 「Google の Allan Scott によれば、カノニカル選択シグナルは約 40 個あります。」 とされています。これは矛盾ではなく、Google が時間とともにより多くを公に説明したという意味です。

Google 自身の文書は、いくつかの要因を明示しています。“There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations.” (翻訳) 「カノニカル化には、HTTP と HTTPS のどちらでページを配信するか、リダイレクト、サイトマップ内の URL の存在、rel=“canonical” リンク注釈など、いくつかの要因が関係します。」 よく挙げられる要因を広げると、重複、カノニカルリンク要素、サイトマップ URL、内部リンク、外部リンク、リダイレクト、hreflang、x-default hreflang、PageRank、HTTP より HTTPS、長い URL より短い URL などです。

どのシグナルがより強いのか

シグナルの重みは同じではありません。Illyes は、“301 redirect, or any sort of redirect actually, should be much higher weight… than whether the page is on an http URL or https.” (翻訳) 「301 リダイレクト、実際にはどの種類のリダイレクトでも、ページが http か https かよりはるかに高い重みを持つべきです。」 と明言しました。またカノニカルタグ自体を “quite a strong signal” (翻訳) 「かなり強いシグナル」 と呼びました。強いものの、より強い矛盾したシグナルに負けることはあります。私の カノニカル化ガイド で説明したとおり、カノニカルタグは “is sometimes referred to as a hint because it’s just one canonicalization signal, but it is considered a strong signal. Google ignores it if other signals are stronger.” (翻訳) 「カノニカル化シグナルの 1 つにすぎないためヒントと呼ばれることがありますが、強いシグナルとみなされます。他のシグナルが強ければ Google は無視します。」。

なぜヒントであり指示ではないのか

このテーマの正確さを支える中心はここです。Google は、“You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.” (翻訳) 「これらの方法で Google に希望を示せますが、さまざまな理由で Google があなたとは別のページをカノニカルに選ぶことがあります。つまり、カノニカルの希望を示すことはヒントであり、ルールではありません。」 Evidence for this claim Canonical declarations express a preference; Google can select a different canonical based on its signals. Scope: Google Search canonicalization; redirects and rel=canonical are strong signals while sitemap inclusion is weaker. Confidence: high · Verified: Google Search Central: How to specify a canonical URL 宣言したカノニカルが負けると、Search Console に 「Duplicate, Google chose different canonical than user」 と表示されます。これは、“means that Google chose a different URL to index than the one the user selected.” (翻訳) 「ユーザーが選択した URL とは異なる URL を Google がインデックス登録用に選んだことを意味します。」。“add a stronger tag” (翻訳) 「もっと強いタグを追加する」という対応はほとんど役に立たず、解決策は矛盾するシグナルをそろえることです。

カノニカルを指定する方法

Google は最初に、“none of them are required; your site will likely do just fine without specifying a canonical preference,” (翻訳) 「どれも必須ではなく、カノニカルの希望を指定しなくてもサイトはおそらく問題なく機能します。」 と説明しています。それでも実務では意図を明確にします。現在の文書では、これらの方法を積み重ねられるとも説明されています。強く整合したシグナルを複数使うと、どれか 1 つだけで保証することはできなくても、望む URL が選ばれる可能性を高められます。主な方法は次のとおりです。

  • rel="canonical" リンク要素 — <head> 内の 1 行です。最も一般的な方法で、Google は “a strong signal that the specified URL should become canonical.” (翻訳) 「指定した URL がカノニカルになるべきだという強いシグナル」 と呼んでいます。必ず <head> に置きます。閉じていないタグや、JavaScript で <body> に移されたタグは Google に無視されます。ページごとに 1 つだけ宣言してください。複数あると Google はすべて無視します。
  • rel="canonical" HTTP ヘッダー — PDF のような非 HTML ファイルにはタグを置く <head> がないため、HTTP レスポンスヘッダーで指定します。
  • リダイレクト — “a strong signal that the target of the redirect should become canonical.” (翻訳) 「リダイレクト先がカノニカルになるべきだという強いシグナル」 です。コンテンツを実際に移動するなら 301 を使います。
  • サイトマップへの掲載 — “a weak signal that helps the URLs that are included in a sitemap become canonical.” (翻訳) 「サイトマップに含まれる URL がカノニカルになるのを助ける弱いシグナル」 です。サイトマップにはカノニカル URL だけを載せます。
  • 内部リンク — 望むバージョンへ一貫してリンクします。内部リンクが一貫しないことは、シグナルが衝突する最も一般的な理由の 1 つです。

自己参照カノニカルとドメイン間カノニカル

自己参照カノニカルとは、インデックス登録可能なページのカノニカルが自分自身を指すことです。インデックス登録したいすべてのページでのベストプラクティスです。他のシグナルが曖昧でも希望を明示でき、重複に見えるパラメーター付きコピーを打ち消せます。

ドメイン間カノニカルもサポートされています。シンジケーションなどで、管理している別ドメインの URL をページのカノニカルに指定し、そこへ統合できます。注意すべき失敗モードは 乗っ取り（hijacking） です。私の カノニカル化ガイド でも、“In some really bad scenarios, a page on the wrong domain may be shown. This is referred to as hijacking.” (翻訳) 「非常に悪いシナリオでは、間違ったドメインのページが表示されることがあります。これは乗っ取りと呼ばれます。」 と警告しています。まれですが、ドメイン間カノニカルには慎重さが必要な理由です。

エッジケース：実際に何が重複なのか

「重複」と誤って分類されやすい状況は主に 5 つあります。共通するパターンは、URL の特徴（?、ページ番号、言語フォルダー、スクリプトタグ）だけで決めず、レンダリング後の主要コンテンツが実際に何であるかで判断することです。

状況重複として扱う？理由
トラッキングまたはセッションパラメーター（?utm_source=、?sessionid=）通常は yes主要コンテンツが同じなので、きれいな URL へ安全にカノニカル化できます。
フィルター、並べ替え、ファセットパラメーター（?color=red、?sort=price）自動的には扱わない基本ページとは実質的に異なるコンテンツや意図を生成する可能性があるため、消す前に表示内容を確認します。
ページ分割（/page/2/）いいえGoogle はシリーズの各ページを固有の主要コンテンツを持つ別ページとして扱います。各ページに固有 URL と自己参照カノニカルを設定し、ページ 1 を指すカノニカルにはしません。
完全に翻訳されたページいいえテンプレートが同じでも、別言語のコンテンツは原文の重複ではありません。カノニカルではなく hreflang で関連付けます。
同じ言語の地域バリエーション（ほぼ同じ en-US と en-GB など）場合による通常の重複のようにクラスタ化されることがあります。同じ言語内でカノニカルの希望を保ち、相互 hreflang と組み合わせて正しい地域 URL が表示される機会を残します。

次の 2 つの実装上の細部は、十分な頻度で黙って失敗するため、個別に確認する価値があります。

  • JavaScript で設定するカノニカル。 Google の案内は、値の明確な情報源を 1 つにすることです。初期 HTML に置いて JavaScript で上書きしないか、それが無理なら HTML には置かず JavaScript だけで設定します。ソースにカノニカルを宣言したうえでスクリプトで変更することが失敗の本体です。1 ページから 2 つの矛盾したシグナルが出るからです。
  • 非 HTML ファイル。 PDF や Word 文書などの rel="canonical" HTTP ヘッダーは、特に Google ウェブ検索結果でサポートされます。すべての Google サーフェスに共通するシグナルではありません。絶対 URL を使い、ファイル自身のメタデータが矛盾するカノニカルを宣言しないようにします。

Google が選んだカノニカルを確認する方法

HTML を真実の情報源だと思わないでください。真実は Google の選択です。私は次のように説明しています。“Your main source of truth for what Google chose as the canonical will be the URL Inspection tool in Google Search Console. Enter the URL, and it will show what the declared canonical is and what Google chose as the canonical.” (翻訳) 「Google がカノニカルとして何を選んだかを知るための主な真実の情報源は、Google Search Console の URL Inspection ツールです。URL を入力すると、宣言したカノニカルと Google が選んだカノニカルが表示されます。」 2 つが一致しなければ、すべてのシグナルをそろえる合図です。

この項目を絶対視する前に、知っておくべき境界がいくつかあります。

  • インデックス登録済みの状態を示し、ライブ確認ではない。 URL Inspection の Google 選択カノニカルは、Google がすでにインデックス登録した内容から得られます。同じツールのライブテストは現在のシグナルを示せますが、Google が何を選ぶかは予測できません。インデックス登録済みの項目はリアルタイムではなく、過去の状態として扱います。
  • 自分が所有するプロパティに限られる。 Search Console でアクセス権を持つプロパティ内の URL についてのみ、カノニカル情報を確認できます。任意の第三者ページは対象外です。
  • 監査ツールは入力を観測し、Google の決定は観測しない。 上の Canonicalization Checker のようなツールは、HTML、ヘッダー、リダイレクトなど送信しているシグナルを表示します。Google が実際に選んだものを伝えられるのは URL Inspection だけです。
  • 掲載、時期、ランキングの保証はない。 意図した URL がカノニカルに選ばれても、インデックス登録される保証、固定された時期、トラフィックやランキングの保証はありません。カノニカル化が決めるのは代表性であり、それらの結果ではありません。

よくあるカノニカル化の失敗

私が繰り返し目にするものです。いくつかは、私自身がまとめたよくある失敗の一覧から取っています。

  • 本番のカノニカルをステージングサイトの保護に使う。 https://staging.example.com/pricing/ のステージングページが https://example.com/pricing/ をカノニカルに指定しても、Google がシグナルを調整する間にクロール、クラスタ化、さらには表示される可能性があります。カノニカルが示すのはどの重複を優先するかであり、ステージング URL を非公開にしたり、削除を指示したりするものではありません。ステージングホストが検索に漏れた場合、Google がディレクティブを処理するまでは noindex を付けたままクロール可能にするか、本番に恒久的な置き換え URL があるならリダイレクトします。決して公開してはいけない環境には認証を必須にします。
  • 重複ではないページへカノニカル化する。 無関係なページをカノニカルに指定すると、Google に同じものだと伝えることになり、検索結果から「重複」を落とされる可能性があります。カノニカルは本物の重複のために使います。
  • 同じ URL にカノニカルと noindex を置く。 矛盾する指示です。John Mueller は相反するシグナルの組み合わせについて、“I’d just pick one (noindex or followed links). Links on a noindexed page can be picked up, but it’s not guaranteed.” (翻訳) 「どちらか 1 つ（noindex またはリンクをたどること）を選びます。noindex ページのリンクが拾われることはありますが、保証はありません。」 と説明しています。どちらか 1 つを選びます。
  • カノニカル化した URL を robots.txt でブロックする。 Google は、“Don’t use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content.” (翻訳) 「カノニカル化の目的で robots.txt ファイルを使わないでください。Google は robots.txt で許可されていない URL を、コンテンツなしでインデックス登録することがあります。」 と明言しています。ブロックされたページは、カノニカルタグを見るために読むことさえできません。
  • カノニカル化した URL が 4XX を返す。 重複側がエラーになれば、シグナルを統合する先がなくなります。
  • ページ分割されたすべてのページをページ 1 へカノニカル化する。 シリーズの各ページは異なるコンテンツです。ルートへまとめないでください。
  • カノニカルチェーンや矛盾するリダイレクト。 いったん別 URL へリダイレクトする URL をカノニカルに指定すると、Google はきれいなシグナルをたどる代わりに矛盾を解く必要があります。カノニカルは最終到達先を直接指します。
  • カノニカルを複数宣言する、または <body> に置く。 <body> への配置は受け入れられません。複数宣言も衝突であり、先勝ち・後勝ちの信頼できる結果はありません。

神話を検証する

  • 「カノニカルタグがランキングまたはインデックス登録 URL を保証する。」 いいえ。これはヒントであり、Google は別の URL を選べます。GSC の「Duplicate, Google chose different canonical than user」はまさにその状態を報告します。
  • “rel=canonical is the same as a 301 redirect.” (翻訳) 「rel=canonical は 301 リダイレクトと同じです。」 いいえ。301 はページを移動する指示で、カノニカルは両方の URL を到達可能なままにする統合のヒントです。Bing も、コンテンツを移動するならカノニカルではなく 301 を使うべきだと長く説明しています。URL を廃止するならリダイレクトします。
  • 「カノニカルは noindex のようにインデックス登録を止めたり通したりする。」 いいえ。カノニカルはインデックス登録ディレクティブではありません。noindex と組み合わせると矛盾するシグナルになるため、どちらか一方を使います。
  • 「カノニカルタグを増やすほど強いシグナルになる。」 逆です。複数宣言すると Google はすべてを無視します。

Bing と他のエンジン

Bing も同じ基本要素を使います。Bing が 2025 年 12 月に示した見解では、“Duplicate content doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems.” (翻訳) 「重複コンテンツは、それだけで検索ペナルティを引き起こしません。しかし権威を分散させ、意図を混乱させ、検索エンジンと AI 検索システムの双方に更新が届く速度を遅くすることで、可視性を下げます。」 また、“Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” (翻訳) 「カノニカルタグ、リダイレクト、hreflang、noindex、IndexNow はすべてこの明確さを支えますが、土台は不要な重複を避けた整理されたサイトです。」 とされています。Bing Webmaster Tools には URL Normalization 機能もあり、コード変更なしでパラメーターのバリエーションを統合できます。重複が URL パラメーター から生まれる場合に便利です。

次に読む場所

このページは、親テーマであるカノニカル化の概念ハブです。検索の仕組みの中では、より広い インデックス登録 段階に位置します。カノニカル化が、重複クラスタのどの URL を実際にインデックス登録するかを決めるからです。以下の 3 つの詳しい記事では、それぞれをさらに掘り下げます。

  • カノニカルタグ（rel=canonical） — タグそのもの、正確な構文、<head> と HTTP ヘッダーでの実装、自己参照パターン、無視されるすべての理由。
  • 重複コンテンツ — 何が実際に重複に当たるか、なぜペナルティではないか、タグで後付け修正するのではなく発生源で防ぐ方法。
  • URL パラメーター — 重複を最も多く生む要因。トラッキング、並べ替え、フィルター、セッションパラメーターと、無限のバリエーションへページを分断させない方法。

カノニカル化はこのクラスタの兄弟テーマにも関係します。重複とパラメーターの乱立は crawl budget を浪費し、faceted navigation はほぼ重複する URL の主な発生源です。spider traps は、重複を爆発させる無限の URL 空間を生成します。発見、クロール、レンダリング、インデックス登録、表示までパイプライン全体を見るには、How Search Works クラスタを参照してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.