リファラー情報が取得できない！ Chromeでセキュリティ重視の仕様変更

illustration by つきのあめだま

アクセス解析に重大な問題をもたらす仕様変更がChromeにあったようだ。Referrer（リファラー）として渡される参照元URLが変わり、流入元URLとして「元サイトのトップページ」しかわからなくなっているのだ。

なぜそうなったのか、対応策はあるのか、Chromeの動きとともに解説する。

SEOやサイト運営をより良くするための情報を定期的にまとめるこのコーナー、今回もグーグルSEO・ローカルSEO・コンテンツマーケティング・オウンドメディア・アクセシビリティなど、読んで参考になる情報をお届けする：

• グーグルのスニペットに正しい日付を表示する方法
• たったの254文字のコンテンツで上位表示するページの秘密に迫る
• GMBに最近あった2つの更新: 検索結果からの直接編集 と 動画サイズの変更
• 404に関する 2つの TIPS
• コンテンツマーケッター必読！コンテンツ飽和時代のウェブで勝ち抜く戦略
• 10月のオフィスアワー: 画像のインデックスやフレキシブルサンプリング、FAQリッチリザルトなど
• オウンドメディアで成功しているサイト×6
• 438個（！）のhreflangを実装するつわものグローバルサイト
• 視覚障害者に親切ではないサイトにある5つのダメな構成
• Webストーリー用のWordPressプラグインをGoogleが正式公開
• Google検索に2種類のインデックス障害が発生、現在は解消も完全復旧にはなお数日かかる見込み

今週のピックアップ

アクセス解析に痛手!? リファラーで流入元URLの詳細がわからなくなる動き
トップページからの流入が激増しているかも （paiza開発日誌） 国内情報

アクセス解析に重大な問題をもたらす仕様変更がChromeにあったようだ。要は、Referrer（リファラー、参照元ページのURL）から流入元URLを完全には取得できなくなったのだ。

と言っても、リファラーがなくなるわけではない。サイト内のパス（どのページからクリックされたかの情報）が省略され、ドメイン名（どのサイトから来たのか）だけのリファラーになってしまうのだ。

例で解説しよう。たとえば、次のページにあるリンクをクリックして、ユーザーがあなたのサイトを訪問したとしよう：

• リンク元ページ：https://example.com/hoge/1234/

これまでであれば、あなた（リンク先のサイト）のアクセス解析で調べられるリファラーとして、次の情報が伝えられていた。要は、リンク元ページのURLそのままだ：

• 以前の標準リファラー：https://example.com/hoge/1234/

ところが、Chrome 85以降では、次のようなリファラー情報が伝えられる：

• Chrome 85以降の標準リファラー：https://example.com/

わかりやすく言い換えると、参照アクセスのすべてが、元サイトのトップページからの流入としてアクセス解析ツールに記録されてしまうのだ。

グーグルはなぜこの変更を進めたのだろうか。それは、プライバシーだ。上記の例では問題はないが、公開したくない情報がURLに含まれることはある。

そうした例を含めてグーグルは、「リファラーとリファラーポリシーのベストプラクティス」をweb.devのサイトで解説している。

技術的な側面から解説すると、ChromeのReferrer Policyの仕様が厳格になったということだ。従来は標準で no-referrer-when-downgrade だったのが strict-origin-when-cross-origin に変わったのだ。

strict-origin-when-cross-origin では、別オリジン（要は別サイト）に対しては、URLのパス名を除いたドメイン名の部分だけがリファラーとして送信される。Chrome 85から仕様が変わったらしい（いっきに変わったわけではなく、徐々に変更が適用されているようだ）。

リファラーとしてどの情報を渡すかは、自分のサイトの設定や自分が使っているChromeの設定を変更することで変えられる。たとえばWeb担のサイトでは、HTML内に次のタグを入れることで、リファラーとして完全なURLを送るように指定している：

<meta name="referrer" content="unsafe-url">

しかしながら、これは自分のサイトあるいは自分のChromeの動きを変えるだけだ（つまり、自サイトではなく相手のサイトに恩恵がある）。

ほかのサイトやほかの人のChromeからの完全なリファラーを取得することは、今後はどんどん難しくなっていくだろう（FirefoxやEdgeも同様の方向性のようだ）。有効な手立てはなさそうだ。

この動きは、以前にGoogle検索からのトラフィックで検索キーワード情報が隠されるようになった変更を思い出させる。ユーザーのプライバシーを保護するための仕様変更と思われるが、アクセス解析の観点からは、前回と同様に相当の痛手だ。

いずれにせよ、現状がどうなっているのかやその背景など、元記事で詳しく解説されているので、気になる人は確認しておくといいだろう。

グーグル検索SEO情報

グーグルのスニペットに正しい日付を表示する方法
ベストプラクティスを解説するヘルプ記事あり （John on Twitter） 海外情報

グーグルの検索結果ページでは、スニペットの先頭に日付が表示されることがある。

しかし困ったことに、この日付に不適切なものが表示されることがある。グーグルが日付を抽出する処理で失敗していることがあるのだ。

そのためグーグルは、正確な日付を表示させるためにサイト側でやれる施策を公式ブログで解説している。ヘルプページにもベストプラクティスを載せている。

グーグルはスニペットの日付を決めるために、複数の要素を参考にしている。たとえば次のようなものだ：

• ページに書かれている日付
• 構造化データで指定した日付

可能な限り多くのシグナルを適切な形式でグーグルに送ることが重要だ。

SEOでは「検索上位に表示される」ためにがんばることが多いだろう。しかし実際には、表示されるだけでなく、クリックしてサイトに来てもらわなければ意味がない。

そして、ユーザーがクリックするかどうかの判断に、表示されている日付の情報が影響することがある。最新の情報を求めているときに数年前の記事を読みたいとは思わないだろう。正確な日付を表示するためにも、ヘルプに目を通しておくといい。

なお、HTMLというかHTTPには最終更新日を指定するmetaタグがある。

<meta http-equiv="last-modified" content="2020-10-09">

グーグルはブログ記事でもヘルプ記事でも言及していないので、この情報は参考にしていないと思われる。

たったの254文字のコンテンツで上位表示するページの秘密に迫る
記事の長さはランキング要因ではない、大切なのはユーザーのクエリに答えること （CyrusShepard on Twitter） 海外情報

アメリカ海軍天文台のウェブサイトにはマスタークロック（Master Clock）の時刻を表示するページがある。

ページのコンテンツは米国で使われている時間帯を刻む飾り気のない時計だけだ

このページにはたったの

• 64個の単語
• 254文字

しかない。

しかし驚くべきことに、100種類以上のキーワードで毎月1,000件以上の検索トラフィックを獲得しているそうだ。

この事実をツイッターでシェアしたサイラス・シェパード氏は次のように指摘している。

🚫記事の長さはランキング要因ではない
✅ユーザーのクエリをどのくらい上手に満足させるかがランキング要因だ

長い記事が上位表示する傾向は……あるかもしれない。だがそれは、そのクエリに対する回答にはそのくらいの量の記事が必要だからだ。長いからという理由だけで評価されているわけではない。

アメリカ海軍天文台のマスタークロックのページに訪れるユーザーは正確な時刻を知りたいのだ。アメリカ海軍天文台の歴史やマスタークロックの仕組みなどを知りたいわけではないだろう。時刻さえわかれば検索ニーズは満たされる。だから少量のコンテンツでも上位表示できるのだと考えられる（このページは大量のリンクを集めているわけでもない）。

この例からもわかるように、盲目的に長い記事を書くのではなく、ユーザーの検索意図をいかに満たすかに重点を置いてコンテンツを作成してほしい。結果的に長い記事になることもあるだろう。だが、「上位表示のために2000文字以上の記事を書く」といったことを必須条件にする必要はない。

GMBに最近あった2つの更新: 検索結果からの直接編集 と 動画サイズの変更
GMB管理者は知っておく （Google Japan on Twitter） 国内情報

ローカルSEOをがんばっている人に、グーグル マイビジネスの最新情報を2つお伝えする。

検索結果からのビジネスプロフィール編集

検索結果からビジネスプロフィールを直接編集できるようになった。グーグルマイビジネスのダッシュボードにアクセスする必要はない。クチコミへの返信も検索結果からできる。

自分が管理するビジネスの名称で検索するとキャプチャのようなエリアがトップに出てくる、ここから操作可能だ。

動画サイズの変更

グーグル マイビジネスにアップロードする動画のファイルサイズが変更された。最大100MBだったのが75MBに縮小した。動画を投稿しているなら注意しよう。

404に関する 2つの TIPS
グーグル検索における技術的な情報 （John on Twitter） 海外情報

404 エラーに関係する情報を2つお伝えする。どちらも、グーグルのジョン・ミューラー氏がツイッターでフォロワーに回答したものだ。

404ページを復活させてもOK

「いったん削除して404エラーを返していたURLを、その後復活して同じURLで再公開」することに、問題はないとのことである。

301してから404を返してもOK

404を直接返さずに、404を返すエラーページに301リダイレクトしても問題ないそうだ。