タグ: 検索結果

ほとんどの時間は、Google の検索エンジンは正常に動作しています。私たちは、ウェブを検索しているユーザーや、Google にインデックス登録されているサイトのウェブマスターに影響を及ぼすような、技術的な問題が起きないように尽力しています。同様に、検索エンジンの基盤となるシステムも、ほとんどの場合意図したとおりに動作しています。わずかな障害が発生しても、サービスの運用を担当するチーム以外はほとんどわかりません。ただし、複雑なシステムである以上、大規模な障害が発生することがあり、ユーザーとウェブマスターの双方に影響する可能性があります。

過去数か月の間に、インデックス登録システムで問題が発生し、インフラストラクチャの他の部分にも波及しました。できる限り迅速に状況の改善に取り組みましたが、ユーザーとウェブエコシステムに高品質のサービスを継続的に提供するという目標に反することになり、誠に申し訳ありませんでした。

その後、何が起きたのかを綿密に精査しました。その過程で得られたいくつかの教訓をここで皆さんと共有したいと思います。このブログ投稿では、発生した問題について詳細に説明したのち、今後同様の問題が発生した場合にどのようにみなさまにお伝えする予定でいるかを共有します。その上で、Google への問い合わせ方法ついてウェブマスターの方々に改めてお伝えします。

数か月前に発生した問題

4 月に、インデックスに関する問題がいくつか発生しました。Google の検索インデックスは、ウェブからクロールした、ユーザーの質問に答えるのに有用と思われる数千億のウェブページを保持するデータベースです。ユーザーが Google 検索エンジンでクエリを入力すると、ランキング アルゴリズムが検索インデックスに登録されているページの中から、最も有益で関連性の高い検索結果を瞬時に見つけます。では、何が起こったのか、詳しく見ていきましょう。

1. インデックス登録の問題

はじまりは検索インデックスの一部が一時的に失われたことでした。
「インデックスの一部が失なわれた」とはどういうことでしょうか。

基本的に、検索結果をユーザーに提供する場合、サービス速度を向上させるために、ユーザーのクエリは Google 検索サービスをサポートする最も近いデータセンターに「旅」します。ここで Search Engine Results Page（SERP）が生成されます。そのため、インデックスの構成に変更（一部のページの追加や削除、ドキュメントの統合、または他の種類のデータ変更）がある場合、対象となるすべてのデータセンターに変更を反映する必要があります。結果として、世界中のユーザーに、最新バージョンのインデックスから一貫したページが提供されます。

すべてのデータセンターで同一のインデックスを維持し続けることは簡単な作業ではありません。大規模なユーザー向けサービスの場合、まず 1 つのデータセンターで更新をデプロイし、関連するすべてのデータセンターが更新されるまで拡大していきます。慎重に扱うべきインフラストラクチャについては、数日間にわたってロールアウトを実施し、異なる地域のインスタンスにインターリーブすることもあります（出典）。

予定していた検索インデックスに対する変更を進めている最中の 4 月 5 日（金）にデプロイシステムの一部が破損しました。具体的には、一部のデータセンターでインデックスを更新しているときに、少数のドキュメントが誤ってインデックスから削除されてしまいました。これが「インデックスの一部が失なわれた」ということです。

幸いにも、Google のオンコール エンジニアが問題を即座に察知しました。これは、私たちがソーシャル メディア上で問題を認識し始めたのと同時でした（週末に Google に連絡してくれた皆さん、ありがとうございました！）。その結果、問題が察知されてからわずか数時間で、すべてのデータセンターの検索インデックスを以前の安定した状態に戻し始めることができました（Google では、このような事態に備えてインデックスのバックアップを保持しています）。

Google は 4 月 7 日（日）に、この問題を認識しており、正常な状態に戻りつつあることを報告しました。データセンターのインデックスが徐々に安定した状態に戻りつつある中、Twitter での発信を続けました（4 月 8 日、4 月 9 日）。これは、4 月 11 日にすべてのデータセンターのインデックスが完全に元通りになったと確信できるまで続きました。

2. Search Console の問題

Search Console は、ウェブマスターが利用できる一連のツールやレポートであり、ウェブサイトの検索に関するパフォーマンスのデータにアクセスできます。たとえば、毎日のオーガニック検索結果における表示回数やクリック数、または検索インデックスに登録されているページ、未登録のページに関する情報を確認できます。

検索インデックスに上記の問題が発生した結果、Search Console でも不整合が見られるようになりました。これは、Search Console で表示されるデータの一部が検索インデックス自体から抽出されているためです。

• インデックス カバレッジ レポートは、データセンター間で整合性が取れた検索インデックスに依存します。
• 検索インデックスにページを格納するとき、ページにリッチリザルトのマークアップが含まれている場合など、ページに関する重要なシグナルでエントリにアノテーションを付けることができます。したがって、検索インデックスの問題は Search Console のリッチリザルト レポートに影響を及ぼす可能性があります。

基本的に、Search Console の個別レポートの多くは、専用データベースからデータを抽出しています。このデータベースの一部は、検索インデックスから取得した情報を使用して構築されています。以前のバージョンの検索インデックスに戻す必要があったため、Search Console データベースの更新も一時停止する必要がありました。これにより、一部のレポート（および URL 検査ツールなどの他のレポート）のデータが横ばい状態になりました。

問題が発生した検索インデックス全体のロールバックに数日かかったため（上記の説明を参照）、インデックス登録の問題が修正された数日後まで Search Console データベースの修正に取り掛かることができませんでした。Google は 4 月 15 日に、Search Console に問題があり、修正に取り組んでいることをツイートで明らかにしました。修正が完了したのは 4 月 28 日（レポートで新しいデータの収集を再開した日。上のグラフを参照）でした。4 月 30 日には Twitter で問題が解決したことを報告しました（ツイート）。

3.（インデックス登録の問題とは無関係な）その他の問題

Google 検索は数多くのシステムで構成されており、それぞれが別のシステムと密に連携しています。問題が同時期に起きた場合そこには因果関係があることが多いですが、場合によっては同時期に直接関係のない複数の問題が発生することもあります。

たとえば今回のケースでは、上記で説明したインデックス登録の問題とほぼ同時期に、新しい Google ニュースにおける最新のコンテンツの収集に関する問題が短時間発生しました。さらに、ページのレンダリング中に、特定の URL が Googlebot を他の無関係なページにリダイレクトし始めました。この問題はインデックス登録の問題とは関係ないもので、すぐに解決することができました（ツイート 1、ツイート 2）。

Google のコミュニケーションとその改善予定

数週間の間に行った（これまでご紹介してきた）ソーシャル メディアを使用した報告に加え、2 つの別チャネル（Search Console と Search Console ヘルプセンター）でウェブマスターに詳細を説明しました。

Search Console ヘルプセンター記事

Google は、問題を完全に特定した後、Search Console のデータの異常に関するヘルプページを更新しました。このページは、多数のウェブマスターに影響が及ぶ場合に、データ破損に関する情報を Search Console サービスに伝えるために使用されます。

Search Console

すべてのユーザーがソーシャル メディアや外部のヘルプセンター ページを読むわけではないので、Search Console レポートにアノテーションを追加して、データが正確でない可能性があることをユーザーに通知しました（下の画像を参照）。この情報は、問題が解決した後に追加したものです。[詳細を見る] をクリックすると、ヘルプセンターの「データの異常」ページに移動します。

今後のコミュニケーションについて

問題が発生した場合、Google には「事後分析」の文化があります。障害に関して報告するドキュメントを作成し、同じ問題が今後発生しないよう努めます。プロセス全体について詳しくは、Google サイト信頼性エンジニアリングのウェブサイトをご覧ください。

4 月のインデックス登録の問題をきっかけに、大規模なシステム障害が発生した場合にウェブマスターに明確に伝える方法を事後分析に含めました。主な決定事項は次のとおりです。

1. Search Console 内で広範な問題に関する情報を迅速に共有する方法を探り、機能停止が疑われる場合にウェブマスターが確認すべき主な参照ポイントとして役立つ情報を提供します。
2. 必要に応じて、より迅速に Search Console のデータの異常ページに投稿します（Search Console データに長期間にわたって障害が見られる場合）。
3. このような問題の発生時に、Google が問題を認識しており、その解決が近いことを速やかに知らせてウェブマスターの方々に安心していただけるよう、可能な限り速やかに Twitter で発信を続けます。

上記のコミットメントは、今後起こり得る同様の状況に備えて、ウェブマスターに対し全体的な透明性を確保するためのものです。

改善策の実施例「新しい URL のインデックスが登録されない」

5 月 22 日に別の問題が発生した際、新しいコミュニケーション方法を試しました。発生した問題は、特定の URL の処理中、予定されていたインフラストラクチャ アップグレードの後に重複管理システムのメモリが不足し、すべての受信 URL の処理が停止したというものです。

上記 の 3 つのポイントに加えて、コミュニケーションについて考慮した結果を時系列で示します。

1. Google が問題を認識（カリフォルニア時間 5 月 22 日午前 5 時半頃）
   現在発生中の問題についてツイート（同 5 月 22 日午前 6 時 40 分頃）
   解決したことをツイート（同 5 月 22 日午後 10 時頃）
2. ヘルプセンターの「データの異常」ページを更新することを検討しましたが、大部分のウェブマスターの Search Console データに長期的な影響はないと判断し、更新を見送ることにしました。
3. この問題によりご迷惑をかけたことで、「いずれかの Google システムに問題が発生し、ウェブマスターに影響を及ぼす可能性がある」ことを Search Console 上で明確に知らせる手段が必要という以前の結論が裏付けられることになりました。こうしたソリューションの実装には時間がかかる場合があります。このトピックは今後も引き続き取り上げていく予定です。

8 月にも同様のインデックスの問題が発生しました。5 月 22 日の時と同じように、みなさんに問題の発生と問題解決に取り組んでいることをお伝えするツイートを行い、問題が解決した際にもツイートしてお知らせしました。

デバッグ方法とお問い合わせについて

この投稿により、Google のシステムの複雑さと、時にはシステム障害が発生する事を知っていただけたことと思います。また、問題が発生したときに Google がどのようにお知らせするかをご理解いただく一助となれば幸いです。ただし、この投稿ではシステムの広範囲にわたる障害に焦点を当てていますが、ほとんどのウェブサイトにおけるインデックス登録の問題は、個々のウェブサイトの構成に原因があります。構成によっては Google 検索が対象のウェブサイトのインデックスを適切に登録できない場合がありますので、ご留意ください。そのような場合、ウェブマスターは Search Console やヘルプセンターを使用して問題をデバッグすることができます。デバッグした結果、自身のサイトの問題ではないと考えられる場合、または解決方法がわからない場合は、Google や Google コミュニティまでご連絡ください。いつでもお待ちしております。Google に問題を報告する方法は次のとおりです。

• ウェブマスター コミュニティを確認する。他のウェブマスターが報告した問題で、あなたのサイトに影響を及ぼすものが含まれている場合があります。
• 直接、報告する。イベントの際などにも直接ご報告ください。いつでもお待ちしています（カレンダー）。
• Google プロダクト内で報告する。Search Console のフィードバック ツールをご利用いただくと、非常に助かります。
• Twitter や YouTube もぜひご活用下さい。

検索ユーザーはさまざまな疑問の答えを求めて Google を利用しています。

求めている答えが、ユーザー同士が質問に答え合う Q&A サイトで見つかる場合も少なくありません。Q&A サイトには、人気のソーシャル ニュース サイト、エキスパート フォーラム、ヘルプやサポートに関するメッセージ ボードなどがあります。

疑問に対する最適な回答を検索結果の中から簡単に見つけられるよう、Google は Q&A サイト向けの新しいリッチリザルトを開発しました。対応する Q&A ページの検索結果には、上位の回答のプレビューが表示されます。この新しい表示方法により、サイト所有者はコンテンツに適したユーザーにリーチでき、ユーザーは疑問に対する適切な情報をすばやく取得できるようになります。

この機能に対応するには、Q&A コンテンツを掲載しているページに Q&A 構造化データを追加します。構造化データ テストツールを使用することで、ページがこの機能に対応していることを確認し、検索結果でどのように表示されるかをプレビューできます。Search Console では、統計情報とマークアップ エラーの例を確認できます。また、検索パフォーマンス レポートでは、どのような検索クエリに対して検索結果に Q&A リッチリザルトが表示されているかを確認したり、検索結果の推移を確認したりできます。

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

たとえば、カップケーキを作りたいとしましょう。どんなカップケーキを作るか迷ったときは、画像検索でいろいろな写真を見ると良いアイデアが浮かぶかもしれません。ただし、画像検索からレシピを見つけるのはなかなか大変です。おいしそうな写真をクリックしてみたら、ケーキ屋さんのメニューが表示されるかもしれませんし、お気に入りのカップケーキを集めただけでレシピは載せていないサイトにたどり着くかもしれません。

このたび Google では、ユーザーが必要な情報を簡単に見つけられるようにするため、モバイル端末で画像検索を実行したときのサムネイルにバッジ（英語）が表示されるようになりました。現時点では、レシピ、動画、商品、アニメーション画像（GIF）のバッジを用意しています。

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

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

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

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

画像検索で「似ている商品」というサービスを、モバイルウェブと Android 版検索アプリで開始しました。「似ている商品」は、ユーザーが写真の中で気になった商品を Google 画像検索で見つけやすくする機能です。この機能は画像認識技術を使用しており、日常生活で目にする画像の中で商品を識別し、類似する商品をユーザーに表示します。「似ている商品」が現在サポートしているのはハンドバッグ、サングラス、靴ですが、今後数か月以内に衣料品やホーム＆ガーデンといった他のカテゴリにも対応する予定です。

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

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

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

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

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

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

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

注 : この投稿は、Google のウェブ検索に固有のものです。Google の他のサービスについては、適切なヘルプセンター（Google ショッピングなど）またはヘルプ フォーラムに問い合わせてください。

今や「年中無休」が当たり前となっている世の中ですが、オンラインサービスでは、サイトを一時的に停止しなければならない場合もあります。今回は、検索結果の掲載順位に影響を及ぼすことなく、サイト（またはその一部機能）を一時停止する方法をご紹介します。

方法 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 を通常の設定に戻します。

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

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