プロンプトトラッキング
ChatGPTおよびAIにおけるブランドの可視性を測定・最適化します。
Claude
Claudeがあなたのブランドと競合をどう言及するかを監視します。
Soon
AIトラッカー
AIがSEOに与える実際の影響を測定します。
Gemini
Geminiが競合と比較してあなたのブランドをどう位置付けるかを発見します。
Soon
ChatGPT
ChatGPTがあなたのブランドと競合をどう言及するかを追跡します。
Soon
Perplexity
Perplexity AIでのブランドの可視性を分析します。
Soon
料金デモ

canonicalタグとは?使い方と仕組みを完全ガイド

canonicalタグとは?使い方と仕組みを完全ガイド
David Kaufmann
SEO Tutorials
16 min read

1つまたは複数のウェブサイトを所有していると、それが製品、サービス、または異なるタイプのセクションに焦点を当てたものであっても、さまざまな理由でプラットフォーム上の多くのページが類似していたり、ほぼ同一であったりするのは一般的です。これは特にEコマースで頻繁に見られますが、ブログのタグやさまざまなタイプのコンテンツに関するコンサルティング業務でも検出しています。

どんなウェブサイトでも重複コンテンツの問題に直面する可能性があることは容易に想像できます。Googleは重複コンテンツのあるサイトにペナルティを与え、これは間違いなく検索結果のランキングに影響します。

では、ウェブサイトが重複コンテンツを持っていても、ウェブマスターがペナルティを心配する必要がないのはなぜでしょうか?

その答えは、canonical属性またはcanonicalリンクとして知られているものにあります。次のセクションで、その定義、目的、利点、適用方法、使用すべきタイミング、そして重複コンテンツによる潜在的なペナルティを回避するためにcanonical属性を使用する際の潜在的な欠点について詳しく説明します。

canonicalリンクとcanonical属性とは?

一般的に言えば、canonicalリンクとは、タグまたは属性によって、ウェブサイトの「メイン」または「オリジナル」のリンクとして記述されているリンクで、類似したコンテンツを持つページのURLをそのリンクに向けることができます。これにより、Googleのボットや検索アルゴリズムは、そのリンクを優先または優先順位の高いバージョンとして認識します。

このようにして、重複と見なされる可能性のあるコンテンツを正しく、比較的簡単に処理できます。canonicalとして記述されない場合、プラットフォームのランキングに影響を及ぼし、ペナルティにつながる可能性があります。これは、重複コンテンツが意図的に配置されていない場合でも、製品の販売、サービスの提供、関連セクションなどを通じて自然かつ有機的に発生する場合にも起こり得ます。

技術的な観点から、canonical URLは、canonicalタグを組み込んだHTMLコードで書かれたリンクであり、それにcanonical属性を与えます。これにより、上記のようにGoogleのボットがそれをメインアドレスまたはソースアドレスとして認識し、類似したリンクが繰り返しまたは重複として扱われるのを防ぎます。

URLをcanonicalまたはメインとして宣言する方法の例を以下に示します:

<link rel="canonical" href="/ja/">

canonicalリンクの起源とSEO上のメリット

canonicalリンクの使用は、インターネット検索の主要3社であるGoogle、Bing、Yahooが共同でcanonical属性を導入した2009年に始まりました。

論理的に考えて、canonicalリンクはSEOの観点から大きな可能性を持っています。前述のペナルティを回避し、最も重要なURLをGoogleに知らせるのに役立つからです。

そのため、サイトのSEOと関連する戦略の適用に関しては、canonicalリンクの組み込みは常に計画の一部であり、特に同一になり得る相当数のURLを持つ大規模サイトではそうです。

URLをcanonicalにする方法

ウェブサイトを持っているか、サイトを最適化している過程で、多数の類似したURLがあることに気づいたら、canonicalization(正規化)プロセスを開始する必要があります。これは、どのURLが最良かを選び、それにcanonical属性を与えることから成ります。

時には最良のURLを選ぶことは簡単です。最も最適化されたコンテンツと技術的構造を持っているからです。しかし、他の場合では、選択がより複雑になることがあります。特にページが非常に似ていて区別が難しい場合です。

いずれにせよ、簡単な推奨事項を一つ:類似したセクションやページがある場合、canonical URLを選ぶ方が常に良いです。そうしないと、ランキングに悪影響を及ぼし、トラフィックに永続的な影響を与えるペナルティが発生する可能性があります。

URLをcanonicalにするには、最初のステップは類似している可能性のあるURLを比較することです。これは、ユーザーがさまざまな方法で製品やサービスのリストにたどり着くEコマースサイトでよく見られます。次のようなURLが生じることがあります:

両方のURLがサイトに価値があるか、同じ製品やページに通じるため、行うべきことは、どちらがより関連性が高いかを次のように選ぶことです:

  • 訪問数、トラフィック、権威に基づいて、最も関連性の高いURLを選びます。

  • リンクが選ばれたら、非canonicalページからcanonicalページを指すcanonical属性を追加します。次のようになります:

<link rel="canonical" href="https://example.com/wordpress/seo-plugin/">

これによって達成されるのは、Googleにどのページが正規化されたURL(オリジナルのコピーとして扱う)で、どれがcanonical URL、つまりオリジナルかを伝えることです。このリンクは「コピー」URLに置かれ、オリジナルのURLを指します。

言い換えれば、次のスキームに従います:

Rel Canonical
Rel Canonical

canonical URLの使用が推奨されるケース

製品、サービス、その他の情報や投稿など、多くのページやセクションを持つウェブサイトがある場合、これらのページやURLの一部が非常に類似している可能性が高く、canonical URLの使用が強く推奨されます。

ただし、そのような場合、canonicalタグの代わりに本物の301リダイレクトを使用することもできます。これは、リダイレクトが恒久的になる場合やサイト移行の際に特に役立ちます。とはいえ、技術的な問題やペナルティの場合は、canonicalタグを設定することが次に最も推奨されるオプションです。

他のプラットフォームで変更なしに再公開されるコンテンツのように、異なるサイト間のURLにcanonicalタグを使用することさえ可能で、適切な許可を得て、ペナルティを回避するため常にオリジナルを指すようにします。

rel=canonicalに関する重要な注意事項

これを最後に取っておいたからといって、重要性が下がるわけではありません。canonical属性はGoogleへの提案であり、指示ではないことを明確にする必要があります。これは、サイトの他の部分で送る信号がそれを定義した方法と矛盾している場合、Googleがそれを無視する可能性があることを意味します。

言い換えれば、URL AからURL Bへのcanonicalを設定したのに、内部的にすべてのリンクがAを指し、外部リンクもAを指している場合、Googleはそのcanonicalを無視し、Aを正規のものとして扱う可能性があります。Bはその場合Aのコピーとなり、ペナルティの対象になる可能性があります。

GoogleがどのURLをオリジナルとして扱い、どれをcanonicalとして扱うかを知るには、Search Consoleに入り、URLをinspectorに追加し、Google Search Consoleから提供される情報を確認する必要があります。

そこで次のデータが得られます:

canonical URLを確認
canonical URLを確認

canonical URLでよくある間違い

canonical URLに関連するさまざまな問題と頻繁に起こる間違いがあり、特にこのツールが誤って使用される際に共通して現れます。例えば:

  • ページネーションされたアーカイブをページ1にcanonicalにすべきではありません。同様に、ページのcanonicalタグはそのページ自体を指すべきです。例:ページ2からページ2へ。そうしないと、検索エンジンはより深いページのアーカイブをインデックスするのに苦労する可能性があります。

  • canonical URLを排他的かつ一意にする必要があります。これがHTTPからHTTPSへのプロトコル切り替えを意味するとしてもです。

  • canonicalタグは、必要なURLに基づいて、変数を使用せず直接的な方法で設定する必要があります。

  • ページに複数の関連するcanonical URLがある場合、逆効果で予測不可能になる可能性があります。Googleが私たちのウェブサイトを迅速かつ明確に理解する必要があることを忘れずに、簡単にしましょう。

  • もう一つの重要な間違いは、canonical属性を/headやヘッダーではなくbody内で使用することから来る可能性があります。Googleは公式コミュニケーションで、すべてのコンテンツを解析する際の問題を回避するため、属性をできるだけ早くheadで使用することを推奨しています。検出されない可能性があるためです。

  • noindexとrel=canonicalを一緒に使用すること。John Muellerは多くのhangoutの一つでこれを具体的に取り上げ、両方の信号が矛盾しておりGoogleを混乱させ、Googleはnoindexよりcanonical属性を優先すると説明しました。したがって、これらを決して一緒に使用すべきではありません。

  • canonical属性を404ページや30xページに向けること。少し考えてみましょう:URL Aに属性を追加してBを指すようにし、Bがエラーを返したりリダイレクトしたりする場合、Googleに間違った信号を送っているのではないでしょうか?「オリジナル」のURLがエラーページかリダイレクトだと伝えていることになります…意味がありません。

canonical属性の高度な使用

canonical属性には、次のような他の機能や高度な使用法があります:

  • HTTPヘッダーcanonicalリンク:このタイプのヘッダーは、PDFドキュメントを正規化する場合に非常に役立ちます。HTMLではないので、正規化したい場合はこのオプションを選ぶ必要があります。次のようになります:

Link: <http://www.example.com/downloads/seoguide.pdf>; rel="canonical"

  • それほど類似していないページでcanonicalを使用する:実際には、本当に同一ではない、かなり異なるページでもcanonicalタグを使用することは可能です。これはサイト全体の権威を助ける可能性がありますが、推奨されません。Googleはcanonicalの誤用を検出し、サイトにペナルティを与え、その後実際のcanonical URLを無視する可能性があるためです。

  • canonical属性をHreflangと一緒に使用するHreflangを含む戦略をcanonicalタグと同時に使用することができ、適切に適用すれば良い結果を得られます。ただし、Hreflangを使用する場合、canonicalの言語実装は完璧でなければならず、両方の戦略により多くの害を及ぼす予測不可能な問題や競合を回避するため、常に自分自身を指すようにする必要があることを明確にしなければなりません。

この魅力的なSEOタグについてまだ質問がありますか?喜んでお手伝いします!

著者: David Kaufmann

David Kaufmann

私はこの10年以上、SEOに完全に夢中になって過ごしてきました。正直なところ、他の生き方は考えられません。

私のキャリアが新たな次元に到達したのは、Chess.com でシニアSEOスペシャリストとして働いたときでした。Chess.com はインターネット全体で最も訪問数の多い上位100サイトの1つです。数百万ページ、数十言語、そして最も競争の激しい SERPs の1つという規模で仕事をした経験は、どんなコースや資格でも得られないことを教えてくれました。あの経験は、本当に優れたSEOとは何かという私の視点を一変させ、それ以降に私が築いてきたすべての土台となりました。

その経験から、私は SEO Alive を創業しました。オーガニック成長に本気で取り組むブランドのためのエージェンシーです。私たちは dashboards や月次レポートを売るためにここにいるのではありません。本当に成果を動かす戦略を構築するためにここにいます。クラシカルなSEOの最良の部分と、Generative Engine Optimization (GEO) というエキサイティングな新しい世界を組み合わせ、あなたのブランドが Google の青いリンクだけでなく、ChatGPT、Perplexity、Google AI Overviews が毎日何百万人もの人々に届けている AI 生成の回答の中にも確実に表示されるようにします。

そして、この両方の世界をきちんと扱えるツールが見つからなかったので、自分で作りました。それが SEOcrawl です。rankings、テクニカル監査、backlinks モニタリング、crawl ヘルス、そして AI ブランド可視性トラッキングを1つの場所に統合した、エンタープライズ向けのSEOインテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。

→ David のすべての記事を読む
著者の他の記事: David Kaufmann

この著者の他のコンテンツをご覧ください