Google により異なるページが正規ページとして選択された重複の対処法

「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」（英語版では "Duplicate, Google chose different canonical than user"）は、そのページが正規 URL を指定しているものの、Google が類似ページとまとめたうえで別の URL を正規 URL としてインデックスに登録したため、この URL が検索結果に表示されない状態を意味します。問題かどうかは、Google がどの URL を選んだかで決まります。それが実際にユーザーに訪れてほしいアドレスなら、タグを直すだけで済みます。別のページ、古いバリエーション、あるいは他のウェブサイトであれば、サイトが矛盾したシグナルを送っているので修正が必要です。

Google によるこのステータスの説明

Google のページ インデックス登録レポートのドキュメント（2026 年 10 月に確認）は、このステータスを、一連のページの正規ページとしてマークされているものの、Google が「別の URL のほうが正規 URL として適している」と判断したページだと説明しています。Google は自身が選んだ URL をインデックスに登録し、該当ページをその URL の重複として扱います。

修正にあたって、Google のドキュメントから押さえておくべき点は 2 つです。

• 指定した canonical はヒントにすぎません。 Google の正規化に関するドキュメントでは、指定された canonical はルールではなくヒントだとされています。重複 URL に関するドキュメントでは、リダイレクトと rel="canonical" を強いシグナル、サイトマップへの掲載を弱いシグナルとしています。Google はこれらをコンテンツそのものと合わせて評価し、ユーザーの指定を覆すことがあります。
• 指定する canonical は本当の重複でなければなりません。 ページ インデックス登録レポートのトラブルシューティング手順には、ユーザーが指定した正規ページが現在のページと類似していない場合、Google がそれを選択することはないと書かれています。

このステータスは問題なのか

ステータス自体に良し悪しはありません。どう対応すべきかは、Google が選んだ URL を見れば分かります。

flowchart TD
    A["該当 URL を URL 検査ツールで開く"] --> B["ユーザーが指定した正規 URL と Google が選択した正規 URL を比べる"]
    B --> C{"Google が選んだのはインデックスさせたい URL か"}
    C -->|はい| D["canonical タグをそれに合わせて修正する"]
    C -->|いいえ| E{"Google が選んだ URL は自分のドメインか"}
    E -->|いいえ| F["コピー、配信、ハッキングを疑い、サーバーを確認してからホストに連絡する"]
    E -->|はい| G{"指定した正規 URL は 200 を返し、インデックス可能で、自己参照 canonical を持ち、このページと類似しているか"}
    G -->|いいえ| H["指定先を修復するか、正常で類似した URL を指定する"]
    G -->|はい| I{"リダイレクト、サイトマップ、内部リンクは同じ URL を示しているか"}
    I -->|いいえ| J["すべてのシグナルを 1 つの URL に揃える"]
    I -->|はい| K{"メインコンテンツは明確に異なるか"}
    K -->|いいえ| L["ページを統合するか、内容を差別化する"]
    K -->|はい| M["hreflang、JavaScript、サーバー設定を確認する"]

Google が別の正規 URL を選ぶ 6 つの原因

1. 他のシグナルが別の URL を示している。 canonical タグは A を指しているのに、リダイレクト、XML サイトマップ、内部リンクは B を指している状態です。Google の重複 URL に関するガイダンスは、同じページに対して異なる方法で異なる正規 URL を指定しないこと、そして内部リンクは重複ではなく正規 URL に向けることを求めています。2026 年 5 月から 10 月にかけて SEOReport の監査に送信され、サイトマップのページを取得できた外部ウェブサイト 29 件のうち、6 件（21%）が XML サイトマップに別の場所へリダイレクトする URL を掲載していました。つまり、サイトマップが告知するアドレスと、サーバーが実際に返すアドレスが異なっていたのです。サイトマップとページの canonical の食い違いに関する分析では、この不備が監査のたびに残り続ける理由を示しています。

2. 指定した URL が正規 URL になり得ない。 リダイレクトする URL、404 を返す URL、noindex が付いた URL、robots.txt でブロックされた URL、さらに別の正規 URL を指定している URL を canonical で指すと、Google に使えないものをインデックスするよう求めることになり、Google は別の URL を選びます。指定先が重複ではなく別のページである場合も同じです。たとえば、絞り込み後の一覧ページがフィルタなしのカテゴリページを指している場合や、アーカイブの 3 ページ目が 1 ページ目を指している場合です。また、Google は <link rel="canonical"> 要素を <head> 内でしか受け付けず、相対 URL ではなく絶対 URL の使用を推奨しています。

3. プロトコルやホストのバリエーションが食い違っている。 Google は、問題や矛盾するシグナルがない限り、正規 URL として HTTP より HTTPS を優先します。ドキュメントでは、SSL 証明書が無効な場合、画像以外に安全でない依存関係がある場合、HTTPS ページが HTTP へ、または HTTP を経由してリダイレクトする場合、HTTPS ページの canonical が HTTP の URL を指定している場合が挙げられています。HTTPS から HTTP へのリダイレクトがあると、Google は HTTP を非常に強く優先します。www ありとなしのホストや末尾のスラッシュについても同じです。両方のバージョンが 200 を返し、サイト内のリンクがその両方を混在して使っていれば、タグは判断材料の 1 つにすぎません。

4. 言語版や地域版のメインコンテンツが同じ。 Google が異なる言語版を重複として扱うのは、主要コンテンツが同じ言語の場合に限られます。メニューとフッターだけを翻訳したページは、元のページの重複のままです。米国版と英国版のように同じ言語で地域ごとに分けたページには hreflang アノテーションが必要で、各ページの canonical は自分自身の言語のページを指したままにしておく必要があります。言語をまたいで指定された canonical タグに関する記事で、この矛盾を詳しく解説しています。

5. ページがほぼ同一である。 属性が 1 つ違うだけの商品バリエーション、都市名だけを差し替えた地域ページ、同じ一覧を繰り返すタグページやアーカイブページは、1 つのグループにまとめられます。Google はその中から最も完全で有用と判断したバージョンを選ぶため、コンテンツが実質的に同じであれば、各ページに canonical タグを付けても区別は保てません。

6. 誰が取得するかによって canonical が変わる。 1 ページに 2 つの canonical タグがある（テーマと SEO プラグインがそれぞれ追加している）、JavaScript フレームワークが読み込み後に canonical を書き換える、スマートフォン版が別の URL を指定している、といった状態では、いずれも Google に 2 通りの答えを送ることになります。Google の JavaScript に関するガイダンスは、JavaScript で設定する canonical は元の HTML の canonical と一致させるべきであり、複数の canonical タグは予期しない結果を招く可能性があるとしています。Google のトラブルシューティング ドキュメントには、あるサイトのコンテンツを別のホスト名で返すサーバーの設定ミス、ハッキングによるリダイレクト、他のウェブサイト上にあるコンテンツのコピーも挙げられています。

どの原因に当てはまるかを確認する方法

まず Search Console で確認し、次にサーバーが実際に何を返しているかを調べます。

1. 該当 URL を検査する。 URL 検査ツールでは、インデックス登録済みの結果に「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」が並んで表示されます。Google は正規 URL をインデックス登録時に決定するため、公開 URL のテストには指定した正規 URL しか表示されません。公開 URL のテストに問題がなくても、Google の選択を予測できるわけではありません。
2. Google が選んだ URL も検査する。 そのステータス、その URL 自身の canonical、サイトマップに含まれているかどうかを記録します。
3. ブラウザを使わずに両方の URL を取得する。 ブラウザはリダイレクトを隠し、JavaScript 実行後のページを表示するため、サーバーの生のレスポンスを使います。

# Status codes and redirect hops, plus any canonical sent as an HTTP header
curl -sIL https://www.example.com/guide/ | grep -iE '^(HTTP/|location:|link:)'

# Every canonical tag in the HTML the server returns (more than 1 is a conflict on its own)
curl -sL https://www.example.com/guide/ | grep -io '<link[^>]*canonical[^>]*>'

1. シグナルを 1 行に並べて比べる。 指定した正規 URL、リダイレクト後の最終 URL、サイトマップ上の URL、ナビゲーションとパンくずリストのリンク先 URL、レンダリング後のページの canonical を書き出します。たいていの場合、食い違っている列が原因です。

具体例を挙げます。あるページが https://www.example.com/guide/ を指定しているのに、Google は http://example.com/guide を選択していました。HTTPS の URL を取得すると、あるテンプレートで HTTP へのリダイレクトが見つかりました。この場合は原因 3 に当たり、直すべきはタグではなくリダイレクトのルールです。

1 つの URL の確認は数分で終わります。しかし食い違いは通常テンプレートやサイトマップ生成ツールから生じるため、そのテンプレートが生成するすべてのページで繰り返されます。それらをすべて見つけるには、サイト全体を調べる必要があります。

原因ごとの修正方法

すべての修正に共通する原則は、1 つのコンテンツに 1 つの URL を割り当て、どこでも同じ URL で示すことです。

インデックスさせたいページの正しい最終状態は次のとおりです。

<head>
  <link rel="canonical" href="https://www.example.com/guide/" />
</head>

Sitemap entry:        https://www.example.com/guide/
Final URL after hops: https://www.example.com/guide/  (200)
Internal links:       https://www.example.com/guide/

状況を悪化させる近道が 2 つあります。Google のガイダンスは、正規化に robots.txt を使うことも、同じサイト内でどのページを正規ページにするかを noindex で誘導することも推奨していません。ブロックされた重複ページや noindex が付いた重複ページは、優先したいページにシグナルを引き渡せません。重複 URL がそもそも存在する必要がないなら、恒久的なリダイレクトのほうが強いシグナルになります。その後 Google がどう報告するかは、Search Console の「ページにリダイレクトがあります」ステータスのガイドで解説しています。

修正を検証する方法

デプロイ後、同じ curl のチェックをもう一度実行します。次に、ページ インデックス登録レポートで該当する問題の「修正を検証」をクリックします。Google が再確認するのはその問題に表示されている URL だけで、サイト全体ではありません。ドキュメントによると、検証には通常最長で約 2 週間かかり、さらに長くかかることもあります。また正規化のトラブルシューティングには、ほぼ重複していたページを明確に異なる内容にした後でも、Google が最長 2 週間はそれらを重複グループに残すことがあると記載されています。待っている間に canonical を再び変更しないでください。数日おきに切り替わるシグナルでは、Google が同意できる安定した基準がなくなります。

重要な URL が数件だけであれば、URL 検査ツールの「インデックス登録をリクエスト」で、Google に早めの再クロールを依頼できます。1 日あたりの上限があり、インデックス登録が保証されるわけではありません。

SEOReport の完全な診断でわかること

Search Console には Google が選んだ正規 URL が表示されます。SEOReport の完全な診断では、自分のシグナルが指定した正規 URL とどこで食い違っているかがわかります。たとえば、別の場所へリダイレクトするサイトマップ上の URL、canonical が別のページを指している別言語版のページ、そしてホームページについては、別のドメインを指定する canonical、リダイレクトする・noindex が付いている・別の正規 URL を指定している canonical の指定先、canonical と異なる Open Graph の URL、JavaScript の実行後やスマートフォンで変わる canonical です。Google が選択した正規 URL は確認できないため、URL 検査ツールと組み合わせて使ってください。それぞれのシグナルの本来の働きは、canonical タグのガイドで解説しています。

よくある質問

このステータスは順位に悪影響を与えますか？

該当する URL は検索結果に表示されませんが、そのコンテンツは Google が選んだ正規 URL を通じて表示される可能性があります。その URL が正しいものであれば、失うものはありません。損失が生じるのは、Google が選んだのが別のページ、古いバリエーション、あるいは他のウェブサイトである場合です。

Google に自分の canonical を使わせることはできますか？

どのタグも単独では強制できません。Google は canonical を指示ではなく強いシグナルとして扱います。自分の選択を通すには、すべてのシグナルを一致させることです。つまり、タグ、リダイレクト、サイトマップ、内部リンク、そして別々に残すべきページについては明確に異なるコンテンツです。

「重複していますが、ユーザーが正規ページとして選択していません」とはどう違いますか？

このステータスは、canonical を指定したうえで Google がそれに同意しなかった状態です。「重複していますが、ユーザーが正規ページとして選択していません」は canonical を何も指定しておらず、Google が独自に選んだ状態です。canonical を指定して Google が同意した場合、その重複ページは「代替ページ（適切な canonical タグあり）」と表示され、通常は対応不要です。

Google が選択した正規 URL が他のウェブサイトにあるのはなぜですか？

Google のトラブルシューティング ドキュメントは、他の場所にホストされたコンテンツのコピー、記事を転載する配信パートナー、ハッキングによるリダイレクト、別のホスト名であなたのコンテンツを返すサーバーを挙げています。配信については、Google はパートナー側でコピーのインデックス登録をブロックするよう推奨しています。無断コピーの場合は、そのサイトのホストに連絡してください。