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

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

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

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

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

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

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

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

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

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 という機能があります。

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

検索結果内の検索ボックスが新しくなりました

このたび、サイトリンクの検索ボックスが新しくなりましたのでお知らせいたします。この検索ボックスを使用すると、ユーザーはサイト独自の検索ページを通じて直接サイト内の特定のコンテンツに簡単にアクセスできるようになります。

この検索ボックスの仕組みと検索結果に表示されるタイミング


たとえば [ABC 出版] や [株式会社 XYZ] のように名前で会社を検索する場合、ユーザーは実際にはそのウェブサイト内の特定の情報を探しているかもしれません。今までは、Google のアルゴリズムでこのような検索キーワードが認識されると、多数のサイトリンクが表示され、その検索結果の下に追加の検索ボックスが表示されていました。ユーザーはこの検索ボックスを使用して検索結果から直接、このサイトにsite: 検索を行うことができます(例: [site:example.com 登山ガイド])。

今回は、この検索ボックスが改良され、オートコンプリートにも対応しました。正しいマークアップが使用されていれば、ユーザーはウェブサイトの独自の検索ページに直接リダイレクトされます。


サイトをマークアップする方法


サイトでは、サイト固有の検索エンジンを使用している必要があります。既に使用している場合は、schema.org/SearchAction (英語)マークアップの potentialAction プロパティ(英語)を使用して、ホームページを schema.org/WebSite (英語)エンティティとしてマークアップすることで Google に知らせることができます。マークアップには、JSON LD、microdata、RDFa を使用できます。実装について詳しくは、デベロッパー サイト(英語)をご確認ください。

サイトにマークアップを実装すると、ユーザーはサイトリンク検索ボックスから直接、サイトの検索結果ページにジャンプできるようになります。マークアップがない場合は、今までと同様に「site: 検索キーワード」に一致する Google 検索結果ページが表示されます。

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

HTTPS をランキング シグナルに使用します

セキュリティは Google の最優先事項です。Google は、デフォルトで強力な HTTPS 暗号化を導入するなど、業界でも最先端のセキュリティを Google サービスに導入することに力を注いでいます。これにより、たとえば Google 検索、Gmail、Google ドライブを使用しているユーザーは自動的に、Google に安全に接続することができます。

Google は、Google のサービスだけにとどまらず、より広い範囲でインターネットを安全に利用できるように取り組んでいます。そこで大きな割合を占めているのは、ユーザーが Google から安全なサイトにアクセスできるようにすることです。たとえば、Google ではウェブマスター向けにハッキングの対策や修正方法について詳しい情報を提供するサイトを作成しました。

Google ではさらにもう一歩踏み込んで、数か月前の Google I/O では、「HTTPS everywhere」をウェブで提唱しました。

また、ますます多くのウェブマスターが HTTPS(HTTP over TLS / Transport Layer Security)を彼らのサイトに導入するようになってきています。これはとても心強いことです。

こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。


Google は、みなさんがより簡単に TLS を導入し、よくある失敗を避けられるように、今後数週間のうちに詳細なベスト プラクティスを公開する予定です。開始にあたって、以下の基本的なヒントもご確認ください。
  • 必要な証明書タイプを決定します: シングル、マルチ ドメイン、ワイルド カード
  • < 2048 bit の証明書を使用します
  • 同じ安全なドメイン上にあるリソースには相対 URL を使用します
  • 他のすべてのドメインにはプロトコル相対 URL を使用します
  • サイトのアドレスの変更方法について詳しくは、サイト移転に関するヘルプ記事をご覧ください
  • robots.txt を使用して HTTPS サイトへのクロールをブロックしないでください
  • 可能な限り検索エンジンがページをインデックス登録できるようにします。Noindex メタタグの使用は避けます。
サイトが既に HTTPS で配信されている場合は、Qualys Lab ツールを使用してウェブサイトのセキュリティ レベルと設定をテストできます。TLS とサイト パフォーマンスについて不安がある場合は、「Is TLS fast yet?」(英語)をご覧ください。また、ご質問やご不明な点がある場合は、ウェブマスター ヘルプ フォーラムでお尋ねください。

このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。

今後、より多くのウェブサイトで HTTPS が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。

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 をお試しください。何かご質問があれば、ウェブマスター ヘルプ フォーラムへ!

App Indexing の最新情報

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


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

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

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

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

検索に関するご質問を!ウェブマスター オフィスアワーでお待ちしています!


Google では、日本のウェブマスターのみなさまに向けて、昨年度から Google+ のハングアウト オンエア機能を利用したウェブマスター ハングアウトを行ってきました。

みなさまからご好評を頂き、2014 年に入りハングアウト形式の情報発信を拡充しています。従来のオンライン講義形式のウェブマスター ハングアウトだけでなく、リアルタイムに Google 社員がみなさまからのご質問にお答えする「ウェブマスター オフィスアワー」と称したイベントを頻繁に開催し、多くの方にご参加頂いています。

今回は「ウェブマスター オフィスアワー」についてその概要と参加方法をご紹介します。

ウェブマスター ハングアウトとウェブマスター オフィスアワー

2014 年から、Google サーチ クオリティ チームでは、2 種類のハングアウトを実施しています。

従来から行っていた「ウェブマスター ハングアウト」では、オンライン授業形式で Google 社員より様々なトピックについてまとまった情報をお届けしています(実施例)。
一方「ウェブマスター オフィスアワー」は、特定のトピックは決まっておらず、Google 社員がリ参加者から頂いた Google 検索やサイト運営上の質問にアルタイムで答えていく、カジュアルな Q&A セッションとなっています。例えば
  • Google 検索と相性の良いサイト運営法とは?
  • ウェブマスター ツール上でエラーが出たけれどどう対処すればいい?
  • Goolge 検索に関して、知っておくとよい最新の情報を教えて!
といったご質問に Google 社員がリアルタイムでお答えします。

参加するには?

各回ごとに Google+ 上にイベント ページを設置しますので、そちらで参加表明をお願いします。Webmaster Japan コミュニティオフィスアワー サイトでも最新の日程をご確認いただけます。
イベント当日は、イベント ページ上からライブ配信の動画を閲覧し、リアルタイムで質問をすることも可能です。イベント終了後は、録画された動画が公開されます。

質問するには?

ウェブマスター オフィスアワーで質問するには 2 つの方法があります。
  1. イベント ページ上に質問を投稿する:イベント ページ上にテキストで質問を投稿して頂けます。イベント開催前から質問の投稿は可能ですので、聞きたい質問を思いついた際には忘れない内にご投稿ください :) 頂いた質問にはオフィスアワーの時間内に、リアルタイムにお答えしていきます。 
  2. ハングアウトに直接参加する:ビデオ会議形式で、Google 社員が参加しているハングアウトに直接参加し、顔を見ながら会話ベースで質問をすることも可能です。こちらは、映像にご自身の顔(カメラをオフにして参加することも可能です)や発言が記録され、公開されることをご理解の上ご参加ください。なお、ハングアウトに参加しないで閲覧するだけでは顔が映ることはありませんのでご安心ください :) 
「こんな質問をしたらレベルが低すぎて恥ずかしいかな」といった声を聞くこともありますが、ご心配は無用です。



過去に実施したこちらのオフィスアワーの動画をご覧いただくとおわかり頂けるかと思いますが、初心者の方から上級者まで、どんなレベルの方でも気軽にご質問頂ける場となることを心がけていますので、疑問がありましたら、遠慮せずにご参加、ご質問をして頂けたらと思います。

また、一度質問しても不明点が残った場合に追加で「○○ の部分をもう少し詳しく説明して欲しい」とリクエスト書き込んだり、ハングアウトで 直接参加して、質問の意図を説明してより詳しい回答を得たりといったことも可能です。リアルタイム、インタラクティブだからこそ、みなさまの疑問点をより具体的に解消できるのがウェブマスター オフィスアワーの魅力だと考えています。

過去の動画をもっと見るには?

こちらのプレイリストから過去の動画(ウェブマスター ハングアウト、ウェブマスター オフィスアワー)をご覧いただけます。 次回の開催は? 次回のウェブマスター オフィスアワーは 3 月 5 日 17:00 (日本時間)を予定しています。また、今後も 2 週間に 1 回程度の開催を予定していますので、ぜひお気軽にご参加ください。

みなさまにウェブマスター オフィスアワーでお会いできることを楽しみにしております!

サイトの不正なハッキングをいち早く見つける 3 つの方法

サイトが不正にハッキングされているのを見たことがありますか?

不正にハッキングされた可能性のあるサイトには検索結果上でメッセージを表示しています。

不正なハッキングによる被害は依然、世界中で増えています。例えば最近では、不正なハッキングによって、ブランド名や製品名(「財布」「バッグ」等)、「激安」などのキーワードやコンテンツを挿入し、オンラインでショッピングをしようとしているユーザーを別のショッピング サイトに誘導するケースが見られます。

また、他のスパム行為と比べ、不正なハッキングでよく見られる特徴としては、別言語のコンテンツが挿入されてしまうため、ハッキングされていること自体に気づきにくいという現象が起こりえます。例えばロシア語のサイトがハッキングされ、日本語の悪質なコンテンツを挿入されてしまう、といったケースがみられます。

Google では、不正なハッキングや悪質なコンテンツの挿入の被害にあっていると思われるサイトの検索結果に警告メッセージを表示し、 検索ユーザーがサイトにアクセスしないよう注意喚起を行っています。しかし、ウェブマスターのみなさまが、日頃からサイトの状況を把握し、いち早く被害に気づくことが、検索ユーザーにとってもウェブマスターのみなさまにとっても被害を最小限に抑えるために何よりも重要です。

今回は、ハッキングの被害にいち早く気づくための最新のヒントをご紹介します。

1. サイト内に不自然なディレクトリや URL がないか確認する


みなさんのサイトでサイト演算子による検索(site:example.com)を試してみてください。サイト内にご自身で作成してないサブ ディレクトリやページが存在していないでしょうか?ハッキングにより不正にディレクトリを作成されたり、ページが挿入されたりすることがありますので、定期的にサイト内の状況を確認してみてください。[site:example.com 激安] や [site:example.com viagra] のように site: 演算子の後にハッキングで狙われやすいクエリ(キーワード)を付け足して検索することも可能です。また、こうした検索クエリで Google アラートを設定しておくと、変化により早く気づくことができるでしょう。

2. ウェブマスター ツール上の「検索クエリ」に不自然なクエリが表示されていないか確認する


ウェブマスター ツールには、ご自身のサイトがどのような検索クエリにヒットして検索結果上に表示されているかを知ることができる機能が備わっています。この「検索クエリ」にお使いの言語以外のクエリが表示されている場合、それがサイトがハッキングされていることを示すシグナルとなっていることがあります。

英語のサイトが日本語のコンテンツでハッキングされた例。
検索クエリのページに日本語の見知らぬクエリが表示されています。

別言語の読めない文字であるという理由で、こうしたデータを無視し、ハッキングの被害を見逃してしまうこともありますので、他言語の検索クエリを見つけても、「自分には関係のないデータだ」などと無視せずに、深く調査することをおすすめします。

3. ウェブマスター ツールのメール転送機能を活用する


ウェブマスター ツールでは絶えずサイトの状況をモニターしているため、サイトに何か問題があったときにはウェブマスター ツールのメッセージ センターに通知されます。メール転送機能を使うと、これらの通知を Google アカウントに関連付けられているメール アドレスに転送することができますので、ウェブマスター ツール内での確認の前に、みなさまがいち早く被害に気づくことができます。

以上、サイトの不正なハッキングをいち早く見つける 3 つの方法をご紹介しました。なお、不正なハッキングの被害が見つかった場合の対処方法や、未然に被害を防ぐためのヒントについては、以下のブログ記事やヘルプ ページをご覧ください。
これらのツールや情報を、被害にあう前から確認しておき、サイトが不正なハッキングの被害にあった場合にすぐに対処を行えるような状態にしておきましょう。また、サイト上で利用しているソフトウェアの更新状況を常に確認し、セキュリティの脆弱性に対応した最新のものにアップデートしておくことも重要です。

ご質問やご意見がある方は、ウェブマスター ヘルプ フォーラムのマルウェアへの感染、サイトのハッキングに関するカテゴリもぜひご活用ください。

Google サーチ クオリティ チームではこのような被害を防ぐため、日々より良い検索結果を提供できるよう改善に努めていますが、みなさまからの報告やフィードバックも問題を把握する上で重要な情報となっています。もし不正なハッキングの被害にあっていると思われるサイトを見かけた場合は(それが自分のサイトでなかったとしても)、スパム レポートからご報告をお願いします。

ウェブマスター ツール「検索クエリ」機能が改善されました

あけましておめでとうございます。あなたの新年をより良いものにすることを願って、この度、ウェブマスター ツールで人気の機能の 1 つを改善いたしました。「検索クエリ」機能で表示されるデータが、概算ではなくなります。

検索クエリ機能は、検索結果にあなたのサイトからのページが少なくともひとつ表示されている検索クエリについての情報を表示するものです。過去 90 日間で、ページが検索結果に表示された回数と、ユーザーが実際にあなたのサイトを訪れた回数(クリック数)を収集し、表示しています。

この度のアップデートの前と後を比較してみてください:
アップデート前

アップデート後

この改善により、あなたのサイトがユーザーによってどのように見られ、クリックされているかについて、より詳しい情報を得ることができるようになります。ご質問はヘルプ フォーラムまでお願いいたします。

自分が所有していないサイトのコンテンツの URL 削除プロセスを改善しました

インターネット上のコンテンツが変更されたり、削除された際に、検索結果上でもその情報がすぐに反映されると役立つ場合があるかもしれません。今回、Google は公開 URL 削除ツールを改善し、その新しいバージョンの提供を開始しました。今までよりも簡単に、自分が所有していないサイトのコンテンツに生じた変化について検索結果に反映させることをリクエストできます。

 

このツールは、自分が所有していないサイトのコンテンツの URL の削除手続きに役立ちます。ページからコンテンツが完全に削除されているか、コンテンツが変更されてスニペットとキャッシュの削除を希望する場合にお使いいただけます。もしあなたがそのサイトの所有者であるならば、ウェブマスターツールの URL 削除ツールをご利用いただいたほうがより早く、より簡単です。

ページを検索結果から削除する方法

もしページが完全に削除されている場合、Google 検索からその URL を削除するようにリクエストすることができます。この場合、そのページが適切な HTTP ステータスコード(403, 404, または 410)を返すようになっているか、noindex robots メタ タグを設定しているか、robots.txt によってブロックされている必要があります(なお、 robots.txt によるブロックはその URL がインデックスされることを完全に防ぐものではありません)。HTTP ステータスコードは HTTP Header Checker で確認することができます。Google ではソフト 404 エラーもサポートしていますが、明確なステータス コードを返すようにサイトを設定することが望ましいです。

ページを削除する際のリクエスト方法をご紹介します。
  1. ページの URL を入力します。以前のバージョンのツールと同じように、検索結果から削除したいコンテンツの正確な URL を入力してください。正確な URL を見つける方法はこちらをご覧ください。
  2. URL の入力後、分析ツールが、そのページが既に存在していないことを確認します。確認結果をご覧の上、削除をリクエストしてください。
  3. 3 ステップ目はありません!たった 2 ステップで簡単です。

検索結果上のキャッシュとスニペットを削除する方法

もしページが削除されていない場合は、そのページ上から当該のテキスト(名前など)が削除されている、または更新されていることを Google に伝えることができます。これによって、サイトの情報が Google 検索上で完全に更新されるまで、キャッシュ ページとスニペットが削除されます(タイトルや掲載順位には影響がありません)。このプロセスでは、ページの URL だけでなく、ページ上に過去には含まれていたけれど現在は削除された単語をリクエスト時に入力する必要があります。キャッシュの削除について詳しくはこちらのヘルプ記事をご覧ください。
  1. 更新されたページの URL を入力します。検索結果から削除したいコンテンツの正確な URL を入力してください。正確な URL を見つける方法はこちらからご覧ください。
  2. ページが更新されているか削除されていること、そしてキャッシュとスニペットの情報が古いこと(現在のコンテンツと合致しないこと)を確認してください。
  3. キャッシュやスニペットには残っていて、ページ上では現在削除されている単語を入力してください。参考ブログ記事もご覧ください(英語)。
URL の削除についてより詳しい情報をヘルプ センターでご紹介しています。併せてご覧ください。

また、ご質問がある際は、ウェブマスター ヘルプフォーラムまでお寄せください。

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

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


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

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

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



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

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

検索ポリシーについてアイデアをお聞かせください

今回、Google では検索ポリシーに関するアイデアを募集します。日常的に Google 検索を利用し、その改善についてアイデアのある方は、こちらのフォーム からぜひお聞かせください。皆様のアイデアが Google で直接採用されるかもしれません。

Google では、最近開設した「検索の仕組み」ウェブサイトの一部として、検索ポリシーの原則検索コンテンツのポリシー を公開しました。こうした情報の公開は、世界中の情報への迅速なアクセスを推進しながら、時には様々な異なる意見のある検索結果上のコンテンツの取り扱いについて、Google がどのように考えているかを紹介することを目的としています。

Google は、常により良いサービスの提供を目指しており、ユーザーの皆様が、Google 検索、特にそのポリシーのあり方にどのようなご意見をお持ちかお聞きしたいと考えています。Google の検索ポリシーとプロセスをより良いものにするため、皆様のアイデアをぜひお寄せください。例えば、検索キーワードに関連する情報がウェブ上に十分にない場合にアラートを表示すべきか、検索のランキングに影響する可能性のある情報を Google でどのように公開すべきか、ハッキングされていると見られるサイトをどのように取り扱えばよいか、ユーザーに対するサポートを根本的に変える必要があるか、など、検索結果のコンテンツの表示方法や、ユーザーへの対応に関することであれば、どのような内容でもかまいません。

皆様の貴重なご意見、アイデアをぜひお寄せください。こちらのフォーム から送信できます。お送りいただいたご意見は担当者がすべて目を通し、優れたアイデアをお送りいただいた方には直接ご連絡させて頂く場合があります。

今後も Google で快適な検索をお楽しみください。

追記: アイデアのヒントが必要でしたら、Google の検索ポリシーに関する SMX West の「Walk a Mile in Google's Shoes: Dealing with Tough Calls in Search」(英語)をご覧ください。

組織のロゴの schema.org マークアップのサポートを開始しました

このたび、Google では組織のロゴについての schema.org マークアップのサポートを開始いたしました。このマークアップによって、組織を象徴する画像とサイトを結び付けることができます。ウェブマスターの皆様は、Google 検索結果で組織のロゴとして使用される画像を指定することができます。

schema.org の Organization マークアップ (英語)を使用すると、使用したいロゴが存在する場所を Google のアルゴリズムに示すことができます。たとえば、ホームページが www.example.com である企業は、ページ上での表示に関わる要素を使用して次のマークアップをホームページに追加できます:

<div itemscope itemtype="http://schema.org/Organization">
  <a itemprop="url" href="http://www.example.com/">Home</a>
  <img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

この例では、「この画像が、(マークアップにも含まれている)ホームページのロゴ画像として指定されており、可能ならば、この画像を Google 検索結果で使用できるものである」ということを Google に示しています。このようなマークアップは、たとえば Google がユーザーのクエリに基づいて右側にナレッジ グラフを表示するときに、他よりも優先してこの画像を表示してほしいという、Google アルゴリズムへの強いシグナルとなります。

ご不明な点がある場合はウェブマスター ヘルプフォーラムからお問い合わせください。

検索の仕組み: 毎日の莫大な数の検索に一瞬で答えを出すために

みなさんが情報を探そうと Google にアクセスしたとき、少しでも簡単に、直感的に検索できるようにしたいと Google は考えています。質問を入力すると答えが表示されますが、この間、見えないところで多くの Google のテクノロジーが動いています。Google ではユーザーの意図をより正確に把握し、探しているものをお届けできるよう、常にこのテクノロジーの向上に努めています。Google 検索を支えているテクノロジーについては、たくさんご質問をいただきます。それにお答えするために、この度 Google では、検索の仕組みに関する新しいウェブサイ を公開しました。

このサイトにアクセスすると、ウェブから始まって、クロール、インデックス、アルゴリズムに基づいたランキングと検索結果の配信、ウェブ スパム対策まで、1 つの検索キーワードがたどるサイクルを知ることができます。このサイトは、このブログ、ヘルプセンターヘルプ フォーラムウェブマスター ツール、詳細な 研究報告書 (英語)といった既存の資料を補完する内容となっています。

たとえば、次のような情報をご覧いただけます:

  • Google 検索に関するインタラクティブな図解(英語)
  • 主な検索アルゴリズムと検索機能に関する詳しい説明
  • 検索結果の評価方法を説明した 43 ページのドキュメント(英語)
  • 最近対策を行ったスパム サイトのライブ スライドショー
  • ウェブスパムの問題とその対策について示すグラフ
  • 法的な理由による削除など、コンテンツの削除に関するポリシーのリスト

この新しいサイト をご覧いただければ、検索結果が表示されるまでのほんの一瞬の間に起きていること、仕組みについてご理解いただけることと思います。アニメーションを用いたサイトは英語版のみですが、テキスト バージョンは 43 か国語でご利用いただけます。

データ ハイライター を利用して、イベント情報を Google 検索に表示させよう

Google ではより便利な検索結果を提供するため、構造化データの活用にますます力を入れています。たとえば、ユーザーが検索結果上でコンテンツを見つけやすいよう、リッチ スニペット などを提供しています。
これまでは、サイトの HTML コードをマークアップする方法しか、Google に構造化データを提供する方法はありませんでした。しかし、ウェブサイトによってはマークアップするのが難しい場合があります。
そこで、Google は、HTML コードを変更する必要がない簡単な方法として、「データ ハイライター」をウェブマスターの皆さまに提供します(英語では既に提供していましたが、この度日本語での提供を開始しました)。現時点では、対応する構造化データはイベント(コンサートやスポーツ イベント、展覧会、ショー、お祭りなど)のみとなっていますが、今後、他のデータ タイプにも対応していく予定です。 データ ハイライターは、HTML コードを変更する必要はなく、クリックするだけで操作できる簡単なツールです。Google ウェブマスター ツールにおいて適切な権限をもっている方であれば、どなたでも使用できます。使い方は、ウェブサイト内にあるイベント情報の載ったページ上で、主要なデータを 1 つ 1 つマウスで選択しハイライトしてタグ付けをするだけです。


複数のイベントを一定の形式で掲載しているページであれば、皆さんがタグ付けしていくうちに、データ ハイライターはその形式を学習し、追加すべきタグの候補を自動的に表示するので、作業のスピードアップが図れます。同様に、一定の形式で書かれたイベント情報が複数ページに渡る場合も、いくつかのページに対してタグ付けを行うと、データ ハイライターは形式の種類を学習し、タグの候補を表示します。通常、手動で 5~10 ページ分のタグ付けをすれば、Google の高度な機械学習アルゴリズムは、サイト内の他の似たページも認識できるようになります。
作業が終わったら、データ ハイライターが現在認識しているすべてのイベント データのサンプルを確認できます。それが正しければ「公開」をクリックします。

それ以降、Google はサイトをクロールしたときに最新版のイベント リストを認識し、それを検索結果の表示対象にします。クロールされたデータは、構造化データ ダッシュボード から調べることができます。クロールされたデータはいつでも確認でき、また、公開を取り消すことができます。

以下の、操作手順を説明する動画をご覧ください。



データ ハイライターの使用を開始するには、ウェブマスター ツール にアクセスしてご自分のサイトを選択し、左のサイドバーにある「最適化」リンクをクリックし、続いて「データ ハイライター」をクリックします。

この記事に関するご質問がありましたら、ヘルプ センターの記事 をお読みいただくか、ウェブマスター ヘルプフォーラム にてお尋ねください。データ ハイライターをぜひご活用ください。

行政機関のウェブマスターのみなさまからの質問を受けて

市町村や都道府県、そして国といった行政機関のウェブサイトがきちんと表示されることは Google 検索にとっても非常に重要なことです。例えば、行政機関はたくさんのコンテンツをサイト上で提供していますが、その多くは市民にとって重要な情報源となっています。Google で行われる検索のうち、およそ 20 % が地域に関連する情報ですが (英語)、地方自治体はまさにそのような地域に関連する情報のエキスパートと言えるでしょう。

こうした理由から、私はこの数年 National Association of Government Webmasters (NAGW) の全国会議でお話してきました。ウェブマスターの方と検索について話をするのはいつも大変興味深いもので、行政機関のサイトを運営する方とお話すると、特有の悩みや質問があることがわかります。今回は、行政機関のウェブマスターの方との会話の中でよく話題に上がる質問と、それに対する Google の回答をご紹介したいと思います。

質問 1: 検索結果や Google マップ上に表記されている電話番号や住所が間違えている時、どうすれば修正できますか?


行政機関のウェブマスターの方は、その機関のウェブサイトの運営だけでも膨大な作業量がありますが、その他にも、ウェブ上での他の問題を解決するように求められるそうです。その中で圧倒的によく聞かれる問題は、検索結果上に表示されている誤った電話番号や住所をどうすれば修正できるのか、というものです。この修正方法については Google プレイス においてリスティングの管理者権限を得ることで、電話番号や住所などの情報をご自身で修正したり追加したりすることが可能になります。

Google マップ上の多くのロケーション(オフィス、公園、ランドマークなど)は、Google+ ローカルのページ を持っています。例えば、 San Francisco Main Library の Google+ ローカル ページには連絡先や開館時間の他、ユーザーからのレビューや写真など、ユーザーが楽しめる要素も掲載されています。もし検索ユーザーがサンフランシスコの図書館を探していると思われる場合、関連する地図とこのリスティングが表示されれば、ユーザーがほしい情報にたどり着くのに役立つでしょう。

もし政府機関にお勤めで、このリスティングの編集を希望される場合は、サイトと同じドメインの E メール アドレスをもとに共有の Google アカウントを利用されることをおすすめします。なお、リスティング ページのオーナー確認は、基本的に電話やハガキにて行われます。


質問 2: 私たちのオフィスのリスティング情報は追加したのですが、他に追加をしたい公共施設(図書館や公民館など)のリスティング情報が 43 件もあります。どのように追加すればいいですか?


10 件以上のリスティング情報や住所がある場合、スプレッドシート ファイルを利用して、一括でアップロードすることが可能です。http://www.google.co.jp/places/ にログインし、電話番号入力画面で [一括アップロード] をクリックするか、リスティング ダッシュボードで [データ ファイルをアップロード] をクリックすると、スプレッドシート アップロード画面に切り替わります。

オーナー確認でお困りの場合は、こちらの トラブル シューティングのページ をご参照ください。


質問 3: .go.jp ドメイン から .co.jp ドメインへの移行を予定しています。どのような手順を踏めばいいですか?


詳しい情報は こちらのヘルプ記事 でご案内していますが、基本的なプロセスには以下のステップが含まれます。

  • 新旧両方のドメインが同じウェブマスター ツールのアカウント上に追加されているか確認してください。
  • すべてのページに 301 リダイレクト を設定し、検索エンジンにサイトが完全に移転したことを伝えてください。
  • 古いサイトのすべてのページを移転先のサイトのホームページにだけリダイレクトさせるような設定はしないでください。ユーザー エクスペリエンスに悪影響を与えます。
  • 以前のサイトと新しいサイトのページが 1 対 1 で対応しない場合(対応させることをおすすめします)は、以前のサイトの各ページをコンテンツが類似している新しいページにリダイレクトするようにしてください。
  • リダイレクト設定ができない場合、クロスドメインでの canonical リンク の利用を検討してみてください。
  • 移転先が Googlebot によってクロール可能な状態にあるか、ウェブマスター ツールの Fetch as Google 機能を利用して確かめてください。
  • ウェブマスター ツールの アドレス変更ツール を使い、Google にサイトが移転したことを通知してください。
  • サイトへのリンク ページを確認し、古いサイトのコンテンツにリンクをしている重要なサイトのウェブマスターにサイトの移転を伝えましょう。
  • コンテンツや URL 構造、ナビゲーションを大幅に更新するなど、サイト移転と同時に他にも大きな変更を行うことは避けることをおすすめします。
  • Google が新しい URL を早く見つけ出すことができるように、Fetch as Google 機能を使って URL を送信してください。また、新しいサイトの URL を網羅したサイトマップの送信も行ってください。
  • 混乱を避けるため、できるだけ長い期間(少なくとも 180 日間)古いサイトのドメインの管理権限とリダイレクトの設定を維持してください。

  • サイトの一部を移転する場合はどうしたらいいでしょうか?この質問もよくお受けします。例えばある市のサイトにあった観光情報のセクションだけを新しい独自ドメインに移動したい、といったケースです。

    こうしたケースでも新旧両サイトのウェブマスター ツールへの登録、301 リダイレクトの使用、古いサイトへのリンクの整理など多くのステップは共通します。しかし、サイトの部分的な移転となりますので、ウェブマスター ツールのアドレス変更ツールを使う必要はありません。もし何らかの理由で、部分的にでも同じコンテンツを両方のサイトで掲載する必要がある場合は、クロスドメインでの canonical 設定 を行い、どちらか一方を canonical 指定しください。


    質問 4: たくさんの作業を経て、各ページの内容に合ったタイトルやメタ ディスクリプションを個別に設定したのですが、これが Google 検索上にきちんと表示されるにはどうしたらよいでしょうか?


    各ページの内容に合ったタイトルやメタ ディスクリプションの設定は Google 検索エンジン最適化(SEO)スターターガイド でもおすすめしていますので、そうした作業を進められるのはとても嬉しく、検索エンジンと相性の良いサイトを運営する上でも重要です。適切なサイトのタイトルと説明 は、検索ユーザーが、どのページに探している情報があるか検討し検索結果をクリックする上で役立ちます。ちなみに、私がお会いした行政機関のウェブマスターの方々は、サイトのコンテンツや構成に十分な注意を払い、またユーザーにとってわかりやすいタイトルや説明の設定に努めていました。

    Google 検索でのページ タイトルと説明(スニペット)の生成は完全に自動化されており、ページのコンテンツとウェブ上での言及のされ方の両方に基づいて行われています。サイトに変更があるとそれは再クロール時に検知されますが、それ以外に Google 側にページの変更を伝える方法が 2 つあります。

    • 最新の XML サイトマップ を送信するとサイト上のすべてのページについて Google が把握できます。
    • ウェブマスター ツール上の Fetch as Google 機能を使って変更のあったページの URL を Google に伝え、URL をインデックスに送信する ことができます。
    • URL とそのページからリンクされているすべてのページを送信することも可能です。例えばサイト内のあるセクションをすべて更新した場合、そのセクションのメインとなるページや index ページの URL をこの方法で送信すると、セクション内のページを網羅的に伝えることができます。

    質問 5: 行政機関向けの YouTube パートナー プログラムにはどのように申し込むことができますか?


    このご質問には、残念なニュースと良いニュース、そしてさらに良いニュースがあります。まず、行政機関向けの YouTube パートナー プログラム は残念ながら終了となりました。しかし、このプログラムで提供していた機能の多くは、現在一般の YouTube アカウントでも利用することができますのでご安心ください。例えば、今は一般アカウントでも 10 分以上の動画をアップロードすることができます。
    そして、「さらに良いニュース」をご紹介しましょう。YouTube では最近、行政機関の方々にも役立つと思われる機能をたくさん追加しています。


    ここでご紹介した情報が皆さまのお役に立つことを願っていますが、行政機関の方々が知りたい内容のすべてをカバーできてはいないと思います。さらに知りたいことがありましたら、 Webmaster Academy (英語) をご参照ください。検索エンジンと相性の良いサイトの作成や運営について学ぶことができます。また、具体的な質問がありましたら、ウェブマスター ヘルプ フォーラム までお寄せください。

    新しくなった画像検索 – ウェブマスターの皆さまへのポイント

    Google で画像を検索するとき、画像とメタ データ(画像に関する詳細情報)の両方を見ながらたくさんの画像に目を通したいと思うユーザーの方が多いかと思います。検索ユーザーとウェブマスターの双方からのご意見をもとに、今まで以上に優れた検索体験を提供するため、Google 画像検索のデザインを改良しました。具体的には、検索結果にパネルを挿入し、そこに選択した画像を表示することにより、これまでよりも速く、美しく、信頼性の高い検索結果ページとなりました。パネル上に表示される画像は、キーボード(←→)を使って素早く切り替えることができます。また、他の結果画像の閲覧に戻りたいときは、そこから下にスクロールすれば続きを見ることができます。


    ウェブマスターの皆さんに知っておいて頂きたい変更点をご紹介します。
    • 従来のように別のランディング ページへユーザーをリダイレクトする代わりに、これからは検索結果の画像のすぐ下に、画像に関する詳細情報(メタ データ)を表示します。 画像が含まれているページのタイトル、ドメイン名、および画像サイズといった主要な情報を画像の横に見やすく表示します。
    • ドメイン名をクリック可能にしたことに加え、元の画像が載っているページを訪れるための新しいボタンも追加しました。つまり、クリックして元の画像の載っているページへ移動できる箇所が、これまでの 2 つから 4 つに増えます。Google で実施したテストでは、これによりクリックが増加する傾向が認められました。
    • 元の画像のページを iframe に読み込んで詳細画像の背景に表示することはなくなります。これにより、ユーザーに対してより速い検索体験を提供することができ、また、元の画像があるサイトのサーバーへの負荷を減らし、さらにウェブマスターが利用するページ ビューなどのデータの精度を高めることもできます。画像検索クエリ データは従来通り、ウェブマスター ツールの 上位の検索クエリ で確認できます。
    ご質問がありましたら、ウェブマスター ヘルプ フォーラム までお寄せください。

    関連ブログ記事(Google Japan Blog) : 画像検索が新しくなりました

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

    データを重要視している 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 版のサイトを表示させます。

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



    リッチ スニペットに関するガイドラインを公開しました


    検索結果に表示される、テキストのみの従来のスニペットは、Google のウェブ検索結果に表示されているページの内容を簡単に説明する役割を持っています。リッチ スニペット(上図)は、ウェブマスターの皆さんがページに構造化データのマークアップを追加することによって生成され、従来のスニペットに比べより詳しく、充実したページの要約を表示するものです。この度 Google は、リッチ スニペット用に使う構造化データ の良質なマークアップを実装していただくため、ガイドライン を公開しました。

    構造化データのマークアップをあなたのサイトに正しく追加していただければ、そのマークアップに基づいたリッチ スニペットがアルゴリズムによって生成されます。マークアップした内容が、ページの内容を正確に表していて、最新の情報であり、またページ上にユーザーが簡単に見つけることができる状態で存在していれば、Google のアルゴリズムがそのページに関するリッチ スニペットを生成・表示する可能性が高まります。

    逆に、リッチ スニペットのマークアップが、スパムのような内容を含む場合、誤解を招きやすい内容である場合、あるいはリッチ スニペットを悪用する意図があると思われる場合は、Google のアルゴリズムはそのマークアップを無視し、テキストだけのスニペットを生成する可能性が高くなります。リッチ スニペットはアルゴリズムによって生成されるものですが、ユーザー エクスペリエンスを阻害するような行為を発見した場合、Google には手動で対処する(特定のサイトのリッチ スニペットを無効化するなど)権利があります。

    ガイドラインの考え方を理解するのに役立つ、具体的な例をいくつかご紹介しましょう。
    • ある音楽バンドに関するページでは、関連する他のバンドや同じ地域で活動する他のバンドによるコンサートの情報ではなく、そのバンドのコンサートについての情報をマークアップしましょう。
    • 商品を販売しているサイトでは、各ページ上のレビューは、ショップに対するレビューではなく、ページに掲載している商品についてのレビューになっているようにしましょう。
    • 歌詞を提供するサイトでは、マークアップするレビューは、その曲自体の出来栄えではなく、その歌詞の出来栄えに関するものになっているようにしましょう。
    全体的な リッチ スニペットの品質に関するガイドライン のほか、Google では ヘルプ センター 上で、特殊なタイプのリッチ スニペットの使用に関するガイドラインも公開しています。この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。