アプリバナーでよりモバイル フレンドリーなウェブページを

ユーザーが携帯端末で検索した場合、探している情報がアプリにある場合もウェブページにある場合も、関連性の高い検索結果がユーザーに表示される必要があります。Google では最近、検索ユーザーがより簡単にアプリモバイル フレンドリーなウェブページを見つけられるよう対応しました。しかし、ユーザーが携帯端末上で検索結果をタップすると、コンテンツの大部分を覆い隠すアプリ インストール インタースティシャルが表示され、アプリのインストールを求められる場合があります。Google の分析によると、これは検索エクスペリエンスを低下させ、ウェブページのコンテンツを確認したいユーザーの利便性を妨げるものとなっています。

Google では、本日付けでモバイル フレンドリー テストを更新し、検索結果ページから移動した先のコンテンツの大部分を覆い隠すアプリ インストール インタースティシャルをできるだけ使わないようにすることを推奨します。Search Console のモバイル ユーザビリティ レポートには、このようなインタースティシャルの問題があると診断されたサイト内のページ数が表示されます。

11 月 1 日以降、検索結果ページから移動した際にコンテンツの大部分を覆い隠すアプリ インストール インタースティシャルが表示されるモバイル ウェブページは、モバイル フレンドリーとは見なされなくなります。これ以外のインタースティシャルに影響はありません。アプリ インストール インタースティシャルの代わりとして、各ブラウザからも、アプリのインストールを促進するよりユーザー フレンドリーな方法が提供されています。

コンテンツの大部分を覆い隠すアプリ インストール インタースティシャルは検索エクスペリエンスを低下させる

押し付けがましくないアプリ インストール バナーが望ましい


アプリ インストール バナーは Safari(スマートバナー)と Chrome(ネイティブ アプリ インストール バナー)でサポートされています。バナーであれば、一貫したユーザー インターフェースを提供しながらアプリのインストールを促進でき、ユーザーもブラウジング エクスペリエンスを自分で制御できます。ページ コンテンツを隠してしまうことがなければ、独自のアプリ インストール バナーを実装することもできます。

ご不明な点がありましたら、ウェブマスター プロダクト フォーラムでお気軽にご質問ください。

Google+: アプリ ダウンロードのインタースティシャルに関する事例紹介

多くのモバイル サイトでは、プロモーション用のアプリ インタースティシャルを使用して、ユーザーにネイティブ モバイル アプリのダウンロードを宣伝しています。アプリによっては、ネイティブ版のほうがユーザー エクスペリエンスが優れており、ブラウザでは簡単にアクセスできない端末機能を使用できるものもあります。そのため、多くのアプリ所有者は自分のオンライン プロパティやサービスのネイティブ版をユーザーに宣伝したいと考えています。しかし、どれくらい積極的に宣伝すべきかは明らかではありません。ページ全体に表示されるインタースティシャルは、ユーザーがアクセスしたいコンテンツの邪魔になっているかもしれません。


そこで Google では、Google+ モバイル ウェブにおけるインタースティシャルの利用状況を詳しく調査することにしました。Google社内でのユーザー エクスペリエンス調査では、インタースティシャルが妨げになっていることがわかりました。昨年の IO でもジェニファー・ゴーブがこの話題を取り上げ、ユーザーの不満が高かったと語っていました。

インタースティシャルは削除すべきと思われましたが、Google ではデータに基づいて意思決定しているため、まずはインタースティシャルが Google ユーザーにどのような影響を与えているかを調べました。その結果、次のようなことがわかりました。

  • Google のインタースティシャル ページにアクセスしたユーザーのうち 9% が「アプリを入手」ボタンを押していました(このユーザーのうち数パーセントは既にアプリをインストールしているか、アプリストアでのダウンロードを完了しませんでした。
  • Google のページから離れたユーザーは 69% でした。これらのユーザーはアプリストアを訪れることもなく、Google モバイル サイトの閲覧も中止しました。

キャンペーンの CTR が 9% というのは良い結果のようですが、Google ではそれよりも、インタースティシャルで遮られたためにサービスの利用をやめたユーザーの数に注目しました。2014年7月、Google は、前述のデータを踏まえて、インタースティシャルの削除がサービスの実際の利用にどのような影響を与えるかについて実験で調査することにしました。Smart App Banner を追加し、モバイル SEO ガイドのよくあるミスを回避する ページの推奨どおりに、目立たない方法で引き続きネイティブ アプリのプロモーションを行いました。その結果は驚くべきものでした。

  • モバイル サイトの 1 日のアクティブ ユーザーは 17% 増加しました。
  • Google+ の iOS ネイティブ アプリのインストール数には、ほとんど影響がありませんでした(-2%)(Android 搭載端末からのインストール数については、ほとんどのユーザーが Google+ をインストール済みなのでここでは扱いません)。

この結果に基づき、このインタースティシャルを完全に廃止することにしました。Google サービスでユーザー数が増えたことはプラスの変化です。この結果を見て、ウェブマスターの皆様にはプロモーション インタースティシャルの使用を再考していただければと思います。邪魔なものを取り除いて、モバイル ウェブのユーザー エクスペリエンスを向上させましょう!
(この調査の結果、Google は App Banner すら表示しないような、より心地よいモバイル体験(英語)を提供することにしました。※このバナーは、iOS6 以下では表示されています。)

goo.gl がクロスプラットフォームでのリンクの共有に対応しました

このたび goo.gl 短縮リンクに新機能が加わり、1 つの goo.gl リンクを Android アプリ、iOS アプリ、ウェブサイトなどにまたがるコンテンツへのリンクとして使用できるようになりました。Android と iOS の App Indexing を設定すると、goo.gl で生成されたリンクは、アプリをインストール済みのユーザーはアプリ内の適切なページへ、そうでないユーザーはウェブサイトへリダイレクトするようになります。これにより、ユーザーにアプリを再度利用してもらう機会を増やすことが可能になります。この機能は過去に生成した短縮 URL にも同じように適用されます。

適切に機能するリンクを共有しよう

さらに、URL Shortener API をアプリの共有フローに統合すると、ユーザーがリンクを共有する際、プラットフォームが異なっていても自動的にネイティブ アプリにリダイレクトされるようになります。また、自分のアプリへのディープリンクを、他のウェブサイトやアプリに埋め込むこともできます。

Google マップを例に説明しましょう。クロスプラットフォームになった goo.gl リンクを開くと、ユーザーがどのプラットフォームを利用しているか、マップ アプリがインストールされているかどうかが自動的に検出されます。アプリがインストールされている場合は、Android または iOS のマップ アプリで直接そのコンテンツが開かれます。アプリがインストールされていない場合やパソコンを使用している場合は、マップのウェブサイトが表示されます。

実際に試してみましょう。Google マップ アプリがインストールされた携帯端末で、http://goo.gl/maps/xlWFj にアクセスしてみてください。

設定方法

goo.gl を利用して、あなたのアプリへのディープリンクを設定するには:
  1. g.co/AppIndexing にアクセスし、Android と iOS で App Indexing を使用するのに必要な手順を行います。なお、現行の Google 検索からのディープリンクとは異なり、goo.gl ディープリンクはすべての iOS 開発者が利用できます。この手順を完了すると、既存の goo.gl 短縮リンクもアプリへのディープリンクとして機能するようになります。
  2. 必要に応じ、URL Shortener API をアプリの共有フローやメール キャンペーンなどに統合します。これにより、アプリに直接アクセスできるディープリンクをプログラムによって生成できるようになります。
この新機能を活用し、クロスプラットフォームでのリンクの共有にお役立てください。

#MobileMadness: サイトをモバイル フレンドリーにするためのキャンペーンを実施しました

Google サーチ クオリティ チームでは、先日開始したモバイル フレンドリー アップデートに先立ち、3 月の間 Google+ や Twitter 上で #MobileMadness と題したキャンペーンを実施し、サイトをモバイル フレンドリーにするために参考になる情報を発信しました。キャンペーン中は、参考になる tips(ヒント)のご紹介だけでなく、ウェブマスター オフィスアワーを開催してみなさんのご質問にお答えしたり、Google+ の投票機能を使ってウェブマスターの皆さんの声を聞いたりと、様々な企画を行いました。ここで 1 か月に渡ったキャンペーンについてまとめてご紹介したいと思います。

モバイル フレンドリー Tips

1 か月の間、サイトをモバイル フレンドリーにする際に参考になる tips (ヒント)をご紹介しました。
例えば、モバイル サイトをデベロッパーと共同で構築する際に気をつけたいポイントをまとめてご紹介したり、
Google+ 上での投稿

リダイレクトの設定で間違えやすい点をご紹介したりしました。
Google+ 上での投稿
他にも様々な tips(ヒント)をご紹介しましたので、ぜひ Google ウェブマスター コミュニティ上の投稿をご確認ください。

ウェブマスター オフィスアワー

3 月 19 日に実施したウェブマスター オフィスアワー(Hangouts On Air 形式の Q&A セッション)では、モバイル フレンドリー アップデート関連の質問もたくさん頂き、サーチ クオリティ チームのメンバーでお答えしました。
また、3 月のキャンペーン期間後にはなりましたが、モバイル フレンドリー アップデート直前の 4 月 16 日にもウェブマスター オフィスアワーを開催し、多くのご質問にお答えしました。

ウェブマスター みんなで投票

その他にも、Google+ の投票機能を使い、ウェブマスターのみなさんに、モバイル フレンドリーにまつわる質問にお答えいただきました。例えば、「この投稿を、どの端末から閲覧していますか?」という質問では、41 % の方がモバイル端末上から投稿を閲覧していることがわかり、モバイルからのコンテンツの閲覧が一般的になってきていることが垣間見えました。
また、「モバイル端末からブラウジングする際に、最も不快なことは何ですか?」という質問では、36% のウェブマスターが「インタースティシャル広告が表示される」ことを最も不快に感じているという結果になりました(英語圏のウェブマスターの回答では、43% のウェブマスターが「表示速度が遅い」ことを最も不快に感じているという結果となり、インタースティシャル広告が表示されることが最も不快と感じるのは 17% と、言語圏による違いも見られました。興味深いですね!)。

モバイル フレンドリー サイト 1 か月チャレンジの結果

キャンペーン中、「サイトを 1 か月でモバイル フレンドリーにすることにチャレンジしてみましょう」という呼びかけを行ったところ、世界中で多くのウェブマスターの方に参加頂きました。ここでは参加された方の声をいくつかご紹介します。
  • ニコラス・シェバリエールさん: #mobilemadness 以降、私たちが管理しているほぼすべてのサイトをレスポンシブ デザインへと変更することができました。
  • ダニエル・ハリソンさん: まだレスポンシブ デザインへの更新作業中です。2 週間後までには 100%終えられるように頑張ります。 ギーナ・ガウジオ・グレーブスさん: 私たちのサイトはもう完全に #mobilefriendly です。[中略] さらに、多くの生徒たちのサイトも #mobilefriendly になりました!どうもありがとう!
  • アンドリュース・ベッカーさん: もう 2、3 日 必要ですね。たくさんサイトがあるんですから :) 現在はだいたい 90% というところでしょう。
#MobileMadness キャンペーンにご参加いただいた皆さん、どうもありがとうございました! 最後にもう一度、モバイル フレンドリー テストモバイル ユーザビリティ レポートを利用してサイトがモバイル フレンドリーとなっているか確認しましょう。また、モバイル ガイドでは、サイトをモバイル フレンドリーにする上でのステップについてステップごとに詳しくご紹介していますので、ぜひご活用ください。

モバイル フレンドリー サイトのための確認シート

また、今回、サイトをモバイル フレンドリーにする上での確認シートを作成しました。こちらからダウンロードして、ご利用ください。
もちろん、何かご不明な点がある場合は、いつでも ウェブマスター ヘルプ フォーラムへお寄せください。


モバイル フレンドリー アップデートを開始します

今年の 2 月に発表したように、本日より、Google は全世界でモバイル フレンドリー アップデートを開始します。これにより、モバイル版の検索結果では、モバイル フレンドリーなページの掲載順位が引き上げられ、検索ユーザーは、小さなスクリーン上でも読みやすい、高品質で関連性の高い検索結果をより簡単に見つけることができるようになります。こういったページには、タップやズームなどをしなくてもテキストが読みやすい、タップ ターゲットの間隔が適切、再生できないコンテンツが含まれていない、横方向へのスクロールが発生しない、などの特徴があります。

ref.png
4 月 21 日から実施されるモバイル フレンドリー アップデートにより、モバイル検索では、携帯端末で読みやすく使いやすいページの掲載順位が引き上げられます。

このアップデートには以下のような特徴があります:
  • 携帯端末での検索の掲載順位にのみ影響する
  • 世界中のすべての言語で検索結果に影響する
  • ウェブサイト全体ではなく、個々のページが対象となる
この変更は重要なものですが、ランキングにおける他のシグナルの重要性を無視するものではありません。検索クエリの意図は非常に重要なシグナルです。ですので、たとえクオリティの高いコンテンツが掲載されているページがモバイル フレンドリーではなかったとしても、関連の強いクエリでは高い順位に掲載される可能性があります。

サイトがモバイル フレンドリーかどうかを確認するには、モバイル フレンドリー テストで個々のページを確認するか、ウェブマスター ツールのモバイル ユーザビリティ レポートでサイト全体の対応状況を確認してください。サイトがモバイル フレンドリーではない場合、Google 検索からのモバイル トラフィックが大幅に減少する可能性があります。しかし、サイトがモバイル フレンドリーに対応すれば、Google によるページの再処理(クロールとインデックス登録)は自動的に行われるので、ご安心ください。また、Fetch as Google の「インデックスに送信」機能を使用して、この処理を早めることもできます。処理が完了すると、そのページはモバイル フレンドリーとして順位付けされるようになります。

ご不明な点がありましたら、こちらのモバイル フレンドリー アップデートに関する FAQ をご覧いただくか、モバイル ウェブサイトに関するウェブマスター フォーラムをご覧ください。

4 月 21 日のモバイル フレンドリー アップデートについてのよくある質問

4 月 21 日に実施されるモバイル フレンドリー アップデートについてのよくある質問とその回答をご紹介します。Google ではこの 2 月にモバイル フレンドリー アップデートを発表し、モバイル版の検索結果におけるモバイル フレンドリー ページ(スマートフォンで見やすく使いやすいページ)の掲載順位を全世界で引き上げるとお知らせしました(逆に、大きい画面のみを対象にデザインされたページは、モバイル版の検索結果で掲載順位が大きく下がる可能性があります)。この件についてよくある質問を以下にご紹介します。

全般的なよくある質問
  1. パソコンやタブレットでの掲載順位もこの変更の影響を受けますか?
    いいえ。今回のアップデートは、タブレットやパソコンからの検索には影響しません。影響する範囲は、スマートフォンから行われるすべての言語および地域での検索です。
  2. ページ単位とサイト単位のどちらでモバイルの掲載順位が上がるのですか?
    ページ単位の変更になります。たとえば、サイト内で 10 個のページがモバイル フレンドリーになっていて、他のページはモバイル フレンドリーでない場合、掲載順位が上がるのはモバイル フレンドリーになっている 10 ページのみです。
  3. 自分のサイトのページがモバイル フレンドリーかどうかを確認する方法はありますか?
    個別のページが「モバイル フレンドリー」かどうかは、モバイル フレンドリー テストを使用して確認できます。

  4. モバイル フレンドリー テストで個別の URL をリアルタイムでテストします。

    モバイル フレンドリーについての情報をサイト単位で調べるには、ウェブマスター ツールのモバイル ユーザビリティ レポートを確認します。この機能では、当該サイトのページを Google が最後にクロールしてインデックス登録したときのデータを使用します。


    ウェブマスター ツールの [モバイル ユーザビリティ] ではサイト全体のモバイル フレンドリーへの現在の対応状況を知ることができます。

  5. 4 月 21 日までにモバイル フレンドリー ページを準備できなかった場合、掲載順位においてモバイル フレンドリーと判断されるまでにどの程度の時間がかかりますか?
    ページがモバイル フレンドリーかどうかは、ページがクロールされてインデックスに登録されるたびに判断されます。次のアップデートを待つ必要はありません。ページをモバイル フレンドリーにしたら、スマートフォン用の Googlebot によってページが再度クロールされてインデックスに登録されるのを待つか、ウェブマスター ツールFetch as Google の [インデックスに送信] を使用して処理をリクエストすることができます。URL が大量にある場合は、サイトマップの送信をご検討ください。前から存在する URL(レスポンシブ ウェブ デザイン動的な配信などの URL)をモバイル コンテンツに使用する場合は、サイトマップに lastmod タグも含めてください。
  6. モバイルの掲載順位変更が 4 月 21 日に実施され、4 月 22 日にトラフィックが減少しなかった場合、自分のサイトの掲載順位には影響がなかったと判断できますか?
    サイトの掲載順位がモバイル フレンドリー アップデートの影響を受けたかどうかについて、4 月 22 日に最終判断を下すことはできません。モバイル フレンドリー アップデートの公開は 4 月 21 日より開始しますが、インデックス内のすべてのページにこのアップデートが反映されるまで 1 週間程度かかる見込みです。
  7. 所有するモバイルサイトのページが、モバイル フレンドリー テストではモバイル フレンドリーでないと判定されます。なぜですか?
    スマートフォンで適切に動作するようデザインされたページがモバイル フレンドリー テストを通過しない場合、その原因としてよくあるのが、スマートフォン用 Googlebotによるリソース(CSS や JavaScript など)のクロールが禁止されていることです。これらのリソースがクロールできないと、ページがスマートフォンで見やすく使いやすいかどうか(つまり、モバイル フレンドリーかどうか)を判断することができません。対処方法は次のとおりです。
    • ブロックされたリソースがモバイル フレンドリー テストで表示されるかどうかチェックします(多くの場合、ページの画像も部分的にしか表示されません)。
    • 必要なファイルに対する Googlebot のクロールを許可します。
    • ページがモバイル フレンドリー テストを通過するか再度チェックします。
    • Fetch as Google の [インデックスに送信]更新した robots.txt を Google に送信を使用して、更新したページの再処理をリクエストします(または、ページが再クロールされてインデックスに登録されるのを待ちます)。

      モバイルページがモバイル フレンドリー テストを通過しない原因の多くは、スマートフォン用 Googlebot による CSS や JavaScript などのリソースのクロールを許可していないことです。これらのリソースはページがモバイル フレンドリーかどうか判断するうえで重要です。

      繰り返しますが、サイト所有者の皆様は Googlebot にページのすべてのリソース(CSS、JavaScript、画像を含む)のクロールを許可するようおすすめします。そうすることで、Google がページを正しく解析してインデックスに登録できるようになるほか、このケースではページがモバイル フレンドリーかどうかを判断できるようになります。

  8. モバイル フレンドリーでないサイトにリンクしている場合はどうなりますか?
    ページから、パソコンや大きな画面向けにデザインされたページなどのモバイル フレンドリーでないページにリンクしている場合でも、「モバイル フレンドリー」と判断されます。モバイル フレンドリー ページからパソコン専用のページへの移動はモバイル ユーザーにとって快適とは言えませんが、モバイル フレンドリー サイトが増えるに伴い、この点は問題にならなくなると思われます。
  9. モバイルサイトを別にホスティングする(パソコン用は www でモバイル用は m.example.com となる場合など)よりも、レスポンシブ ウェブ デザイン(パソコン版とモバイル版で同じ URL と同じ HTML を用いる)のページのほうが、モバイル フレンドリーとして掲載順位が高くなりますか?
    いいえ。レスポンシブ ウェブ デザイン(RWD)、モバイル用の別個の URL動的な配信のどの設定を採用していても、モバイル フレンドリーかどうかの評価は同じになります。サイトでモバイル用の別個の URL や動的な配信を使用する場合は、モバイル SEO ガイドを参照して、モバイルページが Google に正しくクロールおよびインデックス登録されるようにすることをおすすめします。
  10. モバイルフレンドリーでないサイトやページは検索から削除されるのですか?
    モバイル フレンドリーであることは重要ですが、検索結果の掲載順位決定においては、様々なシグナルが利用されています。検索クエリの意図は大変重要なシグナルです。ですので、たとえクオリティの高いコンテンツが掲載されているページがモバイル フレンドリーではなかったとしても、関連の強いクエリでは高い順位に掲載される可能性があります。
専門的なよくある質問
  1. ユーザーがパソコンからのユーザーのみなので、モバイルサイトを作成する理由が見当たらないのですが、その場合はどうなりますか?
    必ずしもモバイルサイトが不要とは言えません。統計では、パソコンを持ったことがない、または既存のパソコンを買い替える考えがないという理由のいずれかで、「モバイルのみ」の利用となるユーザーの増加傾向が示されています。また、モバイル ユーザーが少ないのは、そもそもサイトがモバイル フレンドリーでないから、という可能性もあります。

    モバイル フレンドリー アップデートは、サイトの対象ユーザー、言語、地域、モバイルとパソコンのトラフィックの比率などに関係なく、すべてのサイトにわたって実施されるモバイル検索に適用されます。
  2. YouTube 動画を埋め込んでいるためにモバイル ユーザビリティ エラーが表示されるページがあるのですが、どうすればよいですか?
    YouTube 動画を埋め込む方法には注意を払うようおすすめします。モバイルページで <object> による「古いスタイル」の埋め込みを使用している場合は、幅広い互換性を持つ <iframe> による埋め込みに変更してください。YouTube では現在、ウェブでの既定のプレーヤーとして HTML5 を使用しているため、動画再生ページの「共有」機能や YouTube iFrame API から <iframe> タグを使用して埋め込む動画はモバイル フレンドリーになります。さらに複雑な方法で統合している場合も、スマートフォンに対してスマートフォンのネイティブ サポートを使用するよう指示することから、モバイル フレンドリーになります。

    他の動画サイトの Flash コンテンツについても、専用プラグインの使用を避けるために、上記に相当する HTML5 埋め込みタグやコード スニペットが提供されているか確認してください。
  3. タップ ターゲットのサイズについての明確な標準はありますか?
    はい。重要なタップ ターゲットは高さと幅を 7 mm 以上とし、また、小さいタップ ターゲットの間には 5 mm 以上のマージンを設けることを推奨しています。平均的な大人の指先のサイズは幅約 10 mm なので、これらのサイズを使用することにより、画面のスペースを有効に利用するとともに、操作しやすいインターフェースを提供することができます。
  4. サイトをすばやくモバイル フレンドリーにするために、新たなレスポンシブ サイトが完成するまでの間、機能を大幅に取り除いたバージョンのサイト(別のモバイルページ)の作成を考えています。この方法に問題はありますか?
    まず、Google では 3 種類のモバイル設定をサポートしていることと、ウェブサイトをモバイル フレンドリーにするにはレスポンシブでなくてもよいことを心に留めておいてください。ご質問への回答としては、「機能を大幅に取り除いた」バージョンのサイトの作成は慎重に検討することをおすすめします。ページの形式をモバイル向けにできたとしても、ユーザーが通常のタスクを簡単に行えなかったり、全体のワークフローがスムーズでなかったりすれば、ユーザーの不満の原因となり、結果的に作業が無駄となる可能性もあります。もしも、暫定のモバイルサイトを作成する場合は、レスポンシブ版のサイトの完成後に必ず、サイトを正しく移転してください。たとえば、モバイル用の別の URL を参照することがないよう、すべての URL を更新して、対応するレスポンシブ版にモバイル用 URL を 301 でリダイレクトするようにしてください。
推奨事項
モバイル フレンドリー サイトをまったく作成したことがなくても、問題ありません!モバイル フレンドリー ウェブサイトのドキュメントはじめるをご覧ください。

モバイルサイトの作成をはじめる(https://developers.google.com/webmasters/mobile-sites/)。

既にモバイルサイトをお持ちの場合は、ウェブマスター ツールのモバイル ユーザビリティ レポートをチェックして、サイトのページがモバイル フレンドリーと判定されることを確認してください。

他にご質問がありましたら、下記にお問い合わせいただくか、モバイル ウェブサイトに関するウェブマスター フォーラムをご覧ください。

App Indexing でアプリのインストールを増やしましょう

[この記事は Lawrence Chang, Product Manager による Android Developers Blog の記事 "Drive app installs through App Indexing" を元に、北村が翻訳・加筆し、Google Japan Developer Relations Blog に掲載したものです。詳しくは元記事をご覧ください。]

開発者のみなさんがアプリを素晴らしいものにするため時間と努力を惜しまないのと同様に、我々もみなさんの素晴らしいコンテンツをより多くの人たちに届けるお手伝いをしたいと願っています。既に 300 億のアプリ内リンクがインデックスされていることからもわかるように、App Indexing は Android 向けアプリのインストール後のエンゲージに役立てられています。今週より、Android 向けアプリをインストールしていない方々にも、Google で検索することで、あなたのアプリを発見することができるようになります。App Indexing が実装済みで、あなたのアプリからインデックスされたコンテンツが Android 上の Google 検索の結果と一致した場合、検索結果にあなたのアプリのインストール ボタンが表示される可能性があります。そのボタンを押下することで、ユーザーは Google Play ストアに移動し、アプリをインストール、そしてアプリ内の検索結果に該当する箇所に直接アクセスすることができます。

これらのインストール リンクの追加を皮切りに、アプリをインストールしているか否かに関わらず、App Indexing はすべての Android ユーザーのランキングシグナルとして利用されることになります。これにより、Google の検索機能が新しいユーザーの獲得だけでなく、既存ユーザーとのエンゲージメントにも役立つことを願っています。App Indexing について詳しくは g.co/AppIndexing を、Google 検索の他の活用方法については g.co/DeveloperSearch を御覧ください。

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

多くのウェブサイトでは、重要な目標を達成するための手段としてフォームを使用しています。たとえば、ショッピング サイトでは代金の決済、ニュース サイトでは会員の登録などです。ユーザーの多くは、ウェブ上の各サイトでオンライン フォームを入力するたびに、氏名、メール アドレス、電話番号、住所などの情報を繰り返し入力することになります。同じ情報を何度も入力するのは面倒なだけではありません。入力エラーが発生しやすく、ユーザーがフォームの途中で入力をやめる原因にもなってしまいます。パソコンよりも携帯端末で閲覧するユーザーが多くなり、フォームをすばやく簡単に入力できるようにすることが不可欠となっています。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 のアルゴリズムもあなたのコンテンツをよりよくインデックスすることができます。スマートフォン向けのサイトの構築方法 や、しばしば見られる間違い の修正方法もご確認ください。ご質問は ウェブマスター フォーラム へお願いいたします。