Google ウェブマスター向け公式ブログ

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

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

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

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

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

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

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

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

13 years 10ヶ月 ago
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 のクロールとインデックスの方法は、インターネットそのものと同様に成長を遂げていきます。この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

13 years 11ヶ月 ago
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 は以下のツールを提供しています。
以上のヒントが、ホスティング プロバイダとウェブマスターの皆さまが問題を見つけ出し修正するのに役立てば幸いです。ここに挙げた以外に、サービスの品質やサポートの充実度など、ホスティングの品質面についても気を配るようにしてください。 

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

2011 年もありがとうございました!ウェブマスター ヘルプ フォーラムから感謝をこめて

13 years 11ヶ月 ago
2011 年も残すところあと数日となりました。

Google ウェブマスター向け公式ヘルプ フォーラム は、ウェブマスターの方々の問題解決や、ディスカッションの場として開設されてから 3 年。今年も、さらに多くの方にご参加いただきました。本当にありがとうございました。

ここで、2011 年ウェブマスター向けヘルプ フォーラムのハイライトをご紹介します。

より使いやすく新しい UI へ
つい先日ですが、ウェブマスター向け ヘルプ フォーラムは新しいプラットフォーム「Google プロダクト フォーラム」に移行しました。Google グループをベースに開発された Google プロダクト フォーラムは利便性がより一層高くなり、関心をお持ちのトピックについて他のユーザーと簡単に意見交換したり、質問を投稿して回答を受けたりすることができるようになりました。

トップレベル ユーザーの方々とアメリカへ
9 月にはアメリカのカリフォルニア州サンタクララ、およびマウンテンビューの Google オフィスにて、Google のヘルプ フォーラムで活躍されている全世界のトップレベル ユーザー(ヘルプ フォーラムに貢献してくださっているアクティブなユーザーの呼称)をご招待して「グローバル トップレベル ユーザー サミット 2011」が開催されました。日本のウェブマスター ヘルプ フォーラムからも あうらゆうまさんとマサさんの 2 人がこのイベントに参加され、他の参加者や Google 社員とよりよいヘルプ フォーラムのあり方やプロダクトについてディスカッションしました。私達日本のサーチ クオリティ チームのメンバーもディスカッションに参加し、普段はフォーラム上でしかやり取りできないトップレベル ユーザーのみなさまから直接ご意見をお聞きすることができ、非常に貴重な機会となりました。

みなさまからたくさんのアイディア・ご意見を頂きました
また、今年はユーザーの方々からの貴重なご意見・アイディアも、フォーラムを通してたくさん頂くことができました。3 月に実施した ウェブマスター ヘルプ フォーラム ユーザー アンケートではフォーラム運営についてご意見・アイディアを聞かせていただいたり、10 月には「ウェブマスター ツールにどんな機能があるといいですか?」といったトピックを設定して、ご意見、ご提案を聞かせていただくことができました。また、3 月に起きた東日本大震災の際には、ウェブマスターとして震災に対してできることはないか、多くの方々がディスカッションに参加してくださいました。

これらすべては、多くのウェブマスターのみなさまに日頃から積極的に参加していただいているからこそ生まれたエピソードです。改めまして、今年フォーラムに参加してくださった全てのみなさんに感謝申し上げます。ありがとうございました!

ここで、特に活発にディスカッションに参加し、いつもフォーラムを盛り上げてくださっているみなさまのお名前をご紹介させていただきます。

あうらゆうまさん、 マサさん、たむらはんさん、癋見no さん、suzukik さん、dronpa さん、VAIO さん、den さん、netya さん、emi さん、SEM-ADVISER さん、hnxyy654 さん

来年も多くのみなさまと共に、ウェブマスター向けヘルプ フォーラムをますます活気あるコミュニティとして大きく成長させていけたらと思っています。
2012 年もどうぞよろしくお願いします!

それではみなさま、良いお年をお迎えください。

p.s.
フォーラムで 2011 年のブログ人気記事 をご紹介してます。ちなみに、今年最も多くの方に読んで頂いた記事は「アフィリエイトを導入されているウェブマスターの皆さまへ」でした。2 位以下の記事は、ぜひ以下のスレッドからご覧下さい。
2011 年にウェブマスターのみなさまの関心を集めたブログ記事は!? 年末年始のお休み中にぜひお読みください。

多言語コンテンツのマークアップのヒント

13 years 11ヶ月 ago
世界中のユーザーからのアクセスがあるようなサイトにおいて、ユーザーの言語や地域に適したコンテンツを提供する方法はいくつかあります。Google では昨年、コンテンツは単一の言語で提供し、メニューやナビゲーション、フッターなどを複数の言語で提供しているウェブページ向けに、rel="alternate" hreflang="x" (英語)のサポートを開始いたしました。

今回は、多言語コンテンツに対する以下の 2 つのケースのサポートをさらに充実させます。
  • 多地域向けのサイトで、ほぼ同じ内容のコンテンツを使用している場合。例: オーストラリア、カナダ、米国向けの英語版サイトで、価格のみが異なっているもの
  • 多地域向けのサイトで、内容をすべて翻訳したコンテンツを提供しているもの、あるいは、全く異なる各国言語のコンテンツを地域別に提供しているもの。例: 日本語、英語、韓国語で書かれた製品情報ページを持つサイト
言語と地域を指定する
Google では、rel="alternate" hreflang="x" のサポートをさらに拡張し、翻訳されたコンテンツ、または複数の異なる地域向けに提供されたコンテンツに対応しました(英語)。hreflang 属性では言語が指定でき、また任意で国の指定、同等コンテンツのある代替 URL の指定もできます。このような代替 URL を指定することによって、Google ではこのようなページをグループとして認識し、検索ユーザーの言語地域に最適な URL を提供することを目指しています。代替 URL は、同じサイトのものでも、別のドメインのものでも、どちらでも構いません。

ほぼ同一のコンテンツとしてページにアノテーションを付ける
同一言語を使用し、異なる地域を対象にする、ほぼ同じコンテンツを持つページが複数ある場合は必要に応じて、rel="canonical" 属性 を使用して、優先するバージョンを指定することができます。Google はその指定に基づき、検索結果を表示する際はそのバージョンを優先しつつ、適宜ユーザーの地域に対応する URL を表示するようにします。この方法は、例えば、同一の製品ページのドイツ語版を用意しているが、ドイツ、オーストリア、スイスぞれぞれの Google で検索するユーザーに見せるページを分けたい場合などに活用できます。

使用例
具体的な手順を、URL の例を示しながら説明します。
  • http://www.example.com/ - ウェブサイトの通常のホームページ (スペイン語)
  • http://es-es.example.com/ - スペインのユーザー向けバージョン (スペイン語)
  • http://es-mx.example.com/ - メキシコのユーザー向けバージョン (スペイン語)
  • http://en.example.com/ - 汎用的な英語バージョン
これらのページすべてに対し、マークアップを次のように使用して、言語と地域 (任意) を指定します。

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" />
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

hreflang=”es-ES” や hreflang=”es-MX” のように地域が指定されている場合、Google はその地域をターゲットにしているものと判断します。これらのアノテーションはすべて、URL 単位で使用してください。上記のリンク要素のどちらについても、サイトのトップ ページではなく、特定のページの URL を使用するようにしてください。

困ったときは
多地域、多言語対応のウェブサイトの正しい実装方法に関してご不明な点がありましたら、ヘルプ センター(英語)の該当トピックをご覧になるか、ウェブマスター ヘルプ フォーラム までご質問をお寄せください。

スマートフォン版 Googlebot-Mobile の導入について

14 years ago
スマートフォンユーザの増加に伴い、最近ではスマートフォン用に最適化されたコンテンツを提供するサイトも増えてきました。そこでGoogleでは、従来の携帯電話(フィーチャーフォン)のユーザーエージェントを使用した Googlebot-Mobile に加えて、スマートフォンのユーザーエージェントを使用した Googlebot-Mobile によるクロールを開始しましたのでお知らせいたします。スマートフォン版 Googlebot-Mobile の導入により、より幅広くスマートフォン用コンテンツを収集して、スマートフォンユーザーのための検索サービスの改善に利用していきます。

現時点で Googlebot-Mobile が使用する主なユーザーエージェントは次の通りです。
  • 従来型携帯電話版 Googlebot-Mobile
    • SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
    • DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
  • スマートフォン版 Googlebot-Mobile
    • Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
スマートフォン版 Googlebot-Mobile により収集されたコンテンツは、主にはスマートフォン向け検索の品質向上に利用されますが、デスクトップ検索や他の検索モードの品質向上にも利用されることもあります。新しいクローラが収集する情報の例としては、スマートフォン用のコンテンツであるかどうかや、リダイレクトの情報などが挙げられます。

これらの情報を用いる新たな機能として「スマートフォン用ページのリダイレクトスキップ」があります。この機能は、スマートフォンをスマートフォン用コンテンツにリダイレクトするページについて、検索結果から直接スマートフォン用ページへリンクするというものです。この機能により、検索結果ページをロードする際、リダイレクトに起因して発生する平均0.5〜1秒の遅延を短縮することが可能となります。

Googlebot-Mobile が使用するすべてのユーザーエージェントは特定の機種を指すものとなっていますので、Googlebot-Mobile を特別扱いせず、フィーチャーフォンの Googlebot-Mobile はフィーチャーフォンとして、スマートフォンの Googlebot-Mobile はスマートフォンとして扱ってください。過去のブログポスト で述べたガイドラインは、スマートフォンに関する記述を除いては有効です。Googlebot-Mobile が従来型の携帯電話のユーザーエージェントしか使用しないという前提に基づいて、Googlebot-Mobile を特別に扱っているサイトがあるかもしれませんが、この機会に Googlebot-Mobile に対する方針の見直しをおすすめいたします。

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

2012/2/3 追記
* この記事に関するご質問をウェブマスターヘルプフォーラムで受け付け、スマートフォン版 Googlebot-Mobile に関する質問専用のスレッド でその回答を公開しております。ぜひこちらも合わせてご覧下さい。

Google カスタム検索エンジンがウェブマスター ツール内で作成・管理できるようになりました

14 years ago
Google カスタム検索エンジン (CSE)は、サイト内に Google 検索を用いたオーダーメイドの検索環境を作成するサービスです。複数のサイトをまたいで検索したり、自分のサイト デザインに合わせて検索結果のデザインを変更したり、検索向け AdSense で収益を得ることもできます。この度、この Google カスタム検索エンジンが ウェブマスター ツール から簡単に作成できるようになりました。

初めて CSE を作成する場合、ウェブマスター ツールの「Labs」>「カスタム検索」をクリックすると、自動でサイト内のみを検索するデフォルト設定の CSE が作成されます。そこから、設定を変更してカスタマイズするか、そのままサイトに CSE を追加するためのコードを入手できます。設定を変更したい場合はいつでも CSE の設定ページに移動することができます。

CSE を作成後(または、既に作成している場合)、ウェブマスター ツールの「Labs」>「カスタム検索」をクリックすればウェブマスター ツールのページを離れることなく CSE を管理できます。

今回のアップデートで、ユーザーが皆さんのサイト内で情報を探しやすくなれば幸いです。ウェブマスター ツールと CSE の連携に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

複数ページにまたがる記事やコンテンツをお持ちの方へ。rel=”next” と rel=”prev” を使用したページネーションのご紹介

14 years ago
rel=”canonical” の設定が重複コンテンツを Google に知らせる手がかりになっているのと同様に、複数ページにまたがった一つのコンテンツがある場合、HTML の タグの rel=”next” と rel=”prev” (英語)を使ってそのページ間の関係を Google に示すことができるようになりました。

ウェブを見渡してみると、続きものになっているコンテンツには様々な形態があります。例えば 1 つの記事を複数のページに分けているものや、同一の製品カテゴリに属する製品を複数ページにまたがって掲載しているもの、フォーラムの 1 つのスレッドを一連の複数 URL に分割しているものなどがあります。この度、続きものを構成する個々のページ上で rel=”next” と rel=”prev” マークアップの指定を行うことによって、Google に対し、次のような指定ができるようになりました。
  • 個々のページ / URL にあるリンクの効果などのインデックス対象の属性を、一連のページ全体のものとしてまとめること(つまり、page-1.html、page-2.html といった個々のページにあるリンクをばらばらの状態ではなく、一連のグループとして取り扱うこと)
  • 最も関連性が高いページ / URL (通常は一連のコンテンツの最初のページ)にユーザーを誘導すること
rel=”next” と rel=”prev” を使うことによって、続きものになっているコンテンツの個々の URL 間の関係性を Google に示すことができます

ただし、この rel=”prev” と rel=”next” を実装すべきかどうかについて判断するにあたって、1 つ例外があります。連続するページで構成されるコンテンツとは別に、「すべて表示」ページ( 1 ページに情報のすべてが表示されたページ)をお持ちの場合、あるいはそれを作ろうとしている場合はブログ記事「検索結果に『すべて表示』ページを優先的に表示する方法」を参照してください。ユーザーは検索をするときに「すべて表示」ページを好む傾向にあるため、Google では、適正と判断される場合は、個々のページではなく「すべて表示」ページの方を検索結果に表示するようにしています(rel=”next” および rel=”prev” を使用すれば、個々のページが表示される可能性が高くなります)。

サイトに「すべて表示」ページがない場合や、Google 検索による「すべて表示」ページの表示を無効にしたい場合は、この記事で説明する rel="next" と rel="prev" を使用してください。

「すべて表示」ページが含まれるページ構成については、ブログ記事の 検索結果に「すべて表示」ページを優先的に表示する方法 をご参照ください

ウェブマスターの選択肢

このような続きもののコンテンツに対するウェブマスターの対応については、次の 3 つの選択肢があります。
  1. 特に何も対策はしない。複数ページに分割されたコンテンツがウェブ上に存在し、ページ内の HTML マークアップ rel=”next”、rel=”prev” の有無に関係なく、Google は最も関連性の高い検索結果を表示するよう努めます。
  2. サイトに「すべて表示」ページがある場合、または「すべて表示」ページを設けようとしている場合は、検索結果に「すべて表示」ページを優先的に表示する方法 を参照してください。
  3. ひと続きになっているコンテンツを構成する個々の URL に rel=”next” と rel=”prev” を指定し、URL 間の関係性を Google に示す(このブログ記事で紹介している例です)。これによって Google はコンテンツのインデックス登録がより正確にできるようになり、最も関連性の高いページ(通常は最初のページ)をユーザーに表示するようになります。実装に関しては以下で詳しく説明します。
rel=”next” と rel=”prev” の実装方法

上記の 3 番を選んだ方は、実装方法の説明をご覧下さい。次のようにいくつかの URL にページ分けされているコンテンツを例にとります。

http://www.example.com/article?story=abc&page=1
http://www.example.com/article?story=abc&page=2
http://www.example.com/article?story=abc&page=3
http://www.example.com/article?story=abc&page=4

最初のページ http://www.example.com/article?story=abc&page=1 では、<head> のセクションに次のように記述します。
<link rel="next" href="http://www.example.com/article?story=abc&page=2" />

2 番目のページ http://www.example.com/article?story=abc&page=2:
<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

3 番目のページ http://www.example.com/article?story=abc&page=3:
<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

そして最後のページ http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

いくつか注意すべき点があります:
  • 最初のページには rel=”next” マークアップのみ記述し、rel=”prev” マークアップは記述しない。
  • 2 ページから、最後から 1 つ前のページまでは、rel=”next” と rel=”prev” のマークアップを両方とも記述する。
  • 最後のページには rel=”prev” のみ記述し、rel=”next” は記述しない。
  • rel=”next” と rel=”prev” の値は、相対 URL または絶対 URL のどちらでもよい( <link> タグに準じる)。また、ドキュメントに リンクを指定している場合は、そのベース URL に基づいて相対パスを指定する。
  • rel=”next” と rel=”prev” は、 <head> セクション内で宣言するだけでよく、ドキュメントの <body> 内で記述する必要はない。
  • rel=”previous” は、rel=”prev” リンクの構文上のバリエーションとして許容される。
  • rel="next" と rel="prev" を指定することと、rel="canonical" を指定することは、別々の概念である。よって、同一ページ内に両方の宣言を記述することが可能。たとえば、http://www.example.com/article?story=abc&page=2&sessionid=123 の中で、次のように記述してよい。

    <link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/>
    <link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" />
    <link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />

  • rel=”prev” と rel=”next” は Google に対するヒントであり、絶対的な指示ではない。
  • rel="prev" や rel="next" を指定すべき箇所で指定していないなど、正しく実装されていない場合は、Google はこれまでと同様にページのインデックス登録を行い、コンテンツを把握する。
わからないことがある場合は?

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

検索結果に「すべて表示」ページを優先的に表示する方法

14 years ago
複数ページにまたがる記事やコンテンツをお持ちのウェブマスターの方向けに、「すべて表示」ページ(View-all ページ)を使用して検索結果に優先的に表示する方法をご紹介します。

ユーザーは、情報の一部だけが表示されているページを適宜めくっていく (「次へ」をクリックして次のページを閲覧する)コンテンツよりも、1 ページに情報のすべてが表示されたコンテンツの方を好むということが、我々が実施した調査の結果、判明しました。

ユーザーは、ページをめくることでロードの待ち時間が長くなる複数ページ構成より、1ページにすべてが表示されているコンテンツの方を好むことが多い

これを踏まえて Google はユーザー エクスペリエンス向上のため、続きもののコンテンツ(たとえば page-1.html、page-2.html... が存在するコンテンツ)に「すべて表示」のバージョン(たとえば page-all.html)も存在していることを検出したときは、検索結果には「すべて表示」のバージョンを優先して表示する取り組みをおこなっています。サイトに「すべて表示」のバージョンが存在している場合は、ウェブマスター側では特に何もする必要はありません。また、インデックス対象となるリンクなどの属性は、分割されている個々のページから、「すべて表示」バージョンのページに統合されます。

ただし、ロード時間が長いと 「すべて表示」ページが敬遠される場合も

興味深いことに、ユーザーが「すべて表示」ページを好まなかったケースは、ロード時間の遅さに関連がありました(たとえば「すべて表示」ページに画像が数多く含まれていて、ロードに時間がかかる場合など)。ユーザーは 検索結果表示の遅さにも不満(英語)を感じることを思えば当然のことです。したがって、一般的には「すべて表示」ページの方が好まれてはいるものの、ウェブマスターとしては、このようなパフォーマンスの問題と、全体的なユーザー エクスペリエンスとのバランスを取ることが重要です。

続きもののコンテンツに関する最善策
  1. サイトに 「すべて表示」ページがある場合

    Google では、コンテンツの「すべて表示」ページがある場合、そのページを検出しようとします。(それを構成する個々のページがある場合はそれらのページも同時に検出しようとします)ウェブマスターの皆さまには特に何もしていただく必要はありません。ただし、Google に対してより明確なシグナルを送りたい場合は、個々の構成ページにて rel=”canonical” に「すべて表示」ページを指定することで、一連のページを適切に検出する可能性を高めることができます。

    rel=”canonical” にて、一連の URL に含まれるコンテンツをまとめた「すべて表示」ページ (例: page-all.html)を指定することができます

    なぜこれでうまくいくのでしょうか?

    図に示されているように、一連のコンテンツの 1 つである page-2.html は、canonical のターゲットに page-all.html を指定することができます。ユーザーがあるキーワードで検索をおこない、検索結果から page-all.html が選択された場合、仮にキーワードに最も関連しているのが page-2.html であったとしても、ユーザーは page-all.html の中で、page-2.html に含まれる目的の情報を得ることができます。

    一方、page-2.html にて page-1.html を canonical に指定することは避けてください。page-1.htm には page-2.html のコンテンツが含まれていないためです。ユーザーの検索キーワードは page-2.html 上のコンテンツに関連性が高いことはあり得ますが、page-2.html の canonical に page-1.html が設定されていると、ユーザーは検索結果の中から page-1.html を選択することも考えられます。この場合、目的の情報に到達するために別のページに移動しなければならないという操作が発生します。それはユーザーにとって不便であると同時に、Google にとっても最適といえる結果ではなく、また、ターゲットのはっきりしないトラフィックをサイトに呼ぶことになりかねません。

    ただし、「すべて表示」ページを検索結果に表示しないことを強く希望する場合は、1)一連のコンテンツの個々のページに「すべて表示」ページへの rel=”canonical” が設定されていないことを確認した上で、2)「すべて表示」ページに “noindex” を設定してください。(設定方法は一般的なもので問題ありません)

  2. 個々の構成ページを優先表示したい場合(または 「すべて表示」ページがない場合)

    サイトが下記の状況のいずれか(または両方)に当てはまるケースとなるでしょう。
    • 「すべて表示」ページが検索結果に適さない(たとえばロード時間が長すぎる、ユーザーにとって操作が難しくなるためなど)
    • サイトのユーザーが複数ページ構成の方を好み、また検索結果に「すべて表示」ページではなく、個々のページの表示を望んでいる

    このような場合は、標準的な HTML の rel=”next” と rel=”prev” 要素 を指定して、一連のコンテンツの個々の構成ページ間の関係性を指定することができます。正しく指定されていれば、Google は通常、下記のような挙動をとります。
    • 個々のページ/URL にあるリンクなどのインデックス属性を統合します。
    • 個々のページのうち、最も関連性が高いページ/URL をユーザーに提供します。通常、コンテンツの最初のページですが、アルゴリズムによって、一連のコンテンツのいずれかのページを検索結果に表示する場合もあります。

    個々のページにて、コンテンツの最初のページに対して rel=”canonical” を使用しているケース(たとえば page-2.html にて、rel=”canonical” に page-1.html を指定するなど)が見られますが、これらの個々のページには実際に重複コンテンツがあるわけではないため、このような指定はお勧めできません。rel=”next” と rel=”prev” を使用するのがより適切です。
まとめ

一般に、検索結果には「すべて表示」バージョンを好むユーザーが多いことから、Google では、適切な検出を行ったうえで「すべて表示」バージョンを優先的に表示する取り組みをおこなっています。サイトに続きもののコンテンツがある場合、ウェブマスターの皆さまに特に実施していただく作業はありません。ただし、サイト情報をどのように表示するのが最適なのかをより明確に Google に示したい場合は、下記の作業を行ってください。
  1. 「すべて表示」ページを最適化する場合は、個々の構成ページにて rel=”canonical” を使用し、ターゲットに「すべて表示」ページを指定します。
    あるいは、
  2. サイトの「すべて表示」ページを使わない場合は、 rel=”next” と rel=”prev” 属性を使用し、Google が一連のページを識別した際に構成ページの方を検索結果に表示するよう明示します。
わからないことがある場合

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

2011/12/3 追記
画像内の URL を修正いたしました。ご指摘いただきましたみなさま、ありがとうございました。

著作者情報のマークアップに対応しました

14 years ago
この度、Google ではウェブ上のコンテンツとその著作者を関連付ける、著作者情報のマークアップに対応いたしました。素晴らしい著作者によるコンテンツを検索結果の中で見つけやすくするために、このデータを使用していこうと考えています。

現在 Google では、ウェブサイト内のコンテンツから著作者情報ページへリンクするマークアップに対応しています。たとえば、多くの記事を書いている The New York Times の記者がいたとします。ウェブマスターは著作者情報をマークアップすることによって、これらの記事を The New York Times の記者ページに関連付けることができます。著作者情報ページは、著作者がどういった人物か説明するものであり、著作者の略歴、写真、書いた記事、その他のリンクなどを含めることができます。

もしあなたがこうした記事等の著作物を掲載したサイトを運営しているなら、ぜひ著作者情報のマークアップについて ヘルプ記事「著者情報」 をご一読ください。このマークアップは、各検索エンジンやその他のウェブサービスが、ウェブのいたるところに存在する同一の著作者による著作物を識別できるよう、HTML5 (rel=”author”)や XFN (rel=”me”)などの既存の標準技術を利用しています。schema.org のマイクロデータ (英語)を使用した構造化データのマークアップを既に行っている場合でも、Google は著作者情報として認識します。

Google では、このマークアップを可能な限り簡単に取り入れられるようにしたいと考えています。そのために、The New York Times、The Washington Post、CNET、Entertainment Weekly、The New Yorker などの複数のサイトと協力してページのマークアップに取り組みました。さらに、YouTube や Blogger がホスティングするすべてのコンテンツにもマークアップを追加しました。将来的には、どちらのプラットフォームでもコンテンツの公開時に自動でマークアップが追加されるようになります。

良質なコンテンツは素晴らしい著作者によって生み出されます。Google ではこのマークアップによって、コンテンツの著作者を強調したり、検索結果のランク付けを改良したりできないか、その可能性を模索してまいります。

クロスドメイン URL の選択 - 複数のドメイン間の重複コンテンツの正規化について

14 years 1ヶ月 ago
このブログでも何度か 重複コンテンツ に関して取り上げてきました。重複コンテンツとは、同じコンテンツが複数の URL(同一のドメインにある/なしを問わず)に存在することを指しています。Google では、コンテンツが重複するページ グループを発見した場合、アルゴリズムに従ってコンテンツを代表する URL を 1 つ選択します。ページ グループには、同じサイトからの URL も、別のサイトからの URL も含まれます。複数のドメインが含まれるグループから代表 URL が選択された場合、この選択は「クロスドメイン URL の選択」と呼ばれます。簡単な例を挙げると、a.com からの URL と b.com からの URL が含まれる同じコンテンツのグループで、b.com から代表 URL が選択された場合、a.com の URL はそれ以降 Google の検索結果に反映されず、検索からのトラフィックが減ることがあります。

ウェブマスターは、rel="canonical" 属性 301 リダイレクト などを適切に設定することで、アルゴリズムに選択すべき URL を伝えることができます。アルゴリズムによる選択は、ほんとんどの場合こういったウェブマスターの意図が正しく反映されています。しかし時折クロスドメイン URL の選択を不適切と感じたり、不適切な場合の対処法が分からない、といった声を耳にすることがあります。

そこで Google は、クロスドメイン URL の選択の透明性を高めるために、ウェブマスター ツールに登録された URL ではなく外部 URL がアルゴリズムによって選択された場合、それをウェブマスター ツールにメッセージとして表示し始めました。このメッセージの詳細については、クロスドメイン URL の選択 を参照してください。今回のブログ記事では、クロスドメイン URL のよく見られるいくつかのケースについて取り上げ、不適切な選択を修正する方法についてお話しします。

不適切なクロスドメイン URL の選択がされる主な原因
クロスドメイン URL の選択が適切になされるようアルゴリズムに伝える方法は数多くあります。

実際ほとんどの場合、Google のアルゴリズムはウェブマスターが代表 URL を示すために設定したシグナルに基づいて選択を行います。たとえば、ウェブマスターがサイト移転時の ガイドラインベスト プラクティス (英語) に従っていた場合は、新しいウェブサイトの URL が代表 URL であることを Google のアルゴリズムに正しく伝えていると言えるでしょう。ウェブサイトの移転中にウェブマスター ツールで今回実装された新しい通知メッセージを受信した場合、Google のアルゴリズムがサイト移転に気付いたと見なすことができます。

その一方で、アルゴリズムが代表にしたくない URL を選択した場合はどうすればいいのでしょうか。クロスドメイン URL の選択が不適切 (ウェブマスター側の希望と異なる) であった場合、いくつかの方法で状況を改善することができます。以下に、意図と異なるクロスドメイン URL の選択が行われる一般的な原因と、その修正方法をご紹介します。
  1. 複数リージョン向けウェブサイトを含む重複コンテンツ:多くのウェブマスターの方が、ときには不注意で、そしてときにはユーザーの所在地によってコンテンツを提供するために、同じ言語でほぼ同一のコンテンツを複数ドメイン上で公開しています。たとえば、ウェブマスターが example.com と example.net の両方で英語の同一コンテンツを用意したり、example.de、example.at、example.ch で 1 つのドイツ語のウェブサイトをホストしたりすることは珍しくありません。

    ウェブサイトの性質やユーザーに応じて、現在サポートされている正規化の方法のうちいずれかを用いて、代表 URL をアルゴリズムに通知することができます。詳細については以下の記事を参照してください。
  • 設定ミス:一部の設定ミスによって、アルゴリズムが誤った選択を行うことがあります。例として以下のようなものがあります:
    1. 正規化の間違い正規化 の設定の際に誤って外部ウェブサイトを指定してしまうと、アルゴリズムがその外部サイトの URL を検索結果への表示用に選択してしまうことがあります。これは、ウェブマスターが導入したコンテンツ管理システム (CMS) や CMS プラグイン の設定に間違いがある場合に発生します。

      こういった状況が発生している場合は、ウェブサイトで使用する URL を誤って正規化している部分 (rel="canonical" 属性や 301 リダイレクトの不適切な使用) を見つけて、修正します。
    2. サーバーの設定ミス:時折、サイト a.com のコンテンツが b.com の URL に返されるという、ホスティングの設定ミスが見受けられることがあります。また、2 つの無関係なウェブ サーバーが同一の ソフト 404 エラー を返すと、Google がエラー ページと判断しないことがあります。いずれの場合も、同じコンテンツが異なる 2 つのサイトから返されたと見なされ、アルゴリズムが a.com の URL を b.com の正規化と判断して選択してしまうことがあります。

      こういった場合は、ウェブ サーバーのどこに誤りがあるのか調査する必要があります。たとえば、サーバーがエラー ページに対して HTTP 200 (成功) ステータス コードを返したり、同一サーバー上でホスティングされている別のドメインへのリクエストを取り違えたりすることがあります。問題の原因が分かり次第、サーバー管理者と協力して設定を修正してください。
  • 悪意のあるウェブサイトへの攻撃:ウェブサイトに対する攻撃の中には、勝手に正規化を行うコードを生成するものがあります。たとえば、サイトに HTTP 301 リダイレクト を返させるものや、HTML や HTTP ヘッダーにドメインをまたがった rel="canonical" リンク属性 を挿入するものがあります。この場合は悪意のあるコンテンツをホスティングしている外部 URL を指すことが一般的です。このような例では、攻撃を受けたウェブサイトの URL ではなく、悪意のある URL やスパム URL がアルゴリズムに選択されてしまうことがあります。

    このような場合、サイトがハッキングされた、またはマルウェアに感染した場合のガイドライン に従い、再審査リクエストを送信します。ウェブマスター ツールの Fetch as Googlebot 機能を使用すると、Googlebot に見えているようにコンテンツを表示し、クローキング された攻撃を検出できます。
  • また、まれにではありますが、あなたのコンテンツをあなたから許諾を得ることなく使用している外部サイトの URL が選択されることがあります。著作権に違反して、他のサイトにコンテンツを複製された場合、そのサイトのホストに連絡を取って削除を依頼してください。また、DMCA (デジタル ミレニアム著作権法) に基づく要求を提出する ことで、権利を侵害しているページを検索結果から除外するよう Google にリクエストすることもできます。

    この記事について詳しい情報は、ヘルプ記事「クロスドメイン URL の選択」をご覧ください。コメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

    多言語ウェブサイトの作成について

    14 years 1ヶ月 ago
    多言語のウェブサイトとは、複数の言語に向けてコンテンツを提供するウェブサイトです。多言語のウェブサイトの例には、日本語に加えて中国語と韓国語で公開されているアジアをターゲットとした企業のサイトや、ヨーロッパのサッカーチームのファンサイトを日本語とそのチームの母国語で公開している場合など様々なサイトがあります。

    通常、多言語のウェブサイトを作成する意味があるのは、ターゲット ユーザーの使用する言語が複数にわたっている場合です。ヨーロッパのサッカー チームのブログが日本にいるそのチームのファンに向けたものであれば、日本語のみで公開しても問題ないでしょう。しかし、世界中のそのチームファンにも読んでもらいたいと考えるなら、英語やそのチームの母国語のコンテンツも用意すると役に立つことでしょう。

    Google の言語認識


    Google はページごとにその主となる言語を判断しています。言語を認識しやすくするために、ページごとに使用する言語を統一すること、そして原文と訳文を一緒に表示しないことをおすすめします。1 ページについて複数の言語を認識することも可能ではありますが、ページ内のすべての要素(ヘッダー、サイドバー、メニューなど)の言語は統一して使用することをおすすめします。

    Google では「lang」属性から文書型定義(DTD)まで、コードレベルの言語情報はすべて無視します。一部のサイト制作ソフトでは、これらの属性が自動的に作成されるため、ウェブページの言語を判断する際にこうした情報はあまり信頼できないためです。

    一般的に Google である言語で検索を行う場合、ユーザーは検索した言語に最適化された検索結果が表示されることを期待しています。そこで、サイトの多言語化を図る際には、検索結果に表示されるスニペットや URL などにも気を配る事が重要となります。以下にそのためのヒントをいくつか紹介します。

    多言語のサイトの分析: URL 構造


    多言語のウェブサイトを作成するときに、特別な URL を用意する必要はありません。とはいえ、URL を見て自分がウェブサイトのどのセクションにいるのかを把握できればユーザーにとって便利です。たとえば、次のような URL が使われていると、ユーザーは自分がこのサイトの中の英語用コンテンツにいることが把握できます。

    http://example.ca/en/mountain-bikes.html
    http://en.example.ca/mountain-bikes.html

    一方、次のような URL であれば、同じページをフランス語で表示していることがわかります。

    http://example.ca/fr/mountain-bikes.html
    http://fr.example.ca/mountain-bikes.html

    また、このような URL 構造を使うと、多言語コンテンツのインデックス状況が分析しやすくなります。

    非英語文字が含まれる URL を作成する場合は、必ず UTF-8 エンコードを使うようにしてください。UTF-8 でエンコードされた URL であれば、コンテンツ内からリンクされた場合も適切にエスケープされます。手動で URL をエスケープする必要がある場合は、オンラインの URL エンコーダ を利用するのが簡単です。たとえば、次の URL を英語からフランス語に翻訳するとします。

    http://example.ca/fr/mountain-bikes.html

    翻訳後の URL は次のようになります。

    http://example.ca/fr/vélo-de-montagne.html

    この URL には非英語文字が 1 文字(é)含まれているので、ページ内のリンクで使用するために適切にエスケープすると次のようになります。

    http://example.ca/fr/v%C3%A9lo-de-montagne

    多言語のウェブサイトのクロールとインデックス


    まずはじめに、自動翻訳したページをインデックスの対象としないようにしてください。自動翻訳は意味が通じない場合があるため、スパムとみなされる可能性があります。また、自動翻訳されたコンテンツは、しばしばユーザーにとって理解できなかったり、不自然に感じることがあります。そのようなコンテンツを多言語のウェブサイトとして作成するのは、ユーザーにとって有益ではありません。

    多言語化を行う場合は、Googlebot がサイトのすべての言語バージョンをクロールできるようにしてください。また、ページ間で相互にリンクすることをおすすめします。つまり、同一コンテンツを異なる言語で掲載したページ間をリンクします。ユーザーにとってもこのリンクは非常に便利です。先ほどの例を使って説明すると、たとえばフランス語を使うユーザーが http://example.ca/en/mountain-bikes.html にアクセスしてしまった場合、ワンクリックで http://example.ca/fr/vélo-de-montagne.html に移動して同じコンテンツをフランス語で表示することができます。

    サイトをよりクロールされやすくするために、ブラウザの言語設定による自動的なリダイレクトを行わないようにしてください。このようなリダイレクトを行うと、ユーザー(と検索エンジン)がサイトのすべての言語バージョンを見られなくなる場合があります。

    最後に大切なこととして、各言語のコンテンツには別々の URL を使用してください。つまり、多言語間で同一の URL を使って Cookie でコンテンツを切り替えるような構造は避け、それぞれの言語ごとに URL を設定しましょう。

    文字コードの使用


    Google は、HTTP ヘッダー、HTML ページ ヘッダー、コンテンツから文字コードを直接判定します。文字コードに関して注意していただきたいのは、コンテンツとヘッダーの間などで情報が矛盾していないか注意することです。Google ではさまざまな文字コードを認識できますが、可能であればウェブサイトでは UTF-8 を使用することをおすすめします。

    多言語のウェブサイトの作成についての説明は以上です。この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

    SSL 検索における検索クエリ データの取得方法について

    14 years 1ヶ月 ago
    インターネットの世界において SSL 暗号化は 急速に広まって (英語) きています。Google は、ユーザーの皆さまにより安全にサービスをご利用頂くため、Google アカウントにログインしたユーザーの google.com における検索については、https://www.google.com での SSL 検索がデフォルト (英語) となるよう変更することにいたしました。この変更は数週間ほどかけて実施される予定です。 なお、google.co.jp に関しましては、現在のところ、変更時期は未定です。

    この変更がウェブマスターに与える影響はどのようなものでしょうか。http://www.google.com (SSL 不使用) でのオーガニック検索結果では、ユーザーが google.com から来たことと、その検索クエリがわかります (ユーザーのブラウザーが HTTP リファラー フィールド を通してこの情報を取得し渡します)。しかし、SSL 検索でのオーガニック検索結果では、ウェブサイト側はユーザーが google.com から来たことしかわかりません。ただし、ウェブマスター ツール から 豊富な検索クエリ データ へアクセスすることは可能です。ウェブマスター ツールに追加した確認済みのサイト に対して、ウェブマスターは以下の操作を行えます。
    • 過去 30 日間のデイリー検索クエリ トップ 1,000 と、デイリー ランディング ページ トップ 1,000 の表示。
    • 表示回数、クリック数、クリックスルー率 (CTR) の表示。また、各クエリの検索結果における平均掲載順位を直近 30 日間で比較。
    • CSV 形式でのデータのダウンロード。
    また、Google アナリティクス の検索エンジン最適化レポートをご利用いただいているユーザーは、ウェブマスター ツールと同様の検索クエリ データ にアクセスでき、豊富なレポート機能を活用していただけます。

    ウェブマスター ツールで検索クエリ データを表示する方法について、Google はさらに改善を重ねていきます。ご質問、フィードバック、ご提案があれば、ウェブマスター ヘルプ フォーラム までお寄せください。

    ウェブマスター ツールの検索クエリのデータが Google アナリティクスから利用可能になりました

    14 years 1ヶ月 ago
    これまでウェブマスター ツールからのみご利用頂けた 検索クエリ のデータですが、この度 Google アナリティクスの [トラフィック] セクションで正式にご利用いただけるようになりました。

    なお、本機能につきましては以前 Google アナリティクス公式ブログにて パイロットベータの募集 をアナウンスをさせて頂きました。みなさまからのフィードバックにより、多くの改善を重ね、このたび正式に公開させて頂きました。ご協力ありがとうございました。

    ご利用頂けるデータは次のとおりです。
    • 検索クエリ: 1 日あたり上位 1,000 件のクエリに対するインプレッション数、クリック数、掲載順位、クリックスルー率(CTR) の情報
    • ランディング ページ: 1 日あたり上位 1,000 件のランディング ページに対するインプレッション数、クリック数、掲載順位、CTR の情報
    • 地域別サマリー: 国ごとのインプレッション数、クリック数、CTR
    これらの検索エンジン最適化レポートはいずれも、Google アナリティクスの持つ高度なフィルタリング機能とビジュアル化機能を活用して、データをより深く分析することができます。セカンダリ ディメンションを指定することにより、ウェブマスター ツールでは利用できない方法でサイトのデータを表示できます。


    これらの検索エンジン最適化レポートを有効にするには、ウェブマスター ツールで確認済みのサイト所有者であること、そのプロパティの Google アナリティクス管理者であることが必要です。有効にすると、これらのレポートを表示するプロファイルを管理者が選択できます。

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

    パラメータ付き URL 処理の新機能

    14 years 1ヶ月 ago
    ウェブマスター ツールの [サイト設定] > [設定] セクションから「パラメータ処理」機能がなくなっていることに、お気付きの方もいらっしゃるかもしれません。実は、この機能は「URL パラメータ」という新しいセクションとして独立することになりました。また、名前だけでなく機能そのものも一新されたので、より便利に使っていただけるかと思います。なお、以前の「パラメータ処理」機能による URL パラメータの設定は、自動的にこの新しいバージョンに反映されます。では、この新しい「URL パラメータ」には、どのような便利な機能があるのでしょうか。まずはこの機能の目的と役立つケースについてご紹介しましょう。

    機能の概要
    「URL パラメータ」機能を利用すると、サイト内のどの URL を Googlebot にクロールさせるか、URL 内のパラメータに基づいて指定することができます。それによってたとえば、この機能を使うことで簡単に重複コンテンツがクロールされるのを防ぐことができます。このため、あなたのサイトへのクロール負荷を軽減でき、また重複していないコンテンツがよりたくさんインデックスされやすくなるので、サイトのクロールが効率的に行われるようになるでしょう。また、Googlebot のクロールする範囲がまだ拡大できると思われる場合にも、この機能は有用です。ただし、ご利用にあたっては注意が必要です。というのも、URL パラメータの動作について十分に理解していなければ、クロールされるべき URL が誤ってクロールされない設定になり、そのコンテンツが Googlebot からはアクセスできくなってしまう恐れがあるからです。


    新機能の詳細
    では次に、新たに追加された機能についてご紹介しましょう。まず、個々のパラメータにクロール アクションを割り当てる際に、パラメータの動作が細かく指定できるようになりました。最初の手順としては、各パラメータがページのコンテンツを変更するかどうかを指定します。もしそのパラメータによってページのコンテンツが変化しないのであれば、設定作業はここで終了です。Googlebot はこのパラメータの代表的な値を持つ URL を選択し、クロールするでしょう。パラメータによってコンテンツが変わることはないので、どの値が選択されても同じ結果になります。一方で、もしパラメータによってページのコンテンツが変わる場合は、そのクロール方法を次の 4 つの中から選択することができます。
    • Googlebot が決定
    • すべての URL
    • 値が指定されている URL のみ
    • クロールしない
    なお、「値が指定されている URL のみ」を選択することで、パラメータに使用する値を自分で指定することができます。もう Google が用意する値のリストに制限されることはなくなりました。また、必須ではありませんが、たとえば並べ替えやページ指定、コンテンツ選択など、パラメータの具体的な動作を指定することもできます。さらに、すべてのパラメータに対して、それを含むクロール済み URL の例がそれぞれ表示されるようになりました。

    上記の 4 つのクロール オプションのうち、「クロールしない」は今回追加されたもので、特に注意が必要です。このオプションはもっとも優先度が高く、当該の URL に含まれる他のパラメータのどの設定よりも優先されます。つまり、ある URL のパラメータが 1 つでも「クロールしない」に設定されていると、他のパラメータがたとえ「すべての URL」に設定されていたとしても、その URL がクロールされることはありません。なので、このオプションを使用するときには十分にご注意ください。ちなみに、2 番目に適用が優先されるオプションは「値が指定されている URL のみ」です。

    事例
    では、実際の例を通して、少し頭の体操をしてみましょう。
    - - -
    fairyclothes.example.com という名前のオンライン ストアがありました。このお店のウェブサイトでは、URL の中でパラメータを使用しており、さまざまな URL から同じコンテンツにアクセスできるようになっていました。ある日、オンライン ストアのオーナーは気付きました。冗長な URL があまりにも多いと、Googlebot がサイト全体をクロールできないかもしれない、と。そこで、好奇心旺盛で何でも知りたがる助手を偉大なる「ウェブの魔法使い」の元へ送り、Googlebot による重複コンテンツのクロールを減らすために「URL パラメータ」機能をどのように使用すればよいか、教えを請うことにしました。賢者として知られる「ウェブの魔法使い」は、URL パラメータに目を通すと、次のような設定を提案しました。

    パラメータ名 コンテンツへの影響 Googlebot がクロールする対象
    trackingId なし 代表的な URL 1 つ
    sortOrder 並べ替え 値が「lowToHigh」に指定されている URL のみ
    sortBy 並べ替え 値が「price」に指定されている URL のみ
    filterByColor 絞り込み クロールしない
    itemId コンテンツ指定 すべての URL
    page ページ指定 すべての URL

    助手はさっそく質問します。

    助手: trackingId については代表的な URL を Googlebot に選ばせる(値は Googlebot が選択する)よう指定なさっていますね。「値が指定されている URL のみ」を選択して特定の値を自分で指定しなかったのはなぜですか?
    ウェブの魔法使い: Googlebot がウェブをクロールしているときに、君のサイトにリンクしている URL で次のようなものが見つかったとしよう:
    1. fairyclothes.example.com/skirts/?trackingId=aaa123
    2. fairyclothes.example.com/skirts/?trackingId=aaa124
    3. fairyclothes.example.com/trousers/?trackingId=aaa125
    このとき、もしも Googlebot に「trackingId=aaa125」の URL だけをクロールするよう指定すると、Googlebot は URL 1 と 2 をクロールしなくなってしまうのだ。というのも、どちらの URL も trackingId の値が aaa125 ではないからだ。これらの URL のコンテンツはクロールされず、インデックスもされない。したがって、君の店が仕入れたすてきなスカート(/skirts/)がGoogle の検索結果に並ぶこともない。だからこの場合は、代表的な URL を選ばせるべきなのだよ。なぜかって?そのように指定すると、Googlebot がウェブ上で発見した 2 つの URL がこのパラメータの値だけ違っているとき(上の例でいうと URL 1 と 2)、Googlebot はそのうちどちらか 1 つをクロールするだけで、コンテンツをすべて取得できるからだ。上の例では、1 と 3 か、2 と 3 というペアで、合計 2 つの URL がクロールされることになる。おかげで、スカート(/skirts/)もズボン(/trousers/)も、1 つ残らずクロールされるのだ。

    助手: sortOrder パラメータについてはどうですか?商品のリストが昇順でも降順でもかまわないと思うのですが。Google に代表的な値を選ばせるのではいけないのですか?
    ウェブの魔法使い: Googlebot がクロールを続ける中で、次のような URL が見つかったとしよう:
    1. fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
    2. fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’highToLow’
    3. fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’lowToHigh’
    4. fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’
    最初の 2 つの URL(1 と 2)の違いは sortOrder パラメータの値だけであり、その次の 2 つ(3 と 4)についても同じだ。しかし、URL 1 と 2 のコンテンツは同じではない。最初の URL ではスカートが安い順(’lowToHigh’)に表示され、2 番目の URL では高い順(’highToLow’)になっている。これを踏まえると、この状況で 1 つの代表値だけを使うのは得策ではないといえる。しかも、sortOrder パラメータだけが異なるいくつかの URL から Googlebot に代表的な値を 1 つだけ選択させると、そのたびに違う値が選択される可能性がある。たとえば上の例では、最初の 2 つの URL のうち、URL 1 が選択されたとしよう(sortOrder=’lowToHigh’)。一方で、その次の 2 つの URL では 4 が選択されたとする(sortOrder=’ highToLow’)。もしこの状況になったら、Googlebot は次のように、安い価格帯のスカートだけを 2 回クロールすることになるだろう:
    • fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
    • fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’
    こうなると、高い価格帯のスカートは、まったくクロールされなくなってしまうのだ。このように、並べ替えのパラメータを扱うときは、一貫性が鍵となる。並べ替え順は常に同じにすることだ。

    助手: sortBy の値についてはどうですか?
    ウェブの魔法使い: sortOrder 属性によく似ているよ。商品一覧の URL がクロールされるときに、並べ替え順はどのページでも同じでなければならない。そうでなければ、一部の商品が Googlebot から認識されなくなるからね。ただし、どの値を選択するかについては注意が必要だ。店で書籍の他に靴も売っているとしたら、「title」という値は選ばない方がよいだろう。というのも、靴を表示する URL に「sortBy=title」が含まれることはまずないので、クロールされなくなってしまうからだ。同じように、「sortBy=size」と設定すると、靴のクロールは問題なくても、書籍はクロールされなくなってしまう。パラメータ設定の影響はサイト全体に及ぶことを忘れないように。

    助手: filterByColor というパラメータの付いた URL はクロールさせないのですか?
    ウェブの魔法使い: たとえば、スカートの一覧が 3 ページにわたってあるとしよう。そのうち何点かは青で、何点かは赤、残りは緑色だ。
    • fairyclothes.example.com/skirts/?page=1
    • fairyclothes.example.com/skirts/?page=2
    • fairyclothes.example.com/skirts/?page=3
    このリストは、さらに絞り込むことができる。たとえば、ユーザーが青を選ぶと、青いスカートが次の 2 ページにわたって表示される:
    • fairyclothes.example.com/skirts/?page=1&flterByColor=blue
    • fairyclothes.example.com/skirts/?page=2&flterByColor=blue
    この 2 つは新しいページのように見えるが(表示される商品のセットは他のどのページとも異なる)、実際のところ、新しいコンテンツは何もないのだ。というのも、青いスカートはすべて、元の 3 つのページに含まれているからだ。つまり、コンテンツを色で絞り込んだ URL を別途、クロールさせる必要はないということになる。そのような URL で表示されるコンテンツは既にクロールされているからだ。ここで注意してほしいのは、特定の URL をクロール対象から除外するために「クロールしない」を選択するときだ。そのコンテンツが Googlebot から別の方法でアクセスできるようにしておくことが肝心で、上の例でいえば、最初の 3 つのリンクを Googlebot が発見できる必要があり、このクロールを妨げるような設定がないように配慮しなければならないのだ。
    - - -

    もしご自分のサイトが URL パラメータ を使用していて、コンテンツが重複して生成される可能性がある場合には、ぜひウェブマスター ツールの新機能である「URL パラメータ」を試してみてください。ご感想やご質問は ウェブマスター ヘルプフォーラム までお寄せください。

    再審査リクエストへの回答が、より具体的になりました

    14 years 1ヶ月 ago
    あなたのサイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がっているように見える場合(そして ウェブマスター向けガイドライン に違反していないと思われる場合)、再審査をリクエスト することができます。これまで Google は、ウェブマスターの皆さまにとって使いやすくなるよう、再審査プロセスの改善に取り組んできました。数年前からは、再審査リクエストの受付通知 に加え、リクエストを処理したことをお知らせするメッセージもお送りしてきました。このメッセージはウェブマスターの皆さまにとって、審査完了のタイミングがわかるという意味で、一定の役割を果たしてきたと思います。一方でウェブマスターの皆様からは、リクエストの結果を知りたいというご意見を頂いておりました。そこで今年から再審査リクエストへのより詳しい返答をお送りするということを試験的に開始しており、非常に好意的なフィードバックを頂きました。

    そこで今回、皆様からの再審査リクエストに応じて手動による スパム 判定を取り消したかどうかを、より多くのケースでお知らせするようにしました。サイトにまだガイドライン違反が見受けられる場合は、その旨をご報告いたします。ご不快に思われるかもしれませんが、サイトにまだ問題が残っているとわかれば、問題の原因究明のお役に立つと考えております。※ もし具体的な原因がわからない場合などはぜひ ウェブマスターヘルプフォーラム へお問い合わせください。ウェブマスターヘルプフォーラムには、経験豊富なウェブマスターの方々だけでなく、Google 社員も参加しており、「『不自然なリンクに関する Google ウェブマスター ツールからのお知らせ』を受け取った際に確認をおすすめするポイント」のように具体的な確認方法をご紹介しています。

    また、サイトに対して手動による スパム 判定がされていない場合(ほとんどのケースがこれです)も、より多くのケースでその旨をご報告するようにしました。その場合にサイトのランキングが上位にこないのは、 Google のアルゴリズムによる判定の結果と思われます。サイトに変更が加えられて改善が見られれば、Google のシステムはそれに適切に対応し、ランキングも変化しますので再審査リクエストをお送りいただく必要はありません。他の可能性としては、サイトにアクセス上の問題があって、Googlebot によるクロールやインデックス登録ができない状態であるケースも考えられます。ランキングに関する問題を解消する方法については、サイトの掲載順位が上がらない理由 を参照してください。

    Google では再審査リクエストのプロセス全体の透明性を高めるために様々な取り組みを行っています。個々のリクエストに対しての具体的な対応策についてはお答えできないものの、現在は多くのウェブマスターの皆様に、手動によるスパム判定がされているかどうかをお知らせし、再審査レビューの結果もご連絡するようになっています。理想的には、ランキングの仕組みを全て公開することも可能かもしれませんが、Google はウェブマスターに最大限の情報を公開するように努める一方でその情報をスパマーに悪用されないよう配慮する必要があります。Google では、今後も検索ユーザーとウェブマスターの皆さまのお役に立てるよう、よりよい方法を模索し続けていきたいと考えています。

    サイトの状態が一目で確認できるようになりました。

    14 years 2ヶ月 ago
    ウェブマスターの皆さんとお話する中で、よく聞くお話のひとつに「(サイト運営の)時間のやりくりが大変」というものがあります。ウェブマスターの中には、何十、何百という数のクライアントのサイトを管理している方もいれば、ご自分で事業を営んでいて、財務管理や在庫管理といった業務の合間に、1 日あたり 1 時間しかサイト管理に時間を割けないという方もいるでしょう。Google では、そんな皆さんの助けになればと、ウェブマスター ツールに新しく「サイトの状態」という機能を追加し、問題が発生しているサイトが一目でわかるよう、ウェブマスター ツールのページ デザインもリニューアルいたしました。これによって、管理しているすべてのサイトのレポートを 1 つ 1 つクリックすることなく、重要な項目がひと目でわかるようになります。新しい管理画面は、以下のようになります。


    上の図のように、サイトの状態に問題を抱えるサイトはリストの一番上に表示されます(アルファベット順に表示されるように切り替えることもできます)。サイトで検出された問題の詳細を見るには、こちらのアイコンか、それぞれのサイトの横に表示されている「サイトの状態を確認する」というリンクをクリックしてください。


    この新しい管理画面は、現時点ではウェブマスター ツールに登録されているサイトの数が、確認済みか未確認かに関わらず 100 以下の場合にのみご利用いただけます。将来的には、サイトの数によらず、すべてのアカウントで利用できるよう対応していく予定です。もし 100 個を超えるサイトを管理されている場合は、各サイトのダッシュボードの一番上の部分で状態をご確認いただけます。現在、次の 3 つの点についてサイトの状態がチェックされます。
    1. サイトでマルウェアが検出されていないか
    2. URL 削除ツール によって重要なページが削除されていないか
    3. robots.txt にて、クロールがブロックされている重要なページがないか

    それぞれの項目をクリックすると、サイトで検出された問題に関する詳細な情報を確認することができます。サイトの状態を示すアイコンや、「サイトの状態を確認する」リンクがサイトの横に表示されていないときは、そのサイトでは上記の問題は検出されていないということになります。

    また、上記2、3においてチェックされる「重要なページ」について少し補足いたします。ご存知のとおり、削除された URL の一覧は、[サイト設定] 、 [クローラのアクセス] 、 [URL の削除] で確認できます。また、robots.txt のブロックによりクロールできなかった URL の一覧は、[診断] 、 [クロール エラー] 、 [robots.txt により制限] で確認できます。しかし、ウェブマスターの方々が意図的にコンテンツをブロックしたり削除したりすることはよくあるため、Google では、ウェブマスターが意図していないにも関わらずブロックされたり削除されたりしてしまったと思われる場合に限り、この警告を表示するようにしました。「重要なページ」に限定したのは、このような理由によるものです。現時点では、ページのクリック数([ウェブ上のサイト] 、 [検索クエリ] にて確認できます)から重要度を判断していますが、今後この機能が進化するにつれてそれ以外の要素も付加されるかもしれません。もちろんウェブサイトに起きる問題は、上に挙げた 3 つの項目(「マルウェア」「削除された URL」「ブロックされた URL」)だけではありません。チェック項目は今後増加していく予定です。また、今回のアップデートはウェブマスターの皆様ご自身によるサイトの状態の判断や確認には比ぶべくもありませんが、ひとつひとつすべてのデータやレポートを掘り下げて調べなくても、サイトに起きている重大な問題を簡単にいち早く発見できるようになる手助けになれればと思います。

    私たちが検出したサイトの問題が解決されたのち、ウェブマスター ツールから警告が消えるまでには通常、数日を要します。これは、Google がサイトの再クロールを行って変更を確認し、さらにその情報を Google 検索とウェブマスター ツールに反映されなければならないからです。1 週間以上経ってもサイトの状態に関する警告がまだ残っている場合は、問題が解決されていない可能性があります。その際はぜひ ウェブマスター ヘルプフォーラム をご利用ください。皆様のご意見をお待ちしております。

    ウェブマスター ヘルプ フォーラムからも参加!グローバル トップレベル ユーザーサミット 2011 のご報告

    14 years 2ヶ月 ago
    9 月 13、14 日にアメリカのカルフォルニア州サンタクララ、およびマウンテンビューの Google 本社オフィスにて、「グローバル トップレベル ユーザー サミット 2011」が開催されました。このサミットは、世界各国の ヘルプ フォーラム で大きな貢献をされているトップレベル ユーザーの方々へ 日ごろの感謝をお伝えすると共に、より良いヘルプフォーラムコミュニティ運営のためにトップレベル ユーザーの皆様と Google 社員との間でより深いディスカッションをおこなうことを目的とした、今年初開催のグローバル イベントです。

    全世界から 300 人近いのトップレベル ユーザーが集まったこのイベントには、 日本からも ウェブマスター ヘルプ フォーラム で日ごろ活躍されているトップレベル ユーザーの 方 2 名を含む合計 4 名の方が参加されました。

    サミットに参加された日本のトップレベル ユーザーの皆様(左から 4 名)と Google 社員

    Google Japan Blog にサミットの様子や日本から参加されたトップレベル ユーザーの方々の感想などをご紹介する記事が掲載されましたのでぜひご覧ください。また、ウェブマスター ヘルプ フォーラムで、「そもそもトップレベル ユーザーとはどんな人たちなのか?そしてトップレベル ユーザーになるには?」ということについて、ご紹介させていただいていますので併せてご覧ください。

    Google Japan Blog 「グローバル トップレベル ユーザーサミット 2011 のご報告
    ウェブマスター ヘルプ フォーラム 「 トップレベル ユーザーサミットのご報告 & そもそもトップレベル ユーザーとは?

    今後とも ウェブマスター ヘルプ フォーラム をどうぞよろしくお願いします。

    確認済み
    2 時間 20 分 ago
    Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報Unknownnoreply@blogger.comBlogger443125
    Google ウェブマスター向け公式ブログ フィード を購読

    人気記事トップ10

    人気記事ランキングをもっと見る