[レベル: 中級]
ユーザーエージェント (User Agent) の識別が適切でなかったために、モバイルフレンドリーなのにモバイルフレンドリーだとしてGoogleに認識されなかった事例をこの記事では紹介します。
モバイルフレンドリーだと認識されない
モバイルフレンドリーテストに合格し、PageSpeed Insightsのモバイルのユーザーエクスペリエンスで100点をとっているにもかかわらず、ウェブマスターツールのモバイルユーザビリティ レポートからエラーが消えず、「スマホ対応」のラベルが検索結果で付かない。
こんな状況の原因解明を求めた質問が、英語版のGoogle公式ヘルプフォーラムに投稿されました。
多数のサイトで発生している現象で、新規に公開したサイトにも初めから起こっているため、ツールとレポート、検索結果のタイムラグが理由ではなさそうです。
原因はUAの振り分けミス
原因はユーザーエージェントを正しく振り分けできていないことでした。
問題となったサイトたちは、動的な配信で構成されていたようです。
ユーザーエージェントに基づいて、PC向けページ用のCSSとモバイル向けページ用のCSSを出し分けていました。
この出し分けが不適切で、Googlebotに対して正しく機能していなかったのです。
モバイル用のGooglebotに、PC向けのCSSを返してしまっていました。
ともすると、Googlebotとユーザーに別々のコンテンツを見せるクローキングとしてみなされる可能性さえありました。
Vary HTTP ヘッダーかメディアクエリで対応
ユーザーエージェントの認識を正しく直すことで、とりあえず問題は解決しました。
しかしモバイル向けGooglebotのユーザーエージェントが今後変わることがありえます。
その対応策を、GoogleのJohn Mueller(ジョン・ミューラー)氏が2つアドバイスしました。
- Vary HTTPヘッダー
- CSS メディアクエリ
Vary HTTPヘッダー
キャッシュされたCSS(コンテンツ)の配信によって、モバイル端末やモバイル版GooglebotがPC向けコンテンツを取得しないようにVary HTTPヘッダーを返します。
Vary HTTPヘッダーの働きについては、Web担当者Forumのコラムで詳しく解説しました。
CSS メディアクエリ
同じファイルでも別々のファイルのどちらでも構いませんが、CSSのメディアクエリを利用してモバイル端末(のスクリーンサイズ)に合わせたCSSを適用させます。
ユーザーエージェントとは関係しないので今回のようなトラブルが発生しません。
よってミューラー氏はメディアクエリの使用を推奨しています。
レスポンシブウェブデザインのメリット
レスポンシブウェブデザインだったら、ここで紹介したトラブルは起きなかったでしょう。
ユーザーエージェントに依存しないし、CSS(とHTML)は1つです。
- ユーザーエージェントに応じた振り分け・出し分け
- モバイル向け・PC向けファイルの管理
こうした、スマホ対応でトラブルの原因になりがちな問題をレスポンシブウェブデザインは保有しません。
設定やメンテナンスの容易さが、レスポンシブウェブデザインをGoogleが推奨する理由の1つでもあります。
レスポンシブウェブデザインがすべてにおいて優っているということでは決してありませんが、有力な検討材料になるでしょう。
いずれにしても、動的な配信や別々のURLの構成を採用するときは設定間違い、技術的ミスが生じないように二重、三重のチェックが重要です。