計測用パラメータ付きURLの正規化を確かめる手順

広告やメールマガジンのリンクに ?utm_source=newsletter のような計測用のパラメータ（URLの末尾に付ける、流入元を記録するための文字列）を足す。すると同じ記事が、パラメータの付いたURLと付いていないURLの両方で開けるようになります。ここで手が止まる方は多いはずです。同じ内容のページが増えたぶん、重複コンテンツとして評価が割れるのではないか、と。

先に答えを書きます。やることは1つで、パラメータ付きのURLを実際に1本開き、そのページが「正規のURL」としてどこを指しているかを見ることです。ブラウザだけで数分あれば終わります。指定が効いていれば、あなたの側でやるべき作業は残りません。効いていなければ、直す場所は1か所に絞れます。

計測をやめる判断は、この確認をしてからでも遅くありません。

Googleには、重複したURLから代表を1つ選ぶ処理がある

まず、検索エンジン側がどう動くかを押さえます。Google 検索セントラルの「URL の正規化とは」は、正規化（canonicalization）とは重複したコンテンツを代表するURLを1つ選ぶ処理であり、Googleは最も完全で有用なページを正規URLとして選び、そのページをより定期的にインデックスすると説明しています。

読み替えると、こうなります。同じ内容が複数のURLで開ける状態は、検索エンジンにとって想定外の異常事態ではありません。代表を1つ選ぶという処理が、そもそも用意されている。同ドキュメントは、重複ページが生じる原因として地域・端末・プロトコルの違いなどを挙げています。

ここで挙がっている例は、地域・端末・プロトコルの違いです。計測用パラメータの扱いがこれと同じになるかどうかを、この記述だけから決めてかかるのは避けたほうがよいでしょう。自動的に同一視されることを前提にするのではなく、自分のサイトで代表URLを申告できているかを確かめる。次の節の「指定」が効いてくるのは、そのためです。

指定の方法には、強さの順番がある

「重複した URL を統合する」のドキュメントは、正規URLを伝える手段を複数示し、リダイレクト、rel="canonical" のリンク要素またはHTTPヘッダー、サイトマップへの収録を挙げています。そのうえで強さに差があるとし、リダイレクトが最も強く（非推奨化＝deprecation の場面で使う）、rel="canonical" による方法は強い優先の表明として扱われると説明しています。

そして重要なのが、指定しなかった場合の挙動です。同ドキュメントは、正規URLを指定しなければ、Googleがどのバージョンを検索結果に出すのが客観的に最良かを判断すると書いています。判断してもらえること自体は助かるのですが、それは「どちらが選ばれるかを自分で決めない」ということでもあります。

計測用パラメータの話に戻すと、選択肢は実質1つです。

表の1行目が、計測用パラメータの特殊なところです。末尾スラッシュの統一のように「片方を転送で潰す」やり方は、ここでは使えません。パラメータを剥がしてしまえば、何のためにパラメータを付けたのか分からなくなるからです。ページはパラメータ付きのまま開けたうえで、検索エンジンにだけ代表URLを伝える。2行目の rel="canonical" が担うのはこの役割です。3行目は、作業ではなく点検項目として使います。

手順：パラメータ付きURLで、指定が効いているか確かめる5ステップ

推測ではなく、自分のサイトの実物で確かめます。専門のツールは要りません。

1. 確認用のURLを1本つくる。 よく見られている記事のURLに、実際に配信で使う形のパラメータを足すだけです。たとえば https://example.com/blog/seo-tips に対して https://example.com/blog/seo-tips?utm_source=test&utm_medium=check とします。ここでの = と & の使い方は、公式の「URL 構造をシンプルに保つ」が推奨している共通のエンコード（= でキーと値を区切り、& で追加のパラメータをつなぐ）に沿っています。
2. ブラウザでそのURLを開く。 まず見るのは、記事がふだんどおり表示されるかどうかです。パラメータが付くとエラーになる、内容が変わる、テンプレートが崩れる。こうした挙動があれば、正規化の前にそちらが問題です。
3. ページのソース（HTML）を表示して canonical を探す。 ブラウザの右クリックメニューにある「ページのソースを表示」を開き、ページ内検索で canonical と入力します。<link rel="canonical" href="..."> という1行が見つかるはずです。この href に書かれているURLが、そのページが「代表はここです」と申告している先です。
4. 申告先が、パラメータなしのURLになっているかを見る。 期待する形は https://example.com/blog/seo-tips です。パラメータ付きのURLがそのまま入っていたら、意図した先を指せていません。何も見つからなければ、そもそも指定がない状態です。判定の分岐は次の節の表にまとめます。
5. 同じことを、種類の違うページでもう2〜3本くり返す。 記事ページで効いていても、商品ページやカテゴリー一覧では別のテンプレートが使われていることがあります。テンプレートの種類ごとに1本ずつ見るのが、最小の手間で全体を把握するやり方です。

この5ステップは、パラメータの種類を問いません。広告の識別子でも、メールマガジン用の記号でも、見る場所は同じ canonical の1行です。

ワークスルー：実際に1本通してみる

架空のサイトで、いま挙げた手順を1周してみます。

ステップ1。 直近でいちばん読まれている記事 https://example.com/blog/seo-tips を選び、末尾に ?utm_source=test&utm_medium=check を足しました。

ステップ2。 ブラウザで開くと、記事は問題なく表示されます。見た目はパラメータなしのときと同じです。ここまでは想定どおり。

ステップ3。 ソースを表示し、canonical で検索します。1件だけヒットしました。<link rel="canonical" href="https://example.com/blog/seo-tips"> と書かれています。

ステップ4。 href の中身にパラメータは入っていません。パラメータなしのURLを指しています。つまりこの記事については、パラメータ付きでアクセスされても、代表はパラメータなしのURLだと申告できている状態です。ここで作業は終わりです。

ステップ5。 続けて商品ページで同じことをしたところ、href が https://example.com/items/1234?utm_source=test&utm_medium=check になっていました。開いたURLをそのまま書き出す実装になっているようです。記事側は正しく、商品ページ側だけが直す対象——と切り分けられました。

ここまでで10分ほどです。この切り分けができると、社内やベンダーへの依頼も「サイト全体を見直してほしい」ではなく「商品ページのテンプレートで、正規URLの出力がアクセスされたURLをそのまま使っている」という1行の依頼になります。作業の重さがまったく変わります。

判定表：ソースで見つかった canonical の読み方

ステップ4での分岐を、そのまま点検項目にできる形にしておきます。

上から2行目が、さきほどの商品ページの状態です。3行目に当てはまった場合も、いきなりテンプレートを書き換えにいく必要はありません。「重複した URL を統合する」は、WordPress・Wix・Blogger のようなCMSを使っている場合、HTMLを直接編集できないことがあり、その代わりにCMS側の検索エンジン向けの設定が用意されていることがあると説明しています。管理画面を先に探すほうが早い、ということになります。

最終行の絶対URLについても補足しておきます。同ドキュメントは、rel="canonical" をHTTPヘッダーで指定する場合も、リンク要素のときと同じく絶対URLを使うよう示しています。相対パスで書くと、基準となる位置の解釈しだいで指し先がずれます。パラメータが絡むとその判断はさらに難しくなるので、ここは素直に絶対URLにそろえるのが安全です。

よくある誤解と、つまずきやすいところ

「パラメータを付けた時点で手遅れ」ではありません。 前述のとおり、Googleには重複したコンテンツから代表URLを選ぶ処理があり、その処理は最も完全で有用なページを選ぶものだと公式に説明されています。まず確認すべきなのは、自分のサイトが代表URLを申告できているかどうか。この順番を逆にすると、必要のないURL設計の作り直しに時間を使うことになります。

逆に、「指定してあるから大丈夫」と決めつけるのも早いです。 公式が rel="canonical" を位置づけているのは「強い優先の表明」であって、リダイレクトのほうが強いという順序も明示されています。申告は届けられますが、最終的にどのURLを代表とするかの処理は検索エンジン側にあります。ですから、指定したあとで検索結果に出ているURLを一度は見ておく、という運用が現実的です。

サイトマップにパラメータ付きURLが混ざっていないか。 「重複した URL を統合する」は、サイトマップを使う場合、各ページについて正規URLを1つ選ぶよう示しています。自動生成のサイトマップに、計測用パラメータが付いたURLがそのまま入り込んでいることがあります。ステップ5の確認が終わったら、サイトマップのファイルを開いて utm で検索する。これも数十秒で終わります。

パラメータそのものを増やしすぎない。 「URL 構造をシンプルに保つ」は、シンプルで説明的な単語を使うこと、可能なら読者の言語で書くこと、非ASCII文字にはUTF-8のエンコードを使うことを挙げ、長いID番号を避けることも推奨しています。計測のためのパラメータは仕組み上どうしても増えがちですが、配信のたびに独自の記号を足していくと、あとで自分たちが読めなくなります。運用の都合としても、パラメータの命名は最初に決めておくほうが楽です。

エラーではない状態を、エラーとして扱わない。 パラメータ付きのURLが検索エンジン側に「別のURLとして検出された」形跡があっても、意図した代表URLのほうが検索結果に出ているのであれば、それは指定が働いている可能性が高い状態です。検出されたこと自体をゼロにしようとして、パラメータ付きURLをクロール拒否するといった手を打つと、かえって代表URLの申告が読み取られなくなることがあります。まず見るのは検出の有無ではなく、検索結果に出ているURLのほうです。

自己点検チェックリスト

以下がすべて「はい」であれば、計測用パラメータについてやるべきことは終わっています。

この6行のうち、上の2つが終われば実務上の不安はほぼ解消します。残りは、テンプレートを更新したときに崩れていないかを見るための、定期点検の項目として使ってください。

Wemiroでは、サイト内のページを巡回して正規URLの指定状況を一覧にし、パラメータ付きURLが代表URLへ寄せられているかを自動で検出できます。テンプレートの種類が多いサイトほど、5ステップを手で回す範囲が広がるので、そこを機械に任せる使い方が向いています。

同じ「評価を1つのURLに集める」というテーマを、パラメータ以外の重複も含めて広く扱ったものは 重複コンテンツとcanonicalの考え方 に、URLの表記ゆれを1つに寄せる作業の具体例は URL末尾のスラッシュ有無を統一する手順 にまとめています。