Googlebotのスマートフォン用user-agent更新では振り分けと表示を確認する

Googlebotのスマートフォン用user-agentが変わるときは、文字列だけを書き換えて終わりにしません。user-agentによって表示を分けているsiteでは、新しいGooglebotへ何を返すか、訪問者のスマートフォンにも同じ内容を返しているかを確認します。判定が外れると、検索engineと実際の訪問者で別のpageを見せることがあります。

Googleの公式案内は、Googlebotのスマートフォン用user-agentを2016年4月18日から更新する予定だと説明しています。影響する可能性があるsiteには、Search ConsoleのFetch and RenderまたはbrowserのDeveloper Toolsで新しい文字列を使い、確認するよう案内しています。

影響があるのは、user-agentで分岐しているsiteです。画面幅に合わせてCSSだけを変えるsiteと、requestを受けたserverがHTMLを切り替えるsiteでは、確認する場所が違います。まず自siteがどちらの方法を使っているか、または両方を使っているかを確かめます。mobile対応という同じ呼び方でも、設定や障害の起きる場所は同じではありません。

古い条件が残るのは、serverの設定だけとは限りません。plugin、広告配信のscript、CDN、cacheの規則、外部の制作会社が入れたmoduleなどに、特定の文字列を調べる処理が残ることがあります。見つけた条件を急いで削除するのではなく、なぜ分けていたのか、現在も必要か、変更後にどのpageへ影響するかを記録します。文字列を追加する作業と、表示を正しくする作業を同じに扱いません。

user-agentで何を分けているかを先に書き出す

同じURLでdeviceごとにHTMLを返すsiteでは、server側がuser-agentを見て表示を変えます。ここで必要なのは、「Googlebotかどうか」を判定することではありません。スマートフォンへ返す内容とresourceを、条件ごとに確認することです。

Googlebot専用のcontentを用意して帳尻を合わせる方法は採りません。検索engineへ返すpageと、同じ条件のスマートフォン利用者へ返すpageをそろえます。

ここでそろえるのは文章だけではありません。商品やserviceの条件、料金の案内、問い合わせ先、ページを移動するlink、画像を表示するためのCSSやJavaScriptも確認します。Googlebotの取得結果では本文があるのに、実際のスマートフォンではmenuが開かず問い合わせへ進めないなら、利用者にとって同じpageとはいえません。反対に、見た目が近くても、検索engineへ返すtitleやcanonicalが意図と違えば、検索結果での扱いを判断しにくくなります。

URLを同じにしたまま表示を変えるsiteでは、担当者が「スマートフォン版」と呼ぶものがどこで決まるかを明確にします。templateを替えるのか、本文の一部を出し分けるのか、画像だけを替えるのかで、確認すべき範囲は変わります。service pageだけが分岐するのか、記事や固定pageも分岐するのかを一覧にし、検索から入るURLを優先します。

変更前に二つの表示を比べる

確認は、現在のスマートフォンuser-agentと、新しいGooglebotのuser-agentを比べて行います。URLを一つだけ見るのではなく、検索から入る代表pageを選びます。

1. user-agentで表示を変えるURLを洗い出す。
2. 検索から来る代表pageを三つ選ぶ。
3. 現在のスマートフォンと新しいGooglebotでresponseを確認する。
4. title、本文、主要link、CSS、JavaScriptの取得を比べる。
5. 違いがあれば、判定条件かcacheの設定を直し、もう一度確認する。

Search ConsoleのFetch and Renderを使うときも、画面上で成功と出たことだけでは終えません。取得したHTMLとrenderされた表示を見て、問い合わせや注文などの必要な操作まで進めるかを確かめます。

比較するURLは、トップpageだけにしません。検索から直接開かれるservice page、記事page、問い合わせpage、一覧pageのように、templateや使うscriptが異なるものを選びます。トップでは正しく分岐していても、古いtemplateを使うpageだけがdesktop用のHTMLを返すことがあります。大きなsiteなら全URLを手作業で見る前に、分岐処理を使うtemplateと流入の多いpageを対応させます。

表示を比べるときは、status code、redirect先、title、本文、画像、主要link、formを順に見ます。最初の画面だけを見ると、スクロール後に読み込む要素やmenuの中のlinkを見落とします。問い合わせformなら入力して送信直前まで進み、注文pageなら商品を選んで次の画面へ進めるかを確認します。実際に送ると困る操作はtest用の宛先やdataを用意して確認します。

cacheが関係する場合は、同じURLに対してどの条件でどの表示が返るかを確認します。一度desktop用の表示を見た後に、スマートフォンでも同じ表示が出るなら、user-agentの判定だけを疑うのは早計です。serverの応答、cacheを通った後の表示、browser側の表示を分けて記録します。再現した時刻と条件を残せば、制作側へ原因を伝えやすくなります。

外部へ修正を頼むときは、「Googlebotが変わる」とだけ伝えません。影響が心配なURL、現在のスマートフォン表示、新しい条件で返った表示、期待する内容、確認期限を渡します。修正後には、どの設定を変えたか、ほかのdevice用の条件へ影響がないかを受け取ります。制作会社が文字列を直しても、site側が事業の説明や問い合わせ導線まで確認する責任は残ります。

user-agentの文字列を固定の前提にしない

Googlebotのuser-agentは、技術の変化に合わせて更新されます。特定のdevice名やOSのversionだけを前提にすると、次の更新でも同じ問題が起きます。deviceを判定する必要があるなら、個別の文字列を継ぎ足すより、どの種類のrequestへどのpageを返すかを整理します。

文字列が変わるたびに個別の例外を増やすと、誰も全体を説明できない設定になります。過去にiPhone向け、Android向け、Googlebot向けと分けて追加した条件があるなら、それぞれが今も必要かを確認します。利用者の画面幅に合わせるだけで足りるpageなら、server側でcontentを分ける必要があるのかも考えます。構成を変える判断は急がず、現在の分岐で何を守ろうとしているかを先に把握します。

4月18日までに行うのは、すべての技術を作り替えることではありません。影響を受ける可能性がある条件を見つけ、重要なURLで新しいGooglebotとスマートフォン利用者へ返る内容を比べ、違いがあれば直すことです。確認して問題がなければ、その結果と確認したURLを残します。次のuser-agent変更時に、同じ調査を最初から始めないためです。

最初の一手は、serverの設定からGooglebotやiPhoneの文字列を検索することです。見つかった条件ごとに、何を返しているかを書き出せば、4月18日までに確認すべきURLを絞れます。