新しい年に、新しいウェブサイトへ: 新しいウェブマスター向けウェブサイトのご紹介

新しい年を迎えて、Google のウェブマスター向けウェブサイトも新しくなりました

このサイトの作成にはあたっては、じっくりと時間をかけて、サイト訪問者の行動を分析したりユーザー アンケートを実施したりしました。その結果、サイトをカテゴリ別に分類することでさらに使いやすくすることができました。コミュニティやトップレベル ユーザーの皆様には貴重なフィードバックをいただき、ありがとうございました。

新しいウェブマスター向けウェブサイト

このサイトは、ウェブサイトの問題を解決するのに役立つヘルプリソースや、高品質サイトの作成や検索ランキングの向上に役立つ SEO 学習資料、そして担当チームやウェブマスター コミュニティから最新情報を知ることができる”つながる”ページで構成されています。また、次のような新機能も追加しました。

  • ウェブマスター向けトラブルシューティング: サイトを移転する方法や Search Console で表示されるメッセージなどについてサポートが必要なら、このトラブルシューティングが問題解決のお手伝いをします。また、Google 検索や Google Search Console でよく見られるサイトの問題を解決することもできます。
  • 人気リソース: 人気の Google ウェブマスター向け YouTube 動画や、ブログ記事、フォーラム スレッドをお探しの場合は、こちらをご覧ください。人気のリソースが一覧にまとめられています。このリソースは言語によって異なる場合があります。
  • イベント カレンダー:オンラインのオフィスアワーやお近くのライブイベントでチームの担当者とお話しになりたい場合は、こちらをご覧ください。オフィスアワーとイベントは、世界中で様々な言語にて開催しています。

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

2015年もありがとうございました。- 今年の総まとめ

2015 年もいよいよ終わりが近づいてきました。皆さまにとって、2015 年はどのような一年だったでしょうか。今年最後の投稿となる今回は、Google 検索に関する今年の出来事を振り返り、2015 年を皆さまとともにおさらいしていきたいと思います。

モバイル関連の記事が注目を集める

まずは、ウェブマスター向け公式ブログに投稿されれた記事のうち、今年一年アクセスの多かった記事をランキングでご紹介します。

  1. 検索結果をもっとモバイル フレンドリーに
  2. 検索ユーザーがモバイル フレンドリー ページを見つけやすくするために
  3. "Google Search Console" - ウェブマスター ツールが新しくなりました
  4. Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法
  5. モバイル フレンドリー アップデートを開始します
  6. Google の検索結果からコンテンツを削除するには
  7. HTTPS ページが優先的にインデックスに登録されるようになります
  8. 誘導ページについて、品質に関するガイドラインを更新しました
  9. Google のインデックスからコンテンツを削除する方法
  10. 4 月 21 日のモバイル フレンドリー アップデートについてのよくある質問

上記ランキングの中には、Search Console のように今年初めて登場した言葉も見受けられますが、一年を通して最も人気を博したトピックは "モバイル" でした。上位 10 件中 5 件もの記事がモバイル関連となるなど、ますます読者の皆さまのモバイルに対する関心の高まりを感じます。

App Indexing

2013 年の発表、そして 2014 年の一般公開以降、App Indexing は 多くのウェブマスターやアプリ デベロッパーの皆さんに利用され、Google 検索はより多くの モバイル アプリ内コンテンツをインデックスすることが可能になりました。今年は、ランキング要素の一つとして使用されることが発表され、検索結果でアプリ コンテンツがより簡単に見つかるよう変更が行われました。Google サーチ クオリティ チームでは、

など、App Indexing に関してより良い体験を提供できる体制を整えました。

Google Search Console

一方、Google 検索に関心を寄せるのはウェブマスターだけではなくなったと考えた私たちは、今年 5 月、ウェブマスター ツールを Google Search Console として一新し、アプリ開発者向けの機能を提供するなど、様々なタイプの人たちに向けたサービスの提供を開始しました。もちろん、従来からある機能の改善も継続的に行っています。Search Console はこれからも検索に関心を寄せるすべての人にとっての包括的な情報源となることを目指していきます。Search Console に関する記事を読み直したい方は、Search Console ラベルより検索いただけますので、ぜひご活用ください。

セキュリティ

モバイルなどの話題が盛り上がる一方で、Google はユーザーやウェブマスターの安全性も決して忘れません。昨年に引き続き今年も #Nohacked キャンペーンを開催し、ハッキングを防止するための様々な方法を紹介しました。また、検索結果に表示されるサイトの不正なハッキングに取り組むことを目的に、一連のアルゴリズムの変更も行いました。さらに、セーフ ブラウジングによるユーザー保護の取り組みを紹介したり、HTTPS URL を優先的にインデックスしていくことを発表するなど、ユーザーがより安全にウェブ ブラウジングを行えるための情報提供と環境の改善に力を注ぎました。

皆さんとともに

そしてもちろん、今年もウェブマスターをはじめとする多くの方と出会えたことを私たちは大変嬉しく思います。今年はハングアウトを活用したウェブマスター オフィスアワーのみならず、東京をはじめ、岡山や大阪、金沢といった地域で行われるイベントにも参加し、参加者の皆さんと直接的な意見交換を行いました。また、米国本社では 2 年に一度の TC summit が開催され、ヘルプ フォーラムでユーザー サポートに日々大きな貢献をいただいている世界中のトップレベル ユーザーの方々と、貴重な意見交換や議論を行うことが出来ました。

以上、今年も様々な取り組みが行われましたが、これらは、ヘルプ フォーラムや Google + コミュニティ、ハングアウトなど、様々な場所で皆さんにご参加いただいたり、フィードバックをご提供いただいたおかげです。どうもありがとうございました。Google サーチ クオリティ チームでは、2016 年も皆さんのお役に立つ情報を提供できるよう、継続的に取り組みを行っていきたいと思います。

それでは皆さん、良いお年を!

#NoHacked ブログ パート 5 :スパム ページがサイトに挿入されるタイプのハッキング被害の解決方法

本日は #nohacked キャンペーンの一環として、先週ご紹介した、スパム ページがサイトに挿入されるという、最近よく見られるハッキングの問題を解決する方法についてお話しいたします。たとえサイトがこの種のハッキングの被害を受けていなくても、ここで紹介する手順の多くは、他の種類のハッキングの問題を解決する際にも役立つと思われますので、ぜひお読みください。(本キャンペーンは、TwitterGoogle+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #NoHacked です。パート 1パート 2パート 3パート 4 のブログ記事もご覧ください)。



サイトを一時的にオフラインにする

まずは、サイトを一時的にオフラインにすることで、サイトの訪問者がハッキングされたページにアクセスすることを防ぐとともに、サイトを適切に修正するための時間を確保できます。サイトをオンラインのままにしておくと、問題の修正中に再び攻撃を受ける恐れがあります。

サイトの問題を修正する

次に、サイトに対して技術的な変更を加えます。そのような変更を加えることに慣れていない場合は、そうした変更の経験がある人に相談または依頼することをおすすめします。ただし、これらの手順を知っておくこと自体は、実際に作業をしなくとも、役に立つでしょう。

サイトの問題の修正を始める前に、サイトをバックアップしておくことをおすすめします(このバックアップ ファイルは、ハッキングされたコンテンツが含まれたままの状態です。そのため、すべてのファイルを復元するなどせず、重要なファイルを誤って削除してしまった場合にそのファイルだけ復元する、といった形でのみ利用してください)。サイトをバックアップする方法が不明な場合は、利用しているホスティング プロバイダに協力を要請するか、お使いのコンテンツ管理システム(CMS)のヘルプ ページなどをご覧ください。作業の途中でファイルを削除する際は、必ず、そのファイルのバックアップを残しておくようにしましょう。

.htaccess ファイルを確認する

この種のハッキングでは、サイトを操作するために .htaccess ファイルを作成するか、その内容を改ざんします。.htaccess ファイルの場所が不明な場合は、お使いのサーバーまたは CMS のヘルプ ページをご覧ください。.htaccess ファイルをチェックして、不審な内容が含まれていないか確認します。.htaccess ファイルの内容の意味がわからない場合は、Apache.org のドキュメント(英語)を参照するか、ウェブマスター ヘルプ フォーラムに質問を投稿するか、詳しい人に相談してみてください。以下に、この種のハッキングによって改ざんされた .htaccess の例を示します。

  • <IfModule mod_rewrite.c> 
  •   RewriteEngine On  
  •   #Google 検索経由でサイトを訪れたユーザーはリダイレクトされる 
  •   RewriteCond %{HTTP_REFERER} google.com 
  •   #ユーザーは happypuppy.php という悪意のある PHP ファイルにリダイレクトされる 
  •   RewriteRule (.*pf.*) /happypuppy.php?q=$1 [L] 
  • </IfModule>

見つかった不審な部分をすべて削除します。.htaccess ファイルに悪意のある内容だけが含まれている場合は、.htaccess ファイル全体を削除してしまっても問題ありません。また、.htaccess ファイルに悪意のある PHP ファイル(ここでは happypuppy.php というファイル名ですが、多くの場合 2 つの単語をランダムに組み合わせた名前です)が記述されていることにも気付かれたかと思います。これは次の手順において重要となります。次の手順では悪意のあるファイルを特定する方法を説明します。

その他の悪意のあるファイルを特定する

この種のハッキングで改ざんまたは不正に挿入されることの多いファイルの種類は JavaScript ファイルと PHP ファイルです。通常、ハッカーは次の 2 つのアプローチを用います。1 つ目は、サーバーに新しい JavaScript ファイルまたは PHP ファイルを不正に挿入するというアプローチです。挿入されるファイルには、サイト上の正当なファイルに極めてよく似た名前(正当なファイル wp_cache.php に対して wp-cache.php など)が付けられていることがあります。2 つ目は、サーバー上の正当なファイルに変更を加えて、それらのファイルに悪意のあるコンテンツを挿入するというアプローチです。たとえば、サイト上にテンプレートやプラグインの JavaScript ファイルがある場合、ハッカーによってそのファイルに悪意のある JavaScript が挿入されることがあります。

たとえば、www.example.com において happypuppy.php という名前の悪意のあるファイル(先ほど .htaccess ファイル内で特定されたもの)がサイト上のフォルダに挿入されたとします。ハッカーはそれに加えて、json2.js という名前の正当な JavaScript ファイルの改ざんも行って、このファイルに悪意のあるコードを追加することがあります。改ざんされた json2.js ファイルの例を以下に示します。怪しいコードはこの json2.js.file の下部に追加されています(赤色でハイライトされている部分):




悪意のあるファイルを効率的に特定するには、サイト上の正規の JavaScript ファイルおよび PHP ファイルの機能を理解する必要があります。そのためには、お使いの CMS のドキュメントを確認することが必要となる場合があります。それぞれのファイルでどのような処理が行われるかがわかれば、サイトの機能に関係のない悪意のあるファイルを簡単に特定できます。

また、サイト上で最近変更されたファイルがないかどうかも確認します。特に、最近変更されたテンプレート ファイルは徹底的に調査する必要があります。PHP ファイルの中身を特定しにくいように難読化している場合もありますが、そのような難読化された PHP ファイルの解釈に役立つツールを補足情報に記載しましたのでそちらもご覧ください。

悪意のあるコンテンツを削除する

先ほどご説明したように、ファイルを削除または変更する前にサイトのコンテンツを適宜バックアップしておきましょう。定期的にサイトをバックアップしている場合は、クリーンなバックアップ ファイルを復元するだけで簡単に悪意のあるコンテンツをサイト上からなくすことができるでしょう。サイトのバックアップを定期的に行っていない場合には、代わりにいくつかの手順を行います。まず、サイトに挿入された悪意のあるファイルをすべて削除します。たとえば、上記の www.example.com の場合であれば happypuppy.php ファイルを削除します。json2.js のような改ざんされた PHP ファイルや JavaScript ファイルについては、それらのファイルのクリーンなバージョンをサイトにアップロードする必要があります。CMS をお使いの場合は、主要な CMS ファイルおよびプラグイン ファイルのコピーをインストールし直すことを検討しましょう。

脆弱性を特定して修正する

悪意のあるファイルを削除したら、サイトへの攻撃を許した脆弱性を特定して修正する必要があります。そうしないとサイトが再びハッキングされる恐れがあります。パスワードの流出や古いウェブ ソフトウェアまであらゆるものが、この脆弱性となる可能性があります。ウェブマスター向けのハッキングに関するヘルプで脆弱性を特定して修正する方法について確認してください。サイトがどのような方法で攻撃されたかを解明できない場合は、すべてのログイン認証用のパスワードを変更し、すべてのウェブ ソフトウェアを更新した上で、利用しているサーバーやホスティングの提供元などからより専門的なサポートを得ることも検討しましょう。

次のステップ

サイトの問題の修正が完了したら、Fetch as Google ツールを使用して、ハッキングされたページがまだ Google には表示されているかどうかを確認します。Fetch as Google ツールでチェックするには、サイトをオンラインにする必要がありますのでご注意ください。トップ ページについても、ハッキングされたコンテンツが含まれていないかを必ず確認します。ハッキングされたコンテンツが見つからなければ、サイトの問題は正常に修正されたことになります。Fetch as Google ツールで、ページ上に悪意のあるコンテンツがまだ検出される場合は、引き続き修正作業を行う必要があります。悪意のある PHP ファイルや JavaScript ファイルを見落としていないか、再度確認します。

サイトの問題が解消されて脆弱性が修正されたことが確認できたら、サイトを通常運営に戻し、ユーザーにも復旧をアナウンスしましょう。サイトに手動による対策が適用された場合は、Search Console で再審査リクエストを送信します。

また、今後生じる攻撃からサイトを保護する方法を検討しておきましょう。今後生じる攻撃からサイトを保護する方法について詳しくは、ハッキングされたサイトに関するウェブマスター ヘルプをご覧ください。

このブログ記事を読んで、スパム ページがサイトに挿入されるというハッキングの問題を修正する方法を少しでもご理解いただけることを願っています。ソーシャル メディアで #nohacked キャンペーンをフォローし、サイトを保護するためのアイデアやコツをハッシュタグ #nohacked で共有してください。

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

補足情報

問題の特定と修正に役立つ可能性のあるツールを紹介します。なお、これらのツールは Google が提供およびサポートしているツールではありません。

PHP DecoderUnPHP: ハッカーは通常、読み取りが困難になるよう PHP ファイルを難読化します。これらのツールを使うと、PHP ファイルの実行内容を把握しやすくなります。


#NoHacked ブログ パート 4:ハッキング被害の監視と調査方法

本日は #NoHacked キャンペーンの一環として、最近よく見られるハッキング手法、そしてその監視、調査方法についてお話しします。たとえサイトがこの種のハッキングの被害を受けていなくても、ここで紹介する手順の多くは、他の種類のハッキングに対処する際に役立ちますので、ぜひご覧ください。なお、来週のブログ記事では、このハッキングの問題を解決する方法について紹介する予定です。(本キャンペーンは、TwitterGoogle+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #NoHacked です。パート 1パート 2パート 3 のブログ記事もご覧ください)。



特徴をつかむ(最近よく見られるハッキング手法)

意味不明なページ(Gibberish)
最近多く見られるハッキング手法の特徴は、サイトをハッキングした後、新たに追加された正規のページのように見せかけて、スパム ページを挿入するというものです。こうしたスパム ページには、検索エンジンを欺くためにキーワードをむやみに詰め込んだテキスト、リンク、画像などが含まれています。たとえば、www.example.com/pf/download-2012-free-full-crack.html といったページを作成し、以下のような意味不明なコンテンツを追加するといったやり方が見られます(日本のサイトであっても英語や他言語のページが挿入されることがあります)。





クローキングの併用
このハッキングでは、ハッキングの事実をウェブマスターに気付かれないようにするために、クローキングという手法がよく使われます。クローキングとは、ウェブマスター、サイトへの訪問者、検索エンジンに対しそれぞれ異なるコンテンツまたは URL を表示することです。たとえば、サイトのウェブマスターに対しては空のページまたは HTTP 404 ページが表示されるようにすれば、ウェブマスターはハッキングされた状態が存在しない、あるいは解消されたと考えるでしょう。その一方で、検索結果からアクセスしたユーザーはスパム ページにリダイレクトされ、さらに、そのサイトをクロールする検索エンジンには意味不明なコンテンツが表示される、という状態を作っていることがあります。

サイトを監視する

サイトにハッキングされた兆候がないかどうかしっかり監視することで、早い段階で問題に対処し、ハッキングによる被害を最小限に抑えることができます。ここからは、今回ご紹介したハッキング手法による被害からサイトを守るための監視方法をいくつかご紹介します。

ウェブサイトのトラフィックが急増していないか調べる
このハッキングでは、本来のサイトと関連の低いコンテンツを含んだスパム ページを検索エンジンでクロールさせるため、サイトとは関連の低いキーワードによるトラフィックが増加することがあります。最近トラフィックが突然増えたことがなかったかどうかを確認してください。トラフィックの急増が見つかった場合は、Search Console の検索アナリティクスを使用して、異常なトラフィックの発生源がハッキングされたページであるかどうかを調べます。

サイトが検索結果にどのように表示されるかを追跡する
ウェブマスターにとって、ご自身のサイトが検索結果にどのように表示されるかを定期的にチェックすることは重要です。しかも、この方法でハッキングの兆候を見つけることもできます。ご自身のサイトで「site:」演算子を使用する(たとえば、「site:example.com」で検索する)と、意味不明な内容のページがサイト上に存在していたり、「このサイトはハッキングされている可能性があります」というメッセージが表示され、ハッキングに気づくことがあるでしょう。

Google からの通知が届くように設定する
Google では、サイトを Search Console に追加することをおすすめしています。Search Console を利用すると、手動対策ビューアセキュリティの問題に関するレポートを見て、サイト上でハッキングされたページが見つかったかどうかを調べることができます。さらに、サイト上でハッキングされたページが見つかった場合は、Search Console に警告メッセージが表示されます(メッセージをメールに転送することもできます)。

また、サイトに Google アラートを設定することもおすすめです。Google アラートは、検索クエリに対して新しい検索結果が見つかった場合にメールで通知するサービスです。たとえば、ご自身のサイトとよく使われるスパム ワードを組み合わせた [site:example.com 激安] のようなキーワードを Google アラートで設定するとします。そのキーワードについて新しい検索結果が見つかり Google アラートからメールが来た場合、そのアラートが発生する原因となったサイト上のページをすぐに確認する必要があります。


サイトを調査する

便利なツールを利用する
Search Console では、Fetch as Google ツールを利用できます。Fetch as Google は、Google がページをどのように認識しているかを確認できるツールで、ハッキングやクローキングされたページを特定するのに便利です。Fetch as Google 以外にも、他社が提供している様々なツールがあります(このブログの補足情報をご覧ください)。

ハッキングされたページの有無を確認する
サイト上にハッキングされたコンテンツがあるかどうかはっきりわからないときは、サイトがハッキングされた場合のトラブル シューティングを利用すると、順を追って基本的なチェックができます。また、上述のように、サイトに対して「site:」演算子を使った検索を実行し、検索結果に意味不明なキーワードが表示される不審なページがないかどうか探すことも有効です。サイト上のページが多い場合は、よく使われるスパム ワード リストなども利用しながら 必要に応じてクエリを絞り込み、被害の状況を確認しましょう(たとえば [site:example.com 激安])。いくつかのスパム ワードを当てはめてみて、なんらかの結果が表示されるかどうかを確認しましょう。

ハッキングされたページでクローキングが行われていないか確認する
上述のように、この種のハッキングはクローキングを併せて行っていることがあり、ハッキング行為の発見をより困難なものにしています。そのため、Search Console の Fetch as Google ツールを使って、前の手順で見つかったスパム ページを発見、チェックすることが非常に重要です(一見ハッキングが直っているように見えても、チェックしてみてください)。


このブログ記事を読んで、スパム ページがサイトに挿入されるというハッキングの問題を特定して調査する方法を少しでもご理解いただけることを願っています。来週は、このようなハッキングの問題を解決する方法について説明しますので、そちらもご覧ください。ソーシャル メディアで #NoHacked キャンペーンをフォローし、サイトを保護するためのアイデアやコツをハッシュタグ #NoHacked で共有してください。

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


補足情報

ここで紹介するツールを使用すると、サイトをスキャンして、問題のあるコンテンツを見つけることができる可能性があります。ただし、Google がサポートしている(Google 上で利用できる)ツールは VirusTotal のみです。
VirusTotalAw-snap.infoSucuri Site CheckWepawet: これらのツールでは、サイトをスキャンし、問題のあるコンテンツがあるかどうかを調べることができます。ただし、いずれのツールも、問題のあるコンテンツをすべて特定することを保証しているわけではありませんのでご注意ください。


#NoHacked ブログ パート 3:2 段階認証プロセスでサイトを保護する

本日は、#NoHacked キャンペーンの一環として、2 段階認証プロセスについてお話しいたします。(本キャンペーンは、TwitterGoogle+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #NoHacked です。パート 1パート 2 のブログ記事もご覧ください)。

かつては、オンライン アカウントを保護する手段として、ある程度強固なパスワードやセキュリティ保護用の質問を設定しておけば十分と考えられていました。しかし、Stop Badware が行った調査(英語)によれば、認証情報を盗んでウェブサイトに不正アクセスする、というのがハッカーの常套手段の 1 つとなっており、評判のよいサイトであっても、パスワードなどの個人データを盗まれてハッカーの餌食になるおそれはあるのです。

しかし、2 段階認証プロセスを使えば、アカウントをもっと安全に保護でき、ハッカーによる不正なアクセスからサイトを守ることができます。2 段階認証プロセスでは、アカウントにアクセスする際に、パスワードだけでなく、さらに追加で認証情報を組み合わせて使用します。既に 2 段階認証プロセスを使ったことがある方もいらっしゃるかもしれません。たとえば、ソーシャル メディア サイトにログインするときにスマートフォンに届いたコードを入力した経験や、銀行口座にオンラインからログインするときにカード リーダーを使用した経験はないでしょうか。2 段階認証プロセスを設定することで、たとえ誰かにパスワードを盗まれても、簡単にはアカウントにログインされないようにすることができます。

ウェブサイトを運営されているなら、今すぐアカウントの 2 段階認証プロセスを有効にするとよいでしょう。万が一サイトがハッキングされ、ユーザーのアカウントを乗っ取られたら、重要な個人データが漏洩して、サイトの評判が失墜する事態にもなりかねません。2 段階認証プロセスを設定することで、アカウントとデータを保護し、安心してサイトを運営できるようになります。

Google では現在、Google Apps ドメインを含むすべてのアカウントで 2 段階認証プロセスを提供しています。アカウント認証には、スマートフォン、セキュリティ キーなどのハードウェア トークン、または Google 認証システム アプリを使用できます。これらをうまく使い分けることで、旅行先やモバイル ネットワークに接続できない場所でも安全に認証を行えます。

サイトの管理に使用しているホスティング プロバイダ、コンテンツ管理システム(CMS、リンク先は英語)、またはプラットフォームで 2 段階認証プロセスが提供されていない場合は、今後対応する予定があるかどうかをカスタマー サポートに確認するとよいでしょう。ホスティング プロバイダが、Google のオープンソース コードを使用して 2 段階認証プロセスをプラットフォームに実装することも可能です。不正アクセスからの強固な保護を期待できない場合は、ホスティング プロバイダを変更することも検討してください。https://twofactorauth.org/(英語)で、2 段階認証プロセスに対応しているウェブサイトと、各サイトが対応している認証の種類を確認できます。

ご不明な点がありましたら、ウェブマスター プロダクト フォーラムでお知らせください。8 月 26 日には、セキュリティをテーマとしてハングアウト オンエア(英語)も予定されています。ぜひご参加ください。

#NoHacked ブログ パート 2:ソーシャル エンジニアリング攻撃を見抜いて被害を防ぐ

今回は #nohacked キャンペーンの一環として、ソーシャル エンジニアリング攻撃についてお話します(本キャンペーンは、TwitterGoogle+ でもキャンペーンを展開していますので、ぜひフォローしてみてください。ハッシュタグは #nohacked です。パート 1 のブログ記事もご覧ください)。

ソーシャル エンジニアリングとは、巧みな方法でユーザーをだまし、機密情報を盗み出そうとすることです。ウェブ上である程度の時間を過ごしていれば、なんらかの形でソーシャル エンジニアリングに遭遇することもあるでしょう。

フィッシング

フィッシングは、ソーシャル エンジニアリングの一般的な手法の 1 つです。フィッシング サイトやメールは、正当なサイトを偽装して、ユーザーがユーザー名やパスワードなどの機密情報を入力するように仕向けます。Google の最近の調査(英語)では、一部のフィッシング サイトがユーザーをだます成功率は 45% にものぼります。フィッシング サイトから盗まれた個人情報は売られるか、アカウントの乗っ取りに使われます。

ソーシャル エンジニアリングのその他の攻撃

サイト所有者にとって、警戒が必要なソーシャル エンジニアリングはフィッシングだけではありません。サイトで使用されているソフトウェアやツールからソーシャル エンジニアリングが仕掛けられることもあります。コンテンツ管理システム(CMS)、プラグイン、アドオンをダウンロードまたは使用する場合は、デベロッパーのサイトから直接入手するなど、信頼できる提供先から入手するようにしてください。信頼できないサイトから入手するソフトウェアには、第三者がサイトに容易にアクセスできるようにするようなセキュリティ上の脆弱性が組み込まれているおそれがあります。
一例をあげましょう。ウェブマスターの Wanda さんは最近、ペットショップに雇われて、サイトの作成を手伝いました。概略を設計した後、サイトの構築に必要なソフトウェアを揃えようとしました。ところが、お気に入りの写真表示プラグインが CMS プラグインの正式なサイトから削除され、開発者によるサポートも終了していました。急いで調べてみると、以前のプラグインのファイルを提供するサイトが見つかりました。そのプラグインをダウンロードして使用し、サイトを完成させました。2 か月後、Search Consoleから Wanda さんのクライアントのサイトがハッキングされたという通知がありました。ハッキングされたコンテンツについて急いで調べると、写真表示プラグインが第三者に改ざんされており、悪意のあるユーザーがサイトにアクセス、編集できるようになっていることがわかりました。Wanda さんはプラグインを削除し、ハッキングされたコンテンツを修正し、その後の攻撃からサイトを保護して、Search Console で再審査をリクエストしました。つまり、Wanda さんが、ソフトウェアの改ざんに気付かなかったために、クライアントのサイトが改ざんされたのです。

ソーシャル エンジニアリング攻撃を防ぐ

ソーシャル エンジニアリングが脅威となるのは、自分の行動の何が問題となるのかがわかりにくいからです。しかし、以下の基本事項は、ソーシャル エンジニアリングを防ぐのに有効です。
  • 絶えず警戒する: インターネット上で機密情報を入力する際や、ウェブサイトにあるソフトウェアをインストールする際には、十分に注意します。URL を確認して、不正なサイトに機密情報を入力していないことを確かめます。ウェブサイトにソフトウェアをインストールする際は必ず、開発者のサイトなど、信頼できるソースから入手します。
  • 2 段階認証プロセスを使用する: Google の 2 段階認証プロセスのように、2 つの要素を認証に使用してセキュリティを多重にし、パスワードが盗まれてもアカウントを保護できるようにします。できる限りすべてのアカウントで、2 段階認証プロセスを使用してください。2 段階認証プロセスのメリットについては、来週さらに詳しくご紹介します。

ソーシャル エンジニアリングに関連するその他のリソース:

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

#NoHacked キャンペーンを開始します: 不正なハッキングの標的にならないようにするには

オンラインで何らかの情報を公開するとき、最も重視すべきことの 1 つがセキュリティです。サイトがハッキングされると、オンラインでの評判に悪影響を及ぼすだけでなく、重要な非公開データを失うおそれもあります。Google の把握しているところでは、ハッキングされたサイトの数は過去 1 年間で 1.8 倍に増加しています。Google としてもこの増加傾向を食い止めようとさまざまな対策を講じていますが、サイト運営者ご自身の手でウェブ コンテンツをハッキングの被害から守る方法もご紹介できたらと思っています。

Google では、本日からおよそ 1 か月間、 #NoHacked キャンペーン を再び実施します。キャンペーン期間中、不正なハッキングからサイトを保護する方法に焦点を当て、それぞれの方法がどのように機能するかについて理解を深めていただきたいと思っています。#NoHacked キャンペーンについては、TwitterGoogle+ でもフォローできます。また、セキュリティをテーマとした Google ハングアウト(英語)も予定しています。セキュリティの専門家に質問できる貴重な機会です。ぜひご参加ください。

では早速、キャンペーンのスタートに、ウェブ上のサイトを保護するための基本的な方法をいくつかご紹介します。

アカウントのセキュリティを強化する

パスワードの推測や解読を難しくすることは、サイトを保護する上で不可欠です。たとえば、文字、数字、記号を組み合わせる方法や、字数を増やしてパスフレーズにする方法があります。パスワードの長さは重要です。長くすればするほど推測が難しくなります。パスワードの強度をテストできるサイトも数多くありますが、実際のパスワードを他のサイトに入力しないよう注意してください。実際のパスワードの強度は、似たようなパスワードをテストすることで、ある程度把握できます。

また、複数のサービスで同じパスワードを使い回さないようにすることも重要です。ハッカーは多くの場合、漏えいしたパスワードの一覧やハッキングしたサービスからユーザー名とパスワードを手に入れ、それらを使ってできるだけ多くのアカウントに不正アクセスしようとします。

サービスに 2 段階認証(リンク先は英語。参考:Google アカウントでの 2 段階認証紹介ページ)が用意されている場合は有効にすることも重要です。これによりアカウントのセキュリティが大幅に向上し、さまざまなタイプの攻撃からアカウントを保護できるようになります。2 段階認証のメリットについては、別の日に詳しくご紹介します。

サイトのソフトウェアを常に最新にする

ハッカーがサイトに不正アクセスする際に最も利用されるのが、サイト上の安全性の低いソフトウェアを経由する方法です。サイトに古いソフトウェアがないか確認してください。特に、セキュリティ ホールを塞ぐためのアップデートは定期的に確認しましょう。Apache、nginx などの商用ウェブ サーバー ソフトウェアを使用している場合は、提供されているパッチを必ず適用してください。コンテンツ管理システム(CMS)を使用している場合や、サイトにプラグインやアドオンを追加している場合は、必ずそれらを常に最新のバージョンに更新するようにしてください。また、使用しているウェブ サーバー ソフトウェアや CMS にセキュリティ関連の情報をメールなどで受け取れるサービスがあれば登録します。さらに、ウェブサイトに不要になったアドオンやソフトウェアがあれば削除を検討してください。無用なリスクを避けられるだけでなく、サイトの動作速度が改善する可能性もあります。

ホスティング プロバイダのセキュリティ問題への対応を調べる

ホスティング プロバイダを選ぶ際には、そのプロバイダがセキュリティに関する方針やハッキングされたサイトへの対応ポリシーをきちんと有しているかを考慮に入れることも重要です。ホスティング プロバイダを利用している場合は、サイト上で問題が発生した際に問い合わせられるサポートがあるかどうかを確認してください。また、オンラインでの評判を調べて、ユーザーのサイトからハッキングされたコンテンツを除去する作業を支援した実績があるかどうかも確認しましょう。

サーバーを自前で運用する場合や仮想専用サーバー(VPS)サービスを利用する場合は、発生するすべてのセキュリティ問題にご自身で対処する必要があります。サーバーの管理は非常に複雑です。サーバー管理者の重要な業務の 1 つが、ウェブ サーバーやコンテンツ管理システムのソフトウェアを最新にし、すべてのパッチが適用されている状態に維持することです。やむを得ない理由がない限り、自前でサーバーを管理するのではなく、サーバー管理サービスを提供するホスティング プロバイダを利用することをおすすめします。

Google のツールを使用してサイトのコンテンツがハッキングされた兆候がないか監視する

問題が発生する前からサイトを監視し、問題に対処するためのツールを備えておくことは重要です。不正アクセスの発見が早ければ、早い段階から問題の解決に着手できます。

Search Console をまだご利用いただいていない場合はご利用されることをおすすめします。Google が提供する Search Console は、ハッキングされたコンテンツが見つかった場合も含め、サイト上に発生した問題をウェブマスターに知らせるツールです。また、サイトに Google アラートを設定して、問題の兆候がある場合に通知を受け取ることもできます。たとえば、ペット用品の販売サイト www.example.com を運営している場合に、[site:example.com 格安ソフトウェア] というアラートを設定しておくと、サイトがハッキングされて格安ソフトウェアに関するコンテンツが表示されるようになると通知が届きます。複数のアラートを設定できますので、ハッキングを含むスパム行為でよく使われる言葉を設定しておくとよいでしょう。スパム行為でどのような言葉がよく使われるか不明な場合は、Google で「スパムワード リスト」と検索してみてください。


今回紹介した方法がサイトの保護に役立つことを願っています。ソーシャル メディアで #NoHacked キャンペーンをフォローし、また、サイトを保護するための皆さん自身のアイデアやコツをハッシュタグ #NoHacked でぜひ共有してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XML サイトマップと RSS/Atom フィードのベストプラクティス

サイトマップを送信することは、サイトを最適化する上で重要な要素の一つです。サイトマップを送信することで、あるサイトに存在するすべての URL を検索エンジンが発見できるようになり、ページの内容が変更された時に素早くダウンロードすることが可能になります。そこで今回は、サイトマップにおける重要なフィールドについて、XML サイトマップや RSS/Atom フィードはいつ使えばよいのか、また Google 検索に最適化するためにはどうすればよいか、について解説します。

サイトマップとフィード

サイトマップは、XML サイトマップ(英語)、RSS 、もしくは Atom のいずれかの形式を使用します。主な違いは次のとおりです。XML サイトマップは、あるサイトに存在するすべての URL が含まれますが、RSS/Atom フィードは、最新の更新が含まれます。つまり:
  • XML サイトマップは一般的にファイルサイズが大きくなります。一方、RSS/Atom フィードのファイルサイズは小さく、サイトの最新の更新情報のみが含まれます。
  • XML サイトマップは RSS/Atom フィードほど頻繁にダウンロードされません。
Google では、最適なクロールを行うために、XML サイトマップと RSS/Atom フィードの両方を使用することをおすすめしています。XML サイトマップによって、Google はサイト内の全ページに関する情報を取得することができ、RSS/Atom フィードによって、サイト内のすべての更新情報を取得することができるからです。両者のおかげで、Google はインデックス中のコンテンツをいつも最新の状態に保つことが可能になります。ただし、サイトマップやフィードを送信したからといって、URL のインデックスが保証されるわけではありません。

XML サイトマップの例:
<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>http://example.com/mypage</loc>
   <lastmod>2011-06-27T19:34:00+01:00</lastmod>
   <!-- optional additional tags -->
 </url>
 <url>
   ...
 </url>
</urlset>


RSS フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<rss>
 <channel>
   <!-- other tags -->
   <item>
     <!-- other tags -->
     <link>http://example.com/mypage</link>
     <pubDate>Mon, 27 Jun 2011 19:34:00 +0100</pubDate>
   </item>
   <item>
     ...
   </item>
 </channel>
</rss>


Atom フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
 <!-- other tags -->
 <entry>
   <link href="http://example.com/mypage" />
   <updated>2011-06-27T19:34:00+01:00</updated>
   <!-- other tags -->
 </entry>
 <entry>
   ...
 </entry>
</feed>


"other tags" は必須タグと省略可能なタグの両方を表しており、両者はそれぞれの形式の標準によって定義されています。Google では、Atom/RSS フィードに必須タグを指定することをおすすめしています。この指定により、フィードは Google 検索だけでなく、フィードを扱う可能性のある他のプロパティでも表示することが可能になるからです。


ベストプラクティス

重要なフィールド

XML サイトマップと RSS/Atom フィードは、実際のところ、メタ データが付加された URL の一覧です。その中で、Google にとって最も重要な情報は、URL そのものとその最終更新日時です。

URL

XML サイトマップや RSS/Atom フィード内の URL は、以下のガイドラインに従ってください。
  • Googlebot が取得可能な URL であること。robots.txt によって Googlebot のアクセスを禁止している URL や、ページが存在しない URL が指定されているケースがよく見られますが、それらは間違った指定方法です。
  • 正規 URL であること。内容の重複した複数のページの URL が指定されていることがありますが、これは間違った指定方法です。そのままでは、インデックスが改善されない一方で、あなたのサーバーの負荷が増大してしまいます。

最終更新日時

それぞれの URL に対して、その URL の最終更新日時を XML サイトマップと RSS/Atom フィードに指定してください。最終更新日時とは、そのページのコンテンツが実質的に更新された最新の日時です。ある更新が検索結果に影響を与える可能性がある場合、その更新日時が最終更新日時となります。
  • XML サイトマップでは <lastmod> を使用します
  • RSS では <pubDate> を使用します
  • Atom では <updated> を使用します
最終更新日時を正しく設定、更新するには:
  • 日時を正しい形式で指定します。XML では W3C Datetime 形式 (英語)、Atom では RFC3339 形式 (英語)、RSS では RFC0822 形式 (英語)を使用します。
  • コンテンツが実質的に変更されたときのみ、日時を更新します。
  • サイトマップやフィードが取得されるたびに、現在日時を最終更新日時として指定しません。

XML サイトマップ

XML サイトマップには、サイト内のすべての URL が記載されている必要があります。一般的に、XML サイトマップはファイルサイズが大きく、頻繁には更新されません。使用の際は、以下のガイドラインに従ってください。
  • 単独の XML サイトマップの場合:(定期的に更新されるサイトの場合は、)更新は少なくとも一日一回行い、Google に ping(英語)を送信します。
  • 複数の XML サイトマップの場合:それぞれの XML サイトマップにはできるだけ多くの URL を記載します。一つの XML サイトマップは、最大 5 万 URL もしくは(圧縮されていない状態で)10 MB までとし、ファイルがどちらかの制限に達するまで URL を記載します。XML サイトマップをひとつでも更新した場合は、その都度 Google に ping(英語)を送信してください(サイトマップ インデックス ファイルを使用している場合は、一度だけ送信してください)。それぞれの XML サイトマップにごく少数の URL のみを記載しているケースがしばしば見られますが、それは間違った指定方法です。その場合、Google にとって、想定された時間内で XML サイトマップすべてをダウンロードすることが難しくなります。

RSS/Atom

RSS/Atom フィードは、サイト内の最近の更新情報を伝えている必要があります。通常、RSS/Atom フィードはファイルサイズが小さく、頻繁に更新されます。Google では、RSS/Atom フィードを以下のように設定することをおすすめしています。
  • 新たなページが追加されるか、既存のページが実質的に更新された場合、フィードにその URL と更新日時を追加します。
  • Google による更新情報の見逃しを防ぐため、RSS/Atom フィードには、少なくとも、前回の Google のクロール以降のすべての更新情報が記載されるようにしてください。Google では、そのための最適な方法として、PubSubHubbub(英語)の使用をおすすめしています。ハブが、可能な限り高速かつ効率的な方法で、関係するすべての購読者(RSS リーダーや検索エンジンなど)へフィードの内容を伝達してくれます。

XML サイトマップと RSS/Atom フィードの両方を使用することで、Google や他の検索エンジンによるクロールをうまく最適化することができます。その際に重要な情報は、正規 URL と最終更新日時です。これらを適切に設定し、サイトマップの ping や PubSubHubbub を通して Google などの検索エンジンに伝えることで、クロールを最適な状態で行うことが可能になり、意図した通りに、ウェブサイトが検索結果に反映されるようになります。

ご不明な点がありましたら、この記事にコメントいただくか、ウェブマスター ヘルプ フォーラムのサイトマップ カテゴリまでいつでもお寄せください。

地域対応ページのクロールとインデックス登録

地域対応ページでは、ユーザーの言語や検出された地域に応じてコンテンツが変更されます。Googlebot は通常 Accept-Language HTTP リクエスト ヘッダーを設定せずにページをリクエストし、米国からと判定される IP アドレスを使用するため、地域対応ページのすべてのコンテンツが正しくインデックス登録されるとは限りません。

このたび Google では、リクエストの言語や地域に基づいて配信コンテンツを変更していると判断されたページに対応するため、新しい地域認識クロール設定を Googlebot に追加しました。
  • 地域分散クロール: Googlebot は、米国からと判定される現在の IP アドレスに加え、米国外からと判定される IP アドレスも使用します。
  • 言語依存クロール: Googlebot は、リクエスト内で Accept-Language HTTP ヘッダーを使用してクロールします。
これらの新しいクロール設定は、地域対応ページが検出されると自動的に有効になるため、CMS やサーバー設定を変更しなくても、サイトのクロール方法や Google の検索結果での表示の変化にお気付きいただけることでしょう。

この新しい設定が追加された後も、地域ごとに rel=alternate hreflang アノテーションで別々の URL を使用することを引き続きおすすめします。ユーザーの操作やコンテンツの共有を円滑に行うために、そして地域別のコンテンツを可能な限りインデックス登録してランキングの精度を向上させるために、Google では今後も別々の URL の使用を推奨いたします。

ご不明な点やご意見・ご感想などありましたら、ウェブマスター ヘルプ フォーラムにてお聞かせください。

2014 年もウェブマスター向け公式ブログをご覧頂き、ありがとうございました。

2014 年もウェブマスター向け公式ブログをはじめ、ウェブマスター ヘルプ フォーラムWebmaster Japan コミュニティ、そして Webmaster Hangout/Office Hour など、ご愛読、ご参加いただきありがとうございました。

ウェブマスターのみなさまにとって今年はどんな一年でしたでしょうか?今年公開した人気記事のランキングとともに今年一年を振り返ってみたいと思います。上位 5 つの記事を見てみましょう。

第 1 位:HTTPS をランキング シグナルに使用します
第 2 位:リンク プログラムによるガイドライン違反について
第 3 位:ウェブページをより深く理解するようになりました
第 4 位:検索ユーザーがモバイル フレンドリー ページを見つけやすくするために
第 5 位:検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

今年一番注目された記事は「HTTPS をランキング シグナルに使用します」でした。HTTPS のサイトへの導入については、多くのウェブマスターの方々からご質問を頂きましたが、ランキングのシグナルとして使用しているからというだけでなく、ユーザーにサイトをもっと安全に閲覧していただくためにもぜひ導入を検討していただければと思います。また、今年もう一つ注目を集めたのはモバイルではないでしょうか。今年は他にも「Google の検索結果に、誰もが表示できるウェブサイトを」など、モバイル ユーザーの利便性を意識した改善をたくさん行っています。日本でもモバイルの検索結果に [スマホ対応] と表示されるようになりましたので、ぜひ一度モバイル フレンドリー テストであなたのサイトがモバイル フレンドリーかどうかチェックしてみてください。モバイル フレンドリー サイトの作り方についてはGoogle のウェブマスター向けモバイル ガイドや、2 年前の記事となりますが、「Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法」をぜひご覧ください。

いかがでしたでしょうか?見落としていた記事はありませんか?見落としていた記事がある方は、ぜひ冬休み中、お時間があるときに目を通してみていただけたら幸いです。また、最近日本でもハッキングの被害が引き続き増えています。年末のお休みに入る前に、こちらの記事なども参考にしながら、ぜひ担当されているサイトがハッキングの被害に遭わないように設定を再度ご確認されることをお勧めします。また、年末年始の時期を狙い、詐欺サイトでオンライン ショッピングのユーザーを騙したり、低品質なアフィリエイト サイトで営利を稼ごうといった悪質な行為を行うケースも残念ながら増える傾向にありますのでご注意ください。また、そのようなサイトを見かけた際はスパム レポートでお知らせください(関連 Google+ 記事)。

今年もありがとうございました。それではみなさん、よいお年を!

Takeaki Kanaya, Kiyotaka Tanaka and Kazushi Nagayama, Search Quality Team

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 のインデックス登録システムは、CSS と JavaScript を有効にすることで一般的な最新のブラウザと同じようにウェブページをレンダリングしていると先日お伝えしました。本日、Google ではこの内容を踏まえ、技術に関するウェブマスター向けガイドラインを一部更新いたします。

新しいガイドラインでは、最適なレンダリングおよびインデックス登録のため、ページ内で使用している JavaScript、CSS、画像ファイルに Googlebot がアクセスできるようにする必要がある、としています。サイトの robots.txt を使って Javascript や CSS ファイルのクロールを拒否するように設定すると、Google のアルゴリズムによるコンテンツのレンダリングとインデックス登録を妨げ、最適な結果が得られなくなる可能性があります。

インデックス登録の最適化に関するおすすめの方法を更新

Google のウェブマスター向けガイドラインに記載されていたように、これまで Google のインデックス登録システムは、テキスト ベースの古いブラウザ(Lynx など)にたとえられてきました。しかし、ページのレンダリングに基づいてインデックス登録を行うようになったいま、もはや Google のインデックス登録システムをテキスト ベースのブラウザと同じように考えるのは正しくありません。より正確には、現在使われているウェブ ブラウザに例えるほうが適切です。このような新しい観点からの注意事項は以下のとおりです。
  • 現在使われているブラウザと同じように、Google のレンダリング エンジンも、あるページ内で使用される技術のすべてに対応しているとは限りません。プログレッシブ エンハンスメントという考えに基づいてページをデザインすることにより、ページ内で使われている技術がサポートされていないブラウザやシステムに対しても、基本的なコンテンツと機能が提供できるようになります。
  • すばやくページがレンダリングできれば、ユーザーがあなたのコンテンツをスムーズに閲覧できるだけではなく、ページのインデックス登録をより効率的に行うことができます。特に、ページのパフォーマンスを最適化(英語)するためのおすすめの方法をご紹介いたします。
  • 必ず、JavaScript や CSS ファイルを Googlebot に配信する際に生じる追加の負荷をサーバーが処理できるようにします。
  • テストとトラブルシューティング

    レンダリングベースのインデックス登録を始めるに伴い、Google ではウェブマスター ツールの Fetch as Google 機能も更新しました。この機能により、ウェブマスターの皆様は Google のシステムが、あるページをどのようにレンダリングしているかを把握できるようになります。また、インデックス登録に関する多くの問題(robots.txt による不適切な制限や Googlebot が対応できないリダイレクトなど)を特定することもできます。

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

    リンク プログラムによるガイドライン違反について

    検索エンジンのランキングを操作するために PageRank を渡すリンクを売買することは、Google のウェブマスター向けガイドラインに違反しています。このことは、以前にもこのブログ上でお伝えしてきました。

    この記事では、最近 Google が対策を行った、大規模なリンク プログラムの一例をご紹介いたします。

    (例 1) 自動生成された文章に、特定のサイトへのリンクを、過度に最適化されたアンカーテキストを用いて挿入しているケースです。


    (例 2) 本来対象としているサイト以外への発リンクも設置することで自然なリンクに見せかけているケースです。


    最近 Google が対応を行ったケースでは、委託先 SEO 会社がリンク操作のネットワークを保有して依頼主に提供している例だけでなく、企業自身が主体となってリンク操作のためのネットワークを運用している例が見受けられました。そのような例に対して Google は、ウェブマスター向けガイドライン違反として適宜自動または手動による対策を実施しています。

    ウェブマスターのみなさまには、こういった PageRank を渡すリンクの操作や売買を避けることをこれまでどおり強くおすすめします。サーチ クオリティ チームは、今後とも、ユーザーのために、検索結果からのスパムの排除に全力で取り組んでまいります。

    Apache や Nginx での帯域幅の最適化について

    本記事でご紹介するデベロッパー サイトは、現時点ではまだ日本語に翻訳されていませんが、日本のみなさまにもご利用いただける内容であり、有益であると思いますのでご紹介させていただきます。

    誰もが帯域幅の使用量を削減したいと考えています。ホスティング プロバイダーは料金を節約したいと考えていますし、モバイル ユーザーは使用制限の範囲内に収めたいと思っています。そして、不必要なバイト数の読み込みを待ちたいと思っている人は誰もいません。ウェブには帯域幅を節約できるチャンスがたくさんあります。たとえば、gzip せずに提供されているページ、縮小化されていないスタイルシートや JavaScript、最適化されていない画像などです。

    では、なぜウェブは帯域幅用に最適化されていないのでしょうか。このような節約が誰にとっても有益なら、なぜ誰も実行しないのでしょうか。ほとんどの場合、こういった変更は大変面倒な作業だからです。ウェブ デザイナーはアートワークをエクスポートする際に「ウェブ用に保存」することが奨励されていますが、いつも忘れてしまいます。JavaScript プログラマーは、デバッグが困難になるからという理由でコードの縮小化を好みません。開発や展開のプロセスの一環として、これらの最適化がそれぞれサイトに毎回適用されるようにするカスタム パイプラインを設定することもできますが、大変手間がかかります。

    ウェブ ユーザーにとっての簡単な解決策は、Chrome のようにデータを自動的に最適化し、圧縮してくれるプロキシを使用することです。ユーザーがこのサービスを使用すると、HTTP トラフィックが Google のプロキシ経由となり、ページの読み込みが最適化され、帯域幅の使用も 50% 削減されます。これは有益な方法ではありますが、この機能をオンにしている Chrome ユーザーのみに限定されます。また HTTPS トラフィックを最適化することはできません。

    PageSpeed チームは、帯域幅の最適化機能によってウェブマスターの皆様に同様のテクノロジを提供いたします。これにより、他のブラウザのユーザー、安全なサイト、デスクトップ ユーザーに加え、アウトバウンド トラフィックの料金を低く抑えたいサイト所有者も、最適化を実現できるようになりました。PageSpeed モジュールを Apache または Nginx サーバーにインストールし [1]、設定で帯域幅の最適化機能を有効にすれば、後は PageSpeed がすべて解決してくれます。

    キャッシュの拡張インライン化から、より積極的な機能である画像の遅延読み込みJavaScript の遅延実行まで、PageSpeed の高度な最適化機能は、後からでも PageSpeed 設定で有効にするだけで使用できます。

    詳しくは、PageSpeed のインストール方法帯域幅の最適化を有効にする方法のページをご覧ください。



    [1] 別のウェブサーバーをお使いの場合は、Apache または Nginx プロキシでの PageSpeed の実行をご検討ください。このモジュールは完全なオープンソースであり、現在は IIS (英語)、ATS (英語)などへの移植が進行中です。

    不正なハッキングに対する #NoHacked キャンペーンを世界中で実施しました

    先日、Google サーチ クオリティ チームでは、#NoHacked キャンペーンと題して、サイトの不正なハッキングの問題を改めて知り、サイトを守るための Tips (ヒント)を 1 週間毎日発信するキャンペーンを全世界で行いました。

    このキャンペーンは、11 言語圏でGoogle+TwitterWeiboなど様々なチャンネルを舞台に実施しました。延べ 100 万人近い方が閲覧し、何百もの投稿の共有や、 #NoHacked のハッシュタグを使ったユーザー オリジナルの Tips 投稿が行われました。

    ここで、Google が投稿した 5 つの Tips を改めてご紹介するとともに、世界中から寄せられた素晴らしい投稿の一部をご紹介します。

    Tips その 1:
    今週はハッキングの予防について考えよう!

    Tips その 2:
    ウェブマスター ツールはハッキングからサイトを守る上でも役立ちます。使っていない方はぜひ登録を。お友達にもお知らせください。

    Tips その 3 :
    Google アラートを設定してハッキングの兆候をいち早くつかもう。

    Tips その 4:
    ソフトウェアは常に最新のものにアップデートしておこう。

    Tips その 5:
    ユーザーから寄せられたベスト投稿を発表!(各言語でベスト投稿を発表しました)

    世界中から寄せられた投稿のご紹介

    • ブラジルの Pablo Silvio Esquivel さんは海賊版ソフトウェアを使うことがハッキング被害の危険性につながることを紹介してくれました。
      https://plus.google.com/+PabloSilvioEsquivel/posts/9ahpESFwuac
    • オランダの Rens Blom さんは、パスワードを複数のアカウントで使いまわさず定期的に変更すること、そして 二段階認証 などのセキュリティ機能も使うことをおすすめしてくれました。
      https://plus.google.com/+GoogleNederland/posts/48e3VAsxddS
    • ロシアの Дмитрий Комягин さんは、日頃からサイトへのトラフィックや、検索クエリ、ランディング ページなどをモニターし、数値の想定外の急上昇などがないか把握しておくという方法を投稿してくれました。
      https://plus.google.com/+googleru/posts/CYwe6xf3Xvm
    • 日本の工務店コンサルタントさんは、実際に被害に遭われた際のレポートとそこから得た教訓として、ハッキング対策を適切に行っているホスティングを選ぶこと、ウェブマスター ツールのメール転送機能を設定しておくことなどを詳しくご紹介してくださいました。
      https://plus.google.com/+Asanoyukinobu/posts/hsKmoc2v2cZ
    • ポーランドの Kamil Guzdek さんは、WordPress をインストールした際に、table prefix をデフォルトのものからユニークなものへ変更することで、データベースがハッキングされるのを防ぐという tips を紹介してくれました。
      https://plus.google.com/+KamilGuzdek/posts/Gu63giLNTiZ
    今回、世界同時でキャンペーンを行ったこと、そして、世界中のユーザーからサイトの不正なハッキング対策が多く寄せられたことからもわかるように、サイトの不正なハッキングの問題は全世界的に広がりを見せています。どうぞ今回ご紹介した Tips と共に以下のサイトも参考にし、ご自身のサイトの設定をもう一度確認してみてください。
    ハッキングされたサイトに関するウェブマスター ヘルプ
    http://www.google.co.jp/webmasters/hacked/

    これからも全世界で Tips を共有し、サイトのハッキングと闘いましょう! #NoHacked のハッシュタグはこれからもご利用ください。また質問がある際はウェブマスター ヘルプ フォーラムをご利用ください(ハッキングに関するカテゴリも用意しています)。

    Google では今後もユーザー、ウェブマスターのみなさまのお役に立てる情報をどんどん発信していきたいと思っておりますので、ぜひ Google Webmasters ページGoogle Japan ウェブマスター コミュニティをフォローしてみてください。

    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 が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。

    robots.txt ファイルのテストが簡単になりました

    クロールするべきか、しないべきか、それが robots.txt の問題です。

    正しい robots.txt ファイルを作成して維持することは、ときに難しい場合もあります。ほとんどの場合はそうではありませんが(そもそも robots.txt ファイルを必要としないサイトも多くあります)、大きな robots.txt ファイル内で個々の URL をブロックしている(またはブロックしていた)指定を見つけることは、難しい作業となる場合もあるでしょう。そこで、robots.txt ファイルの編集を容易にするために、このたび、新しい robots.txt テスターを発表いたします。

    新しいテスターは、ウェブマスター ツールの [クロール] セクションにあります:


    ここでは、現在の robots.txt ファイルの確認、および URL のクロールがブロックされているかどうかのテストを行うことができます。複雑な指定をわかりやすくするため、最終的に決定に使われた箇所がハイライト表示されます。ファイルに変更を加えてテストを行うこともできます。変更を有効にするには、変更したファイルをサーバーにアップロードしてください。Google のデベロッパー サイトでは、robots.txt の指定とファイルの処理方法について詳しく説明しています (英語)。

    また、古いバージョンの robots.txt を確認したり、サーバー側の問題によってクロールがブロックされている状況を確認したりすることもできます。たとえば、robots.txt ファイルが Googlebot に対して 500 サーバー エラーを返している場合、通常そのサイトのクロールは一時停止されます。

    既存のサイトでエラーや警告が表示される可能性もあるため、robots.txt ファイルをよく確認することをおすすめします。また、robots.txt テスターをウェブマスター ツールの他の機能と組み合わせることも可能です。たとえば、新しい Fetch as Google を使用してウェブサイトの重要なページをレンダリングした際、ブロックされた URL が見つかったら、robots.txt テスターを使って、その URL をブロックしている指定を見つけて修正することができます。CSS、JavaScript、モバイル コンテンツをブロックする古い robots.txt ファイルが原因で問題が発生することはしばしばありますので、そのような問題は、修正すべき箇所がわかれば簡単に修正できます。

    今回更新したツールを使うことで robots.txt のテストとメンテナンスが容易になれば幸いです。何かご不明な点がある場合や、robots.txt の指定の作成についてアドバイスが欲しい場合などは、ぜひウェブマスター ヘルプ フォーラムをご利用ください。