オンライン フォームを入力しやすくするために

多くのウェブサイトでは、重要な目標を達成するための手段としてフォームを使用しています。たとえば、ショッピング サイトでは代金の決済、ニュース サイトでは会員の登録などです。ユーザーの多くは、ウェブ上の各サイトでオンライン フォームを入力するたびに、氏名、メール アドレス、電話番号、住所などの情報を繰り返し入力することになります。同じ情報を何度も入力するのは面倒なだけではありません。入力エラーが発生しやすく、ユーザーがフォームの途中で入力をやめる原因にもなってしまいます。パソコンよりも携帯端末で閲覧するユーザーが多くなり、フォームをすばやく簡単に入力できるようにすることが不可欠となっています。Google では 3 年前、フォームへの入力をすばやく、簡単に、スマートに行えるようにするため、Chrome で新たに「autocomplete」属性をサポートすることを発表しました。現在では、最新の WHATWG の HTML 標準(英語)に準拠する形で「autocomplete」属性が完全にサポートされています。これにより、ユーザー インターフェースやバックエンドに変更を加えることなく、入力要素項目に一般的なデータ タイプ(「name」、「street-address」など)をラベル付けできるようになっています。既にたくさんのウェブマスターがフォームをマークアップしてオートコンプリートを実装し、フォーム入力の完了率を上昇させています。

たとえば、フォームのメール アドレス項目をオートコンプリートできるようにするには、次のようにマークアップします(サンプル フォームもご覧ください)。

<input type="email" name="customerEmail" autocomplete="email"/>
携帯端末ユーザーが増加した今、操作やブラウジングが簡単なウェブサイトにすることが非常に重要です。「autocomplete」属性でマークアップされたフォームが、今後ますます増えていくことを願っております。詳細については、「Web Fundamentals」の Label and name inputs properly (英語)で仕様を確認してください。ご質問などありましたら、いつもどおりウェブマスター ヘルプ フォーラムに投稿してください。

検索結果をもっとモバイル フレンドリーに

ユーザーが携帯端末で検索した場合、探している情報がモバイル フレンドリー サイトで公開されていてもアプリで公開されていても、関連性の高いタイムリーな検索結果がユーザーに表示される必要があります。インターネットへのアクセスに携帯端末が使用されるケースが増えてきたため、Google のアルゴリズムもこうした使用状況への対応が必要となっています。これまでにも、サイトを適切に設定するための変更、最新端末で表示可能にするための変更を行ってきました。また、検索ユーザーがより簡単にモバイル フレンドリーなウェブページを探せるよう対応し、アプリの有益なコンテンツを検索結果に表示するようになる App Indexing を導入しました。

本日、Google はモバイル フレンドリーなコンテンツをユーザーがより発見しやすくするためにおこなった 2 つの重要な変更についてお知らせします。

1. 検索結果にもっとモバイル フレンドリーなウェブサイトを

Google では、4 月 21 日より、ウェブサイトがモバイル フレンドリーかどうかをランキング要素として使用し始めます。この変更は世界中の全言語のモバイル検索に影響を与え、Google の検索結果に大きな変化をもたらします。この変更によって、検索ユーザーは、クエリへの関連性が高く使用端末にも適した高品質な検索結果を見つけやすくなります。

モバイル フレンドリー サイトの作成について詳しくは、モバイル フレンドリー サイトのガイドをご覧ください。ウェブマスターの皆様は、以下のツールを使うことで、ご自身のページが Googlebot からどのように認識されているかを変更の前に確認することができます。

2. 検索結果にもっと関連性の高いアプリ コンテンツを

本日より Google は、インデックスされたアプリからの情報を、そのアプリをインストールしている ログイン ユーザーに対して、ランキング要素の一つとして使用し始めます。これにより、インデックスされたアプリのコンテンツをより簡単に見つけることができるようになります。アプリのコンテンツが検索結果に表示されるようにする方法については App Indexing サイトで解説していますので、ぜひご覧ください。

モバイル フレンドリー サイトまたは App Indexing についてご不明な点がありましたら、ウェブマスター プロダクト フォーラムでお気軽にご質問ください。

ウェブマスター ツールでモバイル ユーザビリティが確認できるようになりました

スマートフォンが普及するにつれ、モバイルでの閲覧に対応したサイトを作ることは、ますます重要になってきています。今回は、先日ウェブマスター ツールに追加されました、モバイル ユーザビリティを確認できる機能をご紹介いたします。

この新機能によって、あなたのサイトがモバイルで閲覧される際に問題となりうる点が表示されるようになりました。進捗を確認するために、時系列でのグラフもついています。

ここでは、スマートフォンでの閲覧の際、上下のスクロールのみによって簡単に読むことのできるサイトをモバイル フレンドリーと定義しています。左右へのスワイプやズームイン、ズームアウトが必要となる場合、スマートフォンで気軽に閲覧することは難しくなってしまいます。ここで指摘される問題は以下のようなものです。
これらの問題がウェブマスター ツール内で表示されている場合、ぜひ解決法を探ってみてください。テンプレートを変えるだけで直ってしまうこともままあります。詳しい情報は、モバイルガイドを御覧ください。

ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

App Indexing の実装に不可欠な 4 つのステップ

ディープ リンクは、オーガニック検索内で最近見かけるようになった「新入り」ですが、目を見張るような速さで普及しています。ユーザーがログインしている場合、Android での Google 検索結果のうち、15% が App Indexing によるアプリ ディープ リンクを表示しています。前四半期だけで、アプリ ディープ リンクのクリック数が 10 倍に急増しました。

App Indexing を今年 6 月に公開して以来、デベロッパーの皆様からさまざまなフィードバックが寄せられました。ほとんどの実装はうまく行きましたが、うまく行かなかった実装からも多くを学ぶことができました。この記事ではそうした経験を踏まえ、App Indexing の実装を成功させるうえで欠かせない 4 つのステップについて解説します。また、アプリのパフォーマンスを把握したり、アプリの利用を促進したりするための便利な新機能も紹介します。

1. デベロッパーにウェブマスター ツールへのアクセス権限を付与する

App indexing は、ウェブマスターとアプリ デベロッパーが協力して取り組む必要があります。ウェブマスター ツールには、デベロッパーが必要とする情報も表示されます。現時点で表示されるのは以下の情報です。
  • アプリ内のインデックス登録済みページのエラー
  • Google 検索でのアプリ ディープ リンクのクリック数とインプレッション数(週単位)
  • サイトマップに関する統計情報(アプリ ディープ リンクをサイトマップで実装した場合)
今後これらの他にもさまざまな情報を追加する予定です。

しかしながら、ウェブマスター ツールへのアクセスが許可されているデベロッパーは非常に少ないようです。アプリ関連の問題の修正に必要な情報を確実に伝達するには、デベロッパーにウェブマスター ツールへのアクセス権限を付与することが不可欠です。

確認済みのサイト所有者であれば、新しいユーザーを追加できます。付与したい権限レベルに応じて [制限付き] または [フル] を選択してください。

2. 検索結果からのアプリへのアクセス状況を把握する

ユーザーは、検索結果からアプリにアクセスしてくれているでしょうか。アプリ ディープ リンクのパフォーマンスをトラッキングする方法として次の 2 つを追加しました。
  • ウェブマスター ツール アカウントのメッセージ センターに、週ごとのクリック数とインプレッション数が送信されるようになりました。
  • アプリ ディープ リンクによってどれくらいのトラフィックがアプリにアクセスしたかを、リファラー情報(具体的には ACTION_VIEW インテントのリファラー extra)を使用してトラッキングできるようになりました。将来的には、この情報を Google アナリティクスに統合して簡単にアクセスできるようにする予定です。デベロッパー サイトでは、リファラー情報をトラッキングする方法(英語)について解説しています。

3. アプリの重要なリソースがクロール可能であることを確認する

ウェブマスター ツールのクロール エラー レポートで、「コンテンツの不一致」エラーが発生する大きな原因の 1 つがリソースのブロックです。クロールでは、アプリ ページをレンダリングするために必要なすべてのリソースにアクセスする必要があります。これにより、アプリ ページのコンテンツが、関連付けられているウェブページと同じかどうかを確認できます。

アプリ ページのレンダリングに不可欠なリソースにアクセスできない場合に、どのリソースがブロックされているかを簡単に特定できるようになりました。アプリで「コンテンツの不一致」エラーが発生した場合は、詳細ダイアログの手順 5 に沿ってブロックされているリソースの一覧を確認してください。

4. Android アプリのエラーに注意する

アプリのインデックス登録時のエラーを簡単に特定できるようにするため、検出されたすべてのアプリ エラーをメッセージとして送信することになりました。また、そのほとんどがクロール エラー レポートの [Android アプリ] タブにも表示されます。

従来の「コンテンツの不一致」エラーと「インテント URI が無効」エラーに加え、以下の 3 つのエラー タイプを追加しました。
  • APK が見つからない: アプリに対応するパッケージが見つからない
  • First Click Free(英語) がない: アプリへのリンクがコンテンツに直接つながっておらず、ログインしないとアクセスできない
  • 戻るボタンの違反: アプリへのリンクをたどって移動した後、戻るボタンで検索結果に戻ることができない
これまでの経験から、エラーの大部分はアプリの一般的な設定が原因であることがわかっています(リソースがブロックされている、ユーザーが検索結果からアプリを開こうとすると地域選択のポップアップが表示されるなど)。これらの点に注意することで、関連する URI の問題をすべて解決できるはずです。

App Indexing 実装がうまく行くことを願っています。ご不明な点がありましたら、いつでもウェブマスター ヘルプ フォーラムまでお寄せください。

検索ユーザーがモバイル フレンドリー ページを見つけやすくするために

スマートフォンなどの携帯端末で Google の検索結果をタップした時、表示されたページのテキストが細かすぎたり、リンクの表示が小さかったり、またはすべてのコンテンツを見るには横にスクロールしなければならなかったりといった経験はありませんか?これは主に、ウェブサイトが携帯端末での表示に最適化されていないことが原因です。

この問題はモバイル検索ユーザーの利便性を妨げることになります。そこで本日 Google では、ユーザーが目的の情報をより簡単に見つけることができるようにするために、モバイル版の検索結果に [スマホ対応] というラベルを追加します。
この変更は、今後数週間で順次日本を含む世界中で公開する予定です。Googlebot によってクロールされ、以下の条件を満たしたページは、[スマホ対応] ラベルが適用される可能性があります。
  • 携帯端末では一般的でないソフトウェア(Flash など)を使用していないこと
  • ズームしなくても判読できるテキストを使用していること
  • ユーザーが横にスクロールしたりズームしたりする必要がないよう、コンテンツのサイズが画面のサイズと一致していること
  • 目的のリンクを簡単にタップできるよう、それぞれのリンクが十分に離れた状態で配置されていること
ページがモバイル フレンドリーの条件を満たしているかどうかを確認するには:
ここでご紹介したツールやガイドは現在のところ英語のみとなりますが、今後数週間で多くの言語でご利用いただけるようになります。

Google ではこのラベルを、モバイル ユーザーにさらに優れたモバイル ウェブ エクスペリエンスを提供するための第一歩と考えています。また、このモバイル フレンドリーの条件をランキング要素として使用することも実験中です。

ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。Google の願いは、モバイル フレンドリー サイトが今後ますます増えていくことです。すべてのユーザーが快適に利用できるウェブを作り上げていきましょう!

Google の検索結果に、誰もが表示できるウェブサイトを

閲覧しようとしたページが自分の端末に対応していないという状況は、ウェブ ユーザーによくある悩ましい問題です。時には、まったく何もないページや大部分が欠けたページが表示されます。

Google は、本日より日本でも、端末が対応していない技術が使われていると思われるページを検出した際には、モバイルの検索結果上にその旨を表示(英語)するようになりました。たとえば、Adobe Flash は、iOS や Android 4.1 以降を搭載したスマートフォンでは表示できません。このような端末では、大部分が Flash であるようなページは、モバイルの検索結果上で以下のように表示されます。


現在使われている様々な端末に対応したウェブサイトの開発方法


ところで、現在使われているすべての端末に対応したウェブサイトを開発することは難しくありません。HTML5  を使いましょう。HTML5 は、どのような端末でも表示されますし、HTML5 しか使えない端末さえあるからです。そこで、好きな種類のファイルをどのような端末でも表示できるようなサイトを作る一助になればとの思いから、最近、Google は次の 2 つのページを公開いたしました。
  • Web Fundamentals (英語): ウェブサイト作成のベスト プラクティスを集めた用例集。
  • Web Starter Kit (英語):  Web Fundamentals の用例を応用して、ウェブサイトを一から作るためのフレームワーク。
Web Fundamentals に書かれた適切な作り方に従うことで、Google が推奨している、検索に適したレスポンシブ デザイン(英語)であるサイトを作ることができます。この際、Googlebot がサイトのすべてのサブ リソース(CSS、Javascript、画像ファイル等)にアクセスできるよう robots.txt などの設定をしてください。すべてのサブ リソースにアクセスできることで、Google のアルゴリズムは、ページがレスポンシブ デザインであることを検出しやすくなり、ひいては適切に評価することができます。また、ウェブマスター ツールには、インデックスに登録するアルゴリズムがどのようにウェブサイトを認識しているかを調べるための Fetch as Google という機能があります。

ご不明な点がございましたら、ウェブマスター ヘルプ フォーラムをご利用ください。

Android の App Indexing が誰でもご利用いただけるようになりました!

もしあなたがウェブサイトと Android アプリを両方持っているのなら、それらを連携させることで、スマートフォンやタブレットから Google で検索しているユーザーにとって、検索結果からアプリへの起動を非常に簡単にすることができるようになりました。

検索結果に表示されるアプリのディープリンクは、あなたのアプリが既にインストールされている端末の検索結果において、アプリ内のコンテンツへのアクセスをより容易にします。ウェブサイトのページを対応するアプリ側の部分へと接続することで、サイトオーナーとして、適切なコンテンツを、適切なタイミングでユーザーに見せることができるようになります。


いくつものアプリが既に App Indexing を実装しています。今週の Google I/O で、ディープリンクの設定、サイトのアプリへの接続、パフォーマンスやエラーのトラッキングといった一連のプロセスをより容易にするための機能を発表いたしました。

簡単に始められます

このたび、アプリのディープリンクをインデックスさせるために必要なプロセスを大きく簡易化しました。アプリが既に HTTP によるリンクをサポートしているのであれば、
あなたの URL 群がインデックスされると共に、Google はアプリとサイトの繋がりを発見し、検索結果でディープリンクを使用したアプリへの直接的な遷移を可能にします。

アプリのディープリンクの発見とインデックス作業を Google に任せることもできますが、あなた自身がこれらのディープリンクを埋め込み、公開することをおすすめします。もしあなたのアプリがカスタム ディープリンクスキームをサポートしている場合は特にそうです。そのためには、2 つの方法があります:
  • 各ウェブページに対して、rel="alternate" 属性を持った link 要素を <head> 部分に埋め込むか、サイトマップを利用して android-app URI を指定する。デベロッパー サイト上で実装方法を確認できます。
  • App Indexing API (英語)を利用する。
また、このたび、アプリページをインデックスする際に発生した問題について報告を行う新しい機能をウェブマスター ツールに追加しました。ここでは、各アプリページとウェブページのペアについて検知されたエラーと、デバッグのためのサンプル アプリ URI確認することができます。


また、それぞれの問題について、その詳細なデバッグ方法も確認することができます。アプリのディープリンクの QR コードも含まれていますので、携帯電話やタブレットで簡単にリンクを開けます。エラーが検知された場合、ウェブマスター ツール上でメッセージもお送りいたします。


App Indexingは既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。


ぜひ App indexing をお試しください。何かご質問があれば、ウェブマスター ヘルプ フォーラムへ!

PageSpeed Insights を使ってサイトのモバイル操作性を向上させましょう

モバイル対応のページを作成するデベロッパーやウェブマスターの皆さんのお役に立てるよう、Google ではこのたび、PageSpeed Insights の見直しを行い、モバイルでの操作性に関する推奨事項を新たに追加しました。


ページの読み込みが速くても、操作性が低ければその効果が損なわれかねません。Google の調査では、平均的なモバイル ページの読み込みには少なくとも 7 秒はかかる(英語記事)ことがわかっています。PageSpeed Insights ツールを使用し、そこで提示される速度についての提案を活用することで、ページ読み込みの速度を改善することは可能です。では、モバイル サイトの読み込みに 7 秒もかからず 2 秒で済む場合を考えてみましょう。ページの読み込み後、モバイル ユーザーがテキストを読んだりページを操作したりするために、画面をピンチズームしたりスクロールしたりして 5 秒かかってしまったら、ユーザーの体験としてはそのサイトは速いとは言えません。PageSpeed Insights が新しく提案するユーザー エクスペリエンスに関するルールを参考にすれば、こうした操作性についての問題点を見つけ出し、修正することができます。

この新たな推奨事項では、現在のところ次のような対策を紹介しています。
  • viewport を設定する: viewport メタ タグが指定されていないページは、最新のモバイル ブラウザではモバイル非対応ページとみなされてデスクトップ向けのビューポートとして処理され、さらにはフォント拡大が適用される可能性もあるため、意図したとおりのページ レイアウトで表示されないことがあります。モバイルに適したサイトにするためには、まず viewport の設定で width=device-width を使用しましょう。
  • コンテンツのサイズを viewport に合わせる: ユーザーは、モバイル サイトは横ではなく縦にスクロールするものと思っています。viewport を設定したら、ページのコンテンツがその viewport の幅に収まっていることを確認してください。その際、携帯端末の幅は機種によって異なることに注意が必要です。
  • 読みやすいフォント サイズを使用する: ユーザーがスマートフォンで記事を読むときに拡大しないと文字が読めないとしたら、それはモバイルに適したサイトとは言えません。PageSpeed Insights では、大部分のユーザーにとって読みやすい大きさの文字かどうかをチェックします。
  • タップ ターゲットのサイズを適切に調整する: 携帯電話やタブレットのタッチスクリーンでボタンやリンクをタップしようとして、間違えて誤ったターゲットをタップしてしまうことがあります。これは、パソコンのマウス カーソルと比べて指の腹の方が大きいためですが、とても煩わしいものです。モバイル サイトのタッチスクリーンのタップ ターゲットは押しやすいように十分大きくするようにしてください。
  • プラグインを使用しない: ほとんどのスマートフォンでは、Flash などのブラウザ プラグインをサポートしていません。そのため、モバイル サイトでもプラグインを使用しないようにします。
これらのルールについては、PageSpeed Insights のヘルプ ページに詳しい説明があります。準備ができたら、PageSpeed Insights ツールを使ってページをテストし、改善点を確認してみてください。なお、今回の PageSpeed Insights の更新により、モバイル対応のデザインを使用できるようにもなりました。また、ヘルプ ドキュメントの翻訳版が公開され、さまざまな言語でご利用いただけるようになっています。

この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラムまでお寄せください。

App Indexing の最新情報

昨年、検索結果から Android アプリへ直接つながるディープ リンクが Google の検索結果に表示される App Indexing を米国で提供を開始したことをこちらのブログでもお知らせしました。Google では今回、新たに 20 を超えるアプリを追加で有効にし、間もなく検索結果にアプリのディープ リンクが表示されるようになります。また、英語のコンテンツへのアプリのディープ リンクを全世界でご利用いただけるようになりましたことを、お知らせします。


Google では引き続き、すべての言語のサイト運営者様にご参加いただきたいと考えています。提供している Android アプリでディープ リンクをサポートしていない場合や、ウェブサイトやサイトマップでこのようなリンクをまだ指定していない場合は、ぜひ対応していただき、こちらの フォーム(英語)から Google までお知らせください。

サイトマップやウェブサイトにディープ リンクを追加する際に、考慮すべきベスト プラクティスをいくつかご紹介します。
  • アプリのディープ リンクは正規 URL にのみ含めるようにしてください。
  • ホームページにおいてもアプリのディープ リンクを指定することをお忘れなく。
  • サイトマップに含まれているすべてのウェブサイト URL に対応するアプリのディープ リンクを設定する必要はありません。提供しているアプリでサポートされていないディープ リンクを含めないようにしてください。
  • ニュース サイトでニュース サイトマップを使用されている場合は、通常のサイトマップと同様に、ニュース サイトマップにもディープ リンクのアノテーションを含めるようにしてください。
  • ネイティブ ARM コードを実行するディープ リンクのアノテーションを指定しないでください。これにより、すべてのプラットフォームで App Indexing が有効になります。
アプリのコンテンツがインデックスに登録されると、提供しているアプリは、通常の動作の場合と同様に HTTP  リクエストを送信する必要があります。これらのリクエストは、サーバー上では Googlebot から送信されたように表示されます。そのため、これらのリクエストを許可できるようにサーバーの robots.txt ファイルを設定する必要があります。

最後に、アプリの戻るボタンをクリックした場合に、必ず検索結果ページに直接戻ることを確認してください。

実装の詳細については、最新のデベロッパー ガイドライン(英語)をご覧ください。この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラムまでお寄せください。

モバイル サイトを改善するためのチェック リストと動画をご紹介します

スマートフォン用ウェブサイトを改善したいけれど、どこから手をつければよいかわからないとお困りではありませんか?多くのアドバイスの中からどれを優先すればよいのか知りたいと思いませんか?このたび Google では、モバイル サイトを効率よく改善する上で役立つチェック リストを公開しました。このチェック リストでは、複数のトピックから関連するビジネス ケースや研究・調査にリンクしています。また、一部のトピックでは、Google アナリティクスやウェブマスター ツールのデータをサイトの改善に効果的に利用する方法を解説した動画を用意しています(字幕を日本語にしてご覧ください)。こちらのリストは、チェック リスト(英語)の簡易版となります。ぜひ、サイトの改善にお役立てください。

手順 1: ユーザーをイライラさせない
  • 簡単に閉じることのできない JavaScript ポップアップ。
  • 特にアプリをダウンロードするためのオーバーレイ表示(iOS 6 以降の Smart App Banner(英語)またはそれに相当するバナー、サイド ナビゲーション、メール マーケティングなどの使用を代わりにご検討ください)。
  • タスクを完了する前のアンケートの表示。
  • 端末に適した機能を提供する
  • ユーザーの端末で使用できないプラグインや動画を必要とする機能を削除します(たとえば、Adobe Flash は iPhone や Android バージョン 4.1 以降では再生できません)。| ビジネス ケース
  • タブレット ユーザーにはデスクトップ バージョン(可能な場合はタブレット バージョン)を配信します。| 研究・調査(英語)
  • デスクトップ バージョンの機能が携帯端末でもすべて利用できることを確認します。ユーザーがデスクトップ バージョンでの表示を選択した場合には、セッション中はすべてデスクトップ バージョンが保持されるようにします(つまり、各ページが読み込まれた後でユーザーがデスクトップ バージョンを選択しないで済むようにします)。| 研究・調査(英語)
  • トラフィックが多くユーザー エクスペリエンスが悪いモバイル向けページを改善する

Google アナリティクスの直帰率とイベントのデータを使用して、トラフィックが多くユーザー エクスペリエンスが悪いモバイル向けページを改善する方法(スライド
  • パフォーマンス向上のための簡単な修正を加える(競合サイトよりもパフォーマンスが低い場合は継続して修正する)| ビジネス ケース(英語)

モバイル サイトのパフォーマンスを向上するための簡単な修正を加え、競合サイトとパフォーマンスを比較する方法(スライド

「ユーザーの利便性を妨げない」のすべてのトピックを確認するには、フル バージョンのモバイル サイトを改善するためのチェック リストをご覧ください。

手順 2: 簡単にタスクを完了できるようにする
  • robots.txt によりアクセスを制限しているリソース(CSS、JavaScript)の制限を解除します。
  • あなたのモバイルサイトの実装に適した検索エンジンのベスト プラクティスを実装します。
  • サイトの一般的なモバイル ペルソナ ワークフローを最適化する

Google ウェブマスター ツールと Google アナリティクスを使用して一般的なモバイル ワークフローを最適化する方法(スライド

手順 3: ユーザーをファンに変える
  • モバイル アプリの検索への統合を考慮する(※ 2014/3/5 現在のところ日本では未対応です) | お知らせ情報(英語)
  • 価値を提供するための新しい方法をブレーン ストーミングする
  • 実際の店舗などにおいて買い物客がどのようにモバイルを使用するか、という点を考慮して制作します。| ビジネス ケース(英語)
  • スマートフォンの GPS、カメラ、加速度計を活用します。
  • 共有など、ソーシャルを活用します。| ビジネス ケース(英語)
  • スワイプ、シェイク、タップを使用した直感的かつ楽しい体感機能の実装を検討します。

スマートフォン用のコンテンツをクロールするための新しい Googlebot ユーザーエージェント

Google では数年にわたって、従来の携帯電話(フィーチャーフォン)とスマートフォンのコンテンツに対して別々のクローラーを使用してクロールとインデックス登録を行ってきました。こうしたモバイル固有のクローラーはすべて Googlebot-Mobile と呼ばれていました。しかし、フィーチャーフォンとスマートフォンでは端末機能がかなり異なっており、フィーチャーフォンのクロールやインデックス登録をブロックするつもりが誤ってスマートフォンのクロールやインデックス登録をブロックしてしまったという報告もウェブマスターから寄せられていました。この曖昧さにより、一部サイトのスマートフォン向けコンテンツのインデックス登録や、それらのサイトがスマートフォン向けに最適化されていることの認識が難しくなってしまっていました。

スマートフォン用の新しい Googlebot

状況を明確にし、ウェブマスターの皆様がより的確に管理できるようにするために、Google ではスマートフォン用の「Googlebot-Mobile」ユーザーエージェントの使用を 3~4 週間後に中止します。それ以降、スマートフォン用のユーザーエージェントはシンプルに「Googlebot」となりますが、ユーザーエージェント ストリングのどこかに「mobile」という単語は引き続き残ります。新旧のユーザーエージェントは次のとおりです:

スマートフォン用の新しい Googlebot ユーザーエージェント:
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

まもなく使用を中止するスマートフォン用の Googlebot-Mobile ユーザーエージェント:
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

この変更が影響するのはスマートフォン用の Googlebot-Mobile のみです。標準の Googlebot のユーザーエージェントには変更ありません。残りの 2 つの Googlebot-Mobile クローラーのユーザーエージェント ストリングでは引き続きフィーチャーフォン端末が参照されます。これらのクローラーは次のとおりです:

標準の Googlebot ユーザーエージェント:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

フィーチャーフォン用の 2 つの Googlebot-Mobile ユーザーエージェント:
  • SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
  • DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
ウェブマスター ツールの Fetch as Google 機能を使用してサイトのテストを実施できます。また、ヘルプセンターでは、Google のクローラーの一覧をご確認いただけます。

クロールとインデックス

ユーザーエージェントのアップデートでは次の点にご注意ください。スマートフォン クローラー用の新しい Googlebot では、Googlebot-Mobile ではなく Googlebot の robots.txt、robots メタ タグ、HTTP ヘッダーの指定が適用されます。たとえば、新しいクローラーが導入されている場合、以下の robots.txt の指定によって、スマートフォン用の新しい Googlebot ユーザーエージェントと標準の Googlebot ユーザーエージェントによるすべてのクロールがブロックされます:

User-agent: Googlebot
Disallow: /

以下の robots.txt の指定によって、Google のフィーチャーフォン クローラーによるクロールがブロックされます:
User-agent: Googlebot-Mobile
Disallow: /

Google の分析では、このアップデートにより、ウェブマスターはコンテンツのクロールとインデックス登録をより管理しやすくなる一方で、URL に及ぼす影響は 0.001% 未満という結果になりました。ご不明な点がありましたら、以下をご覧ください:

モバイル向けに別サイトを持っている場合の検索クエリ データが改善されました

ウェブマスター ツールの「検索クエリ」機能が、モバイル向けに別の URL を用意しているサイト(モバイル向けに m.example.com、デスクトップ向けに www など)に関して改善されました。2013 年 12 月 31 日より、モバイル サイト側* の「検索クエリ」で、フィルタを「携帯電話」に設定した場合、以下の両方が表示されます:
  • あなたのモバイル向けページが、携帯端末上のブラウザーの検索結果に表示された検索クエリ
  • リダイレクトスキップが発生した検索クエリ。この場合、検索結果上ではデスクトップ版の URL が表示されますが、それをクリックしたユーザーは直接モバイル版へと送られます(サーバー サイド リダイレクトのレイテンシから解放されることになります)。
リダイレクトスキップに関する情報が、モバイル サイト側で表示されています

この改善の前は、リダイレクトスキップが発生している検索クエリもデスクトップ向けのサイトに加算されていました。この変更により、表示回数やクリック数、CTR などの情報がモバイル サイト側で表示されることになりますので、モバイル向けの統計がより理解しやすくなりました。

モバイル向けに別の URL を用意する場合のベスト プラクティス


モバイル向けに別の URL を用意する場合は、以下をおすすめします。
  • デスクトップ向けサイトの側では、対応するモバイル向け URL へ向いた link rel=”alternate” タグを設置してください。これは、Googlebot があなたのモバイル向けサイトを発見する助けになります。
  • モバイル向けサイトの側では、対応するデスクトップ向け URL へお向いた rel=”canonical”  タグを設置してください。
  • ユーザー エージェントに応じて自動的にサーバー側でリダイレクトを行なっている場合は、HTTP Vary: User-Agent ヘッダーを利用してください。
  • ウェブマスター ツールでは、デスクトップ向けサイトとモバイル向けサイトの両方を登録しましょう。このことにより、各サイトのトラブルシューティングがより捗ります。
  • * モバイル向けサイトの所有権が確認されている場合

    ウェブマスター ツール新機能:スマートフォン向けクロール エラー

    スマートフォンで検索を行っていると、サイト側の 設定ミス の結果として、欲しい情報が発見されないことがあります。しばしば見られるのは、デスクトップでは問題なく動作する一方、スマートフォンではエラー ページが表示されてしまったり、関係のないページへリダイレクトされてしまう、といったサイトです。Googlebot からはクロール エラーとして認識されるこれらの問題は、ユーザー体験上、大きな問題になる場合があり、以前このブログでもご案内した、スマートフォン向け検索結果における ランキングの変更 のきっかけでもあります。

    本日より、ウェブマスター ツール内の クロール エラー 機能で、これらの問題を特定することができるようになりました。新たに設けられた「スマートフォン」タブには、スマートフォン向け Googlebot よって検出されたエラーが表示されています。


    ここで表示されるエラーには、以下のようなものがあります。
    • サーバー エラー: Googlebot があるページをクロールした際、HTTP エラー コード を返された場合に表示されます。
    • ソフト 404: Googlebot が 404 を返された、あるいは返されたコンテンツが ソフト エラー ページ であると判断された場合に表示されます。
    • 間違ったリダイレクト: デスクトップ向けのページが、スマートフォン ユーザーを検索クエリとは 無関係なページへとリダイレクト してしまう場合に表示されます。特に、スマートフォン向けサイトのトップ ページへのリダイレクトが多く見受けられます。
    • ブロック: サイトの robots.txt が、スマートフォン向け Googlebot を ブロックしている際 に表示されます。通常、このようなスマートフォンに特化した振る舞いはエラーを招きます。サーバーの設定を再度ご確認ください。
    ウェブマスター ツールに表示されるエラーを修正することにより、よりよいユーザー体験を提供でき、Google のアルゴリズムもあなたのコンテンツをよりよくインデックスすることができます。スマートフォン向けのサイトの構築方法 や、しばしば見られる間違い の修正方法もご確認ください。ご質問は ウェブマスター フォーラム へお願いいたします。

    アプリもウェブサイトと同じようにインデックスに登録されるようになります

    本機能の日本での提供予定は未定ですが、日本のウェブマスターのみなさまから高い関心が寄せられましたので、その概要をご紹介したいと思います。


    スマートフォンで検索をしていると、スムーズな利用を妨げるような場面に遭遇することがあります。たとえば、ウェブページからアプリへの切り替え、あるいは逆にアプリからウェブページへの切り替えが必要になることがありますが、その際にリダイレクトやポップアップ ダイアログが出現して、余計なスワイプやタップが要求されることが多々あります。もし、ウェブサイト上のコンテンツであろうと、アプリ内のコンテンツであろうと、あなたが提供するコンテンツについて、 ウェブサイト上で閲覧するか、アプリ上で閲覧するかユーザーが検索結果上で直接選べるようになったら良いと思いませんか?

    Google は先日、Google 検索の新機能「App Indexing」を発表しました。この機能は、ウェブマスターからの技術的なインプットを活用して、ウェブサイトとモバイル アプリケーションをシームレスに横断するユーザー エクスペリエンスを実現します。

    今回、これまでウェブサイトをクロールしてインデックスに登録してきたのと同じように、Android アプリ内のコンテンツも Googlebot がインデックスに登録することが可能となりました。ウェブマスターは、どのアプリ コンテンツを Google のインデックスに登録させたいかを、現在ウェブページで行っているように、既存のサイトマップ ファイルやウェブマスター ツールを通じて指定できます。ウェブページ コンテンツとアプリ コンテンツ両方がインデックスに登録されると、検索クエリと関連性があると思われ、ユーザーが対象アプリをインストールしている場合、アプリ コンテンツに直接つながるディープ リンクが Google 検索の検索結果上に表示されるようになります。ユーザーがディープ リンクをタップすると、アプリが起動し、対象のコンテンツに直接移動します。たとえば、カリフォルニア州マウンテンビューの不動産物件(home listings)を検索した場合、次のようになります。



    Google では現在、デベロッパー グループと App Indexing のテストを行っています。今後数週間のうちに、米国で Android 搭載端末を使用するログイン ユーザーを対象として、アプリ コンテンツのディープ リンクが Google 検索の検索結果に表示される予定です。提供している Android 向けアプリをインデックスに登録するための手順は簡単です。

    1. まずは興味があることを Google にお知らせください(英語)。
      Google では、この新機能を数多くのウェブサイトとアプリに普及させようと取り組んでいます。ぜひご協力ください。
    2. 提供しているアプリで、ディープ リンクを有効にしてください(英語)。
    3. サイトマップ ファイルか、サイト ページのリンク要素を利用して、代替アプリ URI に関する情報をご提供ください。
    実装や登録の詳細については、Google デベロッパー サイト(英語) をご覧ください。

    スマートフォンサイトの読み込み速度を改善するために

    多くのユーザーがその手軽さや利便性から、スマートフォンからの検索を行っていますが(英語)、携帯端末向けのページではその読み込みに 平均して 7 秒以上かかっていることがわかっています(英語)。この読み込み時間が 1 秒以下になることはユーザーにとってもウェブマスターにとっても理想でしょう。そこで今回、ウェブマスターの方々へ、携帯端末向けページのレンダリングを高速化するための ガイドライン(英語、日本語も準備中です)を公開しました。また、このガイドラインにもとづき、PageSpeed インサイト ツール も更新しました。

    ”above the fold” コンテンツを優先的に扱う
    たとえば こちらのレポート(英語)によると、ページの読み込みに 1 秒以上かかった場合、ユーザーの集中が途切れてしまう傾向にあるようです。サイトの訪問者により良いブラウジング体験を提供してサイトを利用してもらうため、今回策定したガイドラインではいわゆる ”above the fold” と呼ばれる、ユーザーが最初に目にする、スクロールしなくても表示されるエリアのコンテンツを少しでも早く提供する(その他のコンテンツはバックグラウンドで読み込みを進める)ことを重視しました。また “above-the-fold” エリアをレンダリングするのに必要な HTML や CSS, JavaScript は非常に重要なレンダリング パス(critical rendering path(英語))として知られています。

    携帯端末上でのユーザーに最初に見えるコンテンツの読み込み時間を 1 秒未満にするためのベストプラクティスをここでご紹介します。
    • 200 ms 以内にレスポンスを返すようにする
    • リダイレクトの数は極力少なくする
    • 最初のレンダリング時のデータのやり取りを極力少なくする
    • ユーザーに最初に見えるコンテンツを表示するのに必要となる JavaScript および CSS を外部参照せずにインライン化する
    • ブラウザのレイアウト、レンダリング時間を考慮に入れる (200 ms)
    • JavaScript の実行とレンダリング時間を最適化しておく
    今回公開したガイドライン では上記のような項目についてより詳しくご紹介していますのでぜひ御覧ください。また、ご自身のサイトでの改善状況については PageSpeed インサイト ツール でご確認いただけます。

    ご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

    スマートフォン向け検索でのランキングの変更について

    スマートフォン ユーザーは、インターネット ユーザーの中でも成長が非常に早く、重要なユーザー層となってきています。そして Google ではスマートフォンから Google を利用するユーザーにデスクトップ環境と変わらない、リッチなウェブ体験を提供したいと考えています。こうした携帯端末向けのリッチなウェブ サイト作成のため、「携帯端末に最適化されたウェブサイトの構築方法(推奨事項)」や「スマートフォン サイトによく見られるミス」といった情報をご提供してきました。

    こうしたスマートフォン サイトによく見られるミスを防ぐと、スマートフォン ユーザーはあなたのサイトを快適に閲覧して、サイトのコンテンツをさらに閲覧するようになるかもしれないですし、検索ユーザーは探している情報をすぐに見つけることができるようになります。スマートフォン ユーザーへの更なる検索体験の向上と、スマートフォン環境での閲覧の支障を減らすため、Google では近日中に、誤った設定をおこなっているスマートフォン向けサイトに影響のある、いくつかのランキングの変更を予定しています。

    以下では、最も多く見られる設定の誤り、ミスとその解消法をご紹介します。

    間違ったリダイレクト

    ウェブサイトで、デスクトップ ユーザー向けページとスマートフォン ユーザー向けページに対してそれぞれ別の URL を用意しているサイトも多いかと思います。ここで取り上げる間違ったリダイレクトは、デスクトップ ユーザー向けページに訪れたスマートフォン ユーザーをスマートフォン向けサイトにリダイレクトする際に、関連性の低いページにリダイレクトしてしまう、というものです。典型的な例としては、 デスクトップ ユーザー向けページを訪れたスマートフォン ユーザーをすべてスマートフォン向けサイトのトップ ページにリダイレクトするよう設定しているという、ケースがあります。以下の図にある、赤色のリダイレクトは間違ったリダイレクトと考えられます。


    このようなリダイレクト設定は、ユーザーのスムーズなサイト閲覧を阻害し、そのユーザーがサイト上のページを見ることをやめて違うサイトへと離脱しまうことにつながるかもしれません。たとえユーザーがサイトから離れなかったとしても関連性の低いページへのリダイレクトは、特に回線速度の遅いモバイル ネットワークを使っているようなユーザーにとって、とてもわずらわしいものです。こうした間違ったリダイレクト設定はウェブ ページや動画、その他あらゆるものを探しているユーザーのリッチな検索体験を妨げるものですので、ウェブ検索や、他の種類の検索(イメージ検索、ビデオ検索など)において今回のランキングの変更の影響が及びます。

    関連性の低いリダイレクト設定を避ける方法は簡単です:単純に、あるデスクトップユーザー向けページを訪れたスマートフォン ユーザーをそのページに対応したスマートフォンユーザー向けページへとリダイレクトさせるだけです。もしそのコンテンツがスマートフォン向けに最適化された形で存在していない場合でも、関連性の低いページにリダイレクトするよりも、リダイレクトをしないでそのコンテンツが載ったデスクトップ環境向けページを表示させる方がよいでしょう。

    リダイレクトについてはより詳しい情報を「リダイレクトとユーザー エージェントの検出」でご紹介しています。また、デスクトップ ユーザー向けページとスマートフォン ユーザー向けページに対してそれぞれ別の URL を用意している場合は「推奨事項の詳細」もご確認ください。

    スマートフォンでのみエラーが発生する

    デスクトップ環境でアクセスするとコンテンツが表示される URL に、スマートフォンでアクセスするとエラー ページを返すようなサイトがあります。これは様々な状況によって発生しますが、よく見られるケースとしては以下のものがあります。

    • ユーザーが携帯端末からデスクトップ向けページにアクセスしていることを識別した際に、404 ページや ソフト 404 ページ を表示しているケースがありますが、それは避けましょう。そのページに対応するスマートフォン向けページが存在する場合は、そのページへリダイレクトするようにしましょう。
    • スマートフォン向けページ自体がエラー ページではないことを確認してください。また、コンテンツがスマートフォン向けに最適化されていない場合は、デスクトップ向けページを表示してください。エラー ページを表示されるよりも、(どのような形であれ)探していたコンテンツが表示される方がはるかによいユーザー エクスペリエンスとなります。
    • Googlebot-Mobile を不適切に扱わないようにしてください。典型的なミスとしては、デスクトップ向けサイトを訪れたスマートフォン向け Googlebot-Mobile を フィーチャー フォン向けに最適化されたサイト へと誤ってリダイレクトさせているために、さらにそこから デスクトップ向けサイトへとスマートフォン向け Googlebot-Mobile をリダイレクトさせ、もとに戻らせてしまうというものがあります。結果、リダイレクトの無限ループが発生し、Google 側ではエラーとみなしてしまうことになります。

      このミスを防ぐことも簡単です:
      すべての Googlebot-Mobile ユーザー エージェント は特定のモバイル デバイスのユーザー エージェント文字列を含みます。ウェブマスターは、Googlebot-Mobile ユーザーエージェントを特別扱いせず、それらのデバイスに対するのと同様に取り扱うようにしてください。例えば、スマートフォン向け Googlebot-Mobile は現在、iPhone のユーザー エージェント文字列を含むので、iPhone ユーザーに対するのと同じレスポンスを返してください。
    • 多くのウェブサイトがデスクトップ環境ではうまく再生できるのにスマートフォン端末で再生できない動画をページ上に埋め込んでいるのをよく見かけます。 例えば、再生に Adobe Flash が必要なコンテンツは iPhone やバージョン 4.1 以上の Android 端末で再生できません。

    ここでは 2 つのよく見られるミスをご紹介しましたが、ウェブマスターにとって、「スマートフォン サイトによく見られるミス」で挙げているミスを防ぐことはとても重要です。可能な限り多くの種類のモバイル端末やオペレーション システム、またはそれらのエミュレーターで、掲載した動画の閲覧も含めたテストを行ってみてください。そうしたテストをすることで、モバイル ウェブがさらにリッチになり、サイトを訪れるユーザーがハッピーとなり、さらには検索ユーザーやあなたのサイトの訪問ユーザーがコンテンツをフルに楽しめることにつながります。

    ご質問がありましたら ウェブマスター ヘルプフォーラム にお寄せください。


    Original version: Changes in rankings of smartphone search results

    Google+: モバイル サイトでのコンテンツおすすめ機能

    サイト内の優れた記事を見つけやすいようにすると、ユーザーに喜ばれるだけでなく、サイトにより親しんでもらったり、より活発な利用をしてもらうことにつながります。Google では、適切なコンテンツを適切なタイミングでモバイル サイトからおすすめできるよう、Google+ と Google 検索の機能の統合を進めています。

    たとえば Forbes のサイト訪問者は、作者情報 シグナルやさまざまな Google+ アクティビティ(+1 や共有など)に基づいて Forbes サイト内の他のおすすめ記事を簡単に見つけることができます。おすすめコンテンツの関連性を高めるため、おすすめコンテンツは訪問者がその時に閲覧しているページに基づいて決定されます。また、おすすめコンテンツの情報は、詳しく知りたいユーザーがタップした場合のみ画面下部に表示されるため、ブラウジングを妨げることはありません。仕組みは次のようになっています:




    おすすめコンテンツはサイトの訪問者が Google にログインしているかどうかに関係なく表示できますが、Google にログインしている訪問者には、訪問者が設定しているサークル内の友人等が +1 したコンテンツや共有したコンテンツが表示されます。


    これらのおすすめコンテンツの追加や設定を簡単に行うための方法も用意されています。モバイル サイトに JavaScript を 1 行追加するだけで、ウェブ エディタを使わずに、Google+ ページ ダッシュボードの [サイト向け] セクションで変更を加えることができます。


    この最新の機能を試してみるには、お気に入りの iOS 搭載端末や Android 搭載端末で Forbes サイト内のいずれかの 記事ページ にアクセスしてみてください。この機能については、デベロッパー ドキュメント(https://developers.google.com/+/features/recommendations)でも詳しくご紹介しています。

    Google では、Google+ のコンテンツおすすめ機能と Google+ ログイン機能についてより多くの方に使って頂くための改善を計画しており、先日開催した Google I/O では Google+ ログイン機能を利用している 50 社以上の企業の中からいくつかの事例について詳しくお話を伺うことができました。

    「Google+ ログインは、当社の Android アプリで最も利用されているソーシャル ログイン機能です。ソーシャル ログイン経由のユーザーの 41% が Google+ ログイン経由です。」
    - Tom Grinstead、Guardian News プロダクト マネージャー
    「Google+ ログインの統合による最初の成果には大変満足しています。当社の分析では、ウェブ、Android、さらには iOS でも、Google からの膨大なログインがその他の一般的なソーシャル ネットワークを圧倒していることは明らかです。この成功により、他のログイン ソースを廃止して、この新しく成長著しいチャネルをさらに活用していくことを検討しています。」
    - Haisoo Shin、Fancy エンジニアリング ディレクター

    「携帯端末に最適化されたウェブサイトの構築方法」日本版をご紹介します

    スマートフォンの普及やタブレット ユーザーの急激な増加に伴い、みなさんのサイトのユーザーのアクセス環境も大きく変わってきているのではないでしょうか。Google は、これまで モバイルサイトの構築方法 について様々な情報を公開して来ましたが、本日は スマートフォン最適化の記事 の中でご紹介していた 「携帯端末に最適化されたウェブサイトの構築方法」について日本語版をご用意しましたのでご紹介します。

    このサイトではスマートフォンやタブレット、そして従来の携帯電話を組み合わせたサイトについて Google が推奨する構築方法や Tips を、一箇所にまとめています。スマートフォンやタブレットを組み合わせたサイトの構築方法に関心のある方は、ぜひご覧ください。

    また、今回 日本語 以外にも アラビア語ポルトガル語オランダ語フランス語ドイツ語イタリア語ポーランド語ロシア語中国語(簡体)スペイン語 にも対応しましたので必要に応じてセレクトメニューより言語を選択してご利用いただければと思います。

    この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

    レスポンシブ・ウェブデザイン – メディアクエリのパワーを使いこなす

    データを重要視している Google では、アクセス解析を行い自分たちのウェブサイトを分析することに多くの時間を費やしています。みなさんも同じように分析をされてみると、最近の傾向としてモバイル端末からのトラフィックが増加していることに気が付くでしょう。この 1 年、多くの主要なサイトではスマートフォンやタブレットからのページ ビューの割合が大幅に増加しました。つまり、多くの人が最新の HTML や CSS、JavaScript に対応したブラウザでサイトにアクセスしているということです。しかしこれは同時に、例えば幅が 320px というような狭い画面に表示されているということも意味します。

    Google では、アクセシビリティ (英語) の観点から、すべてのユーザーが、心地よくウェブページを閲覧できることを目指しています。モバイル用のウェブサイトを作るのか、あるいはデスクトップとモバイル環境の両方でうまく表示されるように、既存サイトや新規サイトを適合させるのかという点について Google は深く検討してきました。複数のサイトを用意すれば、ハードウェアごとに最適化したサイトを提供できます。しかし、1 種類のサイトで両環境に対応できるなら、正規化 された URL を保持できる上、複雑なリダイレクトを避け、ウェブ アドレスの共有をよりシンプルにできます。このような保守性の観点から、Google では、1 つのページをモバイル端末とデスクトップの両方に対応させるよう、次のガイドラインを満たす方法の検討を始めました。

    1. ページは、どの画面解像度でも読みやすく表示される
    2. どの端末でも表示できるようにコンテンツをひとかたまりごとにマークアップする
    3. ウィンドウサイズにかかわらず、水平方向のスクロール バーは表示しないようにする

    画像サイズを変更すると、コンテンツは縦に並び、ナビゲーションは適切に変化し、画像はリサイズされる
    - Chromebooks (英語)
    それでは、Google の実施している施策と、そこから得られた発見をご紹介します。

    実装

    まずなによりも、、シンプルでセマンティックなマークアップを用いることです。これによって、レイアウトの変更が必要な場合でも、コンテンツがうまくリフローするような柔軟性をページに与えることができます。サイトを リキッド レイアウト (英語) なスタイルにしたなら、既にモバイル対応の第一歩を踏み出していると言えるでしょう。コンテナ要素には width を指定するのではなく、代わりに max-width を指定します。同じく height の代わりに min-height を使います。こうすることで、大きめのフォントや複数行に渡るテキストの場合でも、コンテナからはみ出すことがなくなります。固定幅の画像によってリキッド カラムが強制的に広げられた状態になるのを防ぐため、下記の CSS ルールを適用します。
    
    img {
      max-width: 100%;
    }
    
    リキッド レイアウトから始めるのはよい方法ですが、精巧さに欠けるところがあります。ありがたいことに メディアクエリ (英語) には現在、ほとんどのモバイル端末や IE9+ などの最新ブラウザが対応しています (英語)。メディアクエリによって、「モバイル環境ではグレードをうまく落としたサイト」になるか、「合理的な UI をうまく利用してグレードアップしたサイト」になるか、大きな違いが生じます。しかしまずは、スマートフォンがウェブ サーバーからどのように認識されているのかを考慮する必要があります。

    viewport メタ タグ

    1 ピクセルが 1 ピクセルでなくなるのはどんなときでしょうか。それはスマートフォン上で表示されるときです。初期設定では、スマートフォンのブラウザは、高解像度のデスクトップ ブラウザと同じような挙動を見せ、まるでデスクトップのモニターで表示しているかのようにページをレイアウトします。ズームインしなければ判読できない小さな文字の「オーバービュー モード」で表示されるのはそのためです。デフォルトのビューポート幅 (英語) は、画面の実際の物理的なピクセル (英語) の数にかかわらず、初期設定の Android ブラウザでは 800px、iOS では 980px です。 より読みやい縮尺でブラウザにページを表示させるには、 viewport メタ タグを使用する必要があります。
    <meta name="viewport" content="width=device-width, initial-scale=1">
    
    モバイル端末の画面解像度は多岐にわたりますが、最新のスマートフォン用ブラウザの多くは現在、320px ほどの標準的な device-width であるとされています。モバイル端末が実際には物理的に 640px の場合、320px 幅の画像は、画面の横幅に合ったサイズに変更され、その過程で倍の数のピクセルを使用します。小さい画面ではテキストがより鮮明に見えるのはこのためでもあります。標準的なデスクトップのモニターに比べるとピクセルの密度が倍になっているのです。
    viewport を指定するメタ タグで width = device-width を設定する利点は、ユーザーがスマートフォンやタブレットの向きを変えたときに表示を更新してくれる点です。これをメディアクエリと組み合わせて用いることで、ユーザーが端末を回転させた時のレイアウトを微調整できます。
    
    @media screen and (min-width:480px) and (max-width:800px) {
      /* ランドスケープモードのスマートフォン、ポートレートモードのタブレットまたはウィンドウ幅の狭いデスクトップ向けのスタイル
      */
    }
     
    @media screen and (max-width:479px) {
      /* ポートレートモードのスマートフォン向けのスタイル */
    }
    
    実際には、サイトの流れや各種端末上での表示に応じて、異なるブレークポイントを使用する必要があるかもしれません。また、メディアクエリの orientation を使って、ピクセルで幅などのサイズを指定することなしに特定の向きに対応させることも可能ですが、ブラウザが対応している場合 (英語) に限ります。
    
    @media all and (orientation: landscape) {
      /*ランドスケープモード向けのスタイル */
    }
     
    @media all and (orientation: portrait) {
      /*ポートレートモード向けのスタイル */
    }
    
    コンテンツは縦に並び、画像は縮小して表示する
    - Google 選ぼう 2012

    メディアクエリの例

    2012 年春、Google について のページをリニューアルしました。リキッド レイアウトの設定以外にも、メディアクエリをいくつか追加して、タブレットやスマートフォンなどの小さな画面での閲覧性を向上させました。
    さまざまなデバイスの解像度に対応させる代わりに、比較的広いブレークポイントを設定するという方法を取りました。1024px を超える画面解像度では、Google が標準で使っている 12 カラム グリッドに従って、元々デザインした通りにページを表示します。801px から 1024px の画面解像度では、リキッド レイアウトによって、若干圧縮されたバージョンが表示されることになります。
    画面解像度が 800px まで下がる場合に限り、主要なコンテンツとはみなされないコンテンツはページの下部へと送られます。
    
    @media screen and (max-width: 800px) {
      /* この場合のみ適用されるスタイル */
    }
    
    
    最後に記述するメディアクエリにはスマートフォンを想定した幅を指定します。
     
    @media screen and (max-width: 479px) {
      /* この場合のみ適用されるスタイル */
    }
    
    ここまで来たら、もう大きな画像はロードしませんし、コンテンツ ブロックも縦に並べるだけです。また、コンテンツの項目の間に少し余白を足して、それらが別々のセクションであることがわかりやすくなるようにします。 こういったいくつかのシンプルな方策によって、さまざまな端末上でサイトを利用できるようにしました。
    コンテンツは縦に並び、大きな画像は表示しない
    - Google について

    まとめ

    モバイル端末や狭いビューポートでもサイトをアクセスシブルにする、シンプルで簡単な「たったひとつの冴えたやりかた」のようなものはないということを覚えておきましょう。リキッド レイアウトは、第一歩としては非常に優れていますが、デザインにおける何らかの妥協が必要となる場合があります。メディアクエリは、さまざまな端末上での表示をより洗練されたものにするのに役立ちはしますが、トラフィックの 25% (英語) は、現在この技術をサポートしていないデスクトップ ブラウザからのアクセスであることや、ある程度 パフォーマンスへの影響 (英語) が生じることにも注意しなければなりません。 また、サイト内で趣向を凝らしたウィジェットを使用している場合、細かいコントロールが難しいタッチ端末では、マウスほどの素晴らしい挙動が望めない場合があります。
    ポイントは、より早い段階でより頻繁にテストを行うことです。実際にスマートフォンやタブレットから自分のサイトを使ってみることも大変重要です。本物の端末でテストできない場合は、Android SDK (英語) や iOS Simulator (英語) を使用してください。友人や会社の同僚に頼んで、彼らの端末からサイトを表示してもらい、彼らがどのように操作するのかを観察するのもよいでしょう。
    モバイル ブラウザにサイトを対応させることは、新たなトラフィックを得ることにつながります。そして、「それらにどのように対応していくか」という課題は、多くのウェブマスターにとって、取り組みがいのある新たな課題と言えるでしょう。
    下記のサイトで Google におけるレスポンシブ ウェブ デザインの例をご覧いただけます。

    ご質問やご意見がありましたら ウェブマスター ヘルプフォーラム までお知らせください。

    2013 年 4 月追記:「携帯端末(主にスマートフォン)向けサイトの構築方法の基本的な考え方について」をテーマにウェブマスター ハングアウトを実施しました。



    タブレット端末ユーザーにはフルサイズのウェブを表示しましょう

    スマートフォン向けに最適化されたウェブサイトの構築について、Google がお勧めする方法を公開して以来、ウェブマスターの皆さんから「タブレット端末はどう取り扱うのがよいのか」という質問をよくいただきます。これは Android 向けアプリのデベロッパーの皆さんが直面する問題とよく似ていますので、「Building Quality Tablet Apps (高品質なタブレット用アプリの構築方法)」 (英語)に関するガイドをお読みいただくことから始めるとよいでしょう。

    タブレット向けに最適化された、検索エンジンと相性の良いウェブサイトの構築方法については、Google からは具体的にお勧めしていることはありませんが、スマートフォンとタブレット両方のユーザーに対応するウェブサイトの構築方法に関してはいくつかアドバイスがあります。

    タブレットからサイトにアクセスするユーザーのことを考えるとき、端末のことだけでなく、ユーザーが何を期待しているかを考慮することが大切です。スマートフォンに比べ、タブレットは大きなタッチ スクリーンを持ち、通常は Wi-Fi 接続を使用します。タブレットはデスクトップ PC やノート PC と同等の充実したブラウジング体験を、持ち運びやすく軽量で、通常、より使いやすい形態で提供するものです。つまり、タブレット向けに最適化されたコンテンツを提供している場合を除き、ユーザーはスマートフォン版のサイトではなく、PC 版のサイトが表示されることを期待しているのです。

    The NY Times は閲覧端末がモバイルか、より大きなサイズの Android デバイスのどちらであるかを認識し、タブレット端末に最適化したページの表示を行っています。

    Google では、スマートフォン向けに最適化されたサイトに関して、レスポンシブ ウェブ デザイン (英語) を使用すること、すなわち、あらゆる端末に対応する 1 つのサイトを用意することをお勧めしています。皆さんのサイトが、この推奨に従ってレスポンシブ ウェブ デザインを採用している場合は、さまざまなタブレット端末上でサイトの表示をテストし、タブレット端末も適切に対応されていることを確かめてください。スマートフォンの場合と同様に、さまざまな端末サイズや画面解像度でテストする必要があります。

    このほかよく用いられるのは、PC 向けとスマートフォン向けに別々のサイトを用意し、ユーザーを該当する方のサイトにリダイレクトするという構成です。この構成を採用している場合は、タブレット ユーザーを誤ってスマートフォン版のサイトにリダイレクトしないように注意してください。

    Android スマートフォンとタブレットを識別する

    Android 端末については、ブラウザが提供するユーザー エージェント文字列を使えば、スマートフォンとタブレットとを容易に識別できます。Android のスマートフォンとタブレットのどちらも、ユーザー エージェント文字列には「Android」という単語が含まれていますが、ユーザー エージェント文字列に「Mobile」が含まれているのはスマートフォンの場合のみです。

    まとめると、ユーザー エージェントに「Mobile」が含まれていない Android 端末はすべてタブレット(あるいはその他の大きな画面を持つ) 端末ですので、PC 版サイトで対応するのが良いでしょう。

    例えば、Galaxy Nexus スマートフォン上の Chrome が提供するユーザー エージェント文字列は次のとおりです。

    Mozilla/5.0 (Linux; Android 4.1.1; Galaxy Nexus Build/JRO03O) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

    また、Galaxy Nexus 上の Firefox が提供するユーザー エージェントは次のようになります。

    Mozilla/5.0 (Android; Mobile; rv:16.0) Gecko/16.0 Firefox/16.0

    Nexus 7 上の Chrome が提供するユーザー エージェントは次のようになります。

    Mozilla/5.0 (Linux; Android 4.1.1; Nexus 7 Build/JRO03S) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19

    同じく Nexus 7 で、Firefox の場合は次のとおりです。

    Mozilla/5.0 (Android; Tablet; rv:16.0) Gecko/16.0 Firefox/16.0

    Galaxy Nexus のユーザー エージェントには「Mobile」が含まれているため、スマートフォン向けのサイトで対応し、一方 Nexus 7 には PC 版のサイトを表示させます。

    皆さんが、タブレット向けに最適化されたより高品質なウェブサイトを構築するのに、この記事がお役に立てば幸いです。ご質問がありましたら、ウェブマスター ヘルプ フォーラム までお寄せください。