canonicalが効かない原因の切り分け｜別URLが正規に選ばれるとき
canonical はちゃんと書いた。なのに URL 検査ツールを開くと、「Google が選択した正規 URL」が自分の指定と違う。——この状態の原因は、おおむね4つに絞れます。タグが読まれていない、指定先の URL 自体に問題がある、他のシグナルが別の URL を指している、そしてそもそも2つのページが重複とみなされていない、の4つです。
先に押さえておきたいのは、Google 公式の立場です。rel="canonical" は命令ではありません。公式ドキュメントは、正規化に関わる要因として「HTTP か HTTPS か」「リダイレクト」「サイトマップに URL があるか」「rel="canonical" の指定」を挙げたうえで、これらで希望を伝えることはできるが、Google はサイト側の指定とは異なるページを正規として選ぶことがあると書いています。つまり「無視された」のではなく、「他の手がかりに負けた」か「手がかりとして届いていない」かのどちらかです。
どちらなのかを見分けるのが、この先の作業です。
まず、それは直す必要がある状態か
URL 検査ツールのヘルプは、Google がユーザー指定と異なる URL を正規に選んだ状態について、エラーではなく意図どおりの動作だと説明しています。Google は重複するページを検索結果に出さないので、どちらか一方を代表として選ぶ、という理屈です。
だから、件数があること自体は問題ではありません。
問題になるのは次の2つの場合だけです。
- Google が選んだ URL が間違っていると考える場合。ヘルプは、この場合はそのページの canonical を明示的に指定するよう案内しています。
- そもそも重複ではない（別の内容のページが同一視されている）と考える場合。ヘルプはこれを別の分岐として扱っています。この記事では、2ページの内容をはっきり分ける対処を勧めます。
判断の材料は、公式ドキュメントのもう1つの記述にあります。Google は正規ページを、内容と品質を評価する主な情報源として使うこと。そして検索結果は通常、正規ページを指すことです。言い換えると、評価を集めたいページが正規に選ばれていないなら、直す価値があります。逆に、どちらが選ばれても困らないなら、放置して構いません。
この記事は「直す価値がある」と判断した方に向けて続けます。
原因を4つに分ける判定表
原因の当たりをつけるために、先に全体を表で示します。右端の列が、次の節で行う点検のどのステップで確定するかです。
| 分類 | 症状の出方 | 代表的な中身 | 確定するステップ |
|---|---|---|---|
| ① タグが読まれていない | URL 検査の「ユーザーが指定した正規 URL」が空、または想定と違う | <body> 内に記述、相対パス、複数の canonical が混在、テンプレートの上書き | Step 2〜3 |
| ② 指定先に問題がある | 指定先が 404・リダイレクト・noindex | 旧 URL を指している、末尾スラッシュ違い、http 指定 | Step 3〜4 |
| ③ 他のシグナルが別 URL を指す | タグは正しく読まれているのに選ばれない | サイトマップが別 URL、リダイレクトの向きが逆、HTTPS 版が別にある | Step 4 |
| ④ 重複とみなされていない | canonical 先とは別の理由で「重複」系に分類される、または別々に索引される | 2ページの内容差が大きい／小さい、ページ送りの2ページ目から1ページ目を指している | Step 5 |
一つめの「タグが読まれていない」は、実は最も見落とされます。書いたつもりが、Google には届いていない。公式ブログはよくある間違いの1つとしてこれを挙げ、<body> 内にある rel=canonical は考慮されないと明記しています。HTML の解析トラブルを避けるため、<head> のできるだけ先頭近くに置くことも勧められています。
二つめと三つめは、タグは届いているのに負けているケースです。公式ブログは、指定先の URL が有効であること、指定先に noindex が無いこと、絶対 URL を使うこと、複数の宣言や意図しない宣言を避けることを挙げています。サイトマップやリダイレクトが別の URL を推している場合は、そちらが勝つことがあります。
四つめは、公式ブログの「ページ送りの2ページ目以降から1ページ目へ canonical を向ける」例がわかりやすい。2ページ目は1ページ目の重複ではないので、これは正しい使い方ではない、と書かれています。カテゴリページから特集記事へ向ける例も同じく誤用として挙がっています。
5ステップで原因を確定する手順
ここからは、1つの URL を題材にして実際に通します。題材は EC サイトでよくある「色違いで URL が分かれた商品ページ」です。
- 正規にしたい URL:
https://example.com/items/bag-a/ - 色違い（重複扱いにしたい）:
https://example.com/items/bag-a/?color=red - 状況:
?color=red側に<link rel="canonical" href="/items/bag-a/">を書いたが、URL 検査では「Google が選択した正規 URL」が?color=red自身になっている
- URL 検査で2つの値を書き写す。 Search Console の URL 検査に
?color=redの URL を入れ、「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」をメモします。ヘルプによると、ページが canonical を明示的に宣言していれば前者に表示されます。ここが空なら①の疑いが濃厚で、タグが届いていません。題材では前者が空でした。 - Google が実際に受け取った HTML を見る。 同じ画面の「クロール済みのページを表示」を開きます。ヘルプにあるとおり、ここで HTTP のリクエストと応答、返された HTML を確認できます。ブラウザの表示ではなく、Google が受け取った HTMLで canonical を探すのがポイントです。JavaScript で後から挿入している場合、ここで消えていることがあります。
- 記述位置・形式・個数を点検する。 受け取った HTML で次を確認します。
<head>内にあるか（<body>にあれば考慮されない）hrefが絶対 URL か（題材は/items/bag-a/と相対パスでした。公式ブログは絶対 URL を勧めています）<link rel="canonical">が1つだけか（テンプレートと CMS プラグインで二重に出ることがあります）- 指定先がリダイレクトや 404 になっていないか。ターミナルで
curl -sI https://example.com/items/bag-a/ | head -n 1を打ち、200が返るか見ます
- 他のシグナルの向きをそろえる。 公式ドキュメントが挙げる要因を、1つずつ「どの URL を推しているか」で並べます。
- サイトマップ:
?color=red側が載っていないか。載っているなら正規にしたい URL だけに絞る - リダイレクト:
http://やwww無しから、正規にしたい URL へ正しく 301 で向いているか - HTTPS: 正規にしたい URL が https で、canonical の
hrefも https か ここで向きが割れていれば③です。canonical は「手がかりの1つ」なので、他の手がかりが別を指すと負けることがあります。
- サイトマップ:
- 2ページが本当に重複かを見直す。 題材では色違いで本文がほぼ同一なので、重複とみなされるのが自然です。もし
?color=red側だけに固有の説明文やレビューが大量にあるなら、Google が「別ページ」と判断することがあります。その場合は2つ目の分岐、つまり重複でないなら内容を分ける対処に進みます。
題材の結論はこうなりました。Step 1 で「ユーザーが指定した正規 URL」が空。Step 2 の HTML では、canonical が <body> の直前ではなく、テンプレートの都合で </head> の後に出力されていました。つまり①です。タグを <head> の先頭側に移し、href を https://example.com/items/bag-a/ の絶対 URL に直して、再クロールを待ちます。
修正後にすぐ値が変わるとは限りません。しばらくおいてから、同じ Step 1 をもう一度やって確かめてください。
よくある誤解——「重複があるとペナルティ」ではない
canonical が効かないと聞いて、「重複コンテンツとして罰せられているのでは」と心配になる方がいます。公式ドキュメントはこの点をはっきり否定しています。サイト内に多少の重複があるのは普通で、スパムポリシー違反ではない、と書かれています。
ただし同じ文書は続けて、同じ内容が多くの URL で開ける状態は、ユーザーにとって分かりにくい体験になり得る、とも述べています。どれが正しい URL なのか、訪問者が迷うからです。直す理由は「罰を避けるため」ではなく、評価と導線を1つに集めるためと捉えると、優先順位を間違えません。
もう1つの誤解は、canonical を書けば確実に反映される、というものです。公式ヘルプは canonical の宣言方法として link タグ・HTTP ヘッダー・サイトマップなどを挙げつつ、保証はない旨を添えています。宣言は希望であって、最終判断は Google 側です。だから、宣言した後は必ず URL 検査で結果を見に行く必要があります。
修正前の自己点検リスト
修正を始める前に、次の項目を上から順に確かめてください。1つでも「いいえ」があれば、そこが原因の候補です。
| 点検項目 | はい／いいえ | いいえの場合の対処 |
|---|---|---|
| URL 検査の「ユーザーが指定した正規 URL」に、意図した URL が出ている | <head> 内・絶対 URL・1個だけ、の3点を見直す（①） | |
| 「クロール済みのページを表示」の HTML に canonical が含まれている | JavaScript 挿入をやめ、サーバー側で出力する（①） | |
| 指定先 URL が 200 を返し、リダイレクトしない | 指定先を最終 URL に書き換える（②） | |
| 指定先 URL に noindex が無い | noindex を外すか、指定先を変える（②） | |
| サイトマップに載っているのは正規にしたい URL だけ | 重複側をサイトマップから外す（③） | |
| http→https、www 有無のリダイレクトが正規 URL に向いている | リダイレクト先を正規 URL にそろえる（③） | |
| 2ページの内容がほぼ同一で、片方だけの固有情報が無い | 重複でないなら内容を分け、canonical を外す（④） |
一番上の項目で「いいえ」が出た場合、下の項目を見る前に①の修正を先にしてください。タグが届いていない状態では、他のシグナルをいくら整えても canonical の効果は検証できません。
canonical が正しく届いたあとに「代替ページ（適切な canonical タグあり）」へ分類が変わることがあります。その行の読み方は 代替ページ（適切なcanonicalタグあり）の対処要否を見分ける にまとめています。計測用パラメータ付き URL の正規化を確かめたい場合は、計測用パラメータ付きURLの正規化を確かめる手順 が使えます。
出典