この記事はAhrefs公式ブログの日本語訳です。
原文:Canonical Tags: A Simple Guide for Beginners
(著者:Joshua Hardwick 原文の最終更新日:April 14, 2020)
※フルスピード註:この記事は2020年4月14日時点の記載をもとに翻訳しています。
Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。
canonicalタグとは何か、重複コンテンツの問題を回避するためにどのように使用するか、学びたいですか?
canonicalタグは新しいものではありません。2009年以来 ー 実に10年以上もの長きにわたって存在しています。
このタグは、Google、Microsoft、Yahooの3社が一体となって作り上げられたものです。その目的な何なのか?一言で言えば、重複コンテンツの問題を迅速かつ容易に解決する方法を、ウェブサイトの所有者へ提供することにあります。
では、このタグは目的通りに機能するのでしょうか?はい、完璧に……と言いたいところですが、それにはウェブサイトの所有者が、タグの使い方を正しく理解する必要があります!
ということで、この記事ではcanonicalタグの使い方について、以下を学べます:
- canonicalタグとは
- canonicalタグはどのようなものか
- なぜcanonicalタグはSEOにおいて重要なのか?
- canonical化のベストプラクティス
- canonicalタグの実装方法
- よくある正規化ミスを防ぐには
- 正規化に関する問題の発見と修正方法
テクニカルSEOは初めてですか?
テクニカルSEOの初心者向けガイド
- canonicalタグとは何か?
- なぜcanonicalタグはSEOにおいて重要なのか?
- canonicalタグはどのような記述形式ですか?
- canonicalタグの実装の基本
- canonicalタグの実装方法
- よくある正規化の失敗を防ぐために
- あなたのウェブサイトの正規化の問題を発見し、修正する方法
- まとめ
canonicalタグとは何か?
canonicalタグ(rel=”canonical”)とは、重複ページや類似ページ、またはそれらに近いページについて、本来表示したいメインバージョンのページを定義するHTMLコードのスニペットのことです。つまり、同じまたは似たコンテンツが複数の異なるURLで提供されている場合、canonicalタグを使用して、どのバージョンがメインであるかを指定し、インデックスさせることができます。
なぜcanonicalタグはSEOにおいて重要なのか?
Googleは重複コンテンツを好みません。以下の理由により、どちらを選べばいいか難しくなるからです。
- どれをインデックスすべきか選びにくくなります(彼らは1つしかインデックスしません!)
- どれを関連する検索クエリにおいて上位表示させるべきか選べにくくなります。
- 「リンク・エクイティ(価値や信頼性)」を1つのページにまとめるべきか、複数のバージョンに分けるべきか、判断が難しくなってしまいます。
重複コンテンツが多すぎると、”クロールバジェット“にも影響します。つまり、Googleは、ウェブサイト上の他の重要なコンテンツを発見するためにかけるべき時間を、同じページの複数のバージョンをクロールすることに費やしてしまう可能性があるということです。
クロールバジェットの真実
Googleに重複コンテンツのクロールに無駄な時間を使わせることは、できれば避けたいことです。しかし、Googleは、ほとんどのサイトでは問題ないとしています。
新しいページが公開された場合、通常はその日にGoogleによってクロールされます。そのため、クロールバジェットについて心配する必要はありません。また、サイト内のURL数が数千以下であれば、ほとんどの場合、効率的にクロールされます。
canonicalタグは、上記の問題を解決するための重要な役割を果たします。このタグを使用することで、Googleに対してどのバージョンのページをインデックスし、ランク付けすべきか、また「リンク・エクイティ」をどこに集約すべきか明示できます。
しかし、canonicalタグの指定を誤ると、Googleは独自に問題を解決することになります。
canonical URLの指示がない場合は、最適と思われるバージョンまたはURLを特定します。
このようにGoogleに依存することは望ましくありません。なぜなら、Googleがあなたが本当にcanonicalとして指定したいバージョンのページを選択しない可能性があるからです。
重要な注意事項
Googleは一般的に、指定したcanonical URLを尊重すると述べていますが、常にその通りになるわけではありません。これは、canonicalタグがディレクティブではなくヒントとして扱われるためです。ただし、canonicalタグが適切に設定されていれば、リンクなどのシグナルは通常、canonical URLに集約されるはずです。
canonicalタグのベストプラクティスを使用することは、Googleがページの好ましくないバージョンをcanonicalとみなすリスクを軽減することにもつながります。
「でも、私のウェブサイトに重複したコンテンツはないですよ?」
同じ記事やページを何度も公開していない限り、あなたのウェブサイトに重複コンテンツがないと考えるのは簡単です。
しかし、検索エンジンはウェブページではなく、URLをクロールします。
つまり、example.com/productと example.com/product?color=redは、同一または類似のコンテンツを持つ同じウェブページであるにもかかわらず、固有のページとして扱われます。
これはパラメータ化されたURLと呼ばれ、特にeコマースサイトでは、ファセット/フィルタリングされたナビゲーションを持つ場合に重複コンテンツの問題が発生することがよく知られています。
例えば、Brown Bag Clothingはシャツを販売しています。下記は、彼らのメインカテゴリーページのURLです:
https://www.bbclothing.co.uk/en-gb/clothing/shirts.html
XLシャツのみを対象としたフィルタリングを行った場合、URLにパラメータが追加されます:
https://www.bbclothing.co.uk/en-gb/clothing/shirts.html?Size=XL
さらに、青いシャツだけというフィルターをかけると、さらに別のパラメーターが追加されます:
https://www.bbclothing.co.uk/en-gb/clothing/shirts.html?Size=XL&color=Blue
これらのページはわずかに異なるコンテンツを持っているだけですが、Googleの視点では別々のページと見なされます。
しかし、重複コンテンツの問題はECサイトに限定されるものではありません。
さまざまなタイプのウェブサイトに共通する、重複コンテンツと判定されたときの一般的な原因を以下に照会しましょう:
- 検索パラメータを含むURL(例:example.com?q=search-term)
- セッションIDを含むURL(例:https://example.com?sessionid=3)
- 印刷用の別ページが存在する(例:example.com/pageとexample.com/print/page)
- 異なるカテゴリの投稿に固有のURLがある(例:example.com/services/seoとexample.com/specials/seo)
- 異なるデバイス用のページがある(例:example.comとm.example.com)
- AMP版と非AMP版のページがある(例:example.com/pageとamp.example/page)
- wwwと非wwwのバリアントで同じコンテンツを提供する(例:http://example.comとhttp://www.example.com)
- httpとhttpsのバリアントで同じコンテンツを提供する(例:http://www.example.comとhttps://www.example.com)
- URLの末尾にスラッシュがある場合とない場合で同じコンテンツを提供する(例:https://example.com/page/とhttp://www.example.com/page)
- インデックスページのデフォルトバージョンで同じコンテンツを提供する(例:https://www.example.com/、https://www.example.com/index.htm)
- 大文字と小文字で同じコンテンツを提供する(例:https://example.com/page/、http://www.example.com/Page/)
このような状況では、canonicalタグを適切に使用することが重要です。
また、異なるドメイン間での重複コンテンツの問題も存在します。コンテンツのシンジケーション(配信)を行う場合、自己言及的なcanonicalタグを記事に使用し、シンジケートされたコンテンツがcross-domain canonicalタグでcanonicalバージョンとしてあなたを指定するようにするのがベストプラクティスです。
この設定により、配信されたコンテンツが検索結果から表示されなくなるという保証はないものの、オリジナル版のコンテンツよりも配信先ドメインのコンテンツのほうが上位表示してしまうリスクは軽減できます。
人々が意図的にコンテンツをシンジケートする場合、そのコンテンツの発信元を特定することは難しくなります。そのため、シンジケートするパブリッシャーに対して、canonicalタグやブロッキングの使用を推奨しています。パブリッシャーはこれを要求することができます。https://t.co/hblGLsD0ir https://t.co/yjtx43II8j
– ダニー・サリバン (@dannysullivan)2019年9月18日
注:ウェブサイトによっては、canonicalリンクの追加を拒否する場合があります。そのような場合、これまでに述べたリスクを取るかどうかは、これを読まれているあなた次第です。
canonicalタグはどのような記述形式ですか?
canonicalタグはシンプルで一貫性のある構文を使用し、ウェブページの<head>セクション内に配置されます:
<link rel=“canonical” href=“https://example.com/sample-page/” />
このコードの各パートにおける意味を、わかりやすく説明しましょう:
- link rel=“canonical”: このタグのリンクは、このページのマスター(canonical、正規)バージョンであることを指しています。
- href=“https://example.com/sample-page/”: 正規バージョンのページは、このURLから確認できることを表しています。
canonicalタグの実装の基本
canonicalタグの実装は簡単な手順で行えます。この項目では、4つの異なる設定方法と、それらに関連する5つの黄金律を説明しましょう。
ルール1:絶対的なURLを使用する
GoogleのJohn Muellerは、rel=”canonical “リンク要素で相対パスを使用しないことがベストプラクティスであると述べています。
どちらでも構いませんが、正しく解釈されるように絶対URLを使うことをお勧めします
—ジョンミューラー(公式) – #StaplerLife (@JohnMu) October 24, 2018
ですので、以下のように構成するのが良いでしょう。
正しい構成:
<link rel=”canonical” href=”https://example.com/sample-page/“/>
対照的に、やってはいけない構成:
<link rel=”canonical” href=”/sample-page/”/>
ルール2:小文字のURLを使用する
Googleは大文字と小文字のURLを別々のものとして扱うことがあるため、まずはサーバー上で大文字のURLを強制的に小文字に変換し、canonicalタグに小文字のURLを使用するように設定することが望ましいです。
ルール3:正しいドメインバージョンを使用する(HTTPS vs. HTTP)
SSL(HTTPS)に切り替えた場合、注意していただきたいことがあります。canonicalタグでは、SSL以外の(つまりHTTP)URLを指定しないように注意してください。そうすることで、理論上、混乱や予期せぬ結果が生じる可能性があります。安全なドメインを使用している場合は、以下のバージョンのURLを使用していることを確認してください。
正しい構成:
<link rel=”canonical” href=”https://example.com/sample-page/“/>
対照的な構成:
<link rel=”canonical” href=”http://example.com/sample-page/“/>
ルール4:自己言及的なcanonicalタグを使用する
GoogleのJohn Mueller氏は、強制ではないが、自己言及的なcanonicalタグは推奨されると述べています。
自己言及型canonicalの使用は、どのページをインデックスさせたいのか、あるいはインデックスされたときにどのようなURLになるべきかを私たち(Google)へ明確に示すことができるので、お勧めします。
たとえ1つのページであっても、URLのバリエーションによって、そのページが表示されることがあります。例えば、末尾にパラメータがあったり、大文字と小文字が混在していたり、wwwとnon-wwwが混在していたりします。これらはすべて、rel canonicalタグで一掃することができます。
John Mueller Googleのウェブマスター、トレンド・アナリスト
自己言及型canonicalの仕組みがよくわからない方のために説明すると、基本的に、自己言及型canonicalは、そのページが自分自身を指すこと(言及すること)を意味します。 たとえば、ページURLがhttps://example.com/sample-pageである場合、このページの自己言及型canonicalは以下のようになります。
<link rel=”canonical” href=”https://example.com/sample-page” />
最近の一般的なCMSでは、自己言及URLが自動的に追加されることがあります。ただし、カスタムCMSを使用している場合は、開発者に手動で自己言及型canonicalを追加してもらう必要があります。これにより、検索エンジンは正しいバージョンのページを識別し、重複コンテンツの問題を回避することができます。
ルール5:1ページにつき1つのcanonicalタグを使用する
ページに複数のcanonicalタグがある場合、Googleは両方のタグを無視します。
rel=canonicalを複数宣言している場合、Googleはすべてのrel=canonicalのヒントを無視する可能性が高いです。
canonicalタグの実装方法
正規化されたURLを指定する方法には、以下の5つの方法があります。
これらは通常、「正規化シグナル」と呼ばれます。
- HTMLタグ(rel=canonical)
- HTTPヘッダー
- サイトマップ
- 301 リダイレクト※1
- 内部リンク
各方法の長所と短所については、Googleの公式ドキュメントを参照してください。
1.rel=”canonical “HTMLタグを使用したcanonicalタグの設定
rel=canonicalタグを使用することは、正規のURLを指定する最もシンプルでわかりやすい方法です。
重複するページの<head>セクションに、以下のコードを追加するだけです:
<link rel=”canonical” href=”https://example.com/canonical-page/”/>
例:Tシャツを販売するeコマースサイトがあるとします。そのページのコンテンツは他のURL(例:https://yourstore.com/offers/black-tshirts/)でもアクセス可能ですが、正規のURLとしてhttps://yourstore.com/tshirts/black-tshirts/を使用したいとします。
重複しているページには、以下のcanonicalタグを追加するだけです:
<link rel=”canonical” href=”https://yourstore.com/tshirts/black-tshirts/” />
なお、CMSを使用している場合は、ページのコードをいじる必要はありません。もっと簡単な方法があります。
WordPressでcanonicalタグを設定する:
Yoast SEOをインストールすると、自己参照型のcanonicalタグが自動的に追加されます。
カスタムのcanonicalを設定するには、各投稿またはページの「詳細設定」を使用します。
Shopifyでcanonicalタグを設定する:
Shopifyは、デフォルトで商品とブログ記事に自己言及型の正規化URLを追加します。カスタムの正規化URLを設定するには、テンプレート(.liquid)ファイルを直接編集する必要があります。
このスレッドには、その方法についての情報があります。
Squarespaceでcanonicalタグを設定する:
Squarespaceもデフォルトで自己言及型のURLを追加しています。しかし、Shopifyの場合と同様に、カスタムcanonical URLを追加したい場合は、コードを直接編集する必要があります。
2.HTTPヘッダーにcanonicalを設定する
PDFなどの文書では、通常、ページの<head>セクションが存在しないため、ページヘッダー内にcanonicalタグを配置する方法がありません。そのような場合は、HTTPヘッダーを使用してcanonicalを設定する必要があります。一方、一般的なWebページでは、HTTPヘッダーを使用してcanonicalを指定することができます。
例:このブログ記事のPDF版を作成し、ブログのサブフォルダ(ahrefs.jp/blog/*)にホストすると想像してください。
そのファイルに対するHTTPヘッダーは、次のようになります:
HTTP/1.1 200 OK Content-Type: application/pdf Link: <https://ahrefs.com/blog/canonical-tags/>; rel=”canonical”
おすすめ記事:HTTPヘッダーにcanonicalタグを追加する方法
3.サイトマップにcanonicalを設定する
Googleは、非正規ページはサイトマップに含めるべきでないと述べています。サイトマップには正規化されたURLのみを記載する必要があります。これは、Googleがサイトマップに含まれるページをカcanonicalの提案とみなすためです。
ただし、サイトマップに含まれるURLが常にcanonicalとして選択されるわけではありません。
しかし、サイトマップのURLが常にcanonicalとして選択されるわけではありません。
サイトマップのURLをcanonicalとして認識させることは保証されていませんが、大規模なサイトにおいてcanonicalを定義する簡単な方法であり、サイトマップはGoogleにとって重要なページを伝える便利な手段となります。
4.301リダイレクトでcanonicalを設定する
301リダイレクトは、重複したURLから正規のバージョンにトラフィックを誘導したい場合に使用します。
例:あなたのページが以下のURLでアクセス可能であるとします:
- example.com
- example.com/index.php
- example.com/home/
ここで、1つのURLを正規のバージョンとして選び、他のURLをその正規のバージョンにリダイレクトします。
同様に、サイトの安全なHTTPS/HTTPおよびwww/non-wwwのバージョンについても同じことを行う必要があります。正規のバージョンを1つ選び、他のバージョンをその正規のバージョンにリダイレクトします。
例えば、ahrefs.comの正規のバージョンは、HTTPSの非www URL(https://ahrefs.com)です。以下のURLはすべてその正規のバージョンにリダイレクトされます:
- http://ahrefs.com/
- http://www.ahrefs.com/
- https://www.ahrefs.com/
詳しくは301リダイレクトを導入するための完全ガイドをお読みください。
5.内部リンク
サイト全体で、あるページから別のページにどのようにリンクするかは、正規化シグナルとなります。
GoogleのWebマスター、トレンドアナリストであるJohn Muellerは、この#AskGoogleWebmastersのビデオで、canonical URLを決定する際に使用されるシグナルについて説明しています。
これらのシグナルが一貫しているほど、検索エンジンが好ましい正規化URLを判断しやすくなります。ジョンがビデオで言及したように、GoogleはHTTPよりもHTTPSを優先し、より整ったURLを好む傾向もあります。
よくある正規化の失敗を防ぐために
正規化は、やや複雑なトピックです。そのため、正しく正規化する方法について、多くの誤解や勘違いがあります。
ここでは、正規化しようとするときによくある間違いを紹介します:
間違いその1:robots.txtで正規化したURLをブロックする
robots.txtでURLをブロックすると、GoogleはそのURLをクロールできなくなり、そのページ上のcanonicalタグを見ることができなくなります。つまり、Googleはそのページのcanonicalタグを利用できなくなるため、canonicalでないページからcanonicalに「リンク・エクイティ」を移行することができません。
間違いその2:正規化したURLに「noindex」を設定する
「noindex」と「rel=canonical」を同時に使用することは避けるべきです。これらは矛盾した指示となります。
John Mueller がここで述べているように、通常、Googleは「noindex」タグよりも「rel=canonical」を優先しますが、それでも両方を同時に使用することは推奨されません。両方を同時に行いたい場合は、301リダイレクトを使用します。そうでなければ、「rel=canonical」を使用します。
間違いその3:正規化されたURLに4XXのHTTPステータスコードを設定する
Googleはcanonicalタグを見ることができず、canonicalバージョンに「リンクエクイティ」を転送することができません。したがって、正規化されたURLには正しいHTTPステータスコードを設定することが重要です。
間違いその4:すべてのページ付けされたページをルートページに正規化すること
ページ分割されたコンテンツでは、最初のページ以外のページで正規化を行うべきではありません。代わりに、すべての分割されたページには、自己言及型のcanonicalタグを使う必要があります。
なぜなら、これはrel=canonicalの不適切な使用方法だからです。ジョン・ミューラー氏がRedditで述べたとおりです。
この投稿は正規化に関するものなので、避けるべき主なことは、ページ2でページ1を指すrel=canonicalを使用することです。ページ2はページ1と同等ではないため、このようなrel=canonicalの使用は正しくありません。
John Mueller Googleのウェブマスター、トレンド・アナリスト
また、ページネーションの場合、rel=prev/nextタグを使用する必要があります。Googleでは使用されなくなりましたが、Bingではまだ使用されています。
間違いその5:hreflangでcanonicalタグを使用していない
hreflangタグは、ウェブページの言語や地域的なターゲットを指定するために使用されます。
Googleは、hreflangを使用する場合、「同じ言語の正規ページを指定するか、同じ言語の正規ページが存在しない場合は、可能な限り最良の代替言語を指定する」と述べています。
間違いその6:複数のrel=canonicalタグを持つこと
複数のrel=canonicalタグがあると、Googleに無視される可能性が高くなります。この問題は、異なるポイントでシステムに挿入されるCMS、テーマ、プラグインなどによって引き起こされることが多いです。そのため、多くのプラグインでは、自身がcanonicalタグのソースであることを確認するための上書きオプションが提供されています。
もう1つの懸念事項は、JavaScriptで追加されたcanonicalタグの場合です。HTMLレスポンスでcanonical URLを指定せず、JavaScriptでrel=canonicalタグを追加する場合、GoogleはそのURLをページの正規バージョンとして扱うはずです。しかし、HTMLでcanonicalを指定し、JavaScriptで優先バージョンを変更する場合、Googleに混乱を引き起こすことになります。
間違いその7:bodyにrel=canonicalタグを記述する
rel=canonicalは<head>要素内にのみ配置してください。ページの<body>セクションに配置されたcanonicalタグは無視されます。
これが問題になるのは、ドキュメントの解析時です。ページのソースコード上では、rel=canonicalタグが正しい位置に配置されているかもしれませんが、実際にブラウザで構築されたり、検索エンジンでレンダリングされたりする際に、閉じられていないタグやJavaScriptの挿入、<head>セクション内の<iframe>など、さまざまな要因により、<head>セクションが早期に終了してしまい、レンダリング時に問題が発生することがあります。そのような場合、canonicalタグは誤ってページの<body>内に挿入され、無視される可能性があります。
あなたのウェブサイトの正規化の問題を発見し、修正する方法
正規化に関する問題はよく起こりますので、定期的にウェブサイトを監査し、正規化タグに関連する問題を素早く修正する必要があります。
そのためには、Ahrefsのサイト監査ツールを使用することがおすすめです。
サイト監査は、あなたのウェブサイトをクロールして、canonicalタグを含む100以上のSEOの問題を特定します。
以下に、サイト監査が特定する可能性のある12の問題とその修正方法について説明します:
1.4XXのcanonicalポイントについて
この警告は、1つまたは複数のページが4XXのURLに正規化されている場合に発生します。
課題である理由
検索エンジンは4XXのページをインデックスしません。そのため、検索エンジンは4XXのページを指す正規タグを無視し、誤った(正規ではない)バージョンのページをインデックスする可能性があります。
修正方法
影響を受けるページを確認し、4XXのcanonicalリンクを有効な(200)ページへのリンクに置き換えてください。これにより、インデックスさせたい正しいページが適切に表示されるようになります
2.5XXのcanonicalポイントについて
この警告は、1つまたは複数のページが5XXのURLに正規化されている場合に発生します。
課題である理由
5XXのHTTPステータスコードは、サーバーに問題があることを示しており、その結果、アクセスできないcanonicalページが生成されます。Googleはアクセスできないページをインデックスする可能性が低いため、canonicalを無視する可能性があります。
修正方法
誤ったcanonical URLを有効なURLで置き換えてください。指定されたcanonicalが正しいように思える場合は、サーバーの設定ミスをチェックしてください。ただし、サイトのメンテナンス中にクロールが行われた場合や、サイトのサーバーに負荷がかかった場合は、一時的な問題である可能性もあります。
3.リダイレクトするcanonicalポイント
この警告は、1つまたは複数のページが5XXのURLに正規化されている場合に発生します。
課題である理由
canonicalは常にページの最も信頼性のあるバージョンを指すべきです。これはリダイレクトURLとは異なります。そのため、検索エンジンはcanonicalを誤解したり無視したりすることがあります。
修正方法
正規リンクは、直接リンクされたページの最も信頼性のあるバージョン(HTTPステータスコード200を返し、リダイレクトしないもの)に置き換えてください。
4.canonicalのない重複したページ
この警告は、1つ以上の重複または類似したページが存在し、そのページにcanonicalバージョンが指定されていない場合に発生します。
課題である理由
canonicalが指定されていないため、Googleは検索結果に表示する最適なバージョンを自動的に決定しようとします。しかし、それがインデックスさせたいバージョンとは異なる場合があります。
修正方法
それをすべての重複ページに共通するcanonicalバージョンとして指定してください(このとき、自己言及型のcanonicalタグを追加)。それをすべての重複ページに共通のcanonicalバージョンとして指定します(自己参照のcanonicalタグを追加します)。
5.hreflangを非正規にする
この警告は、1つまたは複数のページがhreflangアノテーションで非正規のURLを指定した場合に発生します。
課題である理由
hreflangタグのリンクは常に正規のページを指す必要があります。hreflangアノテーションから正規でないページへのリンクがあると、検索エンジンが混乱し、誤解を招く可能性があります。
修正方法
影響を受けるページのhreflangアノテーションにあるリンクを、そのページの正規版のURLに置き換えてください。
6.内部リンクがなくて辿り着けないcanonical URL
この警告は、1つまたは複数の指定された正規URLの内部リンクがない場合に発生します。
課題である理由
内部リンクがないcanonical URLは、ウェブサイトの訪問者がアクセスできない状態です。サイト内のどこかで、正規版でないページに誘導されている可能性があり
修正方法
正規化されたページへの内部リンクは、正規化されたページへの直接リンクに置き換えてください。これにより、訪問者が正規バージョンのページにアクセスできるようになります。
7.サイトマップに非正規のページがある
課題である理由
Googleは、サイトマップに非正規のURLを含めるべきではないと述べています。これは、サイトマップに含まれるページは正規化の提案をされたものとみなされるためです。サイトマップには、インデックスさせたい正規のページのみを含める必要があります。
修正方法
サイトマップから非正規のURLを削除してください。正規のURLのみをサイトマップに含めることで、検索エンジンに適切なページをインデックスさせることができます。
8.非正規ページを正規ページとして指定する
この警告は、1つまたは複数のページがcanonical URLを指定し、それが別のページにもcanonical化されている場合に発生します。このような「正規化の連鎖」が発生すると、検索エンジンが混乱し、誤解を招く可能性があります。
課題である理由
このような現象は「canonical チェーン」とも呼ばれ、検索エンジンを混乱させたり、誤解させたりする可能性があります。その結果、指定したcanonicalを誤認したり、無視したりする可能性が発生してしまいます。
修正方法
影響を受けるページのcanonicalタグ内の非canonicalリンクを、正規のURLへの直接リンクに置き換えてください。たとえば、ページAがページBに正規化され、そのページがさらにページCに正規化されている場合、ページAのcanonicalリンクをページCへのリンクに置き換えます。これにより、正しい正規化が行われ、検索エンジンが適切にページを認識できるようになります。
9. Open Graph URLが正規化URLと一致しない
この警告は、1つ以上のページで指定された正規のURLとOpen GraphのURLが一致していない場合に発生します。
課題である理由
Open Graph URLが正規化されたものと一致しない場合、canonicalではないバージョンのページがSNSで共有される可能性が出てきてしまいます。
修正方法
影響を受けるページのOpen Graph URLをcanonicalタグで正規化したURLに変更してください。両方のURLが同じであるか、確認しましょう。
参考までに。Open Graphタグ内のURLは、canonicalの場合と同様に、絶対的なURLである必要があり、http://またはhttps://プロトコルを使用する必要があります。
10.HTTPSからHTTPへのcanonical
この警告は、1つまたは複数の安全な(HTTPS)ページが、安全でない(HTTP)バージョンをcanonicalとして指定した場合に発生します。
課題である理由
HTTPSはランキング要因となっているため、できるだけ安全なバージョンのページをcanonicalとして指定することが望ましいからです。
修正方法
HTTPページをHTTPSにリダイレクトすることです。もしリダイレクトができない場合は、HTTP版ページからHTTPS版ページへのrel=”canonical”リンクを追加します。
参考までに。GoogleはHSTS(HTTP Strict Transport Security)の導入も解決策の候補として挙げています。
11.ウェブサイトをHTTPからHTTPSに移行させたときのcanonical設定
この警告は、1つ以上のセキュアではないページ(http)が、セキュアなバージョン(https)をcanonicalとして指定したときに発生します。
課題である理由
HTTPSのほうがHTTPよりも優先されます。HTTP版のページがあるにも関わらず、HTTPS版をcanonicalと指定するのは論理的ではありません。
補足:この問題が大きな影響を与えることは少ないかもしれませんが、できるだけ修正する価値があります。
修正方法
HTTPのページからHTTPS版への301リダイレクトを実行しましょう。さらに、そのHTTP版ページへ到達する内部リンクを、HTTPS版への直接リンクに置き換えることも必要です。
※フルスピード注:Google 検索セントラル「正規 URL では HTTP より HTTPS を優先して使用する」の項目も参照することをおすすめします。
12.非正規ページがオーガニックな検索流入を得ている
この警告は、1つまたは複数の非正規ページが検索結果に表示され、オーガニック検索トラフィックを獲得した場合に発動されます(これは起こるべきではありません)。
課題である理由
canonicalタグの設定が間違っているか、Googleが指定されたcanonicalを無視することを選択したかのどちらかです。
修正方法
報告されたすべてのページで、rel=canonicalタグが正しく設定されていることを確認することです。もし問題がない場合は、Google Search ConsoleのURL検査ツールを使用して、指定されたcanonical URLが正しく認識されているかどうかを確認します。もし不一致がある場合は、なぜそうなるのかを調査します。
まとめ
canonicalタグは実はそれほど複雑ではありません。ただ、最初に理解するのが難しいだけです。
ただし、覚えておくべきポイントは、canonicalタグが「指示」ではなく、検索エンジンへの「信号、シグナル」であることです。
Google Search ConsoleのURL検査ツールを使用すると、ユーザーが指定したcanonicalとGoogleが選択したcanonicalの両方を確認することができます。これを利用して、自分の意図したcanonicalとGoogleの選択が一致しているかどうかを確認しましょう。
以下は、Google Search ConsoleのIndex Coverage Status Reportで使用されるcanonical URLに関連するカテゴリの説明です:
- 適切なcanonicalタグを持つ代替ページ:正しいcanonicalタグが指定された代替ページが表示されます。つまり、選択したページが正しく集約されていることを意図した動作です。
- ユーザーが選択したcanonicalがない重複:重複したページがあり、どのページにもユーザーが選択したcanonicalが指定されていません。この場合、Googleが自動的に1つを選択しますが、もしもそれがユーザーの意図と異なる場合は、rel=canonicalタグを追加する必要があります。
- 重複、Googleがユーザーと異なるcanonicalを選択した場合:Googleが提案したcanonicalを無視し、異なるバージョンのページをインデックスに表示しています。
- 重複、提出したURLが正規化として選択されていない:正規化のシグナル(サイトマップなどで提出された情報)が無視されています。このセットの重複ページには、明示的な正規化されたURLが指定されておらず、Googleは別のURLがインデックスに表示されるべきだと判断しています。
※フルスピード注:Google Search Consoleのページ インデックス登録レポートに関するヘルプも参照することをおすすめします。
この記事についてご質問はあるでしょうか?お気軽に著者のTwitterへご連絡ください。
著者プロフィール
Joshua Hardwick
Ahrefs のコンテンツ責任者(わかりやすく言うと、私たちが公開するすべてのブログ記事が素晴らしいことを保証する責任者です)。