Google 検索におけるコンテンツのプレビューをもっと制御できるようになります

Google では、文字形式のスニペットを始めとする様々な形式のコンテンツをプレビューとして検索結果に表示していますが、これは、検索結果と検索クエリとの間に関連性があるかどうかを、ユーザーが判断しやすくすることを目的としています。どのような形式のプレビューが表示されるかは数多くの要因によって決められており、その要因の中には、ユーザーが探しているコンテンツの形式や、そのときに使用しているデバイスなどが含まれます。

例えば、Google でレシピの検索を行っているユーザーには、サムネイル画像やレビュー スコアが表示されます。なぜなら、何を食べたいか決める際は、文字形式のスニペットよりも、そういった情報のほうが参考になると考えられるからです。上記のような形式の情報は、パブリッシャーが構造化データを使ってページを作成しているおかげで表示が可能になっています。

Google は、表示された検索結果がユーザーのクエリと関連性が高く訪問したくなるサイトが表示されていることを分かりやすく示すために、プレビューを自動的に生成します。一方で、サイト オーナー側でも、プレビューで表示される情報をある程度調整したいという要望があることを私たちも理解しています。そこで本日は、ウェブマスターが行える新たな設定項目をいくつかご紹介します。これらの設定により、スニペットに表示する文字列はどの部分からどのくらいの長さであるべきか、その他の形式の情報はプレビューに表示するべきかどうか、などをそれぞれのサイトが簡単に定義できるようになります。

スニペットとコンテンツ プレビューの設定を Google に知らせる

これまでは、文字形式のスニペットの表示を許可するかどうかのみが設定可能でした。今回紹介する方法を使用することで、検索結果のページに対して表示されるプレビュー コンテンツを、より細かく設定できるようになります。その方法は、二種類の新しい設定を駆使して行います。その二種類とは、robots メタタグによる設定と、HTML 属性による設定です。

robots メタタグを使用する

robots メタタグは HTML ページの <head> 要素内に追加するか、x-robots-tag HTTP ヘッダー で指定します。ページのプレビュー コンテンツの設定で使用する robots メタタグは、以下の通りです。

  • "nosnippet"
    既存の設定値です。ページに対して文字形式のスニペットを表示したくないときに使用します。
  • "max-snippet:[number]"
    新しい設定値です!ページに対して表示するスニペットの最大文字数を設定します。
  • "max-video-preview:[number]"
    新しい設定値です!動画再生プレビューの最長再生時間(秒)を設定します。
  • "max-image-preview:[setting]"
    新しい設定値です!ページ内の画像がプレビューで表示されるときの最大サイズを指定します。指定可能な設定値は、"none"、 "standard"、 "large" のいずれかです。

上記のメタタグは 2019 年 10 月 より有効になります。設定値は以下のようにまとめて記述することが可能です。

例:

<meta name="robots" content="max-snippet:50, max-image-preview:large">

新しい data-nosnippet HTML 属性を使用する

"data-nosnippet" HTML 属性は、ページ内のコンテンツのうち、スニペットとして表示してよい部分を制限するのに役立つ新しい方法です。span、div、section 要素で使用出来ます。"data-nosnippet" HTML 属性が指定された要素は、そのページに対する文字形式のスニペットとして表示されなくなります。

例:

<p><span data-nosnippet>Harry Houdini</span> is undoubtedly the most famous magician ever to live.</p>

"data-nosnippet" HTML 属性は今年中に有効になります。詳しくは、robots メタタグと X-Robots-Tag HTTP ヘッダーの仕様に関する開発者ドキュメントを参照してください。

リッチリザルトと強調スニペットについて

構造化データ内のコンテンツは、検索結果におけるリッチリザルトとして表示することが可能です。リッチリザルトは、上記のメタ robots による設定で制限することは出来ませんが、構造化データ内のコンテンツ自体を制限したり修正したりすることで、より柔軟な設定が可能になります。例えば、レシピが構造化データに含まれている場合、その構造化データのコンテンツは、検索結果のうち、レシピのカルーセル内に表示されることがあります。そのような表示を制限するために、パブリッシャーは構造化データ内のコンテンツの量や形式を制限することが出来ます。

検索の特別な機能の中には、プレビュー コンテンツが利用可能な場合のみ動作可能になるものがあります。つまり、プレビューを制限することで、それらの特別な機能の領域でコンテンツが使用されるのを防ぐことが出来ます。例えば、強調スニペットは表示するのに必要な最低文字数があり、それに満たない場合は表示されません。しかしながら、これは言語によって様々なので、強調スニペットで確実に表示されるための具体的な max-snippets の値は存在しません。強調スニペットとしてコンテンツを表示したくない場合は、 max-snippets の値を小さくしてみてください。強調スニペットから確実にオプトアウトしたい場合は、nosnippet を指定してください。

AMP フォーマット

AMP フォーマットには確実なメリットがあります。例えば、検索結果Google Discover のフィード画面で、より多くの注目を集めるような形でサムネイル画像を表示することが可能になります。このような特徴により、パブリッシャーはさらに多くのトラフィックを記事ページに誘導できるようになりました。一方で、パブリッシャーの中には、AMP ページが検索や Discover で表示された際に、大きいサムネイル画像を表示してほしくない場合があるかもしれません。その場合は、上記の meta robots タグのうち、max-image-preview に対して “standard” か “none” を指定します。

本日ご紹介した新しい方法は、世界中のコンテンツ所有者の皆様が利用でき、全世界どこでも同じように機能し検索結果に反映されます。Google 検索におけるサイトの価値を最適化し、ビジネスの目標を達成するうえで、今回の方法が皆様のお役に立つことを願っています。さらに詳しい情報は、メタタグに関する開発者ドキュメントを御覧ください。ご質問がある場合は、私たちにお知らせいただくか、ウェブマスター ヘルプ フォーラムまでお越しください。

Google 検索でインデックスの問題が発生: その対処法と教訓

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

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

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

数か月前に発生した問題

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

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

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

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

Google は、上記の写真のようなデータセンター世界中で所有して運営しており、24 時間年中無休でサービスを稼働させています(出典)。

すべてのデータセンターで同一のインデックスを維持し続けることは簡単な作業ではありません。大規模なユーザー向けサービスの場合、まず 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 検査ツールなどの他のレポート)のデータが横ばい状態になりました。

2019 年 4 月の Search Console のデータの更新頻度に関する問題を示す、インデックス登録ページのインデックス カバレッジ レポート。2 回の更新の間隔が通常よりも長くなっている。

問題が発生した検索インデックス全体のロールバックに数日かかったため(上記の説明を参照)、インデックス登録の問題が修正された数日後まで 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 のフィードバック ツールをご利用いただくと、非常に助かります。
  • TwitterYouTube もぜひご活用下さい。

Rendertron によるダイナミック レンダリング

多くのフロントエンド フレームワークは、コンテンツの表示に JavaScript を使用しています。そのため、Google がコンテンツをインデックスに登録したり、インデックスに登録されたコンテンツの更新に時間がかかる場合があります。

昨年の Google I/O では、この問題の回避策としてダイナミック レンダリングが議論されました。ダイナミック レンダリングの実装方法はいくつかあります。このブログでは、Rendertron を使用したダイナミック レンダリングの実装例を紹介します。Rendertron は headless Chromium をベースとしたオープンソース ソリューションです。

ダイナミック レンダリングを検討すべきサイト

あなたのサイトにアクセスする検索エンジンやソーシャル メディア ボットが、すべて JavaScript を実行できるわけではありません。Googlebot が JavaScript を実行するのには時間がかかり、こちらに示すようにいくつかの制限が存在します。

ダイナミック レンダリングは、変更頻度が高く、表示に JavaScript を必要とするコンテンツに対して有用です。

また、ハイブリッド レンダリング(Angular Universal など)を検討することで、あなたのサイトのユーザー エクスペリエンス(特に first meaningful paint までの時間)を向上できる可能性があります。

ダイナミック レンダリングの仕組み

ダイナミック レンダリングとは、特定のユーザー エージェントに応じて、クライアント側でレンダリングされるコンテンツとプリレンダリングしたコンテンツを切り替えることを指します。

JavaScript を実行して静的 HTML を生成するにはレンダラが必要になります。Rendertron はオープンソース プロジェクトであり、headless Chromium を使用してレンダリングを行います。シングルページ アプリでは、頻繁にバックグラウンドでデータを読み込んだり、コンテンツをレンダリングするための作業で遅延が発生したりすることがあります。Rendertron には、ウェブサイトでレンダリングが完了したタイミングを判定するメカニズムがあります。Rendertron は、すべてのネットワーク リクエストが完了し、未処理の作業がなくなるまで待機します。

このブログ投稿で扱う内容

  1. サンプルのウェブアプリを確認する
  2. 小規模の express.js サーバーを設定して、ウェブアプリを配信する
  3. ダイナミック レンダリング用のミドルウェアとして Rendertron をインストールして構成する

サンプルのウェブアプリ

「kitten corner」ウェブアプリは JavaScript を使用して、さまざまな猫の画像を API から読み込み、グリッド形式で表示します。

グリッド形式で猫の画像が表示され、ボタンでさらに画像を表示できます。可愛いと思いませんか?

以下がこのウェブアプリの JavaScript です。

  const apiUrl = 'https://api.thecatapi.com/v1/images/search?limit=50';
  const tpl = document.querySelector('template').content;
  const container = document.querySelector('ul');

  function init () {
    fetch(apiUrl)
    .then(response => response.json())
    .then(cats => {
      container.innerHTML = '';
      cats
        .map(cat => {
          const li = document.importNode(tpl, true);
          li.querySelector('img').src = cat.url;
          return li;
        }).forEach(li => container.appendChild(li));
    })
  }

  init();

  document.querySelector('button').addEventListener('click', init);

このウェブアプリでは、Googlebot でまだサポートされていない最新の JavaScript(ES6)が使用されています。Googlebot がコンテンツを認識できるかは、モバイル フレンドリー テストを使用することで確認できます。

モバイル フレンドリー テストより、このページがモバイル フレンドリーであることがわかりますが、スクリーンショットには猫が一切見当たりません。見出しとボタンは表示されていますが、猫の画像がまったく表示されていません。

この問題は簡単に修正できます。こうした修正は、ダイナミック レンダリングを設定する方法を学習するための良い練習となるでしょう。ダイナミック レンダリングにより、ウェブアプリのコードを変更せずに Googlebot に猫の画像を認識させることができます。

サーバーの設定

ウェブアプリを配信するために、node.js ライブラリの express を使用してウェブサーバーを構築します。

サーバーのコードは以下のようになります(プロジェクトの完全なソースコードはこちらをご覧ください)。

const express = require('express');
const app = express();

const DIST_FOLDER = process.cwd() + '/docs';
const PORT = process.env.PORT || 8080;

// Serve static assets (images, css, etc.)
app.get('*.*', express.static(DIST_FOLDER));

// Point all other URLs to index.html for our single page app
app.get('*', (req, res) => {
 res.sendFile(DIST_FOLDER + '/index.html');
});

// Start Express Server
app.listen(PORT, () => {
 console.log(`Node Express server listening on http://localhost:${PORT} from ${DIST_FOLDER}`);
});

こちらで実際の例を試すことができます。最新のブラウザを使用しているのであれば、複数の猫の画像が表示されるはずです。パソコンからプロジェクトを実行するには、node.js で次のコマンドを実行する必要があります。

npm install express rendertron-middleware
node server.js

次に、使用しているブラウザで http://localhost:8080 を指定します。ここからはダイナミック レンダリングを設定します。

Rendertron インスタンスのデプロイ

Rendertron は、URL を取得して、headless Chromium によってその URL の静的 HTML を返すサーバーを実行します。Rendertron プロジェクトの推奨事項に沿って、Google Cloud Platform を使用します。

新しい Google Cloud Platform プロジェクトを作成するためのフォーム

新しい Google Cloud Platform プロジェクトを作成するためのフォームに関しては、無料枠でプロジェクトを作成できる点に注意してください。また、この設定を本番環境で使用すると、Google Cloud Platform の料金体系に応じた課金が発生する点にも注意してください。

  1. Google Cloud Console で新しいプロジェクトを作成します。入力フィールドにある「プロジェクト ID」をメモします。
  2. Google Cloud SDK をドキュメントに説明されているとおりにインストールしてログインします。
  3. 以下のコマンドで、GitHub にある Rendertron リポジトリのクローンを作成します。
      git clone https://github.com/GoogleChrome/rendertron.git
      cd rendertron
  4. 次のコマンドを実行して依存関係をインストールし、パソコンに Rendertron を構築します。
      npm install && npm run build
  5. 次の内容の config.json という新しいファイルを rendertron ディレクトリに作成して、Rendertron キャッシュを有効化します。
      { "datastoreCache": true }
  6. rendertron ディレクトリから次のコマンドを実行します。「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます。
      gcloud app deploy app.yaml --project EURE_PROJEKT_ID
  7. 任意のリージョンを選択して、デプロイを確定します。デプロイが完了するまで待ちます。
  8. YOUR_PROJECT_ID.appspot.com(「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます)をブラウザに入力します。入力フィールドといくつかのボタンがある Rendertron のインターフェースが表示されるはずです。
Google Cloud Platform に導入した後の Rendertron の UI

Rendertron のウェブ インターフェースが表示されたら、Rendertron インスタンスが正常にデプロイされたことを意味します。次の手順で必要になるため、プロジェクトの URL(YOUR_PROJECT_ID.appspot.com)をメモします。

サーバーへの Rendertron の追加

ウェブサーバーは express.js を使用しており、Rendertron には express.js ミドルウェアがあります。server.js ファイルのディレクトリで、次のコマンドを実行します。

npm install --save rendertron-middleware

このコマンドにより、npm から rendertron-middleware がインストールされます。これで、rendertron-middleware をサーバーに追加できます。

const express = require('express');
const app = express();
const rendertron = require('rendertron-middleware');

bot リストの構成

Rendertron は、ユーザー エージェントの HTTP ヘッダーを使用して、リクエストが bot からのものなのか、ユーザーのブラウザからのものなのかを判断します。Rendertron には、比較に使用できる、適切に整理された bot ユーザー エージェントのリストがあります。Googlebot は JavaScript を実行できるため、デフォルトではこのリストに Googlebot は含まれません。Rendertron に Googlebot リクエストもレンダリングさせるには、ユーザー エージェントのリストに Googlebot を追加します。

const BOTS = rendertron.botUserAgents.concat('googlebot');
const BOT_UA_PATTERN = new RegExp(BOTS.join('|'), 'i');

Rendertron は後でこの正規表現とユーザー エージェントのヘッダーを比較します。

ミドルウェアの追加

bot リクエストを Rendertron インスタンスに送信するには、express.js サーバーにミドルウェアを追加する必要があります。ミドルウェアはリクエストしているユーザー エージェントを確認し、既知のボットからのリクエストを Rendertron インスタンスに転送します。次のコードを server.js に追加します。必ず「YOUR_PROJECT_ID」を Google Cloud Platform プロジェクト ID に置き換えてください。

app.use(rendertron.makeMiddleware({
 proxyUrl: 'https://YOUR_PROJECT_ID.appspot.com/render',
 userAgentPattern: BOT_UA_PATTERN
}));

サンプル ウェブサイトをリクエストする bot は Rendertron から静的 HTML を受け取るので、コンテンツを表示するために JavaScript を実行する必要がありません。

設定のテスト

Rendertron の設定に成功したかどうかをテストするには、もう一度モバイル フレンドリー テストを実行します。

最初のテストとは違い、猫の画像が表示されます。HTML タブには、JavaScript コードが生成したすべての HTML が表示され、コンテンツを表示するための JavaScript が Rendertron によって不要になったことがわかります。

まとめ

ウェブアプリに変更を加えずに、ダイナミック レンダリングを設定しました。このような設定により、ウェブアプリの静的バージョンの HTML をクローラに提供できます。

モバイル ファースト インデックスに向けて、構造化データと画像の代替テキストをお忘れなく!

「モバイル ファースト インデックス」の取り組みについて最初にお知らせしてから 2 年が経過しました。これは、ユーザーがウェブにアクセスする際に最も使用しているデバイスを考慮してスマートフォン用 Googlebot でクロールを行う取り組みです。あらゆる種類のデバイスに対応する素晴らしいウェブサイトが作られ、世界中で数多くのウェブサイトがモバイルウェブに対応しました。まだすべきことは多くありますが、ここに、モバイル ファースト インデックスに移行したページがグローバルでの検索結果の半数を超えたことをお知らせします。

モバイル ファースト インデックスの確認

通常、モバイル ファースト インデックスへのサイトの移行は、移行準備が完了したことをテストで確認できたときに行います。サイトを移行させた場合には、Search Console のメッセージを通じて、サイト所有者への通知が行われます。サイトの移行はサーバーログでも確認できます。移行後はスマートフォン用 Googlebot からのリクエストが大半を占めているはずです。また、URL 検査ツールを使用することでより簡単に確認できます。サイト所有者は同ツールでサイトの URL が最後にどのようにクロールおよびインデックスされているかを確認できます(確認はサイトのトップページだけで十分です)。

レスポンシブ デザインの手法がサイトに採用されているのであれば、特に準備は不要です。レスポンシブ ウェブデザインが採用されていないサイトでは、評価時に次の 2 種類の問題が比較的多く見られました。

モバイル版ページの構造化データの欠落

構造化データは、ページのコンテンツを把握しやすくする上で便利なものです。また、検索結果で自身のページをより効果的に強調できるようにもなります。デスクトップ版ページで構造化データを採用しているのであれば、モバイル版ページでも同じ構造化データを使用する必要があります。これは、非常に重要なことです。モバイル ファースト インデックスでは、インデックスの対象となるのはモバイル版ページのみになるため、モバイル版ページで構造化データが使用されていないと、構造化データが見落とされてしまいます。

なお、この問題に関しては、ページのテストの際に気をつける点があります。テストに際しては、構造化データの一般的な検証を行い、次にモバイル版ページの構造化データと比較することをおすすめしています。モバイル版ページに対しては、モバイル端末のシミュレーションを行ってソースコードを確認したり、モバイル フレンドリー テストツールで生成した HTML を使用したりすることをおすすめしています。一点ご留意いただきたいのは、モバイル ファースト インデックスに関して言えば、ページがモバイル フレンドリーである必要ありません、という点です。

モバイル版ページの画像代替テキストの欠落

画像に alt 属性(「代替テキスト」)を指定することで、スクリーン リーダー(モバイルでも使用されます)を使うユーザーや検索エンジンのクローラに対して、画像の内容を説明できるようになります。画像に代替テキストが指定されていない場合、Google 画像検索でページ上の画像のコンテキストを把握することが非常に難しくなります。

ウェブサイトの主要なモバイル版ページで、ソースコードの「img」タグを確認してください。上述のとおり、モバイル版ページのソースコードは、ブラウザでモバイル端末のシミュレーションを行って表示させることも、モバイル フレンドリー テストで、Googlebot が生成するバージョンを確認することもできます。ソースコードの「img」タグを探し、Google 画像検索で表示させたい画像に alt 属性が適切に指定されているか再度確認してください。

たとえば、次のように指定します。

代替テキストが適切に指定されている例:
<img src="cute-puppies.png" alt="ブランケットの上にかわいい子犬がいる写真">

代替テキストが指定されていない例:
<img src="sad-puppies.png">

多くの素晴らしいウェブサイトが、モバイルでも適切に表示されるようになるのは喜ばしいことです。より多くのウェブサイトがモバイル ファースト インデックスでインデックスされ、サイトへのアクセスに最も使用されるスマートフォンでより多くのユーザーがウェブを検索できるようになることを願っています。Google はこの変更を慎重に確認して評価し続けます。ご不明な点がございましたら、ウェブマスター フォーラムまたはイベントでご質問ください。

ライブストリーム用の Indexing API と構造化データを導入します

ここ数年、ライブ動画のオンライン ストリーミングがこれまでになく簡単になり、セレブ動画からイベント動画まで大きな広がりを見せています。しかし、どの動画が進行中なのか、またいつ動画が始まるのかを見付けるのは必ずしも簡単ではありません。

そこで、Google 検索やアシスタントでライブストリームを簡単に見つけられるようにするため、本日新たに「ライブストリーム構造化データ」を導入しました。ライブストリーム構造化データと Indexing API を使用すると、ライブ動画をいつストリーミングするかを Google に知らせることができます。それにより、ストリーミング中のライブ動画に赤色の「進行中」バッジを表示することも可能になります。

ライブストリーム構造化データをページに追加する

ウェブサイトでライブ動画をストリーミングする場合は、ライブストリームに関するデベロッパー向けドキュメントを参照し、動画がライブ配信であることを示すとともに、配信の開始時間と終了時間を指定してください。さらに、ページ上に動画があることを Google に伝えるために、VideoObject 構造化データを追加する必要があります。

Indexing API でクロールをリクエストする

今回の導入に伴い、Indexing API がライブストリーム構造化データに対応しました。Indexing API を呼び出して、ライブ配信に間に合うようにサイトのクロールをリクエストしてください。Indexing API は、ライブストリームの開始時と終了時、構造化データに変更を加えたときにも呼び出すことをおすすめします。

詳しくは、デベロッパー向けのドキュメントをご覧ください。ご不明な点がありましたら、ウェブマスター ヘルプフォーラムまでお寄せください。皆様のライブ動画が、Google 検索に表示されるのを楽しみにしております。

URL 検査ツールなど、Search Console に新機能を追加しました

数か月前に新しい Search Console をリリースしましたが、その後も機能の拡充を続けています。ここでは、その最新の状況についてお知らせします。

「URL 検査」ツール

Search Console に関するご要望で最も多かったものの 1 つが、「Google 検索が特定の URL をどう認識しているのか、もっと詳しく知りたい」というものでした。こうした声にお応えし、Google 検索をより透明性の高いものにするため、本日新しいツール「URL 検査」のリリースを開始いたしました。URL 検査ツールを使用すると、各ページのクロール、インデックス登録、検索結果の配信に関する詳細情報を Google のインデックスから直接入手できます。

所有するページの URL を入力すると、最終クロール日とそのステータス、クロールやインデックス登録のエラー、そのページの正規 URL などがわかります。ページが正常にインデックス登録されていれば、ページ内で検出された拡張機能(リンクされている AMP バージョン、レシピや求人のリッチリザルトなど)の情報やステータスもわかります。

有効な AMP 拡張機能でインデックス登録されている URL

ページがインデックス登録されていない場合は、その理由を調べることができます。新しいレポートには、ページの noindex robots メタタグと Google の正規 URL に関する情報が追加されています。

HTML 内の noindex メタタグが原因でインデックス登録されていない URL

ワンクリックで同じ問題が発生しているページの一覧が開きますので、問題を分析して、修正するのに役立ちます。

新しい URL 検査ツールが、Google インデックス内の新規ページや既存のページの問題解決に役立つことを願っております。本日より順次リリースを開始し、数週間以内にはすべての方にご利用いただけるようにする予定です。

その他の変更点

URL 検査ツールのほかにも、Search Console に新しい機能やレポートを追加しています。

フィードバックをありがとうございます

Google では、皆様からお寄せいただいたフィードバック、アンケートの回答、使用統計情報などに常に注意を払い、Search Console の改善に役立てています。インデックス カバレッジ レポートや AMP レポートの新しい問題検証フローも多くの方にご利用いただいていており、これまでより迅速に問題を修正できているように思います。また、メールや [検証の詳細] ページによる検証プロセスの改善も高く評価いただき、チーム一同大変喜んでおります。

こうしたフローの改善やバグの修正には、皆様からのご意見、ご要望が欠かせません。フィードバックをお寄せいただいたすべての方に感謝いたします。

今後の展開

新しい Search Console はまだベータ版ですが、毎月のように機能やレポートを追加しています。さまざまなフィードバック方法を用意しておりますので、今後もご意見、ご要望などございましたらぜひお知らせください。

モバイル ファースト インデックスを開始します

本日、Google は 1 年半の慎重な実験とテストの結果、モバイル ファースト インデックスのベストプラクティスに準拠したサイトの移行を開始したことを発表します。

これまで、Google のクロール、インデックス、ランキング システムでは、主にデスクトップ版のコンテンツが使用されてきました。そのため、その内容がモバイル版と大きく異なる場合、モバイル検索ユーザーに問題が発生する可能性がありました。 モバイル ファースト インデックスとは、モバイル版のページをインデックスやランキングに使用し、主にモバイル ユーザーが探しているものを見つけやすくすることを意味します。

検索結果の提供に使用するインデックスは引き続き 1 つのままです。 メインのインデックスとは別の「モバイル ファースト インデックス」はありません。 歴史的にデスクトップ版のコンテンツがインデックスされてきましたが、今後はモバイル版のコンテンツを使用していきます。
モバイル ファースト インデックスに移行しているサイトは、Search Console で通知します。 サイト所有者は、スマートフォンの Googlebot からのクロールが大幅に増加することに気づくでしょう。 さらに Google は検索結果と Google のキャッシュ ページにモバイル版のページを表示します。
Search Console でのメッセージ例(英語の場合)


Google がモバイル コンテンツを特定する方法の詳細については、デベロッパー向けドキュメントをご覧ください。 レスポンシブ ウェブデザインやダイナミック サービングを使用しているサイトでは、一般的にモバイル ファースト インデックスが設定されています。AMP ページと非 AMP ページを持つサイトの場合、モバイル版の非 AMP ページをインデックスします。

最初のローンチのタイミングで適用されなかったとしても、慌てる必要はありません。 モバイル ファースト インデックスは、コンテンツのランキング方法ではなく、コンテンツの集め方に関するものです。コンテンツが モバイル ファースト インデックスによって集められたものであったとしても、その他の方法で集められたコンテンツやデスクトップ版のコンテンツに比べてランキング優位性があるというわけではありません。 さらに、デスクトップ版のコンテンツのみをお持ちの場合でも、コンテンツは引き続きインデックスされます。

一方で、Google ではモバイル フレンドリーなコンテンツを引き続き推奨しています。 私たちは、インデックスのすべてのコンテンツ(デスクトップであろうとモバイルであろうと)を評価して、それがモバイルフレンドリーであるかどうかを判断します。2015 年以降、この評価によって、モバイルで検索しているユーザーは、モバイルフレンドリーなコンテンツを検索結果からより簡単に見つけられるようになりました。 これに関連して、2018 年 7 月初めより、表示に時間のかかるコンテンツは、デスクトップとモバイルの両方の検索結果に悪影響が出ることが、最近発表されました

要点をまとめると:
  • モバイル インデックスを、より広範に展開します。 この方法でインデックスされたとしても、ランキング優位性はなく、モバイル フレンドリーの評価とは独立して動作します。
  • モバイル フレンドリーなコンテンツは、モバイル検索結果の成果を上げる方法を検討しているウェブマスターにとって役立ちます。
  • コンテンツを高速に読み込むことは、モバイルとデスクトップ両方のユーザーにとってより良い成果を上げる方法を検討しているウェブマスターにとっては、依然として役立ちます。
  • いつものように、ランキングには多くの要素を使用します。 他の多くの信号が最も関連性の高いコンテンツであると判断した場合は、モバイルフレンドリーでないコンテンツや、読み込みが遅いコンテンツをユーザーに表示することがあります。

Google はこの変更を慎重に確認して評価し続けます。 ご不明な点がございましたら、ウェブマスター ヘルプ フォーラムまたはイベントでご質問ください。

AJAX クロールのページのレンダリング

AJAX クロールに関するスキーム(英語)は、JavaScript ベースのページに Googlebot がアクセスできるようにするための方法として導入されましたが、廃止の予定であることを以前にお知らせいたしました。長期間にわたる Google のエンジニアの取り組みによって、Googlebot による JavaScript のレンダリング能力は大幅に向上してきました。こうした進歩を踏まえて、2018 年の第 2 四半期に、サイト側に JavaScript ベースのページのレンダリングを求めるのではなく、Google 側でレンダリングする形へと移行します。つまり、AJAX クロールに関するスキームは使用されなくなります。

ご存じのとおり、AJAX のクロールに関するスキームでは、URL に「#!」が含まれているページか、「fragment メタタグ(英語)」が設定されているページのいずれかを対象として、URL に「?_escaped_fragment_=」が含まれたページをクロールします。この URL でクロールされるページは、完全にレンダリング済みのページか、それと同等の状態のページ(そのウェブサイト自体で作成されるもの)である必要があります。

今回の変更に伴い、#! が含まれている URL は Googlebot によって直接レンダリングされるようになり、ウェブサイトの所有者はレンダリング済みのページを提供する必要がなくなります。こうした URL のページは Google 検索結果に引き続き表示されます。

ほとんどの AJAX クロールのウェブサイトに対しては今回のアップデートに伴う大きな変化はないものと想定していますが、ウェブマスターの皆様は以下に説明するようにページを再度確認してください。サイトに潜在的な問題が検出された場合は通知が送信されます。

サイトにおいて現在、#! が含まれている URL か fragment メタタグのいずれかをお使いの場合は、以下の手順を行うことをおすすめします。

  • Google Search Console でウェブサイトの所有権を確認して Search Console のツールへのアクセス権を取得し、問題が検出された場合に Google から通知が届くようにします。
  • Search Console の「取得してレンダリング」を使ってテストします。#! が含まれている URL とエスケープされた URL のテスト結果を比較して、違いがないかを確認します。ウェブサイトのさまざまな部分についてこのテストを実施します。サポートされている API について詳しくはデベロッパー向けドキュメント(英語)をご覧ください。また、必要に応じてデバッグガイド(英語)もご参照ください。
  • Chrome の [要素を検証] を使用して、リンクに「a」HTML 要素が使われていることと、必要に応じて(ユーザー作成コンテンツ内など)rel=nofollow が指定されていることを確認します。
  • Chrome の [要素を検証] を使用して、ページのタイトルと description メタタグ、robots メタタグ、その他のメタデータを確認します。また、レンダリングされたページで構造化データ(英語)が利用可能となっているかどうかも確認します。
  • Flash や Silverlight といったプラグイン ベースのテクノロジーに含まれているコンテンツを検索のインデックスに登録するには、JavaScript か「標準の」HTML に変換する必要があります。

この変更がウェブサイトの運営と管理をより容易にし、サイト側でページをレンダリングする必要性が軽減することを願っています。ご質問やご意見がございましたら、お気軽にウェブマスター ヘルプ フォーラムJavaScript サイトのワーキング グループ(英語)までお寄せください。

サイトを一時停止する場合の対応方法

: この投稿は、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 を通常の設定に戻します。

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

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

Posted by John Mueller, Webmaster Trends Analyst, Switzerland

コンテンツ キーワードが廃止されます

Search Console がまだウェブマスター ツールと呼ばれていた初期の頃、コンテンツ キーワードは、Googlebot によるクロールで検出されたウェブサイトのキーワードを知るための唯一の方法でした。また、Google がページを問題なくクロールできることを確認したり、サイトがハッキングされていないかを確認できる便利な機能でした。

その後、Googlebot がページをどのように取得しているかについては、サイト内のあらゆるページに対して瞬時に確認することができるようになりました。また、検索アナリティクスでは、どんなキーワードによる検索で自分のサイトが表示されたかも確認できます。ハッキングについても様々な種類について Google から自動で通知が届くようになりました。その一方で、コンテンツ キーワードについては、表示されたキーワードについて、ユーザーの間でしばしば混乱が見られました。この状況に鑑み、このたび、 Search Console のコンテンツ キーワードを廃止する運びとなりました。

ページ上の単語(キーワード)は、現在も Google やユーザーがあなたのページを理解するうえで依然として重要です。Google のシステムは改善されましたが、まだあなたの思いを読み取ることまではできません。そのため、自分のサイトはどんなサイトなのか、何を見てほしいのかを明確にする必要があります。あなたのサイト、商品、サービスの特徴を訪問者にしっかりと伝えましょう。

これまでにコンテンツ キーワードに表示されたキーワードの中で、印象深いキーワードにはどのようなものがあったでしょうか?ぜひコメント欄でお知らせください!

ご意見やご感想がございましたら、以下のコメント欄やウェブマスター ヘルプ フォーラムでお気軽にお問い合わせください。

Googlebot のスマートフォン用ユーザー エージェントの更新について

Google では、ウェブ上の技術の変化に応じて、Googlebot で使用するユーザー エージェントを定期的に更新しています。来月、Googlebot のスマートフォン用ユーザー エージェントを更新する予定です。

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
(2016 年 4 月 18 日以降の Googlebot スマートフォン用ユーザー エージェント)

現在は、次の Googlebot スマートフォン用ユーザー エージェントを使用しています。

Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
(現在の Googlebot スマートフォン用ユーザー エージェント)

Google では、最新のウェブ技術を使用しているページをレンダラーが適切に解釈できるように、ユーザー エージェント文字列を更新しています。Google のレンダラーは進化を続けており、今回のユーザー エージェント文字列の更新は、レンダラーが Safari よりも Chrome により近づいていることを示しています。サイトが幅広いユーザーやブラウザで適切に表示されるように、機能検出やプログレッシブ エンハンスメントの使用をおすすめします。

Google の評価によると、今回のユーザー エージェントの変更は 99% のサイトで影響がない見込みです。サイトが影響を受ける場合に最も多い理由として考えられるのは、そのサイトが Googlebot の特定のユーザー エージェント文字列を期待している場合です。Googlebot に対するユーザー エージェント スニッフィングは推奨されておらず、クローキングの一形態と見なされます。Googlebot は他のブラウザと同様に扱ってください。

サイトが今回の更新による影響を受けそうな場合は、Search Console の「取得してレンダリング」ツールを使って(新しいユーザー エージェント文字列で更新済みです)、または、ブラウザのデベロッパー ツール(Chrome のデバイスモードなど)でユーザー エージェント文字列を変更する方法で、サイトを確認することをおすすめします。ご不明点については、ウェブマスター ヘルプ フォーラムでお気軽にお問い合わせください。

HTTPS ページが優先的にインデックスに登録されるようになります

Google では常にユーザーのセキュリティを最優先に考え、長年にわたってウェブの安全性の向上やブラウジング体験の改善に取り組んできました。GmailGoogle 検索、YouTube では以前からセキュアな接続を実現しており、昨年は、検索結果での HTTPS URL の掲載順位を若干引き上げる取り組みにも着手しました。ウェブのブラウジングはウェブサイトとユーザーとの間の私的な体験となるべきであり、傍受中間者攻撃、データ改ざんの対象となってはいけません。Google が「HTTPS everywhere」の推進に取り組んできたのはこのためです。

この流れの一環として、Google は、より多くの HTTPS ページを探すよう、インデックス システムを調整していることをお知らせします。具体的には、HTTP ページに対応する HTTPS ページのクロールを開始します。これは、対応する HTTPS ページがどのページからもリンクされていない場合にも対象となります。同じドメインの 2 つの URL が同じコンテンツを掲載していると思われ、かつ、両者が異なるプロトコル スキームで配信されている場合、通常、以下の条件を満たしていれば HTTPS URL を選択してインデックスに登録します。

  • セキュアでない依存関係が含まれていない。
  • robots.txt によってクロールがブロックされていない。
  • セキュアでない HTTP ページに(または HTTP ページを経由して)ユーザーをリダイレクトしていない。
  • HTTP ページへの rel="canonical" リンクが含まれていない。
  • noindex robots メタタグが含まれていない。
  • 同一ホスト上の HTTP ページヘのリンクが含まれていない。
  • サイトマップに HTTPS URL が掲載されている(または URL の HTTP バージョンが掲載されていない)。
  • サーバーに有効な TLS 証明書がある。

Google のシステムではデフォルトで HTTPS バージョンが優先されますが、HTTP サイトを HTTPS バージョンにリダイレクトしたり、サーバー上に HSTS ヘッダーを実装することで、他の検索エンジンでも HTTPS バージョンを明示的に優先させることができます。

今回の取り組みにより、ウェブの安全性がさらに高まることを嬉しく思います。Google 検索結果で HTTPS ページを表示することにより、Google では、セキュアでない接続を介してウェブサイトを閲覧してコンテンツ インジェクション攻撃を受けやすくなるリスクを減らしたいと考えています。ご質問やご意見がございましたら、ウェブマスター ヘルプ フォーラムまでお気軽にお問い合わせください。

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 に対して提示するコンテンツと、通常のユーザーに対して表示するコンテンツが異なる場合はクローキングと見なされ、ウェブマスター ガイドライン違反と判断されることがあります。

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

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

モバイル フレンドリー アップデートを開始します

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

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

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

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

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

4 月 21 日のモバイル フレンドリー アップデートについてのよくある質問

4 月 21 日に実施されるモバイル フレンドリー アップデートについてのよくある質問とその回答をご紹介します。Google ではこの 2 月にモバイル フレンドリー アップデートを発表し、モバイル版の検索結果におけるモバイル フレンドリー ページ(スマートフォンで見やすく使いやすいページ)の掲載順位を全世界で引き上げるとお知らせしました(逆に、大きい画面のみを対象にデザインされたページは、モバイル版の検索結果で掲載順位が大きく下がる可能性があります)。この件についてよくある質問を以下にご紹介します。

全般的なよくある質問
  1. パソコンやタブレットでの掲載順位もこの変更の影響を受けますか?
    いいえ。今回のアップデートは、タブレットやパソコンからの検索には影響しません。影響する範囲は、スマートフォンから行われるすべての言語および地域での検索です。
  2. ページ単位とサイト単位のどちらでモバイルの掲載順位が上がるのですか?
    ページ単位の変更になります。たとえば、サイト内で 10 個のページがモバイル フレンドリーになっていて、他のページはモバイル フレンドリーでない場合、掲載順位が上がるのはモバイル フレンドリーになっている 10 ページのみです。
  3. 自分のサイトのページがモバイル フレンドリーかどうかを確認する方法はありますか?
    個別のページが「モバイル フレンドリー」かどうかは、モバイル フレンドリー テストを使用して確認できます。

  4. モバイル フレンドリー テストで個別の URL をリアルタイムでテストします。

    モバイル フレンドリーについての情報をサイト単位で調べるには、ウェブマスター ツールのモバイル ユーザビリティ レポートを確認します。この機能では、当該サイトのページを Google が最後にクロールしてインデックス登録したときのデータを使用します。


    ウェブマスター ツールの [モバイル ユーザビリティ] ではサイト全体のモバイル フレンドリーへの現在の対応状況を知ることができます。

  5. 4 月 21 日までにモバイル フレンドリー ページを準備できなかった場合、掲載順位においてモバイル フレンドリーと判断されるまでにどの程度の時間がかかりますか?
    ページがモバイル フレンドリーかどうかは、ページがクロールされてインデックスに登録されるたびに判断されます。次のアップデートを待つ必要はありません。ページをモバイル フレンドリーにしたら、スマートフォン用の Googlebot によってページが再度クロールされてインデックスに登録されるのを待つか、ウェブマスター ツールFetch as Google の [インデックスに送信] を使用して処理をリクエストすることができます。URL が大量にある場合は、サイトマップの送信をご検討ください。前から存在する URL(レスポンシブ ウェブ デザイン動的な配信などの URL)をモバイル コンテンツに使用する場合は、サイトマップに lastmod タグも含めてください。
  6. モバイルの掲載順位変更が 4 月 21 日に実施され、4 月 22 日にトラフィックが減少しなかった場合、自分のサイトの掲載順位には影響がなかったと判断できますか?
    サイトの掲載順位がモバイル フレンドリー アップデートの影響を受けたかどうかについて、4 月 22 日に最終判断を下すことはできません。モバイル フレンドリー アップデートの公開は 4 月 21 日より開始しますが、インデックス内のすべてのページにこのアップデートが反映されるまで 1 週間程度かかる見込みです。
  7. 所有するモバイルサイトのページが、モバイル フレンドリー テストではモバイル フレンドリーでないと判定されます。なぜですか?
    スマートフォンで適切に動作するようデザインされたページがモバイル フレンドリー テストを通過しない場合、その原因としてよくあるのが、スマートフォン用 Googlebotによるリソース(CSS や JavaScript など)のクロールが禁止されていることです。これらのリソースがクロールできないと、ページがスマートフォンで見やすく使いやすいかどうか(つまり、モバイル フレンドリーかどうか)を判断することができません。対処方法は次のとおりです。
    • ブロックされたリソースがモバイル フレンドリー テストで表示されるかどうかチェックします(多くの場合、ページの画像も部分的にしか表示されません)。
    • 必要なファイルに対する Googlebot のクロールを許可します。
    • ページがモバイル フレンドリー テストを通過するか再度チェックします。
    • Fetch as Google の [インデックスに送信]更新した robots.txt を Google に送信を使用して、更新したページの再処理をリクエストします(または、ページが再クロールされてインデックスに登録されるのを待ちます)。

      モバイルページがモバイル フレンドリー テストを通過しない原因の多くは、スマートフォン用 Googlebot による CSS や JavaScript などのリソースのクロールを許可していないことです。これらのリソースはページがモバイル フレンドリーかどうか判断するうえで重要です。

      繰り返しますが、サイト所有者の皆様は Googlebot にページのすべてのリソース(CSS、JavaScript、画像を含む)のクロールを許可するようおすすめします。そうすることで、Google がページを正しく解析してインデックスに登録できるようになるほか、このケースではページがモバイル フレンドリーかどうかを判断できるようになります。

  8. モバイル フレンドリーでないサイトにリンクしている場合はどうなりますか?
    ページから、パソコンや大きな画面向けにデザインされたページなどのモバイル フレンドリーでないページにリンクしている場合でも、「モバイル フレンドリー」と判断されます。モバイル フレンドリー ページからパソコン専用のページへの移動はモバイル ユーザーにとって快適とは言えませんが、モバイル フレンドリー サイトが増えるに伴い、この点は問題にならなくなると思われます。
  9. モバイルサイトを別にホスティングする(パソコン用は www でモバイル用は m.example.com となる場合など)よりも、レスポンシブ ウェブ デザイン(パソコン版とモバイル版で同じ URL と同じ HTML を用いる)のページのほうが、モバイル フレンドリーとして掲載順位が高くなりますか?
    いいえ。レスポンシブ ウェブ デザイン(RWD)、モバイル用の別個の URL動的な配信のどの設定を採用していても、モバイル フレンドリーかどうかの評価は同じになります。サイトでモバイル用の別個の URL や動的な配信を使用する場合は、モバイル SEO ガイドを参照して、モバイルページが Google に正しくクロールおよびインデックス登録されるようにすることをおすすめします。
  10. モバイルフレンドリーでないサイトやページは検索から削除されるのですか?
    モバイル フレンドリーであることは重要ですが、検索結果の掲載順位決定においては、様々なシグナルが利用されています。検索クエリの意図は大変重要なシグナルです。ですので、たとえクオリティの高いコンテンツが掲載されているページがモバイル フレンドリーではなかったとしても、関連の強いクエリでは高い順位に掲載される可能性があります。
専門的なよくある質問
  1. ユーザーがパソコンからのユーザーのみなので、モバイルサイトを作成する理由が見当たらないのですが、その場合はどうなりますか?
    必ずしもモバイルサイトが不要とは言えません。統計では、パソコンを持ったことがない、または既存のパソコンを買い替える考えがないという理由のいずれかで、「モバイルのみ」の利用となるユーザーの増加傾向が示されています。また、モバイル ユーザーが少ないのは、そもそもサイトがモバイル フレンドリーでないから、という可能性もあります。

    モバイル フレンドリー アップデートは、サイトの対象ユーザー、言語、地域、モバイルとパソコンのトラフィックの比率などに関係なく、すべてのサイトにわたって実施されるモバイル検索に適用されます。
  2. YouTube 動画を埋め込んでいるためにモバイル ユーザビリティ エラーが表示されるページがあるのですが、どうすればよいですか?
    YouTube 動画を埋め込む方法には注意を払うようおすすめします。モバイルページで <object> による「古いスタイル」の埋め込みを使用している場合は、幅広い互換性を持つ <iframe> による埋め込みに変更してください。YouTube では現在、ウェブでの既定のプレーヤーとして HTML5 を使用しているため、動画再生ページの「共有」機能や YouTube iFrame API から <iframe> タグを使用して埋め込む動画はモバイル フレンドリーになります。さらに複雑な方法で統合している場合も、スマートフォンに対してスマートフォンのネイティブ サポートを使用するよう指示することから、モバイル フレンドリーになります。

    他の動画サイトの Flash コンテンツについても、専用プラグインの使用を避けるために、上記に相当する HTML5 埋め込みタグやコード スニペットが提供されているか確認してください。
  3. タップ ターゲットのサイズについての明確な標準はありますか?
    はい。重要なタップ ターゲットは高さと幅を 7 mm 以上とし、また、小さいタップ ターゲットの間には 5 mm 以上のマージンを設けることを推奨しています。平均的な大人の指先のサイズは幅約 10 mm なので、これらのサイズを使用することにより、画面のスペースを有効に利用するとともに、操作しやすいインターフェースを提供することができます。
  4. サイトをすばやくモバイル フレンドリーにするために、新たなレスポンシブ サイトが完成するまでの間、機能を大幅に取り除いたバージョンのサイト(別のモバイルページ)の作成を考えています。この方法に問題はありますか?
    まず、Google では 3 種類のモバイル設定をサポートしていることと、ウェブサイトをモバイル フレンドリーにするにはレスポンシブでなくてもよいことを心に留めておいてください。ご質問への回答としては、「機能を大幅に取り除いた」バージョンのサイトの作成は慎重に検討することをおすすめします。ページの形式をモバイル向けにできたとしても、ユーザーが通常のタスクを簡単に行えなかったり、全体のワークフローがスムーズでなかったりすれば、ユーザーの不満の原因となり、結果的に作業が無駄となる可能性もあります。もしも、暫定のモバイルサイトを作成する場合は、レスポンシブ版のサイトの完成後に必ず、サイトを正しく移転してください。たとえば、モバイル用の別の URL を参照することがないよう、すべての URL を更新して、対応するレスポンシブ版にモバイル用 URL を 301 でリダイレクトするようにしてください。
推奨事項
モバイル フレンドリー サイトをまったく作成したことがなくても、問題ありません!モバイル フレンドリー ウェブサイトのドキュメントはじめるをご覧ください。

モバイルサイトの作成をはじめる(https://developers.google.com/webmasters/mobile-sites/)。

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

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

App Indexing でアプリのインストールを増やしましょう

[この記事は Lawrence Chang, Product Manager による Android Developers Blog の記事 "Drive app installs through App Indexing" を元に、北村が翻訳・加筆し、Google Japan Developer Relations Blog に掲載したものです。詳しくは元記事をご覧ください。]

開発者のみなさんがアプリを素晴らしいものにするため時間と努力を惜しまないのと同様に、我々もみなさんの素晴らしいコンテンツをより多くの人たちに届けるお手伝いをしたいと願っています。既に 300 億のアプリ内リンクがインデックスされていることからもわかるように、App Indexing は Android 向けアプリのインストール後のエンゲージに役立てられています。今週より、Android 向けアプリをインストールしていない方々にも、Google で検索することで、あなたのアプリを発見することができるようになります。App Indexing が実装済みで、あなたのアプリからインデックスされたコンテンツが Android 上の Google 検索の結果と一致した場合、検索結果にあなたのアプリのインストール ボタンが表示される可能性があります。そのボタンを押下することで、ユーザーは Google Play ストアに移動し、アプリをインストール、そしてアプリ内の検索結果に該当する箇所に直接アクセスすることができます。

これらのインストール リンクの追加を皮切りに、アプリをインストールしているか否かに関わらず、App Indexing はすべての Android ユーザーのランキングシグナルとして利用されることになります。これにより、Google の検索機能が新しいユーザーの獲得だけでなく、既存ユーザーとのエンゲージメントにも役立つことを願っています。App Indexing について詳しくは g.co/AppIndexing を、Google 検索の他の活用方法については g.co/DeveloperSearch を御覧ください。

ウェブマスター ツールを利用してリソースのブロックを解除しましょう

ウェブページではデザイン性や機能性を高めるため、画像、CSS ファイル、JavaScript ファイルがよく使われます。このようなリソースがクロールからブロックされると、Googlebot では検索用にページをレンダリングする際にそのリソースを使用できません。そこで Google ウェブマスター ツールでは、ウェブマスターの皆様がこのような問題を特定して解決できるよう、ブロックされたリソースのレポートを導入しました。
このレポートには、サイト上のブロックされたリソース(JavaScript、CSS、画像など)の提供元ホスト名が表示されます。行をクリックすると、ブロックされたリソースの一覧と、そのリソースが埋め込まれているページが表示されます。そこから、ページ コンテンツのクロールとインデックス登録を可能にするために何が必要かを診断、解決する手順に進むことができます。

取得してレンダリングすると、これらのブロックされたリソースがどの程度問題であるかが表示されます。URL の取得とレンダリングをリクエストすると、Googlebot としてレンダリングされたスクリーンショットと一般ユーザーとしてレンダリングされたスクリーンショットの両方が表示されます。これにより、ページが Googlebot から異なって認識されることに大きく影響する問題を、より簡単に特定できるようになります。

ウェブマスター ツールでは、ウェブマスターが関与しうると思われるホストのみを表示するため、現時点では、さまざまなサイトで使用されているホスト(一般的な解析サービスなど)は表示されません。すべての robots.txt ファイルを更新するのは時間がかかるため、ブロックされたときに表示が大きく異なってしまうリソースから開始することをおすすめします。関連する手順について詳しくは、ウェブマスター ツールのヘルプセンター記事をご覧ください。

この新機能が、ウェブサイト上のブロックされたリソースを特定してブロック解除する際に、皆様のお役に立てば幸いです。ご不明な点がありましたら、お気軽にウェブマスター プロダクト フォーラムまでお寄せください。

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 の使用を推奨いたします。

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