そのURLが本当に重複かどうか判断する
カノニカルURLは重複またはほぼ重複するページ群の代表アドレスです。link relationとしてのカノニカルは、対象が参照元ページと同一のコンテンツ、または参照元を包含するコンテンツのときに適切です。異なる製品、有用なフィルタ、記事、ロケールを隠す手段ではありません。
訪問者が候補の代表URLに置き換えられた場合に重要なコンテンツ、選択肢、タスク完了が失われるかを問ってください。もし失われるなら別のままにしてコンテンツやローカリゼーションを改善します。失われないなら、安定した1つのURLを選び、そのプロトコル、ホスト、パス、末尾スラッシュ、パラメータのルールを文書化してください。
重複が明らかでない場合でも、優先するインデックス可能なHTMLページごとに自己参照するカノニカルを追加してください。
分析用パラメータ経由など必要な重複は、両方のページが主要なコンテンツを同じく返す場合にのみ優先URLへ向けてください。
古いURLを消すべきならリダイレクトを使う
古いパス、廃止したホスト、HTTP版などが訪問者やクローラの到達先であってはならない場合は、サーバーサイドで恒久的にリダイレクトしてください。Googleは重複の廃止時にリダイレクトを強い正規化シグナルとして扱い、推奨しています。
両方のURLがコンテンツを返す必要があるが検索では一方を代表として扱いたい場合にrel=canonicalを使います。タグは訪問者のアドレスを変えず、他のルートを消すものではありません。ターゲットは成功レスポンスを返すべきで、別へリダイレクトしたり他所をカノニカルにしてはいけません。
レガシーなHTTP URLを直接最終のHTTPS URLへ送信し、そのHTTPS URLを他の場所でも使ってください。
robots.txt、URL削除、noindexは優先する重複を表明する手段ではありません。noindexはページを検索から除外するためのものです。
明確な注釈を1つだけ公開する
HTMLでは、headに1つの絶対URLを使ったrel=canonical注釈を置いてください。CMSの設定だけでなく配信されるソースを確認してください：テーマ、プラグイン、エッジルール、JavaScriptが値を置き換えることがあります。GoogleはHTMLソース内での指定を推奨し、JavaScriptで変更されないことを確認するよう助言しています。
PDFなどの非HTML文書では、適切な場合にHTTPのLinkレスポンスヘッダーでカノニカルを指定してください。HTMLとヘッダーで矛盾する値を出さないようにします。ターゲットはアクセス可能であること、4xxを返さないこと、リダイレクトやチェーンしているURLでないことが必要です。
リソースごとにカノニカルのターゲットは1つにしてください。複数ターゲットは優先が不明瞭になります。
テンプレート、CDN、CMS、ルーティング変更後にサンプルページとヘッダーを取得して最終ターゲットを確認してください。
補助的なシグナルを一致させる
ナビゲーション、パンくず、本文リンク、生成フィードで内部的に優先URLへリンクしてください。検索結果として表示してほしいURLだけをサイトマップに入れてください。サイトマップは弱いシグナルですが、リダイレクトや注釈と一致すると選択を補強します。
サイトマップのURLはホスト、プロトコル、スラッシュのスタイルをカノニカルと同じにした完全修飾URL（フルURL）で生成してください。リダイレクトやパラメータ付きの重複は除去します。パーマリンク、ドメイン、言語、eコマースの変更後は自動生成されるサイトマップをテストしてください。
トラッキング、レガシー、別ホストのURLへのリンクを選んだカノニカルに置き換えてください。
HTTPSリダイレクト、カノニカル対象、サイトマップ、リンクを一貫させてください。証明書やHTTPS→HTTPの不具合は矛盾した信号を送ります。
パラメータ、ページネーション、言語は目的別に扱う
パラメータ＝自動的に重複、ではありません。解析用パラメータはコンテンツを変えない一方で、フィルタやソートは結果集合を変える場合があります。代表的な組み合わせをテストしてください。カート、ログイン、同意、設定に必要なパラメータは保持してください。カノニカルは訪問者のフローを壊してはいけません。
ページネーションの各ページをすべてページ1にカノニカルするべきではありません：後のページにはページ1にないコンテンツが通常含まれます。言語や国別のURLでは、同言語のページが存在する場合はそれをカノニカルにし、代替にはhreflangを使ってください。カノニカルはローカリゼーション設計の代替ではありません。
どのフィルタが独立したランディングページか、どれが並べ替えによる重複かを文書化して、プロダクトとエンジニアリングの変更が整合するようにしてください。
全表示ページを代表にするのは、それが実用的なコンテンツの上位互換である場合のみです。選択する前に読み込みとナビゲーションをテストしてください。
インデックス上とライブの証拠で矛盾をデバッグする
Search Consoleで影響を受けるURLを検査し、Googleがインデックス上で選んだカノニカルとユーザーが宣言した値を比較してください。候補ターゲットも検査します。インデックスレポートはGoogleが最後に処理した内容を反映します。ライブテストは現在のフェッチ、レンダリング、ヘッダー、リソースを示しますが、最終的なカノニカル選択を予測するものではありません。
値が異なる場合、まずGoogleがより良い代表を選んだかを検討してください。そうでなければ、リダイレクト、HTMLおよびHTTPヘッダーの注釈、レンダリング結果、リンク、サイトマップエントリ、hreflang、コンテンツ類似性を辿って矛盾を発見し修正してください。変更を記録し、再評価のための時間を与えます。
テンプレート、ヘッダー、ホストルーティング、セキュリティ変更をチェックしてください。説明のつかないクロスドメインのカノニカルやリダイレクトはセキュリティ調査の対象です。
配信されたソースとヘッダーをCMS設定と比較してください。プラグインやプラットフォームルールが別の値を出力している可能性があります。
SIUのリリースハードニングにカノニカルチェックを組み込む
ドメイン、HTTPS、CDN、CMS、テンプレート、カタログのリリース前に、ホームページ、コンテンツ・商品ページ、パラメータルート、ロケール、レガシーURL、公開ドキュメントをサンプリングしてください。ステータス、最終URL、カノニカルターゲット、サイトマップ収録状況、内部リンクの例を記録します。
修正を可逆にしてください：現在のマッピングをキャプチャし、1つのルールセットを変更し、影響を受けるルートを検証し、ロールバック計画を保持します。これは変更時に安定した公開パスを保護して稼働最適化を支えるものであり、障害検出やインデックス保証を提供するものではありません。
マーケティングとエンジニアリングでカノニカルルールの担当を割り当て、各更新の背後にあるテンプレート、リダイレクト、サイトマップ、プラットフォーム変更をログに残してください。
修正前後の小さなURLとヘッダのサンプルをリリースチケットに添付して、迅速な復旧を可能にしてください。