PC・スマホで別URLのとき、canonicalはPC側に向ける
PC用とスマホ用でURLが分かれているサイトで、正規URLを指す rel="canonical" はどちらに向けるのが正しいのか。スマホ用URLに向けるものだと考えていたなら、向きが逆です。
PC用のURLが常に正規（canonical）で、スマホ用URLはその代替（alternate）。
「モバイルサイトとモバイルファースト インデックスに関するベスト プラクティス」には、別URL構成の例として The desktop URL is always the canonical, and the mobile version is the alternate of that URL.（PC用URLが常に正規URLで、モバイル版はそのURLの代替）と書かれています。スマートフォン向けの見え方をどう作るかという話と、どちらのURLを正規として宣言するかという話は、別のレイヤーなのです。
だから、まず確かめるべきは向きです。そのうえで、PC側とスマホ側が1対1で互いを指しているか。ここがずれているサイトは、実際よく見つかります。
そもそも自社サイトはどの構成か
タグの話に入る前に、自分のサイトがどれに当てはまるかを確定させます。公式ドキュメントは、モバイル対応の構成を3つに分けています。次の表は、そこに書かれている説明をそのまま並べたものです。
| 構成 | 公式ドキュメントの説明 |
|---|---|
| レスポンシブ | easiest design pattern to implement and maintain（実装と維持がもっとも簡単な設計パターン） |
| 動的な配信（Dynamic serving） | 端末によらず同じURLを使う。ユーザーエージェントの判別と Vary: user-agent レスポンスヘッダーに依存して、端末ごとに違うHTMLを返す |
| 別URL（Separate URLs） | 端末ごとに違うHTMLを、別々のURLで配信する |
一つめのレスポンシブなら、この記事の作業はそもそも不要です。表示するURLを端末で分けない作り方なので、PC側とスマホ側の対応関係という概念が発生しません。
二つめの動的な配信も、URLは1本です。ただし公式の説明どおり、端末判別と Vary: user-agent ヘッダーに依存する構成なので、確認する対象は「ヘッダーを返せているか」に変わります。canonicalの向きの話ではありません。
この記事が扱うのは三つめです。https://m.example.com/ のようにスマホ用のホスト名が分かれている、いわゆるm-dot構成。あるいは /sp/ のようなパスで分けている構成も同じ扱いになります。
判別に迷ったら、スマホの実機かブラウザの端末エミュレーションでトップページを開き、アドレスバーのURLを見てください。PCで見たときと文字列が違えば、別URL構成です。
向きは1つに決まっている
別URL構成では、2種類のタグを、それぞれ逆方向に置きます。
PC用ページ（例: https://example.com/dresses/green-dresses）には、対応するスマホ用ページを指す rel="alternate" を置きます。公式ドキュメントの例では、自分自身を指す rel="canonical" と並べて記述されています。
<link rel="alternate" media="only screen and (max-width: 640px)"
href="https://m.example.com/dresses/green-dresses">
<link rel="canonical" href="https://example.com/dresses/green-dresses">
スマホ用ページ（例: https://m.example.com/dresses/green-dresses）には、対応するPC用ページを指す rel="canonical" を置きます。
<link rel="canonical" href="https://example.com/dresses/green-dresses">
ポイントは media 属性です。PC側の alternate には、どの画面幅のときに代替版を使うのかを示す条件が付きます。公式の例では only screen and (max-width: 640px) が使われています。
もう一つ、URLの書き方にも決まりがあります。公式ドキュメントは、rel="canonical" をHTTPヘッダーで返す場合について、link要素のときと同じく絶対URLを使うよう指示しています。ホスト名が example.com と m.example.com で分かれる構成では、相対URLは事故のもとです。必ず https:// から書いてください。
図にすると、向きはこうなります。
PC用URL --- rel="alternate" ---> スマホ用URL
PC用URL <--- rel="canonical" --- スマホ用URL
矢印が両方とも引けて、しかも同じ内容のページ同士を結んでいる。これが正しい状態です。
1対1で対になっているかを確かめる5ステップ
ここからは実際に手を動かします。例として、架空のECサイトの商品ページ https://example.com/dresses/green-dresses を1本通してみます。使うのはブラウザのデベロッパーツールだけです。
- PC用URLをPCのブラウザで開き、head内の
alternateを探す。 デベロッパーツールの Elements タブを開き、検索（Ctrl+F / Cmd+F）にrel="alternate"と入力します。今回の例ではhref="https://m.example.com/dresses/green-dresses"が見つかりました。media属性が付いているかもここで確認します。 - その
hrefの値をコピーして、そのまま開く。 アドレスバーに貼り付けて移動します。ここでスマホ用のトップページに飛ばされたら、対応が1対1になっていません。緑のワンピースの商品ページが表示されるのが正解です。 - スマホ用ページのhead内の
canonicalを確認する。 同じくElementsタブでrel="canonical"を検索し、そのhrefが手順1のPC用URLと文字列として完全に一致するかを見ます。httpとhttpsの違い、wwwのあり・なし、末尾のスラッシュ、余計なパラメータ。細かな揺れが残っていると、意図した対応関係が伝わらないことがあります。ここは完全一致を目指してください。 - 端末を切り替えて、リダイレクトの行き先を見る。 デベロッパーツールの端末ツールバー（Device toolbar）でスマートフォンを選び、手順1のPC用URLを再読込します。Networkタブでリダイレクトの連鎖を追い、最終的な到達先が手順2のスマホ用URLと一致するかを確認します。ここでトップページに落ちる実装は、手順2と同じ症状がリダイレクト側にも出ている状態です。
- テンプレートの種類ごとに記録する。 1URLで通ったからといって、サイト全体が正しいとは限りません。トップ、カテゴリ一覧、商品詳細、記事、検索結果ページ。テンプレートの系統ごとに代表URLを1本ずつ選び、手順1〜4の結果を表に残します。
この5ステップを商品ページで通した結果、alternate は正しく個別ページを指していたのに、スマホ側の canonical がすべてPCのトップページを指していた——というのが、実際によく見つかる型の一つです。片側だけを見ていると気づけません。往復させるからこそ見つかります。
よくあるつまずきと直し方
手順3と手順4で引っかかるパターンを、症状から引けるようにまとめます。
| 症状 | 起きていること | 直し方 |
|---|---|---|
PC側に alternate はあるが、スマホ側に canonical がない | 片方向の宣言。往路だけで復路がない | スマホ用テンプレートに、対応するPC用URLを出力する canonical を追加する |
スマホ側の canonical が全ページ同じURLを指す | テンプレートに固定値が埋め込まれている | ページごとに対応するPC用URLを動的に出力する |
alternate の href がスマホ用トップに集約されている | 対応関係が1対1になっていない | 商品IDやスラッグを引き継いだURLを生成する |
| PC用URLをスマホで開くと無関係なページに着く | 端末リダイレクトの対応表がずれている | 対応するURLへリダイレクトする。対応先が無いページはリダイレクトしない |
canonical や alternate が相対URLで書かれている | ホスト名が変わる構成で解決先がずれる | 絶対URLに書き換える |
| スマホ側だけ本文・画像・内部リンクが少ない | 端末別にコンテンツを出し分けている | タグの前に、内容そのものの差を埋める |
一つめの「片方向」が、いちばん多い型です。PC側の対応だけ先に入れて、スマホ用テンプレートの改修が後回しになったまま残っているケース。手順1は通るのに手順3で止まるなら、これを疑ってください。
二つめと三つめは、原因が同じところにあります。テンプレートの共通部分にURLをベタ書きしてしまい、ページごとの出し分けが漏れている状態。canonical と alternate は、どちらもページ単位で値が変わる要素です。
四つめは、タグではなくリダイレクトの問題です。手順1〜3がすべて緑なのに手順4で落ちるなら、確認する場所はサーバー側の対応表になります。
五つめの相対URLは、同一ホスト内なら動いてしまうぶん、見落としやすい落とし穴です。m.example.com から相対で書いた canonical は、m.example.com 側のURLに解決されます。自分自身を正規と宣言してしまい、意図と逆のことが起きます。
六つめだけは毛色が違います。タグの整合は取れていても、スマホ側の本文や内部リンクが削られていると、期待した評価にならないことがあります。ここは構成の問題ではなく、コンテンツの問題です。
直してもすぐには反映されないことがあります
タグを正しくしたのに、検索結果の表示URLが変わらない。この状態を「設定ミスが残っている」と判断するのは、少し早いかもしれません。
正規化について、公式ドキュメントはこう説明しています。正規ページは最も高い頻度で定期的にクロールされ、重複ページは正規ページより低い頻度でクロールされる、と。つまり、代替として扱われている側のページに加えた変更は、読み取られるまでに間があく場合があります。
もう一つ、押さえておきたい前提があります。公式ドキュメントは、正規化で重要となる要素として、HTTPとHTTPSのどちらでページが提供されているか、リダイレクト、サイトマップ内でのURLの有無、そして rel="canonical" link アノテーションの4つを挙げています。そのうえで、これらの手法でGoogleに希望を伝えることはできるが、別のページが正規として選ばれる場合もあると明記しています。正規化の希望は伝えられても、確実ではない。
ここから逆算すると、canonical タグ以外に打てる手が3つあることが分かります。
- HTTP/HTTPSの提供状況: PC用・スマホ用のどちらも
httpsで統一されているか - リダイレクト: 端末リダイレクトが、対応するURL同士を結んでいるか（手順4で確認したところ）
- サイトマップ内でのURLの有無: サイトマップに載せるURLを、正規として宣言している側に揃えているか
タグだけを直して結果が変わらないときは、この3つが canonical と逆の信号を出していないかを見ます。宣言と実装が食い違っていると、こちらの希望はうまく伝わりません。
なお、この「複数の重複URLから1つを代表として選ぶ」という枠組み自体は、別URL構成に限った話ではありません。公式ドキュメントは、重複コンテンツが発生する原因として、地域の違い、プロトコルの違いと並べて、**デバイスの違い（1つのページにモバイル版とPC版がある場合）**を挙げています。m-dot構成は、URL正規化という大きなテーマの一事例という位置づけです。
自己点検チェックリスト
代表テンプレートごとに、次の6点を確認してください。すべてに「はい」と答えられれば、向きと対応関係については問題ありません。
- PC用ページのheadに、対応するスマホ用URLを指す
rel="alternate"がある（media属性つき） - スマホ用ページのheadに、対応するPC用URLを指す
rel="canonical"がある - 上の2つのURLが、互いに同じ内容のページを指している（トップページに集約されていない）
- URLがすべて絶対URLで書かれている（
https://から始まっている） - 端末を切り替えたときのリダイレクト先が、タグの宣言と一致している
- サイトマップに載せているURLが、正規として宣言している側に揃っている
チェックが1つでも外れたら、前節の表で症状から原因を引いてください。
なお、この作業は「複数のURLに分かれた同じ内容を、どこか1つに寄せる」という一般的な正規化と地続きです。パラメータ違いや www のあり・なしも含めた全体像は 重複コンテンツとcanonicalの考え方 に、URL文字列の細かな揺れをどう潰すかは URL末尾のスラッシュ有無を1つに統一する手順 にまとめています。
出典