カノニカルタグ

統合されるものと、あくまで提案にすぎないもの

重複URLは意図して作られることがほとんどありません。同じ商品が二つのカテゴリに並ぶ、計測パラメータひとつでページが百通りに増える、印刷用とモバイル用が併存する、あるいは同じ内容がwwwありとなし、httpとhttpsの両方で開ける。こうしたバリエーションはそれぞれ別々にリンクや表示回数を積み上げてしまい、結果としてひとつのクエリで自分のページ同士が競合します。これはキーワードカニバリゼーションで説明した自傷的な分散と同じ現象です。カノニカルタグは残したい版を指名し、ほかの版のシグナルをそこへ集約するよう求めます。

創業者が最も誤解しやすいのは、この「求め」の強さです。Googleは宣言されたカノニカルを複数の入力のひとつとして扱い、全体像から自分で優先URLを決めます。

• 宣言したカノニカル — ページのhead内にあるlink要素そのもの。
• リダイレクト — 301は注釈ではなく重複そのものを消すため、タグよりはるかに強い意思表示になる。
• 内部リンク — サイト内のリンクが宣言していない側のURLばかりを指していれば、その宣言は自社のナビゲーションと言い争っている状態になる。内部リンクがこの判断と切り離せないのはそのため。
• サイトマップ — 掲載したURLは、インデックスしてほしいと申告したURLでもある。
• [hreflang](/glossary/hreflang)クラスタ — 相互参照する言語バリエーションはひとまとまりで読まれ、クラスタと矛盾するカノニカルはたいてい退けられる。

これらのシグナルが一致していれば、タグはほぼ確実に尊重されます。食い違っている場合、Googleは自分で結論を出し、選んだURLをSearch Consoleで報告します。技術的には正しく存在しているカノニカルがまったく効かないことがあるのは、この仕組みのためです。

まず疑うべき典型的な失敗

壊れたカノニカルの大半は、いくつかの型に収まります。別の場所へリダイレクトするURLを指したカノニカルは、もうそのページを配信していないアドレスへの統合を求めていることになります。noindexのページを指したカノニカルは、除外してほしいと申告済みの対象にシグナルを集めろと言っていることになります。テンプレートが全ページにトップページのカノニカルを焼き込んでいる場合 — これは実際によくあるバグです — サイト全体がひとつの文書だとGoogleに伝えてしまいます。そしてソース上は正しいのに、スクリプトやレンダリング層に押し出されてheadへ届かないカノニカルは、最も気づきにくい壊れ方をします。確認に使いたくなるツールが、どれも変わらずタグを表示してしまうからです。

Search Consoleには、見た目が似ていて意味が正反対のふたつの状態があります。「代替ページ（適切な canonical タグあり）」は、Googleが宣言を読み、同意して統合したという意味で、重複にとっては健全な着地点であり、追いかけるべきエラーではありません。「重複しています。ユーザーにより、正規ページとして選択されていません」は、ほぼ同一のページを見つけたものの使えるカノニカルがなく、Googleが代わりに選んだという意味です。対処すべきは後者で、最初に確かめるのはタグの指し先ではなく、そもそもGooglebotがそのタグを受け取れているかどうかです。

Googleが当社のカノニカルを見なくなったときに学んだこと

ここからはドキュメントではなく、agentceres.comを運用して得た話です。2026年8月、Search Consoleは当社サイトの88件のURLを「ユーザーにより正規ページとして選択されていない重複」として報告しました。カノニカルタグはその間ずっとソース上に正しく存在していました。原因は二層下にありました。マーケティングと法務のルートが十数本、静的プリレンダリングから静かに外れていたこと。そして当社のフレームワークは動的レンダリングのページではメタデータをストリーミングで送るため、タイトル、robotsディレクティブ、カノニカル、hreflangが、文書の先頭から約1.5KBの地点ですでに閉じたheadより後、body内に出力されていたことです。head外のカノニカルリンクはカノニカルリンクではないので、Googleは受け取ったとおりに記録しました。何も宣言のないほぼ同一のページ群として扱い、代わりに選んだのです。

最も時間を奪われた一点こそ、共有する価値があります。Search Consoleの「公開URLをテスト」はクローラーとは別のユーザーエージェントで取得しており、そのエージェントは当社フレームワークが完全な非ストリーミングのメタデータを返すボットの既定リストに入っていました。一方でGooglebotは意図的に入っていません。そのためライブテストは実行するたびにhead内の正しいカノニカルを表示し続け、実際にインデックスを構築するクロールは何も見ていませんでした。重複として報告されたら、どんなライブテストよりもインデックス済みの結果と生のHTMLを信じてください。ソースを表示し、headがどこで閉じているかを探すことです。同じ事故のより単純な半分も、自社サイトで確認する価値があります。当社のwwwホストは全ページを200で返しリダイレクトしていなかったため、Googleはwwwをapexドメインより上位の正規ホストとしてインデックスしていました。これは301ひとつで解決しました。この規模の修正は、Search Consoleが検証を確定するまでふつう二週間ほどかかります。カノニカルのレポートではなく流入の減少から逆算しているなら、サイトに流入がない理由がこれより手前の確認を扱っています。