canonicalタグ完全ガイド：重複コンテンツを防ぐ正しい設定と実務チェックリスト

canonicalタグとは何か — 概要と目的

canonicalタグ（rel="canonical"）は、複数のURLが同じ、または非常に類似したコンテンツを持つ場合に、検索エンジンに「どのURLを正規（代表）として扱うべきか」を示すためのHTML要素です。主に重複コンテンツ問題の解消と検索エンジン最適化（SEO）のために使われます。正しく設定することで、クロール予算の最適化や検索結果での重複表示の回避、リンク評価（被リンクや内部リンクの評価）の集約が期待できます。

基本的な書き方と設置場所

基本的なHTML記述は次のとおりです。head要素内に置きます。

<link rel="canonical" href="https://example.com/your-preferred-url/" />

ポイント：

• hrefには原則として絶対URLを指定する（スキーム、ホスト、パスを含む完全なURL）。
• 通常、各ページは自己参照（self-referential）canonicalを設定するのが安全。つまり、そのページ自身の正規URLを指す。
• head内に1つだけ設定する。複数のcanonicalタグがあると混乱を招く。

canonicalを使うべき典型的なケース

• パラメータ付きURL（例：sessionID、トラッキングパラメータ、並び替え・フィルタリングパラメータ）で同一コンテンツが複数生成される場合。
• プリント用ページやAMPなど、コンテンツがほぼ同じだが表示形式が異なる場合。
• 複数のURLで同じ製品や記事がアクセス可能な状況（wwwあり/なし、HTTP/HTTPS、末尾スラッシュの有無の違い）を一本化したい場合。

GoogleとBingの扱い（重要）

主要な検索エンジンはcanonicalを「ヒント（hint）」として扱います。つまり、必ずしも指定どおりに扱うとは限らず、検索エンジン側が他のシグナル（リダイレクト、被リンク、サイトマップ、内部リンク構造、HTTPステータスなど）と総合して最終的な正規URLを決定します。

そのため、canonicalは万能ではなく、他の正規化対策（301リダイレクト、内部リンクの統一、サイトマップの整備）と併用するのがベストプラクティスです。

実務上のベストプラクティス

• 自己参照canonicalを各ページに入れる：誤検出を避け検索エンジンに範囲を明示できる。
• URLの正規形を統一する：HTTPSを推奨、wwwあり/なしはどちらか一方に統一する。
• 絶対URLを使う：相対パスは避け、混乱を減らす。
• canonical先は200 OKでアクセス可能にする：404や500、noindexのページを指すと無効化されることがある。
• 大きく異なるコンテンツを無理に統合しない：意味が違うページを1つにまとめるのはミス。canonicalは「ほぼ同一」のページ向け。
• クロスドメインcanonicalは可能だが注意：Googleはクロスドメインcanonicalをサポートするが、外部サイトへ誤って権威を渡すことがないよう管理が必要。

よくある間違い（そしてその対処法）

• canonicalをホームや別ページに無差別に貼る：各ページが固有の価値を持つなら自己参照が原則。
• canonical先をinaccessibleにする：canonicalで指定したURLがクロール拒否（robots.txt 等）または404だと、無視される可能性が高い。
• 異なる言語ページへ誤ってcanonicalを設定：言語ページはhreflangと組み合わせて正しく管理する。hreflangで言語/地域ごとの最適なURLを示す一方、各言語ページは自己参照canonicalにするのが普通。
• パラメータページをすべてトップページへcanonical：トピックが異なるのにトップへまとめると、検索エンジンに迷惑がかかり評価が落ちる場合がある。

canonicalと他の指示（noindex、301リダイレクト、hreflangなど）との関係

• canonical と noindex：canonical先にnoindexを付けるのは推奨されない。検索エンジンはnoindexを尊重してインデックスしないため、canonical先がインデックスされなくなる。混乱を招く。
• 301リダイレクトとcanonical：301はより強いシグナルで、リダイレクトした場合は基本的にリダイレクト先が正規とみなされる。可能ならリダイレクトで統一するほうが確実。
• hreflangとの併用：多言語サイトでは、hreflangで地域／言語ごとのURLを指定しつつ、各言語ページは自己参照canonicalにする。hreflangとcanonicalが矛盾するとGoogleがどちらを優先するかで問題が起きるため注意が必要。

ページネーションとcanonical（以前のrel="prev/next"の扱いも含む）

かつてはrel="prev"/"next"でページネーションの系列を示すことが推奨されていましたが、Googleは2019年にこれをインデックスのためのシグナルとして使わないと表明しました。現在は以下の方針が一般的です：

• シリーズの各ページは通常それぞれ自己参照canonicalにするか、場合によってはシリーズの代表ページ（例：1ページ目）をcanonicalにする選択もあるが、後者は各ページが独自の価値（個別のコンテンツ）を持つ場合は避ける。
• 長いシリーズで重複が多い場合はまとめページを作り、個別ページはcanonicalでまとめページに集約することが有効なこともある。

診断とトラブルシューティングの方法

• Google Search ConsoleのURL検査ツールで、GoogleがどのURLを正規と判断しているか確認する。
• 実際のHTMLをブラウザで「ページのソースを表示」してcanonicalタグの有無とhrefの内容を確認する。
• サーバーログやクロールツール（例：Screaming Frog、Sitebulb）でクロール時のcanonical処理・ステータスをチェックする。
• curlやwgetでHTTPステータスやヘッダーを確認：canonical先が301/302を返していないか、404ではないかを確認する。
• 被リンクや内部リンクの向きも確認：外部・内部のほうが示すURLとcanonicalが矛盾すると検索エンジンは混乱する。

セキュリティや悪用に関する注意点

悪意あるサイトが自サイトのURLをcanonicalに指定して外部ドメインに権威を移そうとするケースが知られていますが、検索エンジン側はこのような「外部からの一方的な要求」をそのまま受け入れるわけではなく、多数のシグナルで判断します。とはいえ、自サイトのcanonical指定は自分でコントロールすべきで、外部サイトに不適切にリンクされないように監視することが望ましいです。

実用的チェックリスト（導入前・導入後）

• 導入前：URL正規化方針（HTTPS/WWW/スラッシュ）を社内で決める。
• 導入前：どのパラメータを保持し、どれを無視するか設計する。
• 導入後：主要なページで自己参照canonicalが入っているか確認。
• 導入後：Google Search ConsoleでCanonicalの扱いが意図どおりかモニタリングする。
• 定期的：サイトの重複ページ、パラメータ生成ページをクローリングツールで検出し、canonical方針を見直す。

具体例（ケーススタディ風）

例1：ECサイトの製品ページで、並び替えや色指定のためにパラメータが付く場合。製品詳細自体に大差がないなら、canonicalでベースURL（例：https://example.com/product/12345）に集約する。パラメータ付きで個別のユニークなコンテンツがあるなら自己参照。

例2：ニュースサイトでモバイル版とデスクトップ版が別URLで提供される場合。AMPやモバイル向けの別URLがあるときは、AMPの正規化は通常AMP側にcanonicalで元ページを指す、または元ページが自己参照しつつ適切にAMPリンクを示す（rel="amphtml"）など、公式ドキュメントに従う。

まとめ

canonicalタグは重複コンテンツ問題の解消やリンク評価の集約に有効な重要ツールです。しかし「必ず従われる命令」ではなく検索エンジンへのヒントである点、その他の正規化手段（301リダイレクト、内部リンク、サイトマップ等）と併用すべき点を理解して運用することが重要です。自己参照canonicalの導入、絶対URLの使用、canonical先の可用性確認など基本的なルールを守ることで、期待した効果を得やすくなります。

参考文献

• Google Search Central: Consolidate duplicate URLs
• Google Search Central: Special tags (rel="canonical" など)
• Google Search Central Blog: Pagination and rel="prev/next"（2019）
• Bing Webmaster: What is the canonical tag?
• Google サポート：サイトの正規化に関するヒント（日本語ページ）