canonicalタグは301転送・内部リンク・サイトマップと役割を分けて使う

canonicalタグは、同じ内容または包含関係にある内容を複数のURLで表示するとき、どのURLを代表にしたいか示すために使います。一般に「canonicalタグ」と呼ばれますが、HTMLへ記述するのはrel="canonical"を指定したlink要素です。

これは、閲覧者を別のURLへ移動させる転送ではありません。ページを削除する機能でも、検索結果への掲載や順位を保証する設定でもありません。恒久的に一つのURLだけを使うなら、まず301転送を検討します。複数のURLを閲覧可能なまま残す事情があり、内容が重複している場合に、rel="canonical"を検討します。

設定作業より先に、重複しているURLと、今後使う代表URLを一組ずつ決めてください。内部リンクとXMLサイトマップも同じ代表URLへそろえます。canonicalだけが別のURLを指している状態では、サイトの方針が分かれたままです。

canonicalが扱うのは、重複する内容の代表URLである

2012年4月に発行されたRFC 6596は、canonicalのリンク関係を、重複する内容の中から優先するIRIを示すものとして定義しました。代表URLの内容は、設定元と重複しているか、設定元の内容を含むものでなければなりません。

たとえば、次の二つのURLで同じサービス案内を表示しているとします。これは、形式を説明するための仮例です。

• http://www.example.com/service/
• http://www.example.com/service/?ref=mail

二つ目のURLにだけ計測用の文字列が付き、本文が同じなら、文字列のない一つ目を代表にする判断ができます。二つ目のHTMLのhead内へ、次のように記述します。

<link rel="canonical" href="http://www.example.com/service/" />

rel="canonical"の公式説明でも、並べ替え用の文字列やセッションIDなどにより、同じか非常によく似た内容へ複数のURLから到達する例が使われています。同資料は、rel="canonical"を命令ではなく、検索結果へ表示してほしいURLを示す手掛かりとして説明しています。

したがって、設定したURLが必ず選ばれるとは断定できません。サイト側が示す代表URLと、検索エンジンが他の情報を含めて判断するURLは、分けて考えます。

先に、301転送とcanonicalを分ける

同じ内容を一つのURLへそろえる方法は、canonicalだけではありません。閲覧者にも検索エンジンにも古いURLを使わせる必要がなく、恒久的に移転したなら、301転送が先の候補です。

末尾スラッシュの異なるURLを統一する説明は、両方のURLが同じ内容を返す場合、代表を一つ選び、内部リンクとサイトマップをそろえ、重複側から301転送する順序を示しています。301転送ができない場合の選択肢として、rel="canonical"も挙げています。

使い分けは、次のように考えます。

「古いURLを消したい」という目的と、「同じ内容を複数URLで見せたい」という条件は別です。前者へcanonicalを入れても、閲覧者は古いURLを開けます。何を残し、どこへ移すかを先に決めます。

内容が違うページを、一つへまとめない

canonicalは、似た検索語を狙うページを一つへ寄せるための印ではありません。文章の一部だけが共通していても、読者へ渡す内容が違えば、単純な重複とは限りません。

RFC 6596は、複数ページに分かれた記事について、二ページ目から一ページ目をcanonicalにする例を避けるよう示しています。一ページ目は、二ページ目の内容を含まないためです。この設定では、二ページ目の固有内容が重複として扱われ、処理されないおそれがあります。一方、全ページの内容を含む「全件表示版」を代表にする例は、内容の包含関係がある場合として説明されています。

会社案内とサービス案内、一覧と個別ページ、地域ごとに固有情報がある案内などは、見出しが似ているという理由だけで一つへ寄せません。各URLの本文を読み、代表URL側に設定元の内容が実際に含まれているか確認します。

代表URLは、表示できる一つのURLへ直接向ける

設定先は、ブラウザで表示できる代表URLにします。RFC 6596は、一つのページから複数のcanonicalを指定しないこと、エラーを返すURLや別URLへ恒久転送するURLを設定先として避けること、canonicalの連鎖を避けることを示しています。

たとえば、AがBを指し、BがCを指すように連ねません。AとBの内容がCと重複し、Cを代表にするなら、AとBからCへ直接向けます。設定後にCを開き、予定した本文が表示されることも確認します。

記述するURLは、httpまたはhttpsから始まる完全な形にすると、基準を目で照合しやすくなります。RFC 6596とrel="canonical"の公式説明は相対IRIも認めていますが、base要素や設置階層による解釈を確認する仕事が増えます。これは規格上の必須条件ではなく、運用上の判断です。

robots.txtで隠す前に、検索エンジンが設定を読めるか考える

重複URLへcanonicalを記述しても、検索エンジンがそのページを取得できなければ、記述を確認できません。重複コンテンツをまとめる説明は、重複ページをrobots.txtで取得禁止にせず、301転送やrel="canonical"などで代表URLを示す考え方を示しています。

ただし、これは「すべての非公開ページを取得可能にする」という意味ではありません。重複URLの整理と、社内用・試験用・個人情報を含むページの公開制御は別の仕事です。公開してはいけないページをcanonicalだけで処理しません。

内部リンクとXMLサイトマップも、同じURLへそろえる

canonicalを設定しても、メニューはA、本文中のリンクはB、XMLサイトマップはCという状態では、サイト側の指定が一致しません。代表URLの統一に関する説明は、代表URLを内部リンクに使い、サイトマップにも代表URLだけを含めるよう案内しています。

URLごとに、次の項目を一行へまとめます。

WordPressなどのCMSでは、テンプレート、追加機能、個別設定が同じlink要素を出す場合があります。製品名だけで判断せず、実際に出力されたHTMLを開き、canonicalが一つだけか、設定先が予定どおりかを確認します。本稿では、特定の追加機能を推奨しません。

決める人と実装する人を分ける

代表URLは、HTMLを編集する人だけで決める項目ではありません。今後、広告、印刷物、メール、電話案内などで使うURLにも関係するためです。

外部へ作業を委託する場合も、「canonicalを設定した」という報告だけで完了にしません。重複URL、代表URL、選んだ方法、変更箇所、確認結果を事業者側へ残します。契約上の権利は、実際の契約で別に確認してください。

最初の一手は、検索結果に二つ出ているかを探すことではありません。自社サイトで同じ本文を返すURLを一組選び、両方を開きます。今後も両方を閲覧可能にする必要があるかを決め、不要なら301転送、必要なら内容の重複を確認してcanonicalを検討します。最後に、内部リンクとXMLサイトマップを代表URLへそろえてください。