Domain 3 / 225
canonical は重複コンテンツの正規 URL を Google に伝える仕組み
canonical の要点
canonical は重複ページの正規 URL を Google に伝えるヒントで、順位を上げる効果はない。指定方法は強い順に 301 / rel=canonical / サイトマップ。指定しても Google が別ページを正規と判定することがあり、URL 検査ツールで確認する
なぜこれを学ぶか
canonical は 誤設定すると重複ページが順位を食い合い、流入が分散したまま気づかれない 静かに損をするタイプのトラブル原因。 逆に正しく使えば、www / 非 www / HTTPS / URL パラメータ違いの評価を 1 ページに集約でき、被リンクシグナルを最大化できる。 EC・大規模メディア・多言語サイトでは、canonical を理解せずに運用すると数百ページ単位でカニバリゼーションが発生する。
学ばないと起きること
| よくある事故 | 被害 |
|---|---|
| 商品カラー違いページに canonical を未設定 | 各色ページが互いの順位を食い合い、Top 10 から落ちる |
| www あり / なしの正規化未設定 | 被リンクが両方の URL に分散して PageRank が薄まる |
canonical を相対パス（/page.html）で書く | ステージング環境がクロールされた時に意図せぬ URL が canonical 化 |
| canonical で順位を上げようと無関係ページに打つ | 内容が違いすぎて Google が無視、施策ごと無効になる |
| HTTPS 証明書エラーがある | Google が HTTP 版を強制的に canonical 化、実装した HTTPS が無視される |
| CMS が勝手に canonical を間違って設定 | 想定と違うページが検索結果に出続け、修正漏れで気づかれない |
| robots.txt で重複を Disallow して canonical 代わりにする | NG。Disallow しても URL は知られ、検索結果に説明なし URL が出る |
学ぶメリット
- 重複によるカニバリゼーションを未然に防げる
- 被リンクシグナルを 1 ページに集約して、検索順位の天井を上げられる
- EC や多言語サイトの運用設計を、Google 仕様に沿って組める
- 商談で「Google に強制はできない、ヒントです」と即答できれば、SEO 担当としての解像度が高いことを示せる
仕組み
canonicalization とは
Google が「同じ・類似コンテンツが複数 URL にある時、どれを代表（canonical）として検索結果に出すか」を選ぶプロセス。 代表に選ばれた URL は最も頻繁にクロールされ、評価シグナルもそこに集約される。それ以外の URL は「代替版（alternate）」となり、モバイル端末や特定クエリで切り替わって表示されることがある。
なぜ重複が生まれるか
Google が公式に挙げる重複の発生源。
| 種類 | 例 |
|---|---|
| 地域別 | US 向けと UK 向けで同内容を別 URL で配信 |
| デバイス別 | デスクトップ版とモバイル版が別 URL |
| プロトコル別 | HTTP 版と HTTPS 版が両方アクセス可能 |
| サイト機能 | カテゴリページのソート / フィルター結果（?sort=price など） |
| 偶発的 | ステージング環境やデモが Googlebot に拾われている |
「重複コンテンツがある = ペナルティ」ではない。Google は重複を検出して 1 ページにまとめるだけで、悪意のある複製でない限りスパム扱いにはならない。
canonical を指定する 4 つの方法（強い順）
| 方法 | 強さ | 主な用途 |
|---|---|---|
| 301 リダイレクト | 強 | 重複ページを完全に削除して統合する場合 |
rel="canonical" link 要素（HTML） | 強 | HTML ページの代表 URL 指定 |
rel="canonical" HTTP ヘッダー | 強 | PDF / Word など非 HTML ファイルの代表 URL 指定 |
| サイトマップに含める | 弱 | 大規模サイトで簡易に正規 URL を示す |
複数併用するとシグナルが重なり、効果が高まる。 ただし「サイトマップでは A、rel=canonical では B」のように矛盾した指定は避ける（混乱の元になる）
canonical はヒントであってルールではない
公式に明記されている重要な性質:
- canonical は Google への「ヒント」であり、別ページを正規と判定されることがある
- Google は HTTPS / 内容の充実度 / 内部リンク / 被リンク など複数シグナルを総合判断する
- 指定しなくても Google が自動で代表 URL を選ぶ（多くのサイトで指定なしでも問題なく動く）
「指定したのに別 URL が選ばれている」場合は Search Console の URL 検査ツールで Google の判断結果を確認する。
キー概念
canonical の HTML 実装
<head> 内に link 要素として記述する。
<html>
<head>
<title>グリーンドレス特集</title>
<link rel="canonical" href="https://example.com/dresses/green-dresses" />
</head>
ポイント:
- 絶対 URL を使う（
https://...から始める）。相対パスはサポートされるが、ステージング誤公開時の事故源になるので非推奨 <head>の中に置く。<body>内では Google に無視される- JavaScript で挿入する場合は、初期 HTML の canonical を上書きしないようにする
非 HTML ファイル（PDF など）の canonical
PDF や Word ファイルは HTML を持たないので、HTTP レスポンスヘッダーで指定する。
HTTP/1.1 200 OK
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"
「同じ資料の .docx 版と .pdf 版で .pdf を代表にしたい」のようなケースに使う。
canonical と HTTPS の関係
Google は基本的に HTTPS 版を優先して canonical にする。ただし、以下の条件があると HTTP 版が選ばれることがある。
| 条件 | Google の挙動 |
|---|---|
| HTTPS の SSL 証明書が無効 | HTTP 版を強く優先（HSTS でも上書き不可） |
| HTTPS ページに混在コンテンツ（mixed content）がある | 同上 |
| HTTPS から HTTP に転送される | 同上 |
| HTTPS ページが HTTP 版に rel=canonical を打っている | HTTP 版を選ぶ |
HTTPS 移行時は「証明書を正しく設置」「HTTP → HTTPS の 301 リダイレクト」「サイトマップ・hreflang は HTTPS 版を記載」「HSTS の併用」をセットでやる。
hreflang クラスタと canonical
多言語サイトで hreflang を使うと、Google は hreflang クラスタ内の URL を優先して canonical にする。クラスタ外の URL（hreflang を持っていない言語版）は canonical 候補から外れやすい。
よくある誤解
| よくある誤解 | 実際のところ | 出典 |
|---|---|---|
| canonical で順位を上げられる | 順位を上げる効果はない、重複ページの統合用 | URL の正規化 |
| canonical を指定すれば必ず Google が従う | ヒント扱い。Google が別ページを正規と判定することがある | 同上 |
| robots.txt で Disallow すれば canonical 代わりになる | NG。Google は Disallow した URL も検索結果に出すことがあり、評価統合もされない | canonical 統合方法 |
| URL 削除ツールを canonical の代わりに使える | 全バージョンを検索から消すツールなので canonical 代替には使えない | 同上 |
<head> でも <body> でも canonical は効く | <head> 内のみ有効。<body> 内のものは無視される | 同上 |
| 相対パスで canonical を書いて問題ない | サポートはされるが、誤公開時の事故源になるため絶対 URL 推奨 | 同上 |
| HTTP / HTTPS が混在しても勝手に HTTPS が選ばれる | 証明書エラーや mixed content があると HTTP 版が canonical 化される | 同上 |
| canonical タグを複数の方法で違う URL に向けてもいい | NG。サイトマップと rel=canonical で異なる URL を指定すると Google が混乱する | 同上 |
| canonical で別ドメインの自社ページを指定できる | 可能（クロスドメイン canonical）。シンジケーション提携などで使う | 同上 |
| 自己参照 canonical（自分自身を指す）は不要 | 推奨。URL パラメータ違いやスクレイピング被害から守るために自己参照を入れるのが安全 | 同上 |
実務での適用
新規サイト・ページ追加時のチェックリスト
- すべてのページに自己参照 canonical（自分自身の絶対 URL）が入っているか
- www / 非 www のどちらかに 301 で統一しているか
- HTTP → HTTPS の 301 リダイレクトが効いているか
- サイトマップに記載する URL は canonical と一致しているか
- URL パラメータ（
?utm_source=...、?ref=...）が混入したページの canonical がパラメータなし版を指しているか - ページネーション（
?page=2）の canonical を 1 ページ目に向けていないか（各ページを別コンテンツとして扱う方が現代では推奨）
EC サイト: 商品カラー違いの canonical 設計
<!-- /products/dress-red （色違いページ）-->
<link rel="canonical" href="https://example.com/products/dress" />
<!-- /products/dress-blue （色違いページ）-->
<link rel="canonical" href="https://example.com/products/dress" />
<!-- /products/dress （統合元の代表ページ、自己参照）-->
<link rel="canonical" href="https://example.com/products/dress" />
色ごとに固有のキーワードで上位を取りたい場合は別ページとして残し、canonical も自己参照にする。 カニバリゼーションが起きていれば代表ページに統合する。
CMS（WordPress 等）の落とし穴
CMS のテンプレートやプラグインが勝手に canonical を出力していることが多い。新規導入時は以下を確認する。
| 確認項目 | チェック方法 |
|---|---|
| canonical が二重出力されていないか | ブラウザの DevTools で <head> を表示、link[rel=canonical] の数を数える |
| canonical が想定外の URL を指していないか | URL 検査ツールで Google が選んだ canonical を確認 |
| プラグイン更新で canonical の挙動が変わっていないか | Search Console の「ページ」レポートで重複扱いが急増していないか定点観測 |
トラブル別の対処
| 症状 | 確認すべきこと |
|---|---|
| 自分が指定した URL と違うページが検索結果に出る | URL 検査ツールで Google が選んだ canonical を確認、シグナル整合（HTTPS / 内容充実度 / 内部リンク）を見直す |
| Search Console で「重複、Google が選択した正規 URL がユーザー指定と異なります」が増えた | サイトマップと rel=canonical の指定が一致しているか、内容差分が小さすぎないか |
| 海外ドメインに自分のページがコピーされて検索結果に出る | DMCA 削除リクエストを Google に提出 |
| HTTPS 移行後も HTTP が canonical のまま | 証明書エラー / mixed content / HTTP → HTTPS リダイレクトの欠落を解消 |
| ページネーション 2 ページ目以降が検索に出ない | 各ページの canonical が 1 ページ目を指していないか、自己参照に修正 |
公式ソース
- URL の正規化（canonicalization）
- canonical URL の指定方法
- canonical の問題を解決する
- URL 検査ツール
- 301 リダイレクト
- hreflang を使ったローカライズ版の管理
自己テスト
Q1. canonical タグで検索順位を上げられるか？
上げられない。canonical は重複コンテンツの統合（正規 URL の指定）が目的であり、順位を上げる効果はない。 被リンクや評価シグナルを 1 つの URL に集約することで、結果的に「分散していた評価が 1 ページに集まる」効果はあるが、絶対的な順位上昇とは別物
Q2. canonical を指定すれば、必ず Google はその URL を検索結果に出すか？
出さないことがある。canonical は Google への「ヒント」であり、ルールではない。 HTTPS の優先、内容の充実度、内部リンク、hreflang クラスタなど、複数のシグナルを総合判断して別ページを正規と判定することがある。 実際にどの URL が選ばれたかは Search Console の URL 検査ツールで確認できる
Q3. canonical を指定する 4 つの方法のうち、最も強いシグナルはどれか？
301 リダイレクト。重複ページを完全に削除して統合する場合に最も強い。 次が rel="canonical" の link 要素 / HTTP ヘッダー、最も弱いのがサイトマップへの記載
Q4. canonical タグは `<body>` 内に書いても効果があるか？
ない。<head> 内に書いた canonical のみ Google に認識される。
JavaScript で後から挿入する場合は、初期 HTML の canonical を上書きしないように注意する
Q5. HTTPS のページがあるのに、Google が HTTP 版を canonical として選ぶことがあるのはどんな時か？
以下のいずれかが起きている時:
- HTTPS の SSL 証明書が無効
- HTTPS ページに mixed content（HTTP リソース）が混入
- HTTPS から HTTP に転送するリダイレクトがある
- HTTPS ページが HTTP 版に rel=canonical を打っている
これらは HSTS でも上書きできないので、証明書とリダイレクトの根本修正が必要
Q6. canonical の代わりに robots.txt の Disallow を使ってもいいか？
NG。Disallow するとクローラーが内容を取得できず、評価統合もされない。 さらに被リンクで URL が発見されると検索結果に「説明なし URL」として出てしまう
Q7. canonical を相対パス（例: `/page.html`）で書いても問題ないか？
サポートはされるが、推奨されない。
ステージング環境がクロールされた時に意図せぬ URL（https://staging.example.com/page.html）が canonical 化される事故源になる。
絶対 URL（https://www.example.com/page.html）で書くのが安全
Q8. PDF ファイルにも canonical を指定できるか？
可能。HTML を持たないので、HTTP レスポンスヘッダーで指定する。
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"
「同じ資料の .docx 版と .pdf 版で .pdf を代表にしたい」のようなケースで使う
これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。