canonicalタグは『ヒント』であって『命令』ではない ── Search Consoleで、Googleが選んだ正規URLを自分のサイトで確認する15項目（2026年9月時点）

01 いま最新版は何か — canonicalタグは「ヒント」であって「命令」ではない

canonicalタグとは何か

同じような内容のページが、複数のURLで存在してしまうことがあります。httpとhttpsの両方でアクセスできる、www有りと無しの両方が生きている、並び替え順やフィルタ条件を表すパラメータが付いたURLが大量に生成される。こうした状態を、Googleは「重複コンテンツ」と呼んでいます。<link rel="canonical" href="...">は、複数のURLのうち、どれを「代表版」として検索結果に載せてほしいかを、ページを作った側からGoogleに伝えるための仕組みです。

この仕組み自体は新しいものではありませんが、多くのサイト運営者が誤解している点が1つあります。それは「rel=canonicalを設置すれば、指定したURLが必ず検索結果に載る」という思い込みです。Google Search Centralの公式ドキュメント（正規化について）には、この点がはっきりと書かれています。

"indicating a canonical preference is a hint, not a rule."

（訳: 正規URLの希望を示すことは、ヒントであって、ルールではありません。）

つまりrel=canonicalは、こちらの希望を伝える手段であって、Googleに実行を強制する命令文ではありません。Googleが実際に選んだURLと、こちらが指定したURLが食い違うことがあります。そしてその食い違いは、grepで本文を探しても、HTTPステータスを見ても分かりません。確認できる場所は1つ、Search Consoleの中だけです。

Search Console「ページのインデックス登録」レポートに、正規URL専用の状態が4つある

Search Consoleの「ページ」（インデックス未登録の理由）レポートには、Search Consoleヘルプ（ページがインデックスに登録されない理由）に定義された多数のステータスが並んでいます。そのうち、正規URLの選択に直接かかわるものが4つあります。以下の表は、その4つを整理したものです。

4つのうち上から3つはSearch Consoleヘルプ（インデックス登録の対象外と判定されたページ）に、最後の1つは前述の「ページがインデックスに登録されない理由」の一覧に、それぞれ定義されています。本記事の05章のチェックリストは、この4つのステータスを実際に自分のサイトで確認する手順を中心に組み立てています。

02 なぜ・背景 — 指定しなくても、Googleは自動で選んでいる

重複が起きる典型パターン

WEBディレクターが日常的に遭遇する重複コンテンツには、いくつかの典型パターンがあります。httpとhttpsの両方が生きたまま残っているケース、wwwの有無で別URLとして扱われているケース、末尾スラッシュの有無、商品一覧ページで並び替え・絞り込み条件がパラメータとしてURLに付くケース、印刷用ページやAMP版のような別URL構成、そしてサイトを移転したのに旧URLが生き残っているケースです。これらは意図的に作られたものではなく、サイトの成長過程で自然に発生します。

ここで押さえておきたいのは、「重複コンテンツがある＝ペナルティを受ける」という理解は誤りだという点です。GoogleのSEOスターターガイドには、次のようにはっきり書かれています。

"Duplicate content 'penalty': If you have some content that's accessible under multiple URLs, it's fine; don't fret about it. It's inefficient, but it's not something that will cause a manual action."

（訳: 重複コンテンツの「ペナルティ」について ── 複数のURLで同じコンテンツにアクセスできる状態があっても問題ありません。気にしすぎる必要はありません。非効率ではありますが、手動対策の対象になるような性質のものではありません。）

つまり重複コンテンツそのものは違反ではなく、「非効率」という性質の問題です。クロールの手間が余分にかかる、評価が複数のURLに分散する、検索結果にどのURLが表示されるかが不安定になる。canonicalタグは、この非効率を整理するための手段であって、ペナルティを避けるための防御ではありません。この前提を取り違えると、必要以上に急いで、根拠のないURLを正規版に指定してしまう判断につながります。

「指定しなくても大丈夫」という前提

もう1つ押さえておきたいのは、canonicalタグを1つも設置していないサイトでも、Googleは重複ページ群から自動で1つを選んでいるという事実です。前掲の正規化ドキュメントには、こう書かれています。

"While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference."

（訳: これらの方法の利用は推奨しますが、いずれも必須ではありません。正規URLの希望を指定しなくても、サイトはおそらく問題なく機能するでしょう。）

ではなぜ、わざわざ指定するのかというと、「Googleに任せた自動判定が、こちらの意図と一致しているとは限らない」からです。同ドキュメントは続けて、Googleは「客観的に見て、検索ユーザーに見せるべき最良のバージョン」を選ぶと説明しています。ここでの「最良」の判断基準にはHTTPSかどうか、サイトマップに含まれているか、内部リンクからどれだけ参照されているか、ページの完全性といった複数の要素が使われますが、こちらが優先してほしいURLと、Googleが客観的に「最良」と判断するURLは、必ずしも一致しません。rel=canonicalを設置する意味は、この自動判定に対して、こちらの希望を明示的に伝える点にあります。

03 この記事で出てくる用語

「ヒント」と「シグナル」の強さの違い

正規化ドキュメントでは、正規URLの判断材料になる方法ごとに、シグナルとしての強さが異なると説明されています。もっとも強いのは301リダイレクトで、次に強いのがrel="canonical"、もっとも弱いのがサイトマップへの掲載です。強い・弱いというのは「Googleが指示に従う確率」のことで、301リダイレクトは物理的にそのURLへ転送してしまうため、Googleにとっても選択の余地がほとんどありません。一方サイトマップは「このURL群を知っていますよ」という情報の提供にすぎず、どれを正規版にするかの判断材料の1つでしかありません。この強弱の違いは、06章の比較表で改めて整理します。

04 型別 — 適用範囲・保証しないこと・手順

🅰 適用範囲 — このガイドが当てはまるサイト・当てはまらないサイト

本記事のチェックリストがとくに効くのは、次のようなサイトです。商品を複数の条件（色・サイズ・並び順）で絞り込めるECサイトやカタログサイト、httpとhttpsのどちらでもアクセスできる古いサイト、CMSの仕様で同じ記事が複数のカテゴリURLの下に出てしまう構成のサイト、そして印刷用ページやモバイル専用URLのような別バージョンを持つサイトです。逆に、1つの記事に対して1つのURLしか存在しない、シンプルな構成の小規模サイトでは、重複そのものが起きにくいため、緊急性は下がります。ただしその場合でも、自己参照のcanonicalタグを置いておくこと自体は、07章で扱う調査が示すとおり、基本の作法として無害です。

🅱 canonicalタグが保証しないこと

canonicalタグを設置すれば、次のことがすべて解決すると思われがちですが、実際にはそうではありません。1つ目に、指定したURLがインデックスされることを保証しません。Googleが「最良」と判断しなければ、別のURLが選ばれることがあります（01章の表の3行目）。2つ目に、インデックス自体を止める機能ではありません。noindexとは別の仕組みで、canonicalは「複数のうちどれが代表か」を示すだけで、検索結果から除外する指示ではありません。3つ目に、重複するコンテンツそのものを消すわけではありません。URLは複数残ったまま、検索結果への表示先だけが整理されます。4つ目に、自社サイトの外で無断転載やスクレイピングが起きている場合、canonicalタグの設置だけでは制御できません。コピー先のサイトが、こちらのcanonical指定を無視して自分たちのURLを正規として扱う可能性があるためです。

🅲 手順 — 棚卸しから確認までの4段階

canonicalタグを正しく機能させるための手順は、大きく4段階に分かれます。1段階目は棚卸しで、同じ内容を持つURL群を洗い出します。並び替えパラメータ付きの一覧ページ、http/https両対応の旧URL、カテゴリをまたいで同じ記事が出るページなどが対象です。2段階目は代表URLの決定で、各グループの中から、検索結果に載せたい1つのURLを選びます。3段階目は設置で、選んだURL以外のページに<link rel="canonical" href="（代表URLの絶対パス）" />を、head内・自己参照を含めて設置します。代表URL自身のページにも、自分自身を指すcanonicalタグを置くのが基本です（自己参照canonical）。4段階目は確認で、Search Consoleを使って、実際にGoogleがどのURLを選んだかを見ます。05章のチェックリストは、この4段階目を中心に組み立てています。

1段階目の棚卸しで判断に迷いやすいのが、一覧ページのページネーション（2ページ目以降）です。すべてのページを1ページ目のURLに正規化してしまうと、2ページ目以降にしか載っていない商品や記事が、Googleから見えなくなる可能性があります。この場合は各ページを自己参照のcanonicalにし、並び替え・絞り込みのパラメータだけを別途整理する形が基本になります。迷った場合は、まず棚卸しの段階で「そのページにしかない情報があるか」を先に確認してください。

05 自分のサイトで確認するチェックリスト

15項目の内訳

ここまでの内容を、今日から手を動かせる作業に翻訳しました。最初の4項目は自分のページのcanonicalタグ自体の確認、次の4項目はSearch Consoleでの実際の選択結果の確認、続く5項目は矛盾ステータスが出ていた場合の切り分け、最後の2項目は重複しやすいページ構成の洗い出しと記録に対応しています。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 自分のサイトの主要ページを1つ開き、ページのソースを表示して<link rel="canonical">の値を控える
• 控えたhref属性が、httpsから始まる絶対URLになっているか確認する
• 控えたhref属性が、いま見ているページ自身のURLと一致しているか（自己参照になっているか）確認する
• 同じページのog:urlの値も確認し、canonicalの値と一致しているか比べる
• Search Consoleの左メニューから「URL検査」を開き、同じページのURLを貼り付けて検査する
• 検査結果の「インデックス登録」欄で、「Googleが選択した正規URL」を控える
• 同じ欄の「ユーザーが宣言した正規URL」を控え、6で控えた値と一致しているか比べる
• 一致していなかった場合、両方のURLを実際に開いて、内容がどれだけ似ているかを見比べる
• Search Consoleの「ページ」レポートを開き、インデックス未登録の理由の一覧を表示する
• 一覧から「Duplicate, Google chose different canonical than user」の件数を書き出す
• 同じ一覧から「Duplicate without user-selected canonical」の件数を書き出す
• 9と10の合計が0件でない場合、該当するURLを最低3件クリックしてページ一覧を開く
• 開いた3件それぞれについて、rel=canonicalが設置されているか、設置先はどのURLかを確認する
• 自社サイト内で似た内容を持つページ（並び替え・絞り込みのパラメータ付きURL、印刷用ページなど）を1つ書き出す
• 13で書き出したページに、rel=canonicalを追加するか、301リダイレクトで統合するかを決めて記録する。対応しないと決めた場合も、その判断をそのまま記録する

優先して手をつける範囲

15項目すべてに目を通す時間の目安は1サイトあたり20〜30分程度です。特に優先すべきは10〜13番目の項目で、これはすでに矛盾が起きているかどうかを確認する部分にあたります。矛盾が0件であれば、14・15番目の「予防」の項目に時間を回すのが効率的です。archives/129で扱った「タイトルで探すと45組、元記事で探すと139組」という実例のとおり、探し方を変えると見つかる重複の数は変わります。今回のチェックリストは、その中でも「Googleが実際にどう判断したか」という、外からは見えない部分に焦点を当てています。Search Consoleの各レポートの見方そのものに迷う場合は、当サイトの🔧 Search Console解説ツールで、「ページのインデックス登録」レポートを含む各機能の読み方を確認できます。

06 正規化を伝える3つの手段を比較する

301リダイレクト・rel=canonical・サイトマップ、それぞれの強さ

正規URLをGoogleに伝える手段は1つではありません。以下は、シグナルとしての強さと、向き不向きで整理した表です。

正規化ドキュメントは、複数の手段を同時に使うことで効果が積み重なるとも説明しています。もっとも堅実な組み合わせは、代表URL以外を301リダイレクトで統合できるものは統合し、統合できずに両方残す必要があるものにはrel=canonicalを設置し、サイトマップには代表URLだけを載せる、という形です。逆に避けたいのは、正規URLとして指定したページ自体にnoindexを設置してしまう組み合わせです。noindexは「インデックスしないでほしい」という指示、canonicalは「こちらが代表版」という指示で、両方を同じページに置くと矛盾した指示になり、Googleがどちらを優先すべきか判断できなくなります。301リダイレクトの仕組みについても、公式ドキュメントに明確な説明があります。

"Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical."

（訳: Googlebotはリダイレクトをたどり、インデックスの処理はそのリダイレクトを「リダイレクト先が正規URLであるべき」というシグナルとして扱います。）

URLパラメータの扱いは、別記事で詳しく整理している

並び替え・絞り込み条件によるパラメータ付きURLの重複を防ぐ設定については、当サイトのURLパラメータとは？ SEOへの影響と、重複コンテンツを防ぐ設定の基本で、アクティブ型・パッシブ型という分類とあわせて詳しく扱っています。本記事はcanonicalタグそのものの働き方と、Search Console側での確認方法に焦点を絞っているため、パラメータの種類ごとの具体的な設定パターンを知りたい場合は、そちらの記事をあわせて確認してください。

07 当サイトで確かめたこと

公開中の記事46本すべてで、自己参照canonicalを確認した

本記事のチェックリストで案内した「canonicalの値が自己参照になっているか」という確認項目を、当サイトの公開中のseo_article記事すべてで実際に行いました。公開中の46本のページを1件ずつ取得し、<link rel="canonical">のhref値が、そのページ自身のURLと絶対パスで一致しているかを確認したところ、46本中46本すべてで一致していました。相対パスで書かれていたものや、値そのものが欠けていたものは0件でした。

この結果は、「設定が存在すること」と「Googleがその設定どおりに動いていること」は別の確認だという、01章の内容をそのまま裏付けています。今回はcanonicalタグの形式面ではすべて合格でしたが、それはあくまでページを作った側の作業が正しいことを示すだけで、Google側が実際にどう判断したかは、この確認方法では測れません。

08 このテーマの、これまで

4層の整合性を、curl 3行で確認した回

sitemap・canonical・内部リンク・HTTP応答の4つが、同じURL文字列で揃っているかを確認した回があります（archives/39）。この回はcanonicalタグを含む4層のうち、どこか1層でも文字列がずれていると、Googleの信頼度が下がるという構造上の整合性を扱いました。正規化ドキュメントは、内部リンクが指し示す先も正規URLの判断材料の1つに含めており、自社の内部リンクが意図せず非正規のURLばかりを指していると、Googleの判断に余計なノイズを与えます。実際、自社ブログの内部リンクを機械で洗い出したところ、リンク切れは0本だったものの、飛び先の59.2%がGoogleの引用対象から外れた状態のページだったという実例もあります（archives/134）。本記事は、これらの整合性が取れている前提の上で、Googleが実際にどのURLを選んだかという、一段先の確認方法を扱っています。整合性のチェックそのものは、archives/39の方法が今も有効です。

「同じ記事が2本ないか」を、探し方を変えて確かめた回

タイトルの完全一致で重複を数えると45組、元記事のURLという別の列で数え直すと139組になった実例があります（archives/129）。canonicalタグは、こうして見つかった重複URL群に対して、Googleへ代表版を伝える手段です。重複を見つける方法と、見つけた重複をどう整理するかは、別の作業です。本記事は後者、archives/129は前者を扱っています。

「出力は在った。だから誰も測らなかった」回

datePublishedやog:typeなど、出力としては存在していたが、実際に正しい値になっているかを誰も確認していなかった4つの実例を扱った回があります（archives/128）。今回のcanonicalタグの確認も同じ構造です。タグが設置されていること（07章で確認済み）と、Googleがその通りに動いていること（05章のチェックリストで確認する対象）は別で、後者は出力を見ているだけでは分かりません。