ウェブマスター ヘルプフォーラム：新しいトップレベルユーザーが誕生しました！

2012年2月1日水曜日 | 18:06

ウェブマスター ヘルプフォーラム から嬉しいニュースのおしらせです。
この度、新たにべしみさん、dronpa さん のお 2 人が、トップレベル ユーザーの一員となりました。

トップレベル ユーザー とは Google のヘルプフォーラム上でユーザーのみなさんの疑問や問題解決を的確にサポートしたり、ユーザー間のディスカッション、情報交換に積極的に参加しフォーラムを盛り上げてくださっているアクティブ ユーザーに Google から付与させていただいているタイトルです。

昨年末の記事 でもご案内したようにウェブマスター ヘルプフォーラムは、新しいプラットフォームへと移行し、ますます多くのウェブマスターの皆さんにご利用いただいています。最近では、スマートフォン 版 Googlebot-Mobile の導入について皆さまからの質問に Google 社員がお答えする Q&A 企画 なども実施しました。今後も日本のウェブマスターの皆さまにさらに役立つコミュニティを目指して、様々な企画をおこなっていきたいと思っています。

新たなトップレベル ユーザーの誕生で、さらにフォーラムが盛り上がっていくことを確信しております！

今後とも ウェブマスター ヘルプフォーラム をよろしくお願いします。まだご利用されたことのない方も、これを機会にぜひご参加ください！

* なお、トップレベル ユーザー制度はあくまでフォーラム上での活動についてのみに限定されたもので、トップレベル ユーザーの方々のウェブサイト運営、SEO 施策、ウェブマスターとしてのお仕事内容などについて Google が保証するのものではないことをご理解ください。

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

Links to this post

Labels:


より多くの有益なコンテンツを検索結果に: クローラが POST リクエストにも対応しました

2012年1月31日火曜日 | 11:02

Google はインターネットの発展とともに、クロールやインデックスの技術も進化させていくべきと考えています。これまでにも、Flash のインデックス登録を改良 （英語）し 、Caffeine というより新しいインフラストラクチャー （英語）を導入してきました。また、妥当と思われる場合は フォームもクロール （英語）するようになりました。その一方で最近では JavaScript や AJAX の人気の高まりにともない、 あるページのコンテンツ全体を取得するのに POST リクエストが必要な場合や、POST リクエストから得られるデータがなければ一部情報が欠けてしまい、ページの見た目がおかしくなってしまう場合が増えてきています。このような状況は、Google 検索にとって理想的とはいえません。なぜなら、コンテンツを正しく取得しインデックス登録することができなければ、ユーザーの検索キーワードに対して、最も包括的で関連性の高い結果を返せなくなってしまう可能性があるからです。

ウェブマスターの皆さんには、ページに必要なリソースを取得する際に、通常 GET を使用するようにアドバイスしています。これは GET でページに必要なリソースを取得できる方がはるかにクロールしやすいためです。POST リクエストを GET に書き換える試みも実験的に開始していますが、ほとんどの場合、POST と GET で返されるコンテンツはまったく異なるので、単純に書き換えるだけでは一部のサイトでしか効果を得られません。また、ウェブマスターの皆さんがサイトを作る際に POST を選択する妥当な理由もあります （たとえば、GET リクエストよりも POST リクエストの方が多くのデータを付加できます）。そこで、GET リクエストの方がまだまだ一般的ではありますが、インターネット上のより多くのコンテンツを検索できるようにするために、妥当かつ安全であると判断した場合は、Googlebot は POST リクエストを実行するようになりました。

Google は、Googlebot の POST リクエストによって、意図しないユーザー側の動作が行われてしまわないよう、細心の注意を払っています。Googlebot による POST は、あくまでもページが自動的にリクエストするリソースをクロールし、通常のユーザーがブラウザでその URL を開いたときに目にするものをシミュレートするためのものです。これにより該当ページのインデックス内容とインスタント プレビューが改善される可能性があります。また、今はこのようなアプローチをとっていますが、今後新たな経験則を見出していくことでよりよい方法へと変わっていくでしょう。

それでは、今回の改善点について、いくつかの POST リクエストを例にとってご説明します。

Googlebot の POST リクエストの例

  • （ケース1）: POST リダイレクト経由でページをクロールする
    <html>
      <body onload="document.foo.submit();">
        <form name="foo" action="request.php" method="post">
          <input type="hidden" name="bar" value="234"/>
        </form>
      </body>
    </html>
  • （ケース2）: POST XMLHttpRequest 経由でリソースをクロールする
    • 以下の手順では、ページのレンダリング時に自動的に実行される XMLHttpRequest を通じて、ページのインデックス登録とインスタント プレビューの両方を改善しています。
    1. Google が以下のようなコンテンツの yummy-sundae.html をクロールします。
      <html>
        <head>
          <title>絶品！アイスクリームサンデー</title>
          <script src="jquery.js"></script>
        </head>
        <body>
          おいしいアイスクリームサンデーのページです。
          <div id="content"></div>
          <script type="text/javascript">
            $(document).ready(function() {
              $.post('hot-fudge-info.html', function(data)
                {$('#content').html(data);});
            });
          </script>
        </body>
      </html>
    1. Google が yummy-sundae.html のインデックス登録を開始します。この過程で、コンテンツのよりよい理解やインスタント プレビュー生成のためにページのレンダリングが必要かどうかを判断します。
    2. レンダリングを行う際は、yummy-sundae.html がリソース hot-fudge-info.html への XMLHttpRequest を自動的に POST で送信します（上記の $.post(...) の部分）。
    3. POST リクエストされた URL （ hot-fudge-info.html ）とリクエストデータ本体が Googlebot のクロール待ち行列に追加されます。
    4. Googlebot が hot-fudge-info.html をクロールするために POST リクエストを送信します。
    5. これで Google は yummy-sundae.html の正確なインスタント プレビューを作成できるようになりました。この際、hot-fudge-info.html のコンテンツを yummy-sundae.html に組み込む場合もあります。
    6. Google が yummy-sundae.html のインデックス登録を完了します。
    7. ユーザーが[hot fudge sundae]を検索します。
    8. ここで Google のアルゴリズムは、上記の検索キーワードに対して、yummy-sundae.html との関連性を hot-fudge-info.html の内容も含めてより適切に判断します。さらに、ページのインスタント プレビューも正しく表示されます。
サイトをクロールしやすく、インデックスに登録されやすくするには？
ヘルプ センター には Google と相性の良いサイトの作り方についての一般的な情報が掲載されています。ここでは Google がクロール、インデックスに登録しやすく、またインスタント プレビューを作りやすいサイトの作成に関しておさらいしておきましょう。
  • リソースを取得する際には（あえて POST を使う理由がない限りは） GET リクエストを使用してください。
  • ページをレンダリングするのに必要なリソースがクロールできる状態であることを確認してください。上の例でいうと、hot-fudge-info.html が robots.txt によってクロールできない状態になっていると、Googlebot はそのページを取得できません。さらに細かく言うと、XMLHttpRequest を発行する JavaScript のコードがサイト外部の .js ファイル内にあり、そのファイルが robots.txt によってクロール不可である場合、Google には yummy-sundae.html と hot-fudge-info.html の関連性がわかりません。この場合、たとえ hot-fudge-info.html がクロールできる状態にあっても、Googlebot が正しくクロールしない可能性があります。インターネット上には、さらに複雑な形で外部のリソースを組み込んでいる例が数多く存在します。Google が皆さんのサイトの構造をよりよく理解できるよう、基本的には Googlebot がすべてのリソースをクロールできるようにしてください。

    サイト内にブロックされているリソースがあるかどうかを確認するためには、ウェブマスター ツール の [Labs] セクションにある [インスタント プレビュー] を選択し、確認してください。
  • Googlebot に返すコンテンツが、ユーザーのブラウザに返しているものと同じであることを確認してください。クローキング  （ Googlebot に返すコンテンツと、ユーザーへ返すコンテンツが異なるようにする行為）は、検索キーワードに関係のないコンテンツをユーザーに検索結果として提供してしまう可能性があるため、Google の ウェブマスター向けガイドライン 違反となります。これまで Google では、悪意のないウェブマスターが POST リクエストに関してクローキングを行っているケースや（悪意がなくてもガイドライン違反となります）、そのクローキングが原因で Javascript エラーが発生し、インデックスに登録されないケースを見てきました。このようなエラーによってページがインデックスされないのであれば、そもそもクローキングを行う意味もなくなります。要するに、検索と相性のいいサイトを作る場合には、クローキングはとにかく避けた方がいいということになります。

    意図せずにクローキングを行っていないか確認するには、先ほど登場したウェブマスター ツール内の[ インスタント プレビュー ] を使用するか、ブラウザのユーザー エージェント文字列を、たとえば以下のように変更します:

    Mozilla/5.0 (compatible; Googlebot/2.1;
      +http://www.google.com/bot.html)

    上記の変更を加えたあとにサイトを確認し、変化がないようであれば問題ありません。空白のページが表示される、JavaScript エラーが発生する、ページの一部が欠けていたり変化したりしている場合は、なんらかの問題があります。
  • 重要なコンテンツ（インデックス登録したいコンテンツ）は、表示の際にユーザー アクションを使用せずに、直接ページにテキストとして記入してください。ほとんどの検索エンジンはテキスト中心に作られており、テキスト ベースのコンテンツを探すことを最も得意としています。Google では様々なタイプのコンテンツをクロールし、インデックスに登録する方法を随時アップデートしていますが、重要なコンテンツはテキストで記載するのがベストであることに変わりはありません。
インデックス登録をコントロールする
Google 検索でクロールしてほしくない、インデックス登録してほしくないコンテンツがある場合は、従来通り robots.txt を使用する のが最も効果的な方法です（訳注: それでもなおインデックスに登録する可能性があります。詳細はリンク先をご参照ください）。ページのインスタント プレビューが作成されないようにする方法については、スニペットとインスタント プレビューの削除をご確認ください。また、Google Web Preview ユーザー エージェントや nosnippet メタ タグについての解説、インスタント プレビューの詳細はインスタント プレビューの FAQ （英語）をご参照ください。

今後について
Google は、ユーザーがより関連性の高い検索結果を得られるよう、今後も包括的なインデックス作りに取り組んでいきます。これからも Google のクロールとインデックスの方法は、インターネットそのものと同様に成長を遂げていきます。この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Pawel Aleksander Fedorynski, Software Engineer, Indexing Team, and Maile Ohye, Developer Programs Tech Lead
Original version: GET, POST, and safely surfacing more of the web

Links to this post

Labels: ,


検索結果によりよいタイトルを

2012年1月27日金曜日 | 10:00

Google の検索結果において、タイトルは重要な位置を占めています。タイトルは一行目に表示され、検索をした人はそのタイトルをクリックしてそれぞれのページにたどり着きます。そのため、そのページが何を表しているか一目でわかるように、具体的でわかりやすいタイトル（およびスニペット用にメタ ディスクリプション）を付けることをウェブマスターの皆様には常々お勧めしてきました。

ユーザーにどのようなタイトルを見せるかを決めるために、Google では多くのシグナルを利用しています。もしウェブマスターの方が <title> タグを使っているならば、基本的にはそれをタイトルに用います。しかしどのような検索キーワードに対しても常に <title> タグに書かれているものをそのまま表示してしまうと、ユーザーにとってはそのタイトルは検索キーワードと関連性が低いように見えることもあるかもしれません。そのような場合にそのページが検索キーワードと関連性が高いものであると気づいてもらうため、Google では代わりのタイトルを生成するアルゴリズムを利用することがあります。Google のテストでは、ほとんどの場合においてこれらの代わりのタイトルの方が元のタイトルよりも検索キーワードに対して高い関連性を示しました。また、これらの代わりのタイトルを使用することによりタイトルのクリック率は大幅に向上しており、検索をするユーザーとウェブマスターの皆さんの双方に役立っていました。これが Google が代わりのタイトルを表示する理由の半分です。

もう一方で、HTML 内に何もタイトルがなかったり、そのページを表すようなタイトルがウェブマスターによってつけられていない場合にも代わりのタイトルは表示されます。例えば、タイトルが単純に「ホーム」と名づけられている場合、タイトルはそのページの内容を表してはいません。また、1 つのサイトのページ内でまったく同じ（またはほぼ同じ）タイトルが使われているという問題もよく見られます。最近では、不必要に長かったり読みにくかったりするようなタイトルを簡潔でわかりやすいものに置き換える、という試みも行われています。

よりよいタイトルやメタ ディスクリプションの書き方、代わりのタイトルを生成する時に使われるシグナルに関しての詳しい情報は、「サイトのタイトルと説明の変更」というヘルプ記事をご覧ください。また、Google ではウェブサイトのタイトルが改善できそうなことを発見した場合はウェブマスター ツールの「HTML の候補」という項目でウェブマスターの方にお知らせする取り組みも行っています。こちらはウェブマスター ツールの左側のメニューの「診断」からご覧ください。

この記事に関するコメントや質問は ウェブマスター ヘルプフォーラム までお寄せください。

Posted by Pierre Far, Webmaster Trends Analyst
Original version: Better page titles in search results

Links to this post

Labels: , , ,


誘導ページ（Doorway Page）はガイドライン違反です

2012年1月16日月曜日 | 10:37

多くの方が、普段運営されているサイトへの集客に様々な工夫をされていることと思います。しかし、ユーザーのためではなく、過度に検索エンジンを意識した集客方法は、Google のウェブマスター向けガイドライン に違反してしまうことがあります。検索結果を人為的に操作してユーザーの利便性を下げてしまうようないくつかの行為を、Google は明確にガイドライン違反としています。その中で今回は日本でも多く見られるケースとして、誘導ページ（ドアウェイ、Doorway） についてご説明したいと思います。

誘導ページとは、ユーザーを特定のサイトに誘導したり、資料請求などをさせたりすることだけを目的に作られた、ユーザーに独自の価値を提供していないページ群のことをいいます。（いわゆる「サテライトサイト」の中にも、誘導ページにあたるものが多くあります。）具体的な例をご紹介しましょう。

例１：品質の低いコンテンツに、ある特定のサイトへのリンクを追加しただけのブログを複数作り、ユーザーを誘導しているケースです。


例２：地名以外ほぼ同一の誘導ページを大量に生成しているケースです。どの地域のページを見ても、資料請求フォームなどは同じものが用意されていることなどが特徴です。こうしたページでは、その地域ごとに特化した有用な情報はほとんど提供していないため、誘導ページと判断される可能性は高いと言えるでしょう。


Google は、ユーザーの検索キーワードに最も関連性が高く、かつ有用な検索結果を提供するよう心がけています。そのため、ここで例にあげたような、検索エンジンからユーザーを誘導するだけのために作られた固有の価値を持たないページは、ガイドライン違反として対応させていただく場合があります。

ウェブマスターの方々の中には、ここまでの説明を読んで、実際ご自身の管理しているページに誘導ページに該当するものがあるかどうか、気になる方もいらっしゃることでしょう。その場合、検索エンジンがなかったとしても、そのようなページを作ったかどうか、考えてみてください。Google ではあくまでユーザーにとってそのページを訪れる価値があるかという観点から判断をおこなっています。本当にユーザーのために作られたページと、検索エンジンからの誘導のみを目的としたページとでは、手のかけ方に大きな違いがあることを Google は認識していますのでご安心ください。

ご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Posted by Takeaki Kanaya, Search Quality Team

Links to this post

Labels: , , ,


ホスティング プロバイダとウェブマスターの皆様へ

2012年1月12日木曜日 | 10:50

Google ウェブマスター向け公式ヘルプフォーラム に寄せられる質問の中には、ホスティング プロバイダの設定に起因するものがときおり見られます。そこで今回は、これまでにあった一般的な問題と修正方法をご紹介します。ホスティング プロバイダとウェブマスターの皆さまがこのような問題を認識、診断、修正するのに役立てば幸いです。

  • Googlebot のクロールがブロックされている: これはよく発生する問題で、通常はファイアウォールや DoS 攻撃防御システムの設定ミスで発生することが多く、また一部のサイトが採用している CMS（コンテンツ マネージメント システム）が原因で発生することもあります。防御システムはホスティングの要ともいえる要素で、サーバー リクエストの頻度が高い場合には自動的にブロックするよう設定されています。Googlebot はその性質上、人間のユーザーよりも多くのリクエストを実行するため、防御システムが Googlebot をブロックの対象と判断してしまい、その結果ウェブサイトがクロールできなくなることがあります。このような問題が発生していないか確認するには、ウェブマスター ツールの Fetch as Googlebot 機能 を使用して実際に Googlebot がクロールできているかを確認したり、ウェブマスター ツールの クロール エラー において何かアラートが表示されていないかを確認したりしてください。

    Google では Googlebot によるクロールをより高度に制御したいウェブマスターの皆さまとホスティング プロバイダ向けに、いくつかのツールや情報を提供しています。これらの対策を実装することにより、クロールの効率も向上します。
    • robots.txt ファイル や URL パラメータの設定 を活用して Googlebot のクロールを制御する方法について、詳細なヘルプ記事を用意しています。
    • Googlebot のユーザー エージェントを偽装した不正なロボット対策方法については、ヘルプ記事「Googlebot の確認」をご利用ください。
    • Googlebot のリクエストの速度を変更するには、ウェブマスター ツールであなたのサイトを確認し、クロール速度の変更 を行ってください。ホスティング プロバイダが IP アドレスの所有権を確認することもできます。
    クロールとインデックスに関する FAQ でも様々な情報を提供していますのでぜひご覧ください。

  • サイトへ接続できない: 上記と似たような問題で、Googlebot（およびユーザー）がウェブサイトにアクセスしようとしても繋がらない場合があります。これには DNS の問題、サーバーの過負荷によるタイムアウトや接続拒否、コンテンツデリバリネットワーク（CDN）の設定ミス、その他多くのエラーが含まれます。Googlebot がこのような問題に遭遇した場合は、ウェブマスター ツールで URL にアクセスできないエラー または クロール エラー として報告されます。

  • 無効な SSL 証明書: ウェブサイトの SSL 証明書が有効であるためにはサイト名と一致している必要があります。よく発生する問題としては、有効期限の過ぎた SSL 証明書を使っていたり、サーバー上のすべてのウェブサイトで同じ証明書を使用する設定にしていたりといったサーバー側の設定ミスがあります。このような状況ではほとんどのウェブ ブラウザーがユーザーに警告を行います。Google もウェブマスター ツール経由でメッセージを送信し、ウェブマスターに通知します。この問題を解決するには、ユーザーが目にするウェブサイトのすべてのドメインおよびサブドメインに対して SSL 証明書が有効であることを確認する必要があります。

  • ワイルドカード DNS: ウェブサイトがすべてのサブドメイン リクエストに応答するように設定できることがあります。たとえばウェブサイト example.com を、foo.example.com、made-up-name.example.com、その他すべてのサブドメインに対するリクエストに応答させることができます。

    特定の場合ではこれが望ましいこともあります。たとえば、ユーザーが作成したコンテンツを提供するウェブサイトでは、各アカウントにサブドメインを付与することがあります。しかし、別のホスト名で不必要にコンテンツが複製され、Googlebot のクロールに影響を与える可能性もあるため一部のウェブマスターにとっては望ましい状況ではありません。

    ワイルドカード DNS の設定に関する問題を最小化するには、ウェブサイトでこの技術を使用しないか、存在しないホスト名に対して成功の応答をしないようにサーバーを設定します。この場合、接続を拒否するか、404 の HTTP ステータス コードを返すようにします。

  • バーチャル ホスティングの設定ミス: この問題では、同じサーバーにホスティングされている複数のホストやドメイン名が、常に 1 つのサイトのコンテンツを返す症状が発生します。つまり、サーバーが複数のサイトをホスティングしていても、リクエスト内容にかかわらず 1 つのサイトのみを返すということです。この問題を調べるには、サーバーが HTTP リクエストの Host  ヘッダ フィールドに正しく応答しているかを確認する必要があります。

  • ホスト専用 URL での重複コンテンツ: 多くのホスティング サービスでは、テストや開発用の URL を提供しています。たとえばホスティング プロバイダが http://a.com/ というウェブサイトをホストしている場合、http://a.example.com/ や http://example.com/~a/ などの URL を介してサイトにアクセスできる場合があります。このようなホスト専用 URL は、パスワードで保護するなどして一般ユーザーにアクセスできないようにすることをお勧めします。一方でこういった URL がアクセス可能な場合でも、Google のアルゴリズムはお客様の意図したとおりに URL を取得する場合が多いです。アルゴリズムが  ホスト専用 URL を選択 した場合でも、正しく 正規化 を行うことでアルゴリズムが取得する URL を指定することができます。

  • ソフト エラー ページ: ホスティング プロバイダの中には、エラー ページの表示にエラーのステータス コードの代わりに 200（成功）のステータス コードを使用している場合があります。たとえば「ページが見つかりません」というエラー ページが  404 ではなく 200 を返す ソフト 404 エラー であったり、「サイトが一時的に使用できません」というメッセージが通常のステータス コード HTTP 503 ではなく 200 を返したりします。Google ではソフト エラー ページの検出に努力していますが、アルゴリズムがソフト エラー ページの検出に失敗した場合、これらのページがそのままインデックスされてしまいます。これはランキングや クロスドメイン URL の選択 で問題が発生する原因となる可能性があります。ステータス コードを確認する方法は簡単です。Fetch as Googlebot などのツールを使用して、サーバーが返す HTTP ヘッダーを確認するだけです。エラー ページが HTTP 200 を返した場合、正しい HTTP エラー ステータス コードを返すように設定を変更します。また、ウェブマスター ツールの診断セクションにあるクロール エラー ページで、ソフト 404 の報告がないか確認してください。

  • コンテンツの変更とフレーム: ホスティング プロバイダによってコンテンツが変更され（一般的には、ページにスクリプトや画像が挿入されます）、驚いたことがあるウェブマスターの方もいるでしょう。また、<frames>や <iframe> を使用してサイトのコンテンツが他のページに埋め込まれて表示されることもあります。ウェブ ホストによってコンテンツに意図しない変更が行われたかどうかを確認するには、ホストが提供するページのソース コードを確認し、ご自身でアップロードしたコードと比較します。サーバーによるコードの変更は、とても便利な場合もあります。たとえば、サーバーで Google の mod_pagespeed Apache モジュール （英語）などのツールを使用している場合、ページの表示速度を最適化するために縮小コードを返すことがあります。

  • スパムやマルウェア: 一部のウェブ ホストやサブドメイン サービスが、マルウェアやスパムを広める要因になっている場合があります。Google ではユーザーの保護と検索品質を維持するための措置は、なるべく細やかに対応するようにしていますが、ホスティングされているサイトの大部分がスパム サイトであったり、マルウェアを配布したりしている場合、ウェブ ホスト全体に対して措置を取る必要が出てくることがあります。マルウェアを制御する助けとして、Google は以下のツールを提供しています。
以上のヒントが、ホスティング プロバイダとウェブマスターの皆さまが問題を見つけ出し修正するのに役立てば幸いです。ここに挙げた以外に、サービスの品質やサポートの充実度など、ホスティングの品質面についても気を配るようにしてください。 

この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

Written by Pierre Far, Webmaster Trends Analyst
Original version: Tips for hosting providers and webmasters

Links to this post

Labels: , , ,


登録: 投稿 (Atom)