意味と範囲
正規化とは、重複した、またはよく似た文書の集まりから、代表となるURLを1つ選ぶ作業です。rel=canonicalのリンクでサイト運営者の希望を示せますが、Googleのドキュメントでは、命令ではなく強いヒントとされています。リダイレクト、内部リンク、サイトマップへの記載は、それぞれ別のシグナルになります。そのため、推奨のURLと矛盾しないように揃えます。
実務の進め方
URLはグループごとに順に確認します。対象は、プロトコルとホストのバリエーション、末尾スラッシュの有無、トラッキングパラメーター、フィルター、印刷用ビュー、ページネーションです。重複したURLごとに、アクセスできる状態を残すべきかを決めます。ユーザーからも消すなら、関連性のある301リダイレクトを使います。アクセスできる状態を残すなら、対応する推奨の文書をcanonicalで指します。canonicalの指定先は、正常なレスポンスを返し、インデックス登録できる状態を保ちます。
確認すること
推奨のURLと、代表的な別バージョンの両方で、レンダリング後のHTMLとレスポンスヘッダーを確認します。そのうえで、クロールしたURLの一部で、canonicalタグ、最終URL、内部リンク、サイトマップのエントリを比べます。Search ConsoleのURL検査では、検査したURLについてGoogleが選んだ正規URLを確認できます。ただし、選ばれた結果は診断の手がかりであり、すべての重複が解消した確証ではありません。
限界とよくある間違い
本当に別の商品、主な検索意図が異なるページ、ページネーションのすべてを、習慣で1ページ目にcanonicalで向けてはいけません。canonicalのチェーン、ループ、リダイレクトされるURLへの指定、noindexのページへの指定も避けます。続けられる成果は、文書化した1つのポリシーを、すべてのテンプレートで一貫して実装することです。
URLの具体例と現場でのチェック
商品が、https://example.test/widget、https://example.test/widget/、https://example.test/widget?campaign=springの3つのURLで見られる場合を考えます。パラメーターのない、きれいなURLが推奨の公開ページなら、到達できる重複URLは、そのURLに直接リダイレクトします。アクセスできる状態を残す場合は、まったく同じ推奨のcanonicalを出力します。推奨のURLも、自分自身を指します。内部のメニュー、パンくずリスト、XMLサイトマップのエントリ、生成される代替の参照は、きれいなURLを使います。リンクがばらばらな状態を、タグだけで打ち消そうとしてはいけません。
<link rel="canonical" href="https://example.test/widget">現場でのチェックは明示的です。リクエストURL、リダイレクト後の最終URL、HTTPステータス、HTMLのcanonical、robotsメタタグまたはX-Robots-Tag、サイトマップへの記載、少なくとも1つの内部のリンク元を記録します。失敗とは、タグがないことだけではありません。サーバーが返すHTMLとレンダリング後のDOMでcanonicalが変わる、きれいなURLがcanonicalなのにパラメーター付きのURLがサイトマップに載っている、canonicalの指定先がリダイレクトされる、といった場合も含みます。これらは食い違うシグナルです。修正するには、推奨の文書を1つ選び、各項目を揃えます。
ページネーションとファセットナビゲーションでは、ルールを適用する前に理由を文書化します。固有の連続した一覧の2ページ目は、自己参照のcanonicalのままにすべき内容を含む場合があります。一方、順序を変えるだけの並べ替えパラメーターは、推奨のURLが異なる場合があります。すべてのパラメーターに同じルールが当てはまるとは限りません。1つのカテゴリURLだけでなく、代表的な組み合わせの一式をテストします。テンプレートやプラットフォームのリリース後には、同じサンプルで再度確認します。
Googleは、リダイレクトとrel=canonicalのアノテーションを強いシグナルとして、サイトマップへの記載をより弱いシグナルとして挙げています。このため、サイトのほかの仕組みが食い違っていると、タグ1つの修正では足りないことがあります。ただし、正規化が保証になるわけではありません。ページが大きく異なる場合や、ほかのシグナルが食い違う場合は特に、Googleが選んだ正規URLは、確認すべき結果であり続けます。