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

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

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

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

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

Posted:
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/)。

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

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

Posted:
[この記事は 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 を御覧ください。

Posted:
今日では、ハッキングされるウェブサイトの数は、1 日あたり数千に及ぶと言われています。ハッキングされたサイトは、ユーザーに悪意のあるソフトウェアを配布する、ユーザーの個人情報を収集する、ユーザーをまったく別のサイトにリダイレクトするなどの方法で、ユーザーに危害を加えるおそれがあります。もしサイトがハッキングされたら速やかに復旧したいものですが、その方法は単純ではありません。

Google では、サイトがハッキングされた場合にできるだけ簡単に復旧できるよう、セキュリティの問題ハッキングされたサイトに関するヘルプハッキングされたサイト専用のフォーラムなどを提供しています。最近、ハッキングされた 2 つのサイトのウェブマスターの方に、どうやってサイトを復旧したかについてお話を伺う機会がありました。こうした事例をご紹介することで、ハッキングの被害にあったウェブマスターの皆様がサイトの復旧を行う際のヒントになれば幸いです。

事例 1: レストランのウェブサイトがハッキングされ、複数のスクリプトが挿入された

このレストランでは Wordpress でウェブサイトを作成していましたが、ある日サイトがハッカーによって改ざんされたことを警告する Google からのメッセージがウェブマスター ツール アカウントに届きました。Google では検索ユーザーを保護するため、このウェブサイトがハッキングされたことを示すラベルを Google 検索結果に表示しました。このサイトのウェブマスターであるサムさんがソース コードを確認したところ、「viagra(バイアグラ)」、「cialis(シアリス)」などの薬剤用語を使った不審なリンクが数多く見つかりました。また、「buy valtrex in florida(バルトレックス 購入 フロリダ)」のような meta description タグが HTML 上に追加されているページも数多く見つかりました。さらには、多くのページに(HTML 内にも)非表示の div タグが挿入され、さまざまなページにリンクしていました。もちろん、これらはサムさんが追加したものではありません。

サムさんは、ハッキングされたコンテンツを可能な限り削除して再審査リクエストを送信しました。リクエストは承認されませんでしたが、Google からメッセージがあり、PHP ファイル(もしくは、その他のサーバー ファイル)内に不審なスクリプトが追加されていないか、.htaccess に変更が加えられていないか確認するようアドバイスされました。これらは、ハッカーがサイトを改ざんする際、スクリプトを追加するのによく狙うファイルだからです。通常、ハッカーはこのようなスクリプトを使って、ハッキングしたコンテンツを検索エンジンに対してのみ表示し、一般のユーザーにはそのコンテンツが表示されないようにしてしまいます。サムさんはすべての .php ファイルを確認し、ハッキング前にバックアップしておいたファイルと比較しました。その結果、footer.php、index.php、functions.php に新しいコンテンツが追加されていることが判明しました。これらのファイルをバックアップ ファイルで置き換えた後にハッキングされたコンテンツがそれ以上見つからないことを確認し、もう一度再審査リクエストを送信したところ、サイト内のハッキングされたコンテンツがすべて削除されていることを知らせる Google からの通知が届きました。

ハッキングされたコンテンツはすべて削除しましたが、サムさんとしては今後のハッカーの攻撃からサイトを保護しなければなりません。そこで以下の方法によりサイトを保護することにしました。
  • コンテンツ管理システム(WordPress、Joomla、Drupal など)を常に最新のバージョンに更新する(プラグインも忘れずに更新する)。
  • コンテンツ管理システムの管理機能を使用できるアカウントに、強度の高いパスワードを使用する。
  • コンテンツ管理システムでサポートされている場合は、ログインの 2 段階認証(英語)を有効にする(2 要素認証と呼ばれることもあります)。この方法は、パスワードの再設定に使用するアカウントにもおすすめします。GoogleMicrosoftYahoo(英語)など、ほとんどのメール プロバイダでサポートされています。
  • インストールされているプラグインやテーマが信頼できる提供元からのものであることを確認する。既にサポートが終了しているようなプラグインやテーマを使用し続けることは大変危険です。また、海賊版のプラグインやテーマには、ハッカーの侵入を容易にするようなコードが挿入されていることが多いようです。

事例 2: 事業用ウェブサイトに検出が難しいハッキングされたページが大量に見つかった

小規模事業主であるマリアさんは、管理しているウェブサイトがハッキングされていることを知らせるメッセージをウェブマスター ツールで受け取りました。メッセージには、ハッカーが追加したページの例として http://example.com/where-to-buy-cialis-over-the-counter/ が挙げられていました。ホスティング プロバイダに相談したところ、ホームページのソース コードを確認してくれましたが薬剤に関するキーワードは見つからず、http://example.com/where-to-buy-cialis-over-the-counter/ にアクセスするとエラー ページが返されるという状況でした。有料のマルウェア スキャン サービスも利用しましたが、サイト内に悪意のあるソフトウェアを見つけることはできませんでした。
その後、ウェブマスター ツールの Fetch as Google 機能を使用して、Google が例示した URL(http://example.com/where-to-buy-cialis-over-the-counter/)にアクセスしてみましたが何も返されませんでした。どうしようもないため再審査リクエストを送信したところ、不承認メッセージが届き、以下の 2 点を試すようアドバイスがありました。
  1. www のないサイト URL をウェブマスター ツールに追加する。これは、ウェブマスターが見落としがちなフォルダにハッカーのコンテンツが隠されている場合があるためです。

    http://example.com と http://www.example.com は同じサイトのように見えますが、Google ではこれらを別々のサイトとして処理しています。http://example.com は「ルート ドメイン」で、http://www.example.com は「サブ ドメイン」です。マリアさんは http://www.example.com は確認していましたが、http://example.com は確認していませんでした。しかし、ハッカーが追加していたページは http://example.com/where-to-buy-cialis-over-the-counter/ のような www のないページで、こちらを確認することが重要だったのです。マリアさんが http://example.com を確認したところ、ウェブマスター ツールの Fetch as Google 機能を使用してハッキングされたコンテンツを表示することができました。
  2. .htaccess ファイルに新たなルールが追加されていないか確認する。

    マリアさんが、ホスティング プロバイダにやり方を教わって .htaccess ファイルを確認したところ、次のような追加した覚えのない不審なコンテンツが追加されていました。

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
    RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
    RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
    </IfModule>


    この mod_rewrite(英語)ルールはハッカーが挿入したもので、特定の検索エンジンから訪れたすべてのユーザーと検索エンジン クローラを、ハッキングされたコンテンツの生成元である main.php にリダイレクトしているものでした。このようなルールで、携帯端末でサイトにアクセスしてきたユーザーをリダイレクトすることも可能です。同じ日、最近のマルウェア スキャンによって、main.php ファイルに不審なコンテンツが見つかっていたことも判明しました。さらには、ウェブサイト開発ソフトウェアの FTP ユーザー領域に、不明なユーザーが登録されていることにも気付きました。
マリアさんは main.php ファイルと .htaccess ファイルを削除し、FTP ユーザー領域から不明なユーザーを削除しました。これにより、サイトのハッキングを止めることができたのです。

今後ハッキングされないための対策

  • サーバーへのファイル転送に FTP の使用を避ける。FTP では、パスワードをはじめすべてのトラフィックが暗号化されません。代わりに SFTP を使用することで、パスワードを含むすべてのトラフィックが暗号化され、盗聴者からデータを保護できます。
  • .htaccess のような重要なファイルへのアクセス権限を確認する。この点については、必要に応じてホスティング プロバイダに相談してください。.htaccess はサイトの改善や保護に使用する重要なファイルですが、このファイルへのアクセスを許してしまうとハッカーに悪用されるおそれがあります。
  • サイトを変更する権限のあるユーザーを確認できる場所(管理パネルなど)をこまめにチェックして、不明なユーザーが追加されていないかどうか確認する。
Google では、ウェブマスターの皆様のサイトがハッキングされないことを願っておりますが、万が一ハッキングされた場合はハッキングされたサイトに関するヘルプをご覧ください。ハッキングされたサイトを復旧するためのさまざまな資料が用意されています。それでもご不明な点がある場合や、他のウェブマスターと情報交換していただける場合は、ウェブマスター ヘルプ フォーラムをご利用ください(フォーラムに投稿する際やサイトの再審査リクエストを送信する際は、#NoHacked を含めるようにしてください)。

最後に、ハッキングによる被害はなかなか気づかないことも多いようです。サイトの不正なハッキングをいち早く見つけ、普段からサイトのセキュリティ強化を意識しましょう!

Posted:
JSON-LD は、Google などの検索エンジンに対してサイト上のコンテンツを記述する構造化データの実装に使用できる JSON ベースのデータ形式です。たとえば、イベント、店舗、人物などのリストがある場合に、schema.org ボキャブラリを JSON-LD スニペットとしてウェブページに埋め込むことで、構造化された方法でリストのデータをページに含めることができます。構造化データにすることで、Google がページの内容を把握しやすくなり、ナレッジグラフ イベントリッチ スニペットなどの検索機能でコンテンツがハイライトで表示されやすくなります。

Web Components は、カスタマイズした再利用可能なユーザー インターフェース ウィジェットとその動作を定義するための技術です。複数の技術で成り立ち、その仕様は現在も策定中です。ウェブ デベロッパーであれば誰でも Web Components をビルドできます。まず、ユーザー インターフェースの個々のパーツについてテンプレートを定義し、Web Components を使用したいページにテンプレートをインポートします。Web Components の動作を定義するには、Custom Elements を使用します。ユーザー インターフェースのパーツの表示とロジックが Web Components にバンドルされるため、このバンドルを他のページや他のデベロッパーと共有したり、再利用したりでき、ウェブ開発が簡単になります。

JSON-LD と Web Components は、併せて利用するととてもうまく機能します。Custom Elements がプレゼンテーション層として機能し、JSON-LD は Custom Elements や検索エンジンが読み込むデータ層として機能します。つまり、schema.org/Eventschema.org/LocalBusiness など、どのような種類の schema.org についても、Custom Elements をビルドできることになります。

アーキテクチャは次のようになります。構造化データはデータ ベースに格納されます(例: チェーンの店舗の所在地)。このデータは JSON-LD スニペットとしてウェブページに埋め込まれます。つまり、Custom Elements によって読み込まれ、人間の訪問者に対して表示されたり、Googlebot によって Google のインデックス登録のために取得されたりできるようになります。

Custom Elements の詳細や独自の Custom Elements の使用方法については、以下をご覧ください。