攻撃からサイトを守るためには、サイトへの不正アクセスがどのように発生したかを把握することが重要です。ここでは、スパマーが主にどのような方法でサイトに不正アクセスするかを説明します。

提供元に注意を払い、無料提供の有料テーマやプラグインに十分気をつける

有料のプラグインが無料で提供されているサイトを見かけたことがある方もいらっしゃるかと思います。通常は購入しなければならないプラグインを無料で提供しているサイトに遭遇した場合は、十分にご注意ください。多くのハッカーは、人気のプラグインをコピーしておとりに使い、「バックドア」（マルウェア）を設置して対象のサイトに侵入できるようにします。同様のケースについて詳しくは、Sucuri 社のブログ（英語）をご覧ください。
また、質の高い正規のプラグインやテーマであっても、次のような場合は危険なものとなる可能性があります。

• 新しいバージョンが入手可能となったときにすぐに更新しない
• テーマやプラグインのデベロッパーが更新を行わないので、時間の経過とともに古くなる

どのような場合でも、サイトのソフトウェアをすべて常に最新の状態にしておくことは、ウェブサイトをハッカーから守るうえで不可欠です。

WordPress のボットネット

ボットネット（英語）とは、第三者の管理下にあるマシンやデバイス、ウェブサイトの集まりで、多くの場合、悪意のある行為（ウェブスパムのキャンペーン、クリックボット、DDoS など）を働くのに利用されるものです。サイトがボットネットに乗っ取られていても、サイトには明確な変化が生じることがほとんどないため、見つけるのは困難です。しかし、サイトがボットネットに取り込まれると、サイトの評判、リソース、データが危険にさらされることになります。ボットネットの詳細や、ボットネットの検出方法、ボットネットがサイトに及ぼす影響について詳しくは、WordPress や Joomla! のボットネットに関する記事（英語）をご覧ください。

ご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご投稿ください。それでは、また来週お会いしましょう。

サイトがハッキングされる原因とは何でしょうか。ハッカーがウェブサイトに不正アクセスする目的はさまざまであり、ハッキング攻撃はそれぞれまったく異なるため、いつも簡単に見つかるとは限りません。ハッキングされたサイトを見つけるのに役立つヒントをいくつかご紹介します。

• はじめに:
  
  Google や他のサービスからセキュリティに関する通知を受け取った場合は、まず、「サイトがハッキングされているかどうかを確認する方法」のガイドをご覧ください。このガイドでは、サイトに不正アクセスの形跡がないかチェックするための基本的な手順をご案内しています。
• Google 検索で表示されるアラートについて:
  
  Google は様々な方法でマルウェアや不正なハッキングを検出しています。マルウェアの検出ツールでは、不正なハッキングは検出されません。つまり、セーフ ブラウジングのサイト ステータスで問題がなくても、それはあなたのサイトがハッキングされていないとは限りません。
• 「このサイトは第三者によってハッキングされている可能性があります」というメッセージがあなたのサイトの検索結果に表示された場合は、あなたのサイトは不正にハッキングされ、改ざんされているおそれがあります。
• サイト URL の下に「このサイトはコンピュータに損害を与える可能性があります」と表示された場合、アクセスしようとしているサイトは、プログラムにより悪意のあるソフトウェアがパソコンにインストールされるおそれがあるものと見なされています。
• サイトが表示される前に大きな赤い警告画面が表示された場合は、さまざまなケースが考えられます。
• 「アクセス先のサイトで不正なソフトウェアを検出しました」と表示された場合、サイトがマルウェアの配布に利用されていることが Google で検出されています。
• 「アクセス先のサイトには有害なプログラムがあります」と表示された場合、サイトで望ましくないソフトウェアが配布されていると見なされています。
• 「偽のサイトにアクセスしようとしています」という警告は、サイトでフィッシングやソーシャル エンジニアリングが行われている可能性があることを示しています。サイトがハッキングされ、このような行為に利用されているおそれがあります。
• マルバタイジングとハッキングの違い:
  
  マルバタイジング（悪意ある広告）による悪質なサイトへのリダイレクトは、あなたのサイトに掲載している悪質な広告によって引き起こされます。サイトの閲覧者を他のサイトにリダイレクトしてしまうため、あなたのサイトがハッキングされたと感じるかもしれませんが、実際には悪質な広告による仕業です。
• オープン リダイレクト: サイトでオープン リダイレクトが有効になっていないかどうかを確認する
  
  ハッカーは、自身の URL を隠すために正規のサイトを悪用する場合があります。その方法の 1 つに、オープン リダイレクトを利用して、サイトにアクセスしたユーザーをハッカーの選んだ URL にリダイレクトさせるという手法があります。こちら（英語）で詳細をご覧いただけます。
• モバイル チェック: 必ずモバイル ブラウザからシークレット モードでサイトを表示してみましょう。不正なモバイル広告ネットワークがないかチェックしてください。
  
  広告や他のサードパーティ要素などの不正なコンテンツによって、知らないうちにモバイル ユーザーがリダイレクトされることがあります。こうした行為は、特定のブラウザからしか見えないため、検出されにくいものです。必ず、サイトのモバイル端末向けバージョンとデスクトップ向けバージョンで同じコンテンツが表示されることをご確認ください。
• Search Console を利用して通知を受け取る:
  
  Search Console は、Google がウェブサイトについてウェブマスターと連絡をとるための手段となります。また、Search Console には他にも、ウェブサイトの改善や管理に役立つさまざまなツールが含まれています。サイトの主要な開発者でない場合でも、必ず Search Console でサイトの確認手続きを済ませてください。Search Console のアラートやメッセージは、サイトで重要なエラーが検出された場合にウェブマスターに知らせるためのものです。

上記の方法をお試しになってもハッキングの形跡を見つけられない場合は、セキュリティ担当者にお問い合わせいただくか、ウェブマスター ヘルプ フォーラムに投稿していただき、再確認してください。


#NoHacked キャンペーンは、今後 3 週間にわたって実施されます。毎週初めにここで 1 週間のまとめを掲載しますので、Google+ や Twitter で Google をフォローしていただくか、このブログの内容をチェックしてください。今後ともよろしくお願いいたします。

このようなサイトは、ユーザーに誤解を与えるおそれがあるということで、手動による対策の対象となることがあります。その場合は、Search Console アカウントに通知が届きます。手動による対策の対象になった場合、サイト全体の構造化データ マークアップが検索結果に反映されなくなることもあります。

このブログ記事では特にクーポンを取り上げましたが、これ以外にもイベントと無関係な情報を「イベント」としてマークアップすると、このガイドラインが適用されます。つまり、マークアップをタイプの異なる情報に使用すると、手動による対策の対象になるおそれがあるということです。十分にご注意ください。

詳しくは、デベロッパー向けドキュメント（英語）をご覧ください。ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムでご質問ください。

AMP は、ウェブのパフォーマンスの大幅な向上と、高速で一貫したコンテンツ利用のエクスペリエンスの提供を目指して導入されました。こうした目標を踏まえて、今後、ページを Google 検索結果に AMP ページとして表示するためには、AMP ページと正規ページのコンテンツを同等にすることを要件として義務付けます。

非 AMP ページに含まれる重要なコンテンツが AMP ページに含まれていない場合、ユーザーには非 AMP ページが表示されます。検索結果での掲載順位には影響しませんが、こうしたページは AMP を必要とする検索機能（AMP のトップニュース カルーセルなど）の対象にはなりません。また、ウェブマスターには Search Console を通じて手動による対策のメッセージで通知され、サイト運営者が問題を修正すると AMP ページが再び配信されるようになります。AMP オープンソース プロジェクトのウェブサイトでは、高速で見やすく、成果の高い AMP ページの作成に役立つガイドを掲載しています。

今回の変更によって、正規ページと AMP ページの間でコンテンツ の同一性を保つ流れが促進されることを願っています。コンテンツの同一性を実現することによってサイトの利便性が高まり、最終的にはユーザーの満足度の向上につながるのです。

これまでお使いのモバイル用 URL からレスポンシブ バージョン（新しいページ）への 301 リダイレクトを設定します。このリダイレクトは、URL ごとに（モバイル用の各 URL からレスポンシブ URL に対して個々に）行う必要があります。

条件付きのリダイレクトや Vary HTTP ヘッダーなど、モバイル用 URL 固有の設定をサイトで利用していた場合は、すべて削除します。

レスポンシブ URL については、rel=canonical を設定してその URL 自体を指すようにすること（自己参照型の正規 URL）をおすすめします。

現在、動的な配信を利用している場合は、レスポンシブ デザインへの移行にあたって、リダイレクトの追加や変更を行う必要はありません。

レスポンシブ ウェブ デザインに移行するメリット

レスポンシブ サイトに移行すると、今後のメンテナンスやレポート作成が簡単になります。すべてのページについて別々の URL を管理する必要がなくなるだけでなく、さまざまな手段や技術（国際化のための hreflang、高速化を実現する AMP、検索機能の向上に役立つ構造化データなど）も取り入れやすくなります。

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

Posted by Cherry Prommawin, Webmaster Relations
Original version: Official Google Webmaster Central Blog: How to move from m-dot URLs to responsive site

Google Dance Tokyo は、米国 Google 本社で開催されている、検索などオンライン マーケティングの担当者を対象としたソーシャル イベントである Google Dance の日本版です。昨年行った第一回が大変好評でしたので、今年も開催する運びとなりました。

昨年同様、イベントには当ブログでのオープンな告知からご応募いただいた方々や、 Advanced Hosting Meetup の参加者、ウェブマスター ヘルプ フォーラムのトップ レベル ユーザーや注目ユーザーの皆さんをご招待し、約 100 名の方々にご参加いただきました。

イベントはセッション タイムとソーシャル タイムの二部構成で行いました。セッション タイムでは製品開発本部長の徳生裕人が AI First の観点からアシスタントなどの最新情報をご紹介した後、Ninja Spamologist の長山一石が「Webmastering 101」と題して初心者ウェブマスターが知っておくべき検索エンジンとウェブ、そして SEO に関わる知識をご紹介しました。また、Live Q&A では、金谷武明と小川安奈が司会を務め、Gary Illyes （Webmaster Trends Analyst）、大倉務（Software Engineer）、徳生、長山が参加し、Mobile First Indexing や AI First などに関して活発な質疑応答が行われました。

Q&A で回答しきれなかったご質問は、後日実施したウェブマスター オフィスアワーで回答いたしましたので、ぜひご覧ください。

ソーシャル タイムでは会場を拡大し、Gary の乾杯音頭の後、Google の検索チームと参加者のみなさんとで軽食をつまみながら交流を深めました。同時に開催した参加者によるライトニング トークは大変盛り上がり、特に、「役に立たない検索結果の探し方（バカ毛）」、「私の考えるこれからの SEO （サイバーエージェント 木村 賢）」、「Twitter 廃人による Twitter 活用術（ちょまど）」（すべて敬称略）などのセッションが好評を博し、笑いと関心を誘っていました。

その他、当日の会場の様子に関しては、ハッシュタグ #GoogleDanceTokyo を作成しましたので、ぜひ Twitter をご覧ください。

みなさんから様々なご意見やご質問、コメントを直接いただき、Google の検索チームとしても、非常に有意義なイベントとなりました。頂いたフィードバックはできるだけ検索エンジンの開発に役立てていきたく思います。

お越しいただいた皆さん、ありがとうございました！また、当日お越しいただけなかった方々も、どこかのイベントでお会いできることを楽しみにしております。

サイトに画像を掲載している場合は、ウェブページで適切な構造化データを使用することで、その画像がどのような内容なのかユーザーが簡単に把握できるようになります。これにより、ユーザーが必要としているコンテンツを簡単に見つけられるようになるだけでなく、ターゲットとしているユーザーがサイトにアクセスする可能性も高くなります。

サイトでレシピを公開しているなら、ページにレシピ マークアップ（英語）を追加します。商品を販売しているなら商品マークアップ（英語）、動画を公開しているなら動画マークアップ（英語）です。GIF の場合はマークアップ不要で、アルゴリズムによって自動的にバッジが追加されます。画像検索の画像に必ずバッジが表示されるとは限りませんが、必須のフィールドに加えて推奨の構造化データ フィールドを追加することで、その可能性が高まります。

なお、ページにエラーがあると画像検索バッジは表示されませんのでご注意ください。ページのエラーは、構造化データ テストツールでチェックできます。マークアップに関する統計情報は、Search Console のリッチカード レポートで確認できます。

この機能についてご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご質問ください。

Posted by Assaf Broitman, Image Search team
Original version: Official Google Webmaster Central Blog: Badges on Image Search help users find what they really want

HTTP サイトを安全でないと明示するという Google の計画は、段階的により幅広い基準に基づいて進められる予定です。Chrome 56 での変更以来、PC からパスワード フォームまたはクレジット カード フォームがある HTTP ページにアクセスする割合は 23% 減少しました。今後は、さらに対策を講じていきます。

秘密にする必要のあるデータは、パスワードとクレジット カードの情報だけではありません。ユーザーがウェブサイトに入力するあらゆる種類のデータに対して、ネットワーク上のその他のユーザーがアクセスできないようにする必要があります。そのため、Chrome バージョン 62 以降では、ユーザーが HTTP サイトにデータを入力すると、「Not secure」警告が表示されます。

ユーザーが Chrome のシークレット モードで HTTP ページを閲覧する場合、プライバシーが確保されていると考えられるかも知れませんが、HTTP ページの閲覧は、ネットワーク上の他のユーザーに対して非公開になっているわけではありません。そのため、Chrome バージョン 62 では、シークレット モードで HTTP ページにアクセスする場合も警告が表示されます。

最終的には、シークレット モードではないときも、すべての HTTP ページに対して「Not secure」警告を表示する予定です。今後のリリースが近づいた際にアップデートを公開しますが、HTTPS への移行はできる限り早く進めてください。HTTPS は今までになく簡単かつ安価に導入できるようになっており、HTTP では実現できない最高のパフォーマンスや強力な新機能を提供します。導入にあたっては、Google のセットアップ ガイドをご確認ください。

Posted by Eiji Kitamura - Developer Relations Team

Google とプログラム参加企業は、情報を探す検索ユーザーと情報を発信するウェブマスターのどちらにとってもより良い、より健全なウェブ エコシステムの維持、発展を目指して、Advanced Hosting Meetup プログラムを 2017 年も継続して実施していきます。

Posted by Takeaki Kanaya on behalf of Advanced Hosting Meetup members

検索結果のスニペットの説明がわかりやすく、また検索キーワードとの関連性が高いほど、ユーザーのクリック数は増え、表示されたページへの満足度が高まります。これまでスニペットは、以下の 3 か所から取得されていました。

1. ページのコンテンツ
2. メタ ディスクリプション
3. DMOZ リスティング

ページのコンテンツは、検索結果のスニペットとして最適です。多くの場合、抽出されるコンテンツはユーザーの検索キーワードと最も関連性が高いと言えます。ただし、コンテンツがスニペットの最適なソースとならない場合もあります。たとえばユーザーがある本の出版社を検索するとします。検索結果には関連性の高いホームページが表示されるかもしれませんが、そのページに会社の画像、ロゴ、リンクしか含まれていない場合、これらはいずれもスニペットとしては役に立ちません。

検索スニペットとして使えるテキスト コンテンツがページに多く含まれていない場合は、代わりにメタ ディスクリプションを使用することができます。これはコンテンツを簡潔にまとめた、短い宣伝文です。

スニペットの生成に使用されるテキスト コンテンツが多く含まれておらず、かつメタ ディスクリプションがない、ページとの関連性が低い、質が低いといった場合は、これまでは DMOZ（Open Directory Project）を利用することができました。Google は 10 年以上にわたって、スニペットとして DMOZ を活用してきました。DMOZ スニペットは、ウェブマスターの皆様にメタ ディスクリプションでご提供いただく内容よりも良質で、またページ内から抽出されるコンテンツよりもしっかりと説明されている場合が多かったためです。

DMOZ の終了にともない、Google もスニペットに DMOZ のリスティングを使用することを停止しております。そのため、ウェブマスターの皆様から、ページにコンテンツを追加できない場合には、適切なメタ ディスクリプションを提供していただくことがより重要になりました。

どのようなメタ ディスクリプションが適していますか？

メタ ディスクリプションとして適しているのは、ページのコンテンツについて正確に説明している短い宣伝文です。そのページがまさに探していたものだとユーザーに確信させる、宣伝文句のようなものです。さらに詳しいヒントとして、このトピックに関する記事をヘルプセンターにご用意していますので、ぜひご覧ください。また、必ずパソコン向けとモバイル向けの両方のページに、タイトルとメタ ディスクリプションの両方を含めるようにしてください。

メタ ディスクリプションについて、よくある問題を教えてください

メタ ディスクリプションは通常、検索エンジンやその他のソフトウェアでしか見えないため、ウェブマスターの皆様がその存在を忘れ、空白のままになっていることがあります。同様の理由で、同じメタ ディスクリプションが複数の（そして多数の）ページで使われていることも多くあります。また、メタ ディスクリプションの内容が的外れである、質が低い、スパムのように見えるというケースも比較的見うけられます。Google はそのようなメタ ディスクリプションは使用しないことにしています。ユーザーが最適な検索結果を得られない原因となるためです。

メタ ディスクリプションに文字数制限はありますか？

メタ ディスクリプションの長さに制限はありません。ただし検索結果のスニペットは必要に応じて切り詰められます（端末の幅に合わせる場合など）。

「NOODP」robots ディレクティブを使用するとどうなりますか？

DMOZ（ODP）の終了にともない、Google では DMOZ データの利用を停止しています。そのため NOODP ディレクティブは処理することができません。

ページのコンテンツをスニペットとして使用されないようにすることはできますか？

「nosnippet」robots ディレクティブを指定すると、Google はスニペットを生成しなくなります。ページのコンテンツのみをスニペットに使用しないように指定することはできません。

ご不明な点がありましたら、フォーラムや Twitter でお気軽にお問い合わせください。

Posted by Gary, Search Team
Original version: Official Google Webmaster Central Blog: Better Snippets for your Users

製品に関する透明性の向上

ここ数カ月間、オートコンプリートに衝撃的な内容や不快な予測が表示されることについて、厳しいご意見をいただきました。これらのご批判を踏まえ、Google ではコンテンツポリシーを見直し、改善の必要な部分について修正しました。この内容を ヘルプセンターに本日公開します。オートコンプリート及び、削除ポリシーについてはこちらをご確認下さい。

Google では年間に数兆もの検索が行われています。しかも、Google で行われる検索のうち、毎日 15% は、これまでに一度も検索されたことのない、まったく新しいクエリです。つまりは、検索クエリに対して、幅広い信頼できるソースから、ベストな答えをお返しするためには、常に新しい課題に挑戦し続けなくてはならないということを意味します。残念ながら、Google の検索結果が、真に「完璧」になることはこれからもないでしょう。しかし、私たちは、皆さんの信頼にお応えし、ユーザーの皆さん全員にとって役立つ製品の開発と提供に尽力してまいります。

Posted by Ben Gomes, VP, Engineering

2017 年に入って早くも数か月が過ぎましたが、ここで 2016 年のウェブスパム対策を通じて得た気づきをお伝えしてみたいと思います。Google は昨年も、スパムによって検索の品質が低下しないよう新たな方法を探し続けるとともに、世界中のウェブマスターと協力してウェブのさらなる改善に努めてきました。

世界中のすべての人に適切な検索結果を提供する、という使命を果たすためには、ユーザーにとって有害な（または単純に不快な）ウェブスパムとの戦いを放棄するわけにはいきません。ユーザーの皆さんがウェブを最大限活用できるようにするための Google のさまざまな取り組みをご紹介します。

2016 年のウェブスパムの傾向

• ウェブサイトのセキュリティは、かねてから私たちを悩ませてきた大きな問題の 1 つです。昨年ハッキングされたサイト数は過去最多を記録し、2015 年に比べ 32% も増加しました。そのため Google では、サイトがハッキングされたときに何をすべきかがすぐにわかるよう、ウェブマスター向けの資料（英語）の拡充に努めています。
• サイトに不正アクセスする目的は、ウェブスパムをホストすることだけではありません。多くのウェブマスターが、ソーシャル エンジニアリング、望ましくないソフトウェア、望ましくない広告の埋め込みなどの被害に遭っています。Google では、セーフ ブラウジング機能をさらに強化し、不正なダウンロード ボタンや繰り返し危険と判定されるサイト（英語）からユーザーを保護しています。また、Search Console の [セキュリティの問題] に関するレポートに、より詳細なヘルプ記事（英語）も追加しました。
• Google 検索をモバイル端末で実行する人が増えており、モバイル ユーザーをターゲットとしたスパムも急増しています。特に増えているのが、ページに挿入したウィジェットや広告ネットワークの広告ユニットを使って、ウェブマスターに気付かれないようにユーザーを他のサイトやページにリダイレクトするスパムです。

2016 年の Google のウェブスパム対策

• Google では、ウェブスパムに対処するためアルゴリズムを継続的に改良しています。サイトの掲載順位についても、中核的なアルゴリズムの 1 つである Penguin をリアルタイム化するなど、複数の改良を施しました。
• アルゴリズムで検出されなかったスパムには手動による対策を実施しています。サイトのウェブスパムに関する問題をウェブマスターに通知するため、これまでに 900 万通のメッセージを送信しました。また、Google アナリティクス経由でのセキュリティ通知も開始しました。
• Google は、アルゴリズムと手動でウェブサイトの品質をチェックし、サイトの構造化データ マークアップ（英語）が品質基準を満たしているかどうかを確認しています。手動による対策は、構造化データを利用した検索に含めるための品質ガイドライン（英語）を満たしていなかった 10,000 以上のサイトを対象に実施しました。

より快適なウェブの実現に向けたユーザーやウェブマスターとの連携

• 2016 年に世界中のユーザーから寄せられたスパムレポートは 180,000 件を数えます。これらの妥当性を慎重に確認した結果、報告されたサイトの 52% がスパムと判定されました。よりクリーンで安全なウェブ エコシステムの実現にご協力いただきありがとうございます。
• 世界中で 170 回以上のウェブマスター オフィスアワーやライブイベントを開催し、150,000 人以上のウェブサイト所有者、ウェブマスター、デジタル マーケティング担当者と交流する機会を持つことができました。
• ウェブマスター ヘルプ フォーラムを 15 言語で運営し、世界中のウェブサイト所有者を継続的にサポートしています。これらのフォーラムには 67,000 件以上の質問が寄せられ、その大部分において、トップレベル ユーザー、注目ユーザー、Google 社員のコミュニティから「ベストアンサー」が得られたと評価されています。
• ウェブマスター ヘルプ フォーラムでは、119 人のトップレベル ユーザーと注目ユーザーがボランティアで活躍してくれています。Google では、4 つの大陸（アジア、欧州、北米、南米）の 11 都市でトップレベル ユーザー ミートアップを開催しました。
• 日本では、11 のブログサービスを中心としたホスティングサービスの方々と連携し、共同でスパム対策を実施しました。こちらの取り組みは 2017 年も続けていきます。

より品質の高い検索結果のために、今年も Google はスパム対策に取り組んでまいります。

Posted by Michal Wicinski, Search Quality Strategist and Kiyotaka Tanaka, User Education & Outreach Specialist

この機能は、ユーザーが目に留まったファッションの写真をブラウジングしてショッピングしたり、興味がある商品の情報を見つけたりするのに役立ちます。「ブランド ハンドバッグ」のようなクエリで検索結果を開くと、実際の機能をお試しいただけます。

画像検索の機能に対するユーザーからのリクエストで多かったもののひとつは「価格や在庫状況を見つけやすいこと」でした。 「似ている商品」のカルーセル表示では、毎日世界中で何百万というインプレッションとクリックが発生しています。

サイトで扱っている商品を「似ている商品」に対応させるには、schema.org の商品メタデータをページに追加して管理します。schema.org の商品マークアップを使用すると、Google がウェブ上で商品を見つけられるようになり、商品情報の概要をユーザーに表示できるようになります。

サイトの商品を「似ている商品」の表示対象にするには、以下の操作を行ってください。

• ページに掲載している商品に、schema.org の商品マークアップ（画像参照を含む）を追加します。ホストページで商品の名前、画像、価格と通貨、在庫の各メタデータを記述すると、「似ている商品」の表示対象となります。
• Google の構造化データ テストツールでページをテストして、商品マークアップの形式が正しいことを確認します。
• 画像検索で「site:<ドメイン名>.com」というクエリを入力し、商品の画像を確認します。検索結果にマークアップが正しく適用されている場合は、サイトの商品画像をタップすると商品情報が表示されます。なお、Googlebot がウェブサイトを再クロールするまでに 1 週間程度かかることがあります。

現在、「似ている商品」は全世界のモバイル ブラウザと Android 版 Google 検索アプリでご利用いただけます。2017 年には、さらに多くのプラットフォームに拡大する予定です。

ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。商品の画像が「似ている商品」に表示されないようにしたい場合は、Google 画像検索からオプトアウトすることができます。

購入可能な商品をショーケースのようにして紹介することで、皆さんのサイトの商品がユーザーにとって見つけやすくなれば幸いです。さらに手軽なオンライン ショッピングを実現するために、今後ともご協力をお願い申し上げます。

Posted by Julia E, Product Manager on Image Search
Original version: Official Google Webmaster Central Blog: Similar items: Rich products feature on Google Image Search

Google はこのたび、サイト ステータス ツールの新バージョンをリリースしました。新しいバージョンでは、結果の表示が簡潔で明確になり、設計が調整されています。この変更により、セーフ ブラウジングの警告を受け取ってからツールにアクセスするユーザーや、Google でのマルウェアやフィッシングの検出についてオンラインで調べようとするユーザーにとってより使いやすいツールになりました。ツールのユーザー インターフェースも整理され、説明はわかりやすく、結果はさらに正確になりました。また、連携している自律システムの詳細な技術的データの一部を、透明性レポートの不正なソフトウェア ダッシュボードに移動しました。

インターフェースこそ整理されましたが、診断情報の詳細が表示されなくなったわけではありません。詳細について調べようとするユーザーは、セーフ ブラウジングの透明性レポートの他のセクションで深く掘り下げることができます。一方、サイト所有者は Search Console で詳細な診断情報について確認することができます。透明性レポートの目標の 1 つは、ポリシーとセキュリティの複合的な問題を明らかにすることであり、今回の設計の調整によって実際に、ユーザーにとって明瞭さが増す結果となることを願っております。

Posted by Deeksha Padma Prasad and Allison Miller, Safe Browsing
Original version: Official Google Webmaster Central Blog: Updates to the Google Safe Browsing’s Site Status Tool

リッチカードを実装すると、検索結果の表示は大きく変わります。たとえばユーザーが [餃子 レシピ] のような料理のレシピを検索すると、結果がカルーセル形式のリッチカードとして表示され、左右にスクロールしながらさまざまなレシピを簡単に閲覧できます。

サイトを所有している方は、リッチカードを活用して検索結果を目立たせることで、ターゲットとするユーザーからのページアクセスを増やすことが可能です。たとえばレシピサイトを運営しているなら、おいしそうな料理の画像をカード形式で表示してユーザーの目を引くことができます。探しものが画像ですぐに見つかるため、「特定の料理のレシピ」を探しているターゲット ユーザーをより確実にサイトに誘導できます。

現時点でリッチカードが表示されるカテゴリは、レシピ、映画、飲食店の 3 つで、すべて AMP 形式に対応しています。各種のリッチカードをギャラリーで紹介しています。スクリーンショットや、マークアップのコードサンプルも用意していますので、コンテンツに合ったタイプを見つける場合はこちらをご利用ください。リッチカードをサポートするカテゴリやデータ形式は、今後も積極的に増やしていく予定です。

サイト所有者やデベロッパーの皆様にリッチカードの実装から掲載結果の確認までをお試しいただけるよう、デベロッパー向けドキュメントを更新し、充実したツールを用意いたしましたのでいくつかご紹介します。

• 構造化データ テストツールを使用すると、マークアップ エラーを確認したり、検索結果に表示されるカードをプレビューしたりできます。
• Search Console のリッチカード レポートを見ると、どのカードにエラーがあるか、マークアップを追加して拡張できるのはどのカードか、などがわかります。
• AMP テストでは、AMP ページだけでなく、ページ上のマークアップも検証できます。

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

方法 1: カート機能をブロックする

ユーザーによる購入のみを停止したい場合は、その特定の機能だけを無効にする方法が一番簡単です。ほとんどの場合、ショッピング カート ページのクロールかインデックス登録のどちらかをブロックすることで対応できます。クロールは robots.txt ファイルで、インデックス登録は robots メタタグでブロックできます。検索エンジンによるコンテンツの検出またはインデックス登録が停止するため、それを適切な方法でユーザーに伝える必要があります。たとえばカートへのリンクを無効にする、適切なメッセージを表示する、カートの代わりに情報ページを表示するなどの方法があります。

方法 2: インタースティシャルやポップアップを常に表示する

ユーザーがサイト全体にアクセスできないようにする場合は、サイトが一時的に利用できないことを示すメッセージ、情報ページ、またはポップアップを表示し、サーバーから 503 HTTP ステータス コード（「サービスはご利用いただけません」）を返します。503 ステータス コードを返すことで、ユーザーに表示する一時的なコンテンツが Google にインデックス登録されるのを防ぐことができます。503 ステータス コードを返さないと、インタースティシャルなどがウェブサイトのコンテンツとしてインデックス登録されてしまうことがありますのでご注意ください。

Googlebot は 503 を返すページに対して、最長で 1 週間ほどクロールを再試行します。その期間を過ぎても 503 を返すページはパーマネント エラーとして扱われ、検索結果から除外されます。Retry-After ヘッダーを追加すると、サイトが利用できない期間を示すことができます。ただしサイトのブロックが 1 週間を超えると、サイトを停止している方法に関わらず、サイトの検索結果に悪影響が及ぶ可能性があります。

方法 3: ウェブサイト全体をオフにする

サーバーを完全にオフにするという方法もあります。サーバーを別のデータセンターに物理的に移動する場合などはこの方法がよいでしょう。この方法を使用する場合は、一時的なサーバーを用意してユーザー向けの情報ページを表示し、すべての URL で503 HTTP ステータス コードを返します。その期間中は DNS を切り替えて、この一時的なサーバーを経由するようにします。

1. 切り替えの数日前に、DNS TTL の時間を短く（5 分など）設定しておきます。
2. DNS を一時的なサーバーの IP アドレスに変更します。
3. リクエストが一時的なサーバーに送信されるようになったら、メインサーバーをオフラインにします。
4. ... サーバーがオフラインになりました ...
5. 戻す準備ができたら、メインサーバーを再びオンラインにします。
6. DNS をメインサーバーの IP アドレスに戻します。
7. DNS TTL を通常の設定に戻します。

これらの方法が、ウェブサイトを一時停止するときにお役に立てば幸いです。ご不明な点などありましたら、ウェブマスター ヘルプフォーラムでお気軽にご質問ください。

なお、地域密着型のビジネスを展開されている方は、ローカル リスティングの営業時間にビジネスの停止期間を設定することも忘れないでくださいね。

Posted by John Mueller, Webmaster Trends Analyst, Switzerland
Original version: Official Google Webmaster Central Blog: Closing down for a day

コメント欄やフォーラム内のスレッドは、とても良い情報源であり、サイトを訪れた人々との交流を通じてユーザーを引き付ける効果的な方法になります。この貴重なコンテンツが、スパマーによって自動生成されたキーワードやリンクで埋め尽くされるのは、避けなければなりません。

サイトのフォーラムやコメント欄を保護し、スパマーに狙われにくいサイトにする方法は多くあります。例えば:

• フォーラム ソフトウェアを常に最新の状態に保つ。定期的に時間を取り、ソフトウェアを常に最新の状態に維持します。セキュリティに関連する重要な更新には特に注意を払うようにしてください。スパマーは、古いバージョンのコンテンツ管理システム（ブログや掲示板など）のセキュリティの問題を悪用してきます。
• キャプチャを追加する。キャプチャを使用すると、投稿しようとしているのが自動化されたスクリプトやロボットではなく、人間のユーザーであることを確認できます。このようなサービスとしては、reCAPTCHA、Securimage、Jcaptcha などがあります。
• 疑わしい動作をブロックする。多くのフォーラムでは、投稿と投稿の間隔を十分に空けるための時間制限を設定できます。また、プラグインを使用して、トラフィックが極端に多い IP アドレスやプロキシを特定したり、人間ではなくボットが実行していると思われる一般的な動作を検出したりできます。たとえば phpBB、Simple Machines、myBB など、多くのフォーラム プラットフォームがこのような設定に対応しています。
• フォーラムの上位投稿者を毎日確認する。最近参加し始めたユーザーの投稿数が極端に多い場合は、そのプロフィールをチェックし、投稿内容がスパムでないか確認します。
• 特定の種類のコメントを無効にすることを検討する。たとえば、フォーラムのスレッドが非常に古く、返信が期待できない場合は、そのスレッドを閉じることをおすすめします。今後フォーラムに手を入れる予定がなく、フォーラムを利用しているユーザーがすでにいない場合は、投稿を完全に無効にすることでスパマーによる悪用を防ぐことができます。
• コメントの管理機能を活用する。コメントの管理機能を使用すると、一定の評価を得ているユーザーのみがリンクを投稿できるようにする、リンク付きのコメントの投稿を承認制にする、といった対応が可能になります。 さらに設定を変更することで、匿名での投稿を無効にすることもできますし、新しいユーザーからの投稿は承認後に一般公開されるようにすることも可能です。 管理者の負担が大きすぎる場合は、同僚や友だち、信頼できるユーザーの協力を仰ぎ、投稿の確認や承認などの管理作業を分担することもできます。フォーラムに新たに参加したユーザーの投稿や言動には十分注意を払いましょう。
• スパム用語のブラックリスト作成を検討する。スパムであることが明らかな用語（違法なストリーミング、薬物関連の用語など）のブラックリストを使用して、不適切なコメントをブロックします。自分のフォーラムや他のフォーラムでよく見かけるスパム投稿から、スパマーしか使わないような不適切な用語やトピックと無関係な言葉を抜き出してブラックリストに追加します。フォーラム プラットフォームによっては、該当するコメントを自動でマークまたは削除できる機能やプラグインを備えている場合もあります。
• コメント欄のリンクに「nofollow」属性を使用する。こうすることで、スパマーがこのサイトをターゲットとしなくなります。Blogger を含む多くのブログサイトでは、投稿されたコメントにこの属性がデフォルトで自動追加されます。
• 自動化されたシステムを利用してサイトを保護する。たとえば Akismet は、多くのブログやフォーラム システムに対応するプラグインを備えた包括的なシステムです。インストールも簡単で、スパムコメントの大部分を自動的に分類してくれます。

これらのトピックについてさらに詳しく知りたい方は、ヘルプセンターにあるユーザー生成スパムに関するガイドラインやコメントスパムを防止する方法をご覧ください。ウェブマスター ヘルプ フォーラムもぜひご利用ください。

Posted by Anouar Bendahou, Search Quality Strategist, Google Ireland