canonicalタグとは？設定例・リダイレクトとの違いと確認手順

canonicalタグは、重複・類似するページの中で、検索エンジンに代表として扱ってほしいURLを伝える指定です。Googleにとって強いシグナルですが、必ずそのURLが選ばれるという指令ではありません。通常は、公開する各ページに適切な正規URLを一つ決め、内部リンク、サイトマップ、リダイレクト等と矛盾させずに運用します。

「パラメータ付きは全部同じURLへ」「2ページ目は1ページ目へ」「英語は日本語へ」と一律に指定すると、別の内容をまとめることになり得ます。このページでは、内容の違いを基準にする判断と、実装後の確認を説明します。URLの構成はURLパラメータの意味と使い方、全体の考え方はSEO対策の基本へつなぎます。

canonical・リダイレクト・noindexの役割

Googleの重複URLの正規化ガイドでは、リダイレクトとrel=canonicalは強いシグナル、サイトマップへの掲載はより弱いシグナルとして説明されています。各手段を整合的に併用することはできますが、異なる代表URLを示すと判断が分かりにくくなります。

移転が目的なら301・302リダイレクトの使い分けを検討します。noindexを付けた重複ページからcanonicalを出し、別ページの正規化を期待するような混在は避けます。機密情報は認証とアクセス制御で守り、検索用の指定だけを保護手段にしません。

どのURLを代表にするか：内容で判断する

Googleのページ分割の公式説明は、2ページ目以降を1ページ目へcanonical指定せず、各ページに固有のURLを使うよう案内しています。商品や記事の一覧で、ページごとの中身が異なるのに、すべてを1ページ目の重複として扱わないようにします。

翻訳ページも、同じ主題であるだけで同じ言語の重複ページとは扱いません。日本語と英語をそれぞれ正規ページとして公開し、言語の対応はhreflangで案内します。canonicalとhreflangの参照先や公開状態が矛盾していないかを確認します。

架空の例：キャンペーンURLと一覧ページ

架空のサイトで、メールとSNSから同じ記事へUTM付きで送客している場合、記事本文は変わりません。記事本来のURLを正規候補にそろえ、各キャンペーンの計測は別の仕組みとして確認します。一方、記事一覧の2ページ目には別の記事群が載るため、1ページ目へまとめる判断とは分けます。

絞り込みページはさらに個別判断が必要です。「価格の安い順」の並べ替えだけか、「特定用途の商品を固有の説明付きで紹介するページ」かで、検索に出す価値やURLの管理方針が異なります。パラメータが付いているという理由だけでは決められません。

実装時は一つの整合した指定を確認する

HTMLではhead内のlink要素で、relの値をcanonicalにし、hrefに正規URLを指定します。例えば、正規URLを指定する記述は <link rel="canonical" href="https://example.com/ja/article"> です。example.comは例示用ドメインで、実装では実際の正規URLに置き換えます。確認項目として「指定元URL」「指定先URL」「どこが生成するか」を台帳に残します。CMS、SEO拡張機能、テンプレートがそれぞれ出力していないかを調べてください。

既存の自己参照指定があるページで別の代表URLに変える場合、canonicalをもう一つ追加するのではなく、既存の出力を適切に置き換えます。相対URLも仕様上使えますが、環境差や基準URLの影響を避けるため、絶対URLを使う運用が分かりやすくなります。

HTTPレスポンスヘッダーでもcanonicalを指定でき、PDF等のHTML以外のファイルにも使えます。ただし、HTMLとヘッダーの両方に設定すると管理が複雑になり、矛盾が起きやすいため、運用上は一つの方法に統一するのが容易です。HTML以外へ設定したことから、すべての検索機能で希望どおり扱われると保証しません。

正規URLの最低限の点検

• 指定先が公開を意図したURLで、必要な本文を正常に提供している。
• 指定元と指定先の主な内容が、正規化の判断に適した同一・類似内容である。
• 削除済み・ログイン必須・noindex・別のURLへの転送先を誤って指定していない。
• ページ内の複数指定、HTTPヘッダー、CMSの出力が食い違っていない。
• 内部リンクとXMLサイトマップが、同じ正規URLを指している。
• 日本語・英語、ページ分割、絞り込みを一括ルールで誤集約していない。

自己参照と循環参照を混同しない

ページAがA自身を正規URLとして示す自己参照canonicalは、通常の設定です。これを「ループだから削除すべき」と判断しません。問題になるのは、AがBを指し、BがAを指すような矛盾した循環や、代表として指定したBがさらに別URLを指定する複雑な連鎖です。

例えばステージング環境のドメインが本番へ混ざると、公開ページの代表先が意図しない場所になります。公開前に環境ごとのドメイン、HTTPS、ホスト名、末尾スラッシュ等の方針を確認し、公開後にも実際の生成結果を見ます。テンプレートの設定値だけでは、最終的なページ出力の証拠になりません。

Googleが選んだ正規URLを確認する

Search ConsoleのURL検査では、ユーザーが指定した正規URLと、Googleが選択した正規URLを分けて読みます。値が異なる場合は、内容の重複、内部リンク、転送、サイトマップ、取得可能性、最終クロール日時を確認します。検査結果はGoogleが把握した状態であり、修正直後の結果や将来の選択を必ず示すものではありません。

Googleの正規化のトラブルシューティングでは、誤った指定やハッキング等も確認対象です。また、転載記事の扱いはcanonicalだけに頼る一律の解決策にはできません。必要に応じて転載先で検索登録を制御する等、当事者間で公開方針を確認します。

XMLの現在の掲載と、URL検査に出るサイトマップ参照は別の証拠です。サイトマップの確認手順と合わせ、現在のファイル、Googleの最終取得、個別登録状態を区別します。検索実績の行がないことだけで、canonicalが誤っているとは断定しません。

指定が一致しないときの調査の順番

最初に、確認しているURLが本番の公開URLかを確かめます。次に、HTMLのheadとHTTPヘッダーを調べ、指定数と指定先を記録します。本文がほぼ同じページが別のホスト名やURLでも公開されていないか、内部リンクがそちらへ集中していないかを見ます。その後でGoogleの最終クロールと選択URLを比較します。原因が分からないままcanonicalを毎日変更すると、どの設定を検証しているか追いにくくなります。

架空の例として、CMSでは新URLを指定したのに、配信されたHTMLでは旧URLを指しているなら、まず出力やキャッシュ等の配信経路を調べます。HTMLは新URLでそろっており、URL検査の最終クロールだけが修正前なら、現在の実装とGoogleの既存情報を分けて記録します。Googleが別URLを選んだ理由を推測だけで断定しないことが大切です。

修正後の検証記録を残す

対象URL、期待する正規URL、実際のHTML・ヘッダーの指定、Google選択の正規URL、確認日、最終クロール、修正担当を記録します。指定を変更したら、内部リンクとサイトマップも確認し、別の指定で上書きされていないかを再点検します。

正規化の修正は、ページの公開方針を整理する作業です。順位の上昇や評価の完全な引き継ぎを約束するものではありません。公開をやめたURLの扱いも含む場合は、404・削除・復元の判断と分け、変更する理由を一つずつ明確にします。