[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

最近、ウェブテスト(A/B テストや多変量テストなど)は検索結果に影響を与えるのか、というご質問をいただくことがあります。質問があるということは、ウェブテストをしている方が多いということで、喜ばしく思っています。A/B テストと多変量テストは、サイトがユーザーにとって本当に魅力的であるかを確認するとても効果的な手段です。

検索に与える影響を詳しく述べる前に、ウェブテストについて簡単に説明します。
ウェブテストとは、実際にパターンの異なるいくつかのウェブ サイト(またはその一部)を試して、それぞれのパターンに対してユーザーがどのように反応したかをデータとして収集します。ソフトウェアを使用して、どのパターンが最も頻繁に、ユーザーから期待どおりの反応を得たかを記録します。つまりどのパターンが、商品の購入やメール ニュースの購読登録、または他の目標とする行動に一番結びつくかを知ることができます。テスト後は、テストで一番優秀だったパターン、つまり最も効果的なコンテンツ構成を使用してウェブ サイトを更新できます。

A/B テストは、固有の URL を持つ複数のパターンのページでテストする方法です。 ユーザーがオリジナル URL にアクセスすると、リダイレクトによって異なるパターンのページの URL に振り分けられます。そしてユーザーの行動履歴を比較することで、最も効果的なページを調べます。

多変量テストは、ページを表示する際にソフトウェアによってウェブサイトのいくつかのセクションを即座に変更して行うテストです。ヘッダー、写真、「カートに入れる」といったボタンなど、ページの複数のセクションをテスト対象にできます。それぞれのセクションのすべてのバージョンの組み合わせをソフトウェアによってユーザーに表示し、統計分析により最も効果的な組み合わせを見つけます。URL は常に 1 つで、各パターンは動的にページに挿入されます。

では、これらのテストは、サイトを訪れる Googlebot にも影響するのでしょうか?複数パターンのコンテンツを提供することは掲載順位に影響するのでしょうか?以下では、効果的なテストを行いながらも、サイトの検索結果に与える影響を最小限にとどめる方法をいくつかご紹介します。

  • クローキングをしない
    クローキング (ユーザー向けと Googlebot 向けとで異なるコンテンツを表示すること)は ウェブマスター向けガイドライン に違反する行為です。これはテストであってもそうでなくても同様です。ユーザー エージェントによって、テストを行うのか、あるいは別のコンテンツを返すのかを切り替えないでください。例えば、ユーザー エージェント「Googlebot」に対して常にオリジナル ページを返すといったことはしないでください。ガイドラインに違反した場合は、検索結果の掲載順位が下がったり、検索結果に表示されなくなったりしてしまう可能性があります。そもそもテストを行った目的と、正反対の結果になってしまいかねないのでご注意ください。

  • rel=“canonical”を使う
    複数の URL を用いた A/B テストを行っている場合は、各パターンの URL にリンク属性 rel=“canonical" を使用して、オリジナル URL が優先する URL であることを示すことができます。なぜ noindex メタ タグではなく rel=“canonical” の使用をお勧めするかというと、その方がテストをおこなっている状況を適切に示すからです。例えば、ホーム ページのパターンをテストしているとします。この場合理想的な状況は、ホームページが検索エンジンのインデックスに登録されないことではなく、各テスト URL がオリジナル URL の非常に似かよった複製、あるいはオリジナル URL の別バージョンであることを検索エンジン側に示し、オリジナル URL が優先する URL として扱われることでしょう。こういった場合に、rel=“canonical” ではなく noindex を使用すると予想外の結果になる場合があります(例:なんらかの理由でパターン ページの URL が優先する URL として処理された場合、オリジナルの URL が複製として扱われてインデックスから除外されるということが起こりえます)。

  • 301 ではなく、302 を使う
    A/B テストでユーザーをオリジナルの URL からテスト用の複数パターンの URL にリダイレクトしている場合は、301 (永続的)リダイレクトではなく、302 (一時的)リダイレクトを使います。これにより検索エンジンはリダイレクトが一時的なもの(テスト期間中のみ)であり、オリジナル URL をリダイレクト先(テスト ページ)で置き換えるのではなく、オリジナル URL をインデックスに保持します。また、JavaScript によるリダイレクトを使用することも問題ありません。

  • テスト期間は必要な期間だけにする
    信頼のおけるテストに必要な期間は、サイトのコンバージョン率やトラフィック量などによって変わります。そのため、良いテスト ツールは、信頼のおける結果を得るために必要なデータが集まったらユーザーに知らせてくれるでしょう。テストを終わらせたら、サイトを望ましいパターンのコンテンツで更新し、テストに関係するすべての要素(複数パターンの URL、テスト用のスクリプトやマークアップなど)を速やかに削除します。必要以上に長くテストを行っているサイトは、検索エンジンを欺いているとみなされ、ウェブマスター向けガイドライン違反となるかもしれません。1 つのテスト用コンテンツのパターンを多くのユーザーに表示し続けている場合は特にそうみなされます。

上記のような方法を参考にすれば、テストが検索結果に与える影響を最小限またはゼロにできることでしょう。また、テストしているコンテンツの種類によっては、たとえ Googlebot がいくつかのパターン コンテンツをクロールまたはインデックスに登録したとしてもまったく問題がない場合もあります。ボタンや画像のサイズ、色、位置の変更、またはユーザーに行動を促すための「カートに入れる」や「今すぐ購入」といったテキストのような変更は、ユーザーの行動には非常に大きく影響しますが、多くの場合、検索結果のスニペットや順位にはほとんど影響しません。さらに、テスト中のサイトが検出されてインデックスに登録されるほど頻繁にクロールされているなら、テスト後に更新されたサイトもすぐにインデックスに登録されることでしょう。

ウェブテストについての詳細は こちらの記事 をご参照ください。Google アナリティクス で無料のテスト ツールもご利用になれます(Google アナリティクスのウェブテスト ツールでは現在多変量テストの機能は提供しておりません)。ウェブテストに関するご質問は アナリティクス ヘルプフォーラム、検索エンジンに与える影響に関するご質問は ウェブマスター ヘルプフォーラム までお寄せください。


スマートフォン向けに最適化されたウェブサイトの構築について、Google がお勧めする方法を公開して以来、ウェブマスターの皆さんから「タブレット端末はどう取り扱うのがよいのか」という質問をよくいただきます。これは Android 向けアプリのデベロッパーの皆さんが直面する問題とよく似ていますので、「Building Quality Tablet Apps (高品質なタブレット用アプリの構築方法)」 (英語)に関するガイドをお読みいただくことから始めるとよいでしょう。

タブレット向けに最適化された、検索エンジンと相性の良いウェブサイトの構築方法については、Google からは具体的にお勧めしていることはありませんが、スマートフォンとタブレット両方のユーザーに対応するウェブサイトの構築方法に関してはいくつかアドバイスがあります。

タブレットからサイトにアクセスするユーザーのことを考えるとき、端末のことだけでなく、ユーザーが何を期待しているかを考慮することが大切です。スマートフォンに比べ、タブレットは大きなタッチ スクリーンを持ち、通常は Wi-Fi 接続を使用します。タブレットはデスクトップ PC やノート PC と同等の充実したブラウジング体験を、持ち運びやすく軽量で、通常、より使いやすい形態で提供するものです。つまり、タブレット向けに最適化されたコンテンツを提供している場合を除き、ユーザーはスマートフォン版のサイトではなく、PC 版のサイトが表示されることを期待しているのです。

The NY Times は閲覧端末がモバイルか、より大きなサイズの Android デバイスのどちらであるかを認識し、タブレット端末に最適化したページの表示を行っています。

Google では、スマートフォン向けに最適化されたサイトに関して、レスポンシブ ウェブ デザイン (英語) を使用すること、すなわち、あらゆる端末に対応する 1 つのサイトを用意することをお勧めしています。皆さんのサイトが、この推奨に従ってレスポンシブ ウェブ デザインを採用している場合は、さまざまなタブレット端末上でサイトの表示をテストし、タブレット端末も適切に対応されていることを確かめてください。スマートフォンの場合と同様に、さまざまな端末サイズや画面解像度でテストする必要があります。

このほかよく用いられるのは、PC 向けとスマートフォン向けに別々のサイトを用意し、ユーザーを該当する方のサイトにリダイレクトするという構成です。この構成を採用している場合は、タブレット ユーザーを誤ってスマートフォン版のサイトにリダイレクトしないように注意してください。

Android スマートフォンとタブレットを識別する

Android 端末については、ブラウザが提供するユーザー エージェント文字列を使えば、スマートフォンとタブレットとを容易に識別できます。Android のスマートフォンとタブレットのどちらも、ユーザー エージェント文字列には「Android」という単語が含まれていますが、ユーザー エージェント文字列に「Mobile」が含まれているのはスマートフォンの場合のみです。

まとめると、ユーザー エージェントに「Mobile」が含まれていない Android 端末はすべてタブレット(あるいはその他の大きな画面を持つ) 端末ですので、PC 版サイトで対応するのが良いでしょう。

例えば、Galaxy Nexus スマートフォン上の Chrome が提供するユーザー エージェント文字列は次のとおりです。

Mozilla/5.0 (Linux; Android 4.1.1; Galaxy Nexus Build/JRO03O) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

また、Galaxy Nexus 上の Firefox が提供するユーザー エージェントは次のようになります。

Mozilla/5.0 (Android; Mobile; rv:16.0) Gecko/16.0 Firefox/16.0

Nexus 7 上の Chrome が提供するユーザー エージェントは次のようになります。

Mozilla/5.0 (Linux; Android 4.1.1; Nexus 7 Build/JRO03S) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19

同じく Nexus 7 で、Firefox の場合は次のとおりです。

Mozilla/5.0 (Android; Tablet; rv:16.0) Gecko/16.0 Firefox/16.0

Galaxy Nexus のユーザー エージェントには「Mobile」が含まれているため、スマートフォン向けのサイトで対応し、一方 Nexus 7 には PC 版のサイトを表示させます。

皆さんが、タブレット向けに最適化されたより高品質なウェブサイトを構築するのに、この記事がお役に立てば幸いです。ご質問がありましたら、ウェブマスター ヘルプ フォーラム までお寄せください。



いつも Google Merchant Center をご利用いただきありがとうございます。このたび Google ショッピング のサービスモデルが変更されることとなりましたので、お知らせ致します。詳細は AdWords 日本版 公式ブログ でご確認ください。

また、以後、Google ショッピングに関するニュースは AdWords 日本版 公式ブログ にてお知らせ致します。
今後とも Merchant Center をよろしくお願い致します。

Google は、リッチ スニペット テスト ツールの名称を「構造化データ テスト ツール」と改称し、最新版の提供を開始しました。主な改良点は次のとおりです。
  • テスト ツールでのリッチ スニペットの表示方法を改良し、検索結果における表示との統一性を持たせました。
  • 視覚的デザインを一新したことで、Google がどの構造化データをページから抽出できるのか、またそれが検索結果にどのように表示されるのかが、以前よりもわかりやすくなりました。
  • 英語以外の言語でも使用できるようになったため、構造化データを実装したサイトを構築する際、世界各国のウェブマスターの皆さまにご活用いただけるようになりました。
ツールでは下記のように表示されます。


今回新しくなった構造化データ テスト ツールは、アプリケーション商品レシピレビュー など、サポートされているすべてのリッチ スニペットおよび 著者情報 のマークアップなどに対応しています。

新しくなった 構造化データ テスト ツールをぜひお試しください。 ご質問やご意見がありましたら ウェブマスター ヘルプフォーラム までお知らせください。



検索結果に表示される、テキストのみの従来のスニペットは、Google のウェブ検索結果に表示されているページの内容を簡単に説明する役割を持っています。リッチ スニペット(上図)は、ウェブマスターの皆さんがページに構造化データのマークアップを追加することによって生成され、従来のスニペットに比べより詳しく、充実したページの要約を表示するものです。この度 Google は、リッチ スニペット用に使う構造化データ の良質なマークアップを実装していただくため、ガイドライン を公開しました。

構造化データのマークアップをあなたのサイトに正しく追加していただければ、そのマークアップに基づいたリッチ スニペットがアルゴリズムによって生成されます。マークアップした内容が、ページの内容を正確に表していて、最新の情報であり、またページ上にユーザーが簡単に見つけることができる状態で存在していれば、Google のアルゴリズムがそのページに関するリッチ スニペットを生成・表示する可能性が高まります。

逆に、リッチ スニペットのマークアップが、スパムのような内容を含む場合、誤解を招きやすい内容である場合、あるいはリッチ スニペットを悪用する意図があると思われる場合は、Google のアルゴリズムはそのマークアップを無視し、テキストだけのスニペットを生成する可能性が高くなります。リッチ スニペットはアルゴリズムによって生成されるものですが、ユーザー エクスペリエンスを阻害するような行為を発見した場合、Google には手動で対処する(特定のサイトのリッチ スニペットを無効化するなど)権利があります。

ガイドラインの考え方を理解するのに役立つ、具体的な例をいくつかご紹介しましょう。
  • ある音楽バンドに関するページでは、関連する他のバンドや同じ地域で活動する他のバンドによるコンサートの情報ではなく、そのバンドのコンサートについての情報をマークアップしましょう。
  • 商品を販売しているサイトでは、各ページ上のレビューは、ショップに対するレビューではなく、ページに掲載している商品についてのレビューになっているようにしましょう。
  • 歌詞を提供するサイトでは、マークアップするレビューは、その曲自体の出来栄えではなく、その歌詞の出来栄えに関するものになっているようにしましょう。
全体的な リッチ スニペットの品質に関するガイドライン のほか、Google では ヘルプ センター 上で、特殊なタイプのリッチ スニペットの使用に関するガイドラインも公開しています。この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。