投稿者: Google Webmaster Central

TC Summit 2015: ウェブマスター フォーラムのトップレベル ユーザーのみなさまに感謝を込めて

先週、米国カリフォルニア州サンフランシスコ、そしてマウンテンビューの Google 本社にて、「トップレベル ユーザー サミット 2015（#TCsummit）」を開催しました。今年も多くのトップレベル ユーザーとお会いできたことを非常に嬉しく思います。

トップレベル ユーザー（Google Top Contributors）は、豊富な製品知識と経験に基づいて、Google 公式ヘルプ フォーラムで世界中の数多くのユーザーのために多大な貢献を果たしてくださっている方々です。「トップレベル ユーザー サミット（Top Contributor Summit）」は、そのユーザー支援への「感謝」として 2 年ごとに開催されるイベントです。今回は 526 名のトップレベル ユーザーが世界中から集まりました。

“Learn, Connect, Celebrate” をモットーに、トップレベル ユーザーは Google のプロダクトについてさらに詳しく学び（= Learn）、Google の未来についてのインサイトを得て Google 社員と様々なトップレベル ユーザーがつながり（= Connect）、そして最後に Google のプロダクトやユーザーに対してトップレベル ユーザーが与えるポジティブな影響について称え合いました（= Celebrate）。
トップレベル ユーザー サミット 2015 の様子を映像でもお楽しみください

また、ウェブマスター関連のトピックに特化したセッションを開催し、ウェブマスター フォーラムの 20 カ国 14 言語を代表する 56 名のトップレベル ユーザーにお会いするという貴重な機会を得ることができました。
ウェブマスター フォーラムのトップレベル ユーザーと
Google のウェブマスター リレーションズ チームの集合写真

1 日をかけて Google のウェブマスター向けガイドラインや Search Console、Google 検索に関する様々な専門的なセッションを開催し、世界中のフォーラムでよく見られるトピックについて意見交換をしたり、検索関連のツールについてのフィードバックに耳を傾けました。また、トップレベル ユーザー プログラム自体やユーザーのために Google やトップレベル ユーザーがさらにどんなことができるかなどを話し合いました。Google のプロダクト マネージャーやエンジニア、そしてサーチ クオリティ チームがセッションに参加し話を伺い、トップレベル ユーザーや（フォーラム上で）ユーザーから寄せられたフィードバックをそれぞれのチームへ持ち帰りました。
ウェブマスター向けセッション中のトップレベル ユーザー
Google のウェブマスター向けガイドラインや Search Console、
Google 検索などについての専門的なセッションに耳を傾けています

トップレベル ユーザーのみなさんとのセッションは、わたしたち Google 社員にとっても様々な気づきや発見があり、ウェブマスター、コンテンツ制作者、そしてユーザーのみなさんが今どんなことを悩んでいるかを知ることができる貴重な機会となりました。こうした貴重な機会に、そしてトップレベル ユーザーのみなさんに感謝します。
日本から参加した様々なプロダクトのトップレベル ユーザーのみなさんと
Google 社員の集合写真。Google+ のコミュニティや
ハングアウトのグループ チャットなどを使って連絡を取り合いました

日本のウェブマスター リレーションズからは
長山と金谷が参加しました

今後も ウェブマスター ヘルプ フォーラム では、多くの方にトップレベル ユーザーとしてご参加いただきたいと思っています。トップレベル ユーザー プログラムの詳細についてはこちら をご覧ください。

Diogo Botelho and Roberta Remigi, Webmaster Relations team

望まない不正なモバイル リダイレクトを検出して除去する

端末の種類に応じて少し異なるコンテンツを表示することは、多くの場合問題ありません。たとえば、スマートフォンの小さな画面に合わせて最適化するために、画像などの一部のコンテンツを変更することもあるでしょう。また、ウェブサイトのメニューをナビゲーション ドロワー（詳しくはこちら）にすると、モバイルでの閲覧が簡単になります。このように、ユーザーのための修正が正しく実装されている場合は何ら問題ありません。

モバイル限定のリダイレクトについても同様です。ユーザー体験を改善するためにモバイルユーザーをリダイレクトする（たとえば example.com/url1 から m.example.com/url1 にリダイレクトする）ことは、ほとんどの場合ユーザーのためになります。一方、モバイル ユーザーを異なるコンテンツへ不正にリダイレクトすることは、悪いユーザー体験であるだけでなく、Google のウェブマスター向けガイドライン（品質に関するガイドライン）に違反する行為です。

苛立たしい体験: PC とモバイルの検索結果に同じ URL が表示され、PC でその検索結果をクリックするとページが正常に表示されるが、スマートフォンで同じ検索結果をタップすると無関係なページにリダイレクトされる。

モバイル限定の不正なリダイレクトを実装したのは誰？

ウェブマスター自身が、不正と認識しつつもモバイルユーザーにリダイレクト ルールを適用している場合があります。これはウェブマスター向けガイドライン（品質に関するガイドライン）に対する典型的な違反であり、Google ユーザーの体験に悪影響を及ぼしている場合は手動による対策の対象となります（この記事の最後の章を参照してください）。

一方、サイト所有者の知らないうちにモバイル限定の不正なリダイレクトが発生している場合もあります。

  • モバイルユーザーのみをリダイレクトする広告スキーム
    ディスプレイ広告や収益化コンテンツに組み込まれたスクリプトなどによって、ウェブマスターの知らないうちにモバイルユーザーが完全に別のサイトにリダイレクトされる場合があります。
  • サイトがハッキングされた結果として発生したモバイル リダイレクト
    その他のケースとしては、ウェブサイトがハッキングされており、スパム行為を行っているドメインにモバイルユーザーのみがリダイレクトされている場合もあります。

サイトでの不正なモバイル リダイレクトを検出するには

  1. スマートフォンでサイトにアクセスしてリダイレクトされるかどうか確認する
    スマートフォンの Google 検索結果からサイトにアクセスして、モバイル ユーザーのエクスペリエンスを確認することをおすすめします。デバッグの際にデスクトップ ブラウザでモバイル エミュレーションを行うと、各種端末をまとめてテストできて便利です。たとえば Chrome、Firefox、Safari などのブラウザから簡単にエミュレーションできます（Safari の場合は、「メニューバーに “開発” メニューを表示」機能を有効にする必要があります）。
  2. ユーザーの声を聞く
    ユーザーには、サイトが本来とは異なる形で表示されているかもしれません。モバイルユーザーの体験に関する問題を察知するには、常にユーザーの不満に耳を傾けることが重要です。
  3. サイトのアナリティクス データでユーザーのアクティビティを観察する
    モバイルユーザーの行動に異常がある場合、ウェブサイトのアナリティクス データをよく観察することで検出できます。たとえば、モバイルユーザーの平均サイト滞在時間は気をつけて見ておくべき指標です。モバイルユーザーの滞在時間が以前に比べ極端に短くなった場合、モバイル限定のリダイレクトが発生している可能性があります。

モバイルユーザーの行動に大きな変化があった場合にすぐ気付けるよう、Google アナリティクスの通知を設定しておくことをおすすめします。たとえば、モバイルユーザーのサイト滞在時間が急に短くなった場合や、モバイルユーザーのアクセスが急に減った場合に警告する通知を設定できます（ただし、これらの指標が大きく変化したからといって、必ずしも不正なモバイル限定のリダイレクトが発生しているとは限りません）。

モバイル ユーザーが不正にリダイレクトされていることを検出しました。私が設定したものではありません。どうしたらよいですか？

  1. サイトがハッキングされていないかどうか確認する
    Search Console のセキュリティの問題を確認します。ハッキングされている場合は、ここに何らかの情報が表示されています。
    ハッキングされたサイトの典型的な症状や、ハッキングされたサイトの事例も参考にしてください。
  2. サイト上のサードパーティのスクリプトや要素を調査する
    サイトがハッキングされていない場合は、サードパーティのスクリプトや要素がリダイレクトを発生させていないか調査することをおすすめします。この調査は次の手順で行います。
    1. リダイレクト元のページから、自分で管理していないサードパーティのスクリプトや要素を 1 つずつ削除します。
    2. 1 つのスクリプトまたは要素を削除するたびに、携帯端末またはエミュレーションでサイトからのリダイレクトがなくなったかどうか確認します。
    3. 不正なリダイレクトの原因となっているスクリプトまたは要素を特定できたら、それをサイトから削除することを検討します。また、そのスクリプトまたは要素の提供元と問題の解決にあたってください。

不正なモバイル リダイレクトについて最後にお伝えしたいこと

検索エンジンのクローラに表示されるコンテンツとは異なるコンテンツを表示するために意図的にユーザーをリダイレクトする行為は、Google ウェブマスター向けガイドライン（品質に関するガイドライン）に違反しています（詳しくは不正なリダイレクトをご覧ください）。Google サーチ クオリティ チームでは、ユーザーに高品質な検索結果を提供するため、このようなサイトの URL を Google のインデックスから削除するなどの対策を講じています。手動による対策を講じる際には、Search Console を通してサイト所有者にメッセージを送信します。Search Console アカウントを正しく設定されているか確認するようにしてください。

知らない間にユーザーがリダイレクトされてしまうのを防ぐには、ユーザー トラフィックをどのように処理するかを明確にしている広告主を選ぶようにします。オンライン広告スペースを信頼できる広告主に提供したいとお考えの場合は、広告ネットワークに参加するにあたっての業界推奨の方法がありますので参考にしてください。手始めに、Trustworthy Accountability Group（Interactive Advertising Bureau, IAB）の Inventory Quality Guidelines をご覧になることをおすすめします。モバイル ソリューションを活用して高品質のユーザー エクスペリエンスを提供しながら、コンテンツを収益化する方法はたくさんあります。ぜひこれらを上手く活用してください。

モバイル限定のリダイレクトについてご意見、ご不明な点などございましたら、Google ウェブマスター フォーラムに投稿してください。

Posted by Vincent Courson & Badr Salmi El Idrissi, Search Quality team

AJAX クロールに関するスキームを廃止します

今後 Google では、 2009 年に提案した AJAX クロールを推奨しません。

Google は、2009 年に AJAX ページをクロール可能にすることを提案しました。その当時、検索エンジンは JavaScript を使ってコンテンツを提供するページをレンダリングして理解することができなかったのです。これは、「クローラが … 動的に作成された … コンテンツを認識 [できなかった]」ことによるものです。その対策として、AJAX ベースのアプリケーションが検索エンジンに確実にインデックス登録されるよう、ウェブマスターの皆様にいくつかの方法を提案しました。

しかし現在は、サイト側で Googlebot による JavaScript や CSS のクロールをブロックしていない限り、最新のブラウザと同じようにウェブページをレンダリングして理解できるようになっています。この改良に伴い、技術に関するウェブマスター向けガイドラインを更新し、Googlebot による JavaScript や CSS のクロールをブロックしないことを推奨することにしました。

Google の 2009 年の提案は、もう有効なものではありませんので、今後は拡張を前提とした作成（いわゆるプログレッシブ エンハンスメント）の原則に沿って開発を進められることを推奨します。たとえば、HTML5 の History API を使用することで、Google のシステムだけでなく幅広いブラウザが履歴にアクセスできるようにすることが可能です。

質問と回答

Q: 私のサイトでは、Google の推奨に沿って _escaped_fragment_ をサポートしています。この推奨が廃止されると、サイトがインデックス登録されなくなるのですか？
A: いいえ、サイトは引き続きインデックス登録されます。次回サイトを更新する際には、業界で最適とされている方法を実装することをおすすめします。Google では、_escaped_fragment_ URL の代わりに #! URL をクロール、レンダリング、インデックス登録します。

Q: AJAX クロールの提案から業界で最適とされている方法に移行すると、サイトの移転と見なされますか？リダイレクトを実装する必要はありますか？
A: もし現在の設定がうまく行っているのであれば、さしあたってなにがしかの変更を行う必要はありません。ただ、新しいサイトを作成する際、あるいはサイトのリニューアルを行う際に _escaped_fragment_ URL に対応する必要はありません。

Q: JavaScript フレームワークを使用し、Googlebot にはプリレンダリングしたページを提示しています。このままで問題ありませんか？
A: 通常、Google のためだけにプリレンダリングする必要はありません。プログレッシブ エンハンスメントの原則に沿いつつ、パフォーマンス最適化のためプリレンダリングを行う場合、プリレンダリングしたコンテンツと、通常のユーザーに対して表示するコンテンツが、見た目上も体験上も同じになるようにしてください。Googlebot に対して提示するコンテンツと、通常のユーザーに対して表示するコンテンツが異なる場合はクローキングと見なされ、ウェブマスター ガイドライン違反と判断されることがあります。

ご不明な点がございましたら、この記事にコメントするか、ウェブマスター プロダクト フォーラムに投稿してください。

Posted by Kazushi Nagayama, Search Quality Analyst
Original version: Official Google Webmaster Central Blog: Deprecating our AJAX crawling scheme

First Click Free のポリシー変更のお知らせ

10 年ほど前に「First Click Free」というポリシーを導入した当時は、現在のような常時接続、マルチスクリーン、マルチデバイスの環境がコンテンツの利用形態をこれほど急速かつ劇的に変化させるとは想像できませんでした。First Click Free（FCF）の目的は、ユーザーが質の高いニュースに最小限の手間でアクセスできるようにする一方で、有料の定期購入モデルを提供するサイト運営者のコンテンツが Google 検索や Google ニュースで発見されやすくすることでした。そしてそのコンセプトは今も変わりません。

2009 年、Google は FCF ポリシーを変更（英語）し、無料で読める記事を 1 日あたり 5 本までとする制限を設けました。これは、一部のユーザーによって FCF ポリシーが悪用されていると感じているサイト運営者を保護するためでしたが、さらに最近になって、現在のモバイルやマルチデバイス環境をこのポリシーに反映させる必要があるとの声がサイト運営者から寄せられました。そこで Google では本日、FCF の制限を 1 日あたり 3 本までに変更いたします。この変更は Google 検索と Google ニュースの両方に適用されます。

Google では、ユーザーと質の高いニュースを、そしてコンテンツを提供するサイト運営者とユーザーを結び付けるという役割を担いたいと考えており、その目標を達成するうえで FCF を重視しています。今後もポリシーの見直しを定期的に行い、必要に応じて変更し、引き続きユーザーにもサイト運営者にもメリットを提供できるように努めてまいります。いつでもお気軽にフィードバックをお寄せください。

First Click Free に関するよくある質問
Q: 以前のガイドラインのその他の部分は引き続き適用されますか？
A: はい。詳細については、Google ニュースのガイドラインとウェブ検索のガイドラインと、関連するブログ記事（英語）をご覧ください。

Q: First Click Free を、サイトの一部のセクションのみ、または Google ニュース向け（またはウェブ検索）のみに適用することはできますか？
A: もちろん可能です。Googlebot とユーザーのどちらにも、適切な検索結果から必要に応じてコンテンツを表示できるようにしてください。なお、Googlebot にページのコンテンツ全体を表示する一方で、ユーザーに登録ページを表示する行為は「クローキング」と見なされますので、ご注意ください。

Q: First Click Free の使用には登録が必要ですか？
A: Google ニュースで使用する場合は、First Click Free を使用するという判断を Google にお知らせください（英語）。Google ウェブ検索については、First Click Free のステータスをお知らせいただく必要はありません。

Q: ユーザーのアクセスをカウントするおすすめの方法は何ですか？
A: サイトのアーキテクチャは多種多様なため、この点についてはサイト運営者のご判断にお任せしたいと思います。
（Google ニュースでの First Click Free の詳細については、関連するブログ記事（英語）をご覧ください。）

Posted by John Mueller, Google Switzerland
Original version: Official Google Webmaster Central Blog: First Click Free update

不正なハッキングに対する新たな取組について

このたび Google では、Google の検索結果に表示されるサイトの不正なハッキングに取り組むことを目的に、一連のアルゴリズムの変更を順次公開しました。現在、膨大な数のサイトがスパマーによってハッキングされ、品質の低いサイト、マルウェアのダウンロード、成人向けコンテンツ、偽造品や違法薬物の販売などへのトラフィックの誘導に使用されています。

セキュリティを確保するためのベスト プラクティスを実装していないウェブサイトは、このようなハッキングの攻撃を受けやすくなります。こうしたウェブサイトの例には、政府、大学、中小企業、企業、レストラン、同好会、会議などのサイトが含まれます。スパマーやサイバー犯罪者は、こうしたサイトを意図的に探し出し、悪意のあるコンテンツを含むページを挿入して、それが検索エンジンに掲載されることでトラフィックを増やそうとします。

Google では、ユーザーとウェブマスターを保護するため、ハッキングへのスパム対策に積極的に取り組んでいます。

言語によって異なりますが、今回のアルゴリズムの変更は、およそ 5% のクエリに影響します。新しいアルゴリズムの順次公開に伴い、特定のクエリについては、表示される検索結果数が減り、関連性の高い結果のみが表示されるようになります。



これは、膨大な数の不正なハッキングを削除した結果であり、今後も改善していく予定です。Google では、正当な検索結果を保持しながら、悪質なコンテンツを排除すべく、システムの調整に引き続き取り組んでいきます。今回のアルゴリズムの変更についてご質問やフィードバックがありましたら、ウェブマスター プロダクト フォーラム までお気軽にお寄せください。

Posted by Ning Song, Software Engineer

ハッキングされたサイトの再審査リクエストに対するサポートについて

2015 年現在、ハッキングされたサイトの数は 180% 増加し、ハッキングされたサイトからの再審査リクエストの数は 300% 増加しています。Google では、ウェブマスターが初めからハッキングを防止できるよう、ブログ記事「サイトの不正なハッキングをいち早く見つける 3 つの方法」や #NoHacked キャンペーンなどの取り組みを通じてサポートしています。今回は、実際にハッキングの被害にあってしまったウェブマスターに向けて、再審査リクエストをより迅速に、容易にするために、Google が現在努力を注いでいる以下の３点についてご紹介します。

1）コミュニケーションの改善
2）ツールの改善
3）継続的なフィードバック ループ

1. ハッキングされたサイトのウェブマスターとのコミュニケーションの改善

昨年、Google では再審査プロセスに「審査担当者からのお知らせ」機能を導入しました。この機能により、再審査リクエストに応じて各ケースに合った具体的な例やアドバイスをウェブマスターに提供できるようになりました。2015 年の現時点までに、ハッキングに関する再審査リクエストが承認されなかったウェブマスターの 70% 以上に対し、カスタマイズしたお知らせを送信し、まだハッキングされたコンテンツが残っている箇所やそれらを見つけ出す方法を具体的にお伝えしてきました。その成果は良好であり、ハッキングに関する手動による対策がサイトに適用されてから、ウェブマスターが問題を解決し、その手動による対策が解除されるまでの平均所要時間を 29% 短縮することができました。

詳細なガイドを含む「審査担当者からのお知らせ」の例と、ハッキングされたテキストやハッキングされたページのカスタム例

Google では、2 回目となる #NoHacked キャンペーンも実施し、ハッキングの防止と復旧をより細かくサポートしました。これは、サイトのセキュリティを改善する方法と、サイトが侵害された場合にサイトを修正する方法に焦点を当てたキャンペーンでした。最初の投稿は ブログ記事「#NoHacked キャンペーンを開始します: 不正なハッキングの標的にならないようにするには」でご覧いただけます。

2. ツールの改善（ハッキングに関する手動による対策の自動解除など）

昨年、Google では Fetch as Google ツールに「取得してレンダリング」機能を導入しました。この機能により、ウェブマスターはウェブサイトが Googlebot にどのように見えているか正確に確認できます。この機能がハッキングからの復旧に役立つのは、多くのハッカーが挿入するクローキング コンテンツは、人間のユーザーには表示されませんが、Googlebot などの検索エンジン クローラは認識できるからです

今年は、サイトがハッキングされた場合のトラブルシューティングも 23 言語で公開しました。これに沿うことで、ウェブマスターはハッキングから復旧するための基本的な手順を確認できます。ご利用の際は、トラブルシューティングが役に立ったかどうかをお知らせいただけると助かります。Google では、トラブルシューティングの機能性と効果の向上に引き続き努めていきます。

さらに、Google ではハッキングに関する手動による対策の一部について、自動解除のベータ版テストも行っています。Search Console で [部分一致] に「ハッキングされたサイト」に対する手動による対策が表示されている場合、ハッキングされたコンテンツが存在しなくなったことが Google のシステムで検出されると、その手動による対策が自動的に解除されることがあります。手動による対策が表示された場合はこれまでどおり再審査リクエストを送信することをおすすめしますが、「ハッキングされたサイト」に対する手動による対策の表示が消えても驚かないでください。

[部分一致] に表示される、ハッキングされたサイトに対する手動による対策の例: ハッキングされたコンテンツが存在しなくなったことが検出されると、手動による対策が自動的に解除されることがある

3. フィードバックの提供をお願いし、対策を講じる

このようなコミュニケーションとツールの改善は、ハッキングされたサイトのウェブマスターから寄せられたフィードバックによってもたらされました。たとえば、今年の初め、Google では米国のマウンテン ビューとアイルランドのダブリンにおいてブレインストーミング セッションを開催し、ハッキングに関する再審査プロセスを経験したウェブマスターを招待しました。また、ハッキングに関する再審査を経験したウェブマスターを対象にサンプリング調査も行いました。その結果、再審査プロセスに不満を感じたウェブマスターは 15% のみでしたが、これらのウェブマスターが直面した主な課題として、ハッキングされたサイトに関する通知とハッキングの解決方法がわかりにくいということが判明しました。このフィードバックは、ハッキングからの復旧に関する詳しいブログ記事だけでなく、最新の #NoHacked キャンペーンの多くのコンテンツの執筆において役に立ちました。

（高解像度バージョン）https://goo.gl/photos/TkvkwYt23MpVHBwz6

ダブリンでは地元のウェブマスターとのミーティングの後に、ハッキングに関する再審査プロセスを改善する方法についてブレインストーミングを行いました

Google では、上記の方法だけでなく、ハッキングされたサイトに関するウェブマスター ヘルプや、セキュリティ、マルウェア、ハッキングされたサイトに関するフォーラムのセクションを通じて、ハッキングされたサイトのウェブマスターを引き続きサポートしていきます。ハッキングされたウェブサイトからの復旧をどうすれば Google がより適切にサポートできるか、ウェブマスター ヘルプ フォーラムや Google ウェブマスター コミュニティへご意見をお寄せください。


Posted by Josh Feira and Yuan Niu, Search Quality Team
Original version: Official Google Webmaster Central Blog: Helping hacked sites with reconsideration requests

ウェブマスター向けガイドライン違反を繰り返すサイトについて

Google では、検索結果の品質を守るために、品質に関するウェブマスター向けガイドラインを設定し、それに違反するサイトに対して、その掲載順位を下げる、あるいは検索結果から削除するなどの、自動及び手動による対策を施しています。あなたのサイトに手動による対策が施されている場合、その対策を解除するには、Search Console 内の [手動による対策] ページからその理由や適用範囲を確認し、それを参考にして違反箇所を削除した上で再審査リクエストを Google に送信します。これにより、数多くのウェブマスターが手動による対策を解除されています。

しかし、手動による対策が解除された後すぐに、その原因となった施策を再度サイトに施す、という例が最近になってしばしば確認されています。例えば、サイトからの不自然なリンクを理由として手動対策を受けたウェブマスターが、一旦当該リンクを nofollow として再審査リクエストを送り、成功裏に再審査が終わった後、すぐに nofollow を取り外す、といったようなことです。そういった形でウェブマスター向けガイドライン違反を繰り返しているサイトは、再審査リクエストにおいて通常よりも厳しく審査する可能性があります。特に、悪意を持ってガイドライン違反を繰り返している場合、手動による対策において、更に厳しい対処を取る場合があります。

そうした事態を避けるためにも、ウェブマスターのみなさまには、品質に関するウェブマスター向けガイドラインの違反を行わないこと、そして意図的な違反の繰り返しをしないことを強くお勧めいたします。サーチ クオリティ チームは、今後とも、ユーザーを守るために、検索結果からのスパムの排除に全力で取り組んでまいります。

Posted by: Google サーチ クオリティ チーム

スクリプトを用いた CSV ファイル ダウンロードについてのお知らせ

先日の新しい検索アナリティクス (Search Analytics) API の登場により、デベロッパーの皆さまは検索クエリやランキングの情報へさらに簡単にアクセスできるようになりました。これを踏まえて、Google では、スクリプトによる CSV ダウンロードのためのアクセスを 2015 年 10 月 20 日に廃止する予定です。
上記のようなスクリプトを用いた CSV ファイルのダウンロードは、長年様々なサイトやツールにおいて利用され、検索クエリやインプレッション数、さらにクリック数やランキングといった情報の取得に活用されてきました。しかし、そこで取得できるデータは新しい検索アナリティクスのものではなく、すでに廃止された ClientLogin API に基づいたものでした。

当該機能は上記日程にて終了となりますが、これからは検索アナリティクス API が皆さまのお役に立つと私たちは考えています。すでに、新しい検索アナリティクス API について多くの活用例が報告されています。皆さまも、新しい検索アナリティクス API の有効な活用事例をお持ちの場合は、ウェブマスター ヘルプ フォーラムや Webmaster Japan コミュニティにて私たちにぜひお知らせください！

Posted by John Mueller, Webmaster Trends (and query, impression, & click trends) Analyst
Original version: Official Google Webmaster Central Blog: An update on CSV download scripts

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

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

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

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

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

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


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

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

Posted by Daniel Bathgate, Software Engineer, Google Search.
Original version: Official Google Webmaster Central Blog: Mobile-friendly web pages using app banners

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

本日は #nohacked キャンペーンの一環として、先週ご紹介した、スパム ページがサイトに挿入されるという、最近よく見られるハッキングの問題を解決する方法についてお話しいたします。たとえサイトがこの種のハッキングの被害を受けていなくても、ここで紹介する手順の多くは、他の種類のハッキングの問題を解決する際にも役立つと思われますので、ぜひお読みください。（本キャンペーンは、Twitter や Google+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #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 Decoder、UnPHP: ハッカーは通常、読み取りが困難になるよう PHP ファイルを難読化します。これらのツールを使うと、PHP ファイルの実行内容を把握しやすくなります。

Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst
Original version:#NoHacked: Fixing the Injected Gibberish URL Hack

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

本日は #NoHacked キャンペーンの一環として、最近よく見られるハッキング手法、そしてその監視、調査方法についてお話しします。たとえサイトがこの種のハッキングの被害を受けていなくても、ここで紹介する手順の多くは、他の種類のハッキングに対処する際に役立ちますので、ぜひご覧ください。なお、来週のブログ記事では、このハッキングの問題を解決する方法について紹介する予定です。（本キャンペーンは、Twitter や Google+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #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 のみです。
VirusTotal、Aw-snap.info、Sucuri Site Check、Wepawet: これらのツールでは、サイトをスキャンし、問題のあるコンテンツがあるかどうかを調べることができます。ただし、いずれのツールも、問題のあるコンテンツをすべて特定することを保証しているわけではありませんのでご注意ください。


Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst
Original version:#NoHacked: Identifying and Diagnosing Injected Gibberish URL Hacking

検索アナリティクス API のご紹介

Google Search Console の検索アナリティクス（Search Analytics）機能からの有益なフィードバックを検討した結果、このデータを API を通じてデベロッパーの皆さまにもご提供することになりました。検索アナリティクス API によって、検索のパフォーマンス データをアプリやツールに統合しやすくなります。

Google の他の API や既存の Search Console API を使用した経験があるなら、検索アナリティクス API の使用は簡単です。ハウツーページのドキュメント（現在は英語版のみ）には Python の例が掲載されており、ご自身のプログラムの参考例としてご利用いただけます。たとえば、この API を次のような用途に使用できます。

[上記のドキュメントは現在英語でのみ提供されています。ご自分の地域の言語での翻訳版があれば役立つと思いますか？こちらからご意見をお寄せください。]

新しい API で何を作成しますか？Google では、この API を使用した新しいツールやアプリが、Google 検索におけるサイトのパフォーマンス情報の収集にどのように役立つかを知りたいと考えています。この API をツールに統合された場合は、ぜひコメント欄で感想をお寄せください。API に関してご質問がありましたら、いつでもウェブマスター ヘルプ フォーラムまでお寄せください。

Posted by: John Mueller, Webmaster Trends Analyst, Google Switzerland
Original version: Official Google Webmaster Central Blog: Introducing the Search Analytics API

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

本日は、#NoHacked キャンペーンの一環として、2 段階認証プロセスについてお話しいたします。（本キャンペーンは、Twitter や Google+ でも展開していますので、ぜひフォローしてみてください。ハッシュタグは #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 日には、セキュリティをテーマとしてハングアウト オンエア（英語）も予定されています。ぜひご参加ください。

Posted by:Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst
Original Version:#NoHacked: Using two-factor authentication to protect your site

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

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

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

フィッシング

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

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

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

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

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

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

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

Posted by: Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
Original version: #NoHacked: How to recognise and protect yourself against social engineering

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

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

Google では、本日からおよそ 1 か月間、 #NoHacked キャンペーン を再び実施します。キャンペーン期間中、不正なハッキングからサイトを保護する方法に焦点を当て、それぞれの方法がどのように機能するかについて理解を深めていただきたいと思っています。#NoHacked キャンペーンについては、Twitter や Google+ でもフォローできます。また、セキュリティをテーマとした 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 でぜひ共有してください。

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

Posted by: Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
Original version: #NoHacked: How to avoid being the target of hackers

Autocomplete API の今後のご利用について

Google 検索では、ユーザーが入力を終える前にクエリを予測するオートコンプリート サービスを提供しています。これまで何年もの間、数多くのデベロッパーが、公開されていない非公式の API を使ってオートコンプリートの結果を自らのサービスに統合してきました。この API には使用の制限もありませんでした。Autocomplete API の存在を知るデベロッパーは、Google 検索に関係のない形でオートコンプリート サービスを組み込むことが可能となっていました。

これまでに何度か、デベロッパーのコミュニティが非公開の API を介して Google サービスをリバースエンジニアリングすることで、大きな進歩につながった事例があります。たとえば、Google Maps API は、創造力のあるエンジニアの手によって地図データと他のデータソースを結合したものが登場してから数か月後、公式にサポートされる API となりました。現在、Google では 80 以上の API をサポートしており、デベロッパーはこれらを使って Google のサービスやデータを自らのアプリケーションに統合することができます。

しかしながら、サポートされていない非公開の API の使用には、ある日突然 API が利用できなくなるというリスクが伴うこともあります。今回もそのような状況のひとつです。

オートコンプリートは Google 検索の補完機能のひとつとして構築されたもので、ユーザーの検索クエリの予測という目的から離れて使用されることは一切意図されていません。オートコンプリートのデータフィードには検索結果の他にも有用な用途があるといえるものの、全体としてオートコンプリートのコンテンツは検索結果とともに使用する意図のもとに最適化されており、ウェブ検索以外の状況ではユーザーに重要なメリットをもたらさない、ということが時間の経過とともにわかってきました。

そこで、Google 検索の一部というオートコンプリートの位置づけを保つため、2015 年 8 月10 日より、非公開の Autocomplete API に対する未許可のアクセスを制限します。Google ではオートコンプリートを、Google 検索と密接に関係したサービスという設計時の用途に沿った形でユーザーの皆様にお使いいただけるようにすることを目指しています。そうすることで、検索とオートコンプリートの両方のサービスにおいて最適なエクスペリエンスを提供できると考えています。

サイトで引き続きオートコンプリート サービスをお使いになりたいサイト運営者およびデベロッパーの皆様は、Google カスタム検索エンジンをお使いいただくと、サイトで検索機能とともにオートコンプリート機能をご利用いただけます。既に Google カスタム検索エンジンをお使いのパートナー様には今回の変更による影響はございません。それ以外の皆様で 2015 年 8 月 10 日以降も引き続きオートコンプリート機能をお使いになりたい場合は、カスタム検索エンジンの登録ページをご覧ください。

Posted by Peter Chiu on behalf of the Autocomplete team
Original version: Official Google Webmaster Central Blog: Update on the Autocomplete API

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 以下では表示されています。）

Posted by David Morell, Software Engineer, Google+
Original version: Official Google Webmaster Central Blog: Google+: A case study on App Download Interstitials

新しいトップレベル ドメイン（gTLD）に対する Google での取り扱いについて

新しいジェネリック トップレベル ドメイン（gTLD）が数多く登場していますので、Google の検索でどのように処理しているかについて説明しておきたいと思います。新しいトップレベル ドメイン（.guru、.how、.ブランド名 gTLD など）の処理については、以下に挙げるようにさまざまな疑問や誤解があるようです。

Q: 新しい gTLD は検索に影響しますか？Google は、新しい TLD が有利になるようアルゴリズムを変更しているのですか？検索において、新しい TLD はどの程度重視されるのですか？
A: 基本的に、新しい gTLD も他の gTLD（.com、.org など）と同じように処理されます。検索において、特定の TLD のキーワードが有利に働くことも不利に働くこともありません。

Q: 「.みんな」のような IDN TLD も、Googlebot がクロールしてインデックス登録し、検索で使用できるようになるのですか？
A: はい。このような TLD も、他の TLD と同じように使用できます（[site:みんな] を検索すると簡単に確認できます）。Google では、Punycode バージョンのホスト名を Unicode バージョンと同等のものとして処理します。したがって、リダイレクトしたり別々に正規化したりする必要はありません。URL の残りの部分に非 ASCII 文字を使用する場合は、URL 内のパスやクエリ文字列に必ず UTF-8 を使用してください。

Q: .ブランド名 TLD の扱いが .com と異なることはありますか？
A: いいえ。そのような TLD も他の gTLD と同じように扱われます。同じ地域ターゲティング設定が必要ですし、URL のクロール、インデックス登録、ランク付けにおいてウェイトや影響が異なるということもありません。

Q: 地域や都市の TLD（.london、.bayern など）はどう処理されますか？
A: 地域固有の TLD も gTLD と同じように処理します。.eu や .asia などの地域 TLD と同じ扱いということです。ただし、実際にどう使用されているかによって、多少の例外がある場合もあります。詳しくは、ヘルプセンターの多地域、多言語のサイトをご覧ください。必要な場合は、Search Console で地域ターゲティングを設定してください。

Q: 従来の ccTLD（国別コード トップレベル ドメイン）はどうですか？Google では、.uk、.jp などの ccTLD を、その国で検索している人のローカル ドメインとして重視しますか？
A: Google の既定の処理では、ほとんどの ccTLD（例外あり）をウェブサイトの地域ターゲティングに使用しています。ccTLD を見れば、そのウェブサイトが該当の国に関係している可能性が高いと判断できます。詳しくは、ヘルプ記事「多地域、多言語のサイト」をご覧ください。

Q: ドメインを .com から新しい TLD に移転する場合、SEO に関して Google のサポートを受けることはできますか？ウェブサイトを移転する際、検索のランキングや履歴を維持するにはどうしたらよいですか？
A: ヘルプセンターのドキュメントで、サイトの移転について詳しく説明しています。Google では、新しい TLD への移転も他のサイト移転と同じように扱います。ドメインを変更すると検索のための処理に時間がかかるだけでなく、検索以外の面でも、メールアドレスが長期間変わらないことをユーザーは期待するものなので、できるだけ長期間使用できるドメインを選択することが重要です。

今回は、Google が新しいトップレベル ドメインをどのように処理しているかについて説明しました。他にご不明な点などありましたら、ウェブマスター ヘルプ フォーラムで質問してください。

Posted by John Mueller, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Google's handling of new top level domains

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 をアプリの共有フローやメール キャンペーンなどに統合します。これにより、アプリに直接アクセスできるディープリンクをプログラムによって生成できるようになります。
この新機能を活用し、クロスプラットフォームでのリンクの共有にお役立てください。

Posted by Fabian Schlup, Software Engineer
Original version: Official Google Webmaster Central Blog: App deep linking with goo.gl

iOS アプリ内のコンテンツも Google 検索に表示されるようになりました

Google では、ユーザーが Google 検索結果で簡単に関連性の高い Android アプリ内のコンテンツを見つけることができるような仕組みとして、App Indexing を提供してきました。本日より、iOS アプリでも同じ仕組みをご利用いただけるようになりました。これにより、Android ユーザーも iOS ユーザーも、Google 検索結果からモバイルアプリのコンテンツを直接開けるようになります。

今後数週間のうちに、いくつかのアプリのディープリンクが、Google アプリあるいは Chrome を利用しているログイン済みの iOS ユーザーの検索結果上に現れるようになります。

iOS アプリをインデックスに登録する方法

iOS 向け App Indexing はまず、小規模のテスト パートナー様を対象に開始いたします。Google では、できるだけ早く他のアプリ開発者様にもこの技術をご利用いただけるよう取り組んでいます。まずは iOS 向け App Indexing をご利用いただくための準備として行っていただける手順を以下にご紹介します。
今週の Google I/O に参加される方は、「Get your app in the Google index（アプリを Google のインデックスに登録する）」というタイトルのセッションで App Indexing について詳しく解説しますのでぜひ足をお運びください。iOS 向け App Indexing に関しては g.co/AppIndexing でも詳細なドキュメントをご覧いただけます。
他にご不明な点がある場合は、ウェブマスター ヘルプ フォーラムでご質問ください。

Posted by Eli Wald, Product Manager
Original version: Official Google Webmaster Central Blog: Surfacing content from iOS apps in Google Search