重複していますが、ユーザーが正規ページとして選択していません：対処法

「重複していますが、ユーザーが正規ページとして選択していません」（英語版では "Duplicate without user-selected canonical"）は、Google がある URL を別のページのコピーと判断し、その URL に canonical の指定がないことを確認したうえで、検索結果に表示するバージョンを自ら選んだことを意味します。指摘された URL がトラッキング パラメータ付きの URL や HTTP のコピーのように誰も訪れる必要のないバリエーションで、Google が優先したいページを選んでいるなら、これは意図どおりの結果であり、対応は不要です。修正が必要なのは、検索結果に表示させたくない URL を Google が選んだ場合や、指摘された URL こそが上位表示させたいページである場合です。

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

このステータスは、ページ インデックス登録レポートの「ページがインデックスに登録されなかった理由」に表示されます。Google のページ インデックス登録レポートのドキュメント（2026 年 10 月に確認）によると、このページは「別のページと重複していますが、優先する正規ページが指定されていません」。同じ項目には、Google は指摘された URL を検索結果に表示しないこと、これはエラーではなく意図どおりの動作であることが書かれ、対処法が 2 つ示されています。Google が誤った URL を選んだ場合は正規 URL を明示的に指定すること、ページが実際には重複していない場合はコンテンツを大きく異なるものにすることです。

「重複しています」は、Google が類似ページをクラスタにまとめた後に下した判断です。「ユーザーが正規ページとして選択していません」は、指摘された URL が Google の読み取れる canonical を何も示していなかったことを意味します。この点が、隣接する 2 つのステータスとの違いです。

Google の正規化に関するドキュメントは、指定された canonical は「ルールではなくヒント」だとも述べています。Google は判断を下す前に、リダイレクト、サイトマップの項目、HTTPS も考慮します。

重複 URL はどこから生まれるのか

指摘される URL のほぼすべては、1 つのページが複数のアドレスでアクセスできる状態から生まれます。Google の URL 構造に関するドキュメントには URL の扱いで大文字と小文字が区別されると書かれており、末尾のスラッシュに関する Google 検索セントラル ブログの記事（2010 年 4 月）は、Google は /shoes と /shoes/ を 2 つの別々の URL として扱うとしています（サイトのルートは例外です）。次のような違いがあるたびに、同じコンテンツに新しい URL が生まれます。

• 優先したいページに canonical がない。 ページが canonical を指定していなければ、そのバリエーションにも canonical はありません。そのため、Google が見つけたコピーはすべてこのステータスになります。たとえば WordPress のコアは、個別の投稿と固定ページにしか canonical タグを出力しません。アーカイブ、カテゴリ、タグ、ブログのトップページの表示には、テーマやプラグインが追加しない限り canonical が付きません。
• プロトコルとホストのバリエーション。 http:// と https://、あるいは www ありとなしのドメインが、1 つのアドレスにリダイレクトせず、どれもステータス 200 を返している。
• 末尾のスラッシュと大文字・小文字。 /shoes、/shoes/、/Shoes/ が同じページを返している。
• パラメータと別表示。 ?utm_source= などのトラッキング タグ、並べ替えや絞り込みのオプション、セッション ID、同じコンテンツの印刷用表示やグリッド表示。
• 意図しないコピー。 Google のドキュメントが原因として挙げている、クローラーに公開されたままのサイトのデモ版、ステージング用のホスト、同じページを配信し続けている古いドメイン。
• Google が読み取れない canonical。 Google が rel="canonical" を受け付けるのは <head> 内だけです。ページのメタデータに関するドキュメントによると、iframe や img など無効な要素が head 内にあると、Google は head がそこで終わったと見なし、それ以降を無視します。その後ろに置いた canonical は、実質的に存在しないのと同じです。
• 自分では別物だと考えているページ。 説明文が同じ色違いの商品や、都市名以外の文章がすべて共通の地域ページ。

2026 年 5 月から 10 月に SEOReport が監査した外部ウェブサイト 45 件のうち、14 件（31%）は、サーバーが返す HTML に canonical タグのないホームページを配信しており、1 件は複数の canonical タグを配信していました。同じサンプルで、45 件中 2 件（4%）は HTTP から HTTPS へリダイレクトしていませんでした。

問題なのか：修正、放置、経過観察

判定は、Google がどの URL を選んだか、そして指摘された URL を検索結果に表示させたいかどうかで決まります。

flowchart TD
    A["「重複していますが、ユーザーが正規ページとして選択していません」と指摘された URL"] --> B["URL 検査ツールで Google が選択した正規 URL を確認する"]
    B --> C{"Google が選んだのは検索結果に表示させたい URL か"}
    C -->|はい| D{"サイト内のリンクやサイトマップが指摘された URL を指しているか"}
    D -->|いいえ| E["放置する：コピーは意図どおり除外されている"]
    D -->|はい| F["リンクとサイトマップを優先 URL に向ける"]
    C -->|いいえ| G{"コンテンツは本当に同じか"}
    G -->|いいえ| H["ページの内容を大きく異なるものにする"]
    G -->|はい| I["優先 URL を明示する：canonical、リダイレクト、リンク、サイトマップ"]
    F --> J["公開 URL をテストし、修正を検証する"]
    H --> J
    I --> J

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

1. 例をパターンでグループ化する。 例の表は最大 1,000 行までで、該当するすべての URL が表示されるとは限りません。件数を数えるのではなく、パターン（すべて http://、すべて ?utm_、すべて大文字など）を探します。
2. 指摘された URL を検査する。 URL 検査ツールで「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」を比べます。このステータスでは、インデックス登録済みの結果のユーザーが指定した正規 URL は通常「なし」と表示されます。「公開 URL をテスト」でそこに canonical が表示される場合、その canonical は Google がその URL を最後にクロールした後に追加されたものです。
3. 2 つの URL を 1 文字ずつ比べる。 プロトコル、ホスト、大文字・小文字、末尾のスラッシュ、パラメータを見ます。違っている部分が原因を示しています。
4. Google がどこでバリエーションに出会ったかを調べる。 検査結果の「参照元ページ」には、Google が URL を見つけるのに使った可能性のあるページが、「サイトマップ」にはその URL を掲載しているサイトマップが表示されます。
5. クローラーと同じ方法でバリエーションを取得する。 ブラウザはリダイレクトを隠しますが、生のレスポンスは隠しません。

# Status code and redirect target for each variant of one page
for u in http://example.com/shoes/ https://example.com/shoes/ \
         https://www.example.com/shoes https://www.example.com/Shoes/ \
         "https://www.example.com/shoes/?utm_source=newsletter"; do
  curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}  $u\n" "$u"
done

# The canonical tag in the HTML the server returns, before any JavaScript runs
curl -s https://www.example.com/shoes/ | grep -io '<link[^>]*canonical[^>]*>'

どのバリエーションも、優先 URL への 301 を返すか、優先 URL を指す canonical 付きで 200 を返すべきです。canonical なしで 200 を返すバリエーションは、このステータスに入り続ける可能性があります。

原因ごとの修正方法

canonical がない。 インデックスさせたいすべてのページに、絶対 URL による自己参照の canonical を設定します。サーバーが送る HTML の <head> 内の、できるだけ前のほうに置いてください。Google のドキュメントは、自己参照の形式と絶対 URL の両方を推奨しています。

<head>
  <meta charset="utf-8">
  <link rel="canonical" href="https://www.example.com/shoes/">
  <title>Trail running shoes</title>
</head>

canonical は、リクエストされた URL からではなく、必ずそのページ自身の優先アドレスから生成してください。リクエストをそのまま出力するテンプレートでは、/shoes/?utm_source=newsletter 自体が canonical になってしまい、バリエーションは統合されずに「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」に移ることがあります。

プロトコルとホストのバリエーション。 すべてのバリエーションを、パスとクエリ文字列を保ったまま 1 回の 301 でリダイレクトします。nginx の場合、HTTP 側は次のようになります。HTTPS の www なしドメインの server ブロックにも同じ return 行を記述してください。

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Google は、無効な証明書や HTTPS から HTTP へ戻るリダイレクトといった矛盾がない限り、HTTPS のページを正規ページとして優先します。各バリエーションは 1 回の転送で最終アドレスに送ってください。プロトコル、ホスト、スラッシュのルールを別々に追加すると、それらが重なってチェーンになる仕組みは、リダイレクト チェーンのガイドで解説しています。

末尾のスラッシュと大文字・小文字。 どちらかの形式に統一し、もう一方はそちらへ 301 でリダイレクトし、CMS がその形式でリンクを生成するようにします。Google の URL に関するガイダンスは、大文字・小文字の表記を 1 つに統一することを推奨しています。

パラメータと別表示。 クリーンな URL に正しい自己参照の canonical があれば、トラッキング パラメータには対応できます。タグ付きのコピーはすべてクリーンなページを指すことになるからです。パラメータ付き URL への内部リンクをやめ、セッション ID は Cookie に移し、印刷用などの別表示にはメインページを指す canonical を設定します。重複を隠すために robots.txt を使わないでください。Google によると、ブロックされた URL もコンテンツなしでインデックスに登録される可能性があり、取得を許可されていないページの canonical を Google は読めません。また Google は、サイト内で正規ページを選ぶ目的で noindex を使うことも推奨しておらず、URL 削除ツールは URL のすべてのバージョンを非表示にしてしまいます。

意図しないコピー。 ステージング用のホストはログインの後ろに置き、古いドメインはページ単位でリダイレクトします。

重複ではないページ。 他のページにはない内容、たとえば仕様、在庫状況、地域ごとの詳細を各ページに加えます。Google のトラブルシューティング ドキュメントによると、変更後も最長 2 週間はページが重複クラスタに残ることがあります。

すべてのシグナルを揃える。 XML サイトマップには優先 URL だけを掲載し、内部リンクは canonical で指定したものと同じ URL に向けます。Google は、サイトマップで 1 つの URL を、rel="canonical" で別の URL を指定しないよう警告しています。その他の矛盾については、ページと食い違うサイトマップの分析とcanonical タグのガイドで扱っています。

修正を検証する方法

1. 指摘された URL とその優先ページで「公開 URL をテスト」を実行します。公開 URL のテストにはユーザーが指定した正規 URL が表示されますが、Google によると、Google がどの URL を選ぶかは予測できません。
2. 重要な優先ページのいくつかで「インデックス登録をリクエスト」を使います。1 日あたりの上限があります。
3. パターンの該当箇所をすべて修正したら、このステータスで「修正を検証」をクリックします。Google のドキュメントによると、検証には通常最長で約 2 週間かかり、さらに長くかかることもあります。また、該当箇所が残っているのを Google が見つけると検証は停止します。
4. URL は消えるのではなく、別のステータスに移ると考えてください。リダイレクトするようになったバリエーションは「ページにリダイレクトがあります」として報告され、Google が受け入れた canonical を持つバリエーションは通常「代替ページ（適切な canonical タグあり）」に表示されます。どちらもコピーとしては正常な状態です。
5. 数週間後、優先ページをもう一度検査し、「Google が選択した正規 URL」が指定した URL と一致していることを確認します。

Search Console からわかるのは Google がどの URL をコピーと判断したかであり、サイト全体のどの設定がそれを生み出し続けているかではありません。SEOReport の完全な診断では、そうしたサイト全体の発生源を外部から確認します。www ありとなしの両方でサイトが配信されている、HTTP が HTTPS にリダイレクトしない、サイトマップ、canonical、hreflang の URL で末尾のスラッシュの形式が混在している、ホームページに canonical がないか複数ある、といった点です。ほぼ重複した記事も特定します。パラメータ付きのコピーや canonical のない下層ページについては、引き続き URL 検査ツールと上記の確認が必要です。すべてのテンプレートのバリエーションを確認するのはサイト全体にわたる作業であり、1 回の AI チャットセッションでは終わらないことが多いのはそのためです。

よくある質問

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

Google はこれを意図どおりの動作としており、ある程度の重複コンテンツは普通のことです。損失が生じるのは、検索結果に表示させたくない URL を Google が選んだ場合や、クロールの時間がコピーに使われる場合です。Google によると、正規ページは最も定期的にクロールされ、重複ページはそれより低い頻度でクロールされます。

サイト内でリンクしていない URL がレポートに表示されるのはなぜですか？

Google は、外部リンク、タグ付きのキャンペーン URL、古いサイトマップ、サイトの以前のバージョンから URL を見つけます。クリーンな URL に正しい canonical があれば、こうしたコピーがどこから来たものでも対応できます。

修正後、重複 URL は Search Console から消えますか？

通常は、検証の手順で説明したとおり、別のステータスで表示され続けます。インデックスに登録されていない URL が問題になるのは、それを検索結果に表示させたい場合だけです。これは「クロール済み - インデックス未登録」にも当てはまる判断基準です。

このステータスは、他の言語の Search Console では何と表示されますか？

Google の各言語版ヘルプページ（2026 年 10 月に確認）では、ドイツ語で "Duplikat – vom Nutzer nicht als kanonisch festgelegt"、スペイン語で "Duplicada: el usuario no ha indicado ninguna versión canónica"、フランス語で "Page en double sans URL canonique sélectionnée par l'utilisateur" となっています。意味と修正方法は、どの言語でも同じです。