Google検索のリファラーのパターン

公開日:

数年前からGoogle検索がデフォルトでhttps化され、サイト運営者がリファラーから検索ワードを取得しにくくなってしまった件です。

現在、Google検索からのリファラーは大きく次の3種類があります。

  • リファラーは送出されるが検索ワード(qパラメータ)は削除される
  • リファラーがGoogleトップページの文字列( https://www.google.co.jp/ など)
  • 従来どおり、リファラーに検索ワードが含まれる

私はアクセス解析やGoogleのサービス内容については門外漢ですが、このブログのアクセスログを見ながら自分なりに調べてみました。

調査の仕方

  • ある一日のアクセスログからウェブページに対するアクセスのみを抽出する(画像やスタイルシートなどのリソース、301リダイレクト、404エラーは除外する)
  • さらにリファラーが空なものとGoogle以外のものを除外する
  • デバイスやブラウザはユーザーエージェント文字列から判断する(UA偽装は考慮しない)

上記のルールで不要データを除去した結果、Google検索から訪問したと判断できるアクセスは184件でした。

リファラーは送出されるが検索ワードは削除される

184件中86件、Google検索のほぼ半数はこれですね。

location.replace() あるいは <meta http-equiv="refresh"> を使ったリダイレクトページを挟むことでリファラーが流れるものの、検索ワードは(おそらく意図的に)除去されています。技術的な仕組みは以下の記事が詳しいので省略します。

リファラーがGoogleトップのURL

184件中87件。 https://www.google.co.jp/ や https://www.google.com/ という文字列なケースです。

ブラウザは1件を除き Chrome またはモバイル向けSafari(iPhone, iPad, iPod)でした。うち3件は暗号化されていないURL(http: から始まる)で、それらはユーザーエージェント文字列に "GSA/3.2.0.25255" が含まれていましたが、それが何を示しているのかは分かりません。

で、なぜトップページのURLになるかというと、これらのブラウザでアクセスした時はGoogleの検索結果ページに以下のmeta要素が埋め込まれるためです。

<meta content="origin" id="mref" name="referrer">

これは検索結果ページから各サイトへ飛ぶ際の速度向上のためにリダイレクトページを経由せず、一方でGoogleからの流入であることは判別できるようにするための処置のようで、このmeta要素のcontent属性値によってリファラー文字列を制御することが可能になります。

通常、httpsなページからhttpなページへリンク遷移した際は、RFC2616の15.1.3(tools.ietf.org)で規定されているようにRefererヘッダは送出されないのですが、この name="referrer" なmeta要素によって(対応しているブラウザでは)送出できるようにもなります。

詳細は Official Google Webmaster Central Blog の記事を参照ください。

ちなみにHTTPリクエストヘッダの "Referer" はスペルミスした単語が採用されてしまっているのですが、meta要素のname属性値は正しい "referrer" です。

リファラーに検索ワードが含まれる

従来どおり、検索ワードが q パラメータに格納されているパターンです。

http://www.google.co.jp/search?q=(URLエンコードされた検索ワード) という感じですね。

184件中11件、内訳は Android標準ブラウザが7件、 IE 6 が2件、 IE 7 とデスクトップ用 Opera 12 が1件ずつでした。

PC用ブラウザの多くは http://www.google.co.jp/ にアクセスしても強制的にhttps版にリダイレクトされるのですが、 IE 10 以前やモバイル向けブラウザなどはそうはならないようで、http版のURLをブックマークから呼び出すなどして検索すると、検索結果ページのリファラーがそのまま流れます(サイト運営者が検索ワードを知ることができます)。

なお、アドレスバーに(URLではなく)文字列を入れて検索した時に http になるか https になるかはブラウザによって異なるようです。