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

ウェブマスターツールのナビゲーション、ダッシュボード、トップページが新しくなりました

2012-05-24T11:00:00.000+09:00

日頃ウェブマスターツールを使っている方はお気づきかと思いますが、ウェブマスターツールでは日々様々な改善や新機能が追加されています。今回、ナビゲーション、ダッシュボード、そしてトップページが見た目にも機能的にも大きく改善されましたのでご紹介します。

新しいウェブマスターツールのダッシュボード。

ナビゲーションを再編成しました
まず、ナビゲーションの改善についてです。関連する機能ごとに項目をまとめ、ナビゲーション項目を再編成しました。新しい項目は、設定、健全性、トラフィック、最適化となります。

設定：設定可能な項目（通常頻繁には変更しません）
健全性：サイトに問題が発生していないかを確認するための項目。
トラフィック：あなたのサイトが Google 検索上でどのように成果を上げているかを確認するための項目。
最適化：あなたのサイトを強化するためのヒントを確認するための項目。

また、機能に変更はないのですが、[HTML の提案]の項目名が[HTML の改善]と変更されたように、いくつかの名称変更が実施されました。ナビゲーション項目がどのように整理されたのか、ぜひ新しいウェブマスターツールのナビゲーションをひと通り確認してみてください。

ダッシュボードも改善され、見やすくなりました
新しいナビゲーションと同様、新しいダッシュボードも気に入って頂ければと思っています。ダッシュボードの上部では、あなたのサイトについて重要なメッセージがある場合、その情報が表示されます。そしてその下に、あなたのサイトの現在の状態がチャートやグラフでひと目で確認できるようになりました。クロールエラーや検索クエリ、サイトマップといった重要項目の状態が一目で確認できるようになったことで、サイト管理も効率的になることを期待しています。

トップページをコンパクトに
最後に、サイトリストのプレビューサムネイルを非表示にしてリストをコンパクトに表示することが可能になりました。レイアウトはいつでも切り替え可能です。

トップページのコンパクトレイアウト

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

Written by Kamila Primke, Software Engineer, Webmaster Tools
Original version: Navigation, Dashboard and Home page

画像検索についての A to Z

2012-05-15T11:00:00.000+09:00

創造性は私たちの生活に大切なもので、日々の暮らしに豊かさを与えてくれます。たとえば、友人のために見た目も楽しいラテアートを作ってあげたいけど創造的で素敵な絵柄が思いつかない。そんなとき、私が利用するのが Google 画像検索です。

検索結果に表示される画像は、ブロガーや情報サイト、写真素材サイトなど、大小さまざまな規模のサイトオーナーが、自分の HTML ページに埋め込んでいる画像です。Google は、BMP、GIF、JPEG、PNG、WebP、SVG といった形式の画像をインデックスに登録しています。

しかし、Google はどうやってこれらの画像が紅茶ではなくコーヒーであることを認識しているのでしょうか？Google のアルゴリズムは画像をインデックスに登録するとき、その画像が見つかったページのテキストを見て、画像に関する情報を得ています。それ以外にも、ページのタイトルや本文も見ています。画像のファイル名や、リンク先を示すアンカーテキストや「alt 属性のテキスト（英語）」から情報を得ることもあれば、コンピュータービジョンを用いて画像情報を得たり、ページ上にキャプションテキストが存在するときは画像のサイトマップに含まれているキャプションの情報を用いることもあります。

画像をインデックスに登録しやすくするために、下記の点を守ってください。

画像が埋め込まれている HTML ページと画像そのもの、どちらも Google がクロールできるようにしておくこと
Google が対応している形式の画像であること（BMP、GIF、JPEG、PNG、WebP、SVG）

さらに、下記のようにしておくこともおすすめします。

画像のファイル名が画像の内容に関連した名前になっている
画像の alt 属性が、人間が読んで分かるような画像説明になっている
加えて、HTML ページのテキストコンテンツと画像近辺のテキストを、画像に関連した内容にしておくことも有効です。

ここからは、これまでに画像検索について寄せられた質問に対してお答えします。
Q: Googlebot-Image ではなく、Googlebot が画像をクロールしているのを見かけることがありますが、それはなぜですか？
A: URL のリンク先が画像なのかどうか不明なときによくある現象です。こういった場合、Google はまず Googlebot で URL をクロールします。URL のリンク先が画像だと分かれば、通常 Googlebot-Image で再び訪問します。したがって、通常は Googlebot と Googlebot-Image の両方に対して、画像とページのクロールを許可しておくとよいでしょう。

Q: 画像にファイルサイズに上限があるというのは本当ですか？
A: Google では、どんなサイズの画像でもインデックス登録します。ファイルサイズに制限はありません。

Q: 画像に含まれている EXIF や XMP などのメタデータはどうなりますか？
A: ユーザーがより簡単に検索対象にたどり着けるようにするため、Google は見つけたあらゆる情報を使用します。なお、EXIF データなどの情報は、画像をクリックしたときに表示されるページ（インタースティシャルページ）の右側のサイドバーに表示されることがあります。

Q: 画像のサイトマップは送信すべきでしょうか。どんな利点があるのですか？
A: はい、送信してください。画像のサイトマップは、Google に新しい画像の存在を知らせるのに役立つと共に、画像が何の画像なのかを知る助けにもなります。

Q: CDN を使って画像を提供しています。どうやったら画像のサイトマップを使用できますか？
A: クロスドメインの制約（英語）は、サイトマップのタグに対してのみ適用されます。画像のサイトマップでは、タグは別のドメイン上の URL を示すことが可能ですので、画像に CDN を用いていても大丈夫です。Google がクロールエラーを発見した場合にお知らせできるよう、ウェブマスターツールにて CDN のドメイン名を検証することもおすすめします。

Q: 自分が所有する複数のドメインまたは複数のサブドメイン上（例えば CDN や関連サイトなど）に画像が重複して存在する場合は、問題となりますか？
A: 一般的に、どのタイプのコンテンツでも複製しないことが最善の方法です。複数のホスト名にまたがって画像を重複させている場合、Google のアルゴリズムはその中の 1 つをその画像の優先（canonical）コピーに選びますが、それが皆さんの選んでほしいバージョンであるとは限りません。またその場合、画像のクロールやインデックス登録が遅くなることもあります。

Q: 元々の画像が、それ以外のソースのものよりランキングが下位になっている場合がときどきありますが、それはなぜですか？
A: Google は画像の内容を判定する際に、ページのテキストコンテンツを使用していることを覚えておいてください。例えば、オリジナルソースが、テキストがほとんど存在しない画像ギャラリーのようなページである場合、テキストをより多く含むページが上位の検索結果として選ばれることがあります。ある特定の検索キーワードに対する検索結果があまりにもおかしいと思われる場合は、検索結果の下に表示されているフィードバック用リンクで報告するか、ウェブマスターヘルプフォーラムにて事例を報告してください。

セーフサーチ

ユーザーがセーフサーチフィルターをオンにしている場合、Google のアルゴリズムは様々なシグナルに基づき、ある画像（ウェブ検索の話であれば、ページ全体）を検索結果から除外すべきかを判定しています。画像の場合、そういったシグナルの一部はコンピュータービジョンを使って生成されていますが、セーフサーチアルゴリズムでは、もっとシンプルなこと、例えばその画像が以前どこで使用されたのかや、画像が使用されていたコンテキスト（文脈）なども見ています。
ただし、最も強力なシグナルの 1 つは、自発的にマークされたアダルトページです。アダルトコンテンツを配信するウェブマスターの方は、下記のいずれか 1 つのメタタグでページをマークアップすることをお勧めします。

<meta name="rating" content="adult" />
<meta name="rating" content="RTA-5042-1996-1400-1577-RTA" />

ユーザーの多くは、検索結果にアダルトコンテンツが表示されることを好みません（子供が PC を使用する場合は特にそうです）。上記メタタグのいずれかをウェブマスターが用いることで、ユーザーは見たくない検索結果や、想定外の検索結果を見ずに済むので、ユーザーエクスペリエンスの向上につながります。

どんなアルゴリズムにも当てはまりますが、セーフサーチフィルターによってコンテンツが検索結果から意図せずして除外されてしまうことがあります。ご自分の画像やページがセーフサーチによって誤って除外されていると思われるときは、こちらのフォーム（英語）を使ってご連絡ください。

画像のインデックス登録について詳しくは、画像に関するヘルプセンターの記事や、役立つ情報が満載の検索エンジン最適化 (SEO) スターターガイドを参照してください。質問などがございましたら、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Gary Illyes, Webmaster Trends Analyst
Original version: 1000 Words About Images

検索クエリのデータがより長い期間参照可能になりました

2012-05-08T11:03:00.000+09:00

Google ではウェブマスターツールに関して様々な改善を重ねてきました。今回、ウェブマスターツールの検索クエリのデータが改善されましたのでご紹介します。

今回の改善で最も重要なのは、検索クエリのデータの履歴が過去 90 日までさかのぼって確認できるようになった点です。検索クエリのページ右上にある期間の設定をクリックすると、これまで 35 日分のデータしか表示できませんでしたが、90 日分のデータを表示することが可能になりました。

クリック後：

90 日間のデータを見る場合、変動率を表示するオプションは無効になります。以前の期間との変動を確認したい場合は、対象期間は 30 日となるよう調整してください。変動率は、デフォルトでは無効になっていますが、グラフとテーブルの間にあるボタンで切り替えることができます。

ウェブマスターツールのもう 1 つの大きな改善点は、サイトの所有権の確認をするとすぐに、基本的な検索クエリのデータを参照できるようになった点です。もうサイトの情報が表示されるまでお待ち頂く必要はありません。

最後に、Google では現在クリックが発生しているトップ 2000 クエリのデータを収集しています。クエリのデータの発生が複数の国や言語に及ぶ場合は、表示されるクエリ数は 2000 未満となる場合もあります。たとえば、カナダにおける [flowers] という検索は、google.com 上の [flowers] の検索とは区別してカウントされます。この機能により 98％のサイトにおいてはクエリを完全にカバーしています。

今回の改善がみなさんのサイトの運営に役立つことを願っています。この記事に関するコメントやご意見・ご感想は、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Javier Tordable, Tech Lead, Webmaster Tools
Original version: Even more Top Search Queries data

リッチスニペットテストツールが HTML 入力に対応しました

2012-05-01T11:00:00.000+09:00

本日は、リッチスニペットテストツールの新機能を紹介します。

リッチスニペットテストツールが新しく HTML 入力による確認をサポートしました。これまで、多くの方から公開前の HTML ソースをテストできるようにして欲しいというリクエストを頂いてきました。今回、下図のように HTML ソースコードを利用して確認できるようになり、確認・修正のたびに何度もアップロードをする必要がなくなりました。リッチスニペットを導入・設定する際にはぜひご活用ください。

リッチスニペットテストツールについて詳しい情報はヘルプ記事「リッチスニペットテストツール」をご覧ください。

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

Posted by Anthony Chavez, Product Manager
Original version: Updates to rich snippets

良質なサイトをより高く評価するために

2012-04-25T10:15:00.000+09:00

この記事は日本時間の 2012 年 4 月 25 日に英語版の Google Webmaster Central Blog に投稿された記事「Another step to reward high-quality sites」の抄訳です。

Google はこれまで、検索エンジン最適化（SEO）は、有益で建設的なものと成りうる（英語）、と発言してきましたが、それは私たちだけの意見ではありません（英語）。実際、効果的な検索エンジン最適化は、サイトをよりクロールしやすく、個々のページをよりアクセスしやすく、そして見つけやすくすることができます。たとえば、専門家以外の人が検索に使うキーワードを調査することにより、専門用語ばかりのページを避けるといった単純なことも、検索エンジン最適化のひとつです。

ホワイトハット SEO（ウェブマスター向けガイドラインに違反しない SEO）は多くの場合、サイトの使い勝手の改善や、素晴らしいコンテンツ作成の助長、サイト表示の高速化など、ユーザーと検索エンジンの両方に良い効果をもたらします。また、優れた検索エンジン最適化はマーケティング的視点でも見ても非常に有効であることが多いのではないでしょうか。サイトをより魅力的にするような方法、工夫を考えることは検索エンジンにも、ソーシャルメディアにも非常に有効です。良質なサイトを制作することは、しばしばウェブ上のサイトの評判を向上させ、その結果より多くのサイトからのリンクの獲得や、多くのユーザーのサイト訪問をもたらすでしょう。

“ホワイトハット” SEO の反対は “ブラックハット SEO” や “ウェブスパム” と呼ばれるものです。（メールのスパムと区別するために、”ウェブスパム” と呼んでいます）。掲載順位を上げることやトラフィックを増やすことを追求する中で、まったくユーザーのためにならない裏技や抜け道のような手法を使用してそのサイトに本来適切な掲載順位より高い掲載順位を得ようとしているようなサイトのことです。私たちは、サイトの掲載順位を少しでも高く操作するために行われるキーワードの詰め込みやリンクプログラムへの参加など、様々なウェブスパムを毎日確認しています。

検索ユーザーが素晴らしいサイトを見つけて情報を得る、その手助けのために Google は多くの検索アルゴリズム変更を行っています。私たちはまた、検索アルゴリズムだけの為でなく、ユーザーの為に優れたサイトを作っている方々の努力が、きちんと報われてほしいと考えています。

そこで今回 Google は、ウェブスパムをターゲットにした重要な変更を検索アルゴリズムに施しました。これまでも良質なサイトを適切に評価するために様々なアルゴリズムの変更を実施してきましたが、今回の変更では、Google の品質に関するガイドラインに違反しているサイトについて、その掲載順位を下げるような対策を実施します。このアルゴリズムの変更は、ウェブスパムを削減し、良質なコンテンツを促進するための私たちの新たな試みです。変更の詳細を明かすことは、抜け道をくぐり抜けたサイトが検索結果にあふれ検索ユーザーの利便性を損なう可能性があるためできませんが、ウェブマスターのみなさんにお伝えしたいことは、ユーザーにとって利便性の高い良質なサイトを作ること（英語）に専念し、ウェブスパムを駆使することなく “ホワイトハット” SEO を心がけてください、ということです。

この変更によって影響を受けるサイトは、あからさまなスパムばかりではありませんが、共通して言えるのは、検索結果の掲載順位を人為的に操作するためにホワイトハット SEO を逸脱した SEO を行っているということです。

このアルゴリズムの変更は、すべての言語で同時に実施されます。この変更により、英語の検索では全体の 3.1％程度に、日常的に検索を利用するユーザーが気づくかもしれない程度の変化があります。また、ドイツ語、中国語そしてアラビア語ではおよそ 3 %となります。しかし、その割合はウェブスパム率の高い言語ほどより高くなり、たとえば、ポーランドでは 5 % 程度となります。

Google は、ホワイトハット SEO を行う人々（またはまったく検索エンジン最適化をしていない人々）が素晴らしい、魅力的なサイト制作に専念できるよう願っています。

このアルゴリズムの変更が多くのウェブマスターと、検索ユーザーにとって有益なものとなれば幸いです。

Posted by Matt Cutts, Distinguished Engineer
Original version: Another step to reward high-quality sites

ウェブマスターツールのクロールエラーの機能が新しくなりました

2012-04-18T11:00:00.000+09:00

クロールエラーは、ウェブマスターツールで最も重要な機能の 1 つです。本日は、このクロールエラーが改善され、さらに便利になりましたので、お知らせします。

今回の改善により、数多くの新しいタイプのエラーを検出してレポートできるようになりました。それに伴い新しいエラーは、識別しやすいよう「サイトエラー」と「URL エラー」の 2 つに分けて表示しています。

サイトエラー
サイトエラーとは、特定の URL だけでなく、サイト全体に影響するエラーです。たとえば、DNS の解決エラー、ウェブサーバーとの接続エラー、robots.txt ファイルの取得エラーなどです。これまではサイトエラーを URL 別にレポートしていましたが、URL 固有のエラーではないためあまり意味がありませんでした。実際これらのエラーでは、Googlebot が URL のリクエストをすることすらできません。そこでこれを変更し、サイトエラーはタイプ別にエラー発生率を記録することにしました。また、サイトエラーの頻度が上がり、注意を要するレベルに達した場合にはアラートを送信することも検討しています。

サイトエラーの発生率と発生回数の時系列表示

ほとんどのサイトは、これらのエラーが発生しないのが普通です。最近サイトエラーが発生していないのであれば、これらのセクションを逐一チェックする必要はありません。そこで、緑色のチェックマークを表示して、すべてが正常に稼動していることを一目で確認できるようにしました。

最近サイトエラーが発生していないサイト

URL エラー
URL エラーは、特定のページにのみ関係するエラーです。つまり、Googlebot がその URL をクロールしようとして DNS を解決し、サーバーに接続し、robots.txt ファイルを取得して読み込んだ後に、この URL をリクエストしたら問題が発生した、というエラーです。ウェブマスターツールでは、URL エラーをその原因に基づいていくつかのカテゴリに分類しています。サイトで Google ニュースやモバイルのデータ（CHTML/XHTML データ）を提供している場合、それらのエラーは別のカテゴリで表示されます。

タイプ別 URL エラーの発生回数の時系列表示

少ない方が効果的
これまでのウェブマスターツールでは、タイプごとに最大 10 万件のエラーを表示していました。これほどの量の情報をすべて消化しようとするのは、消防車のホースの水をすべて飲むのと同じくらい困難だったのではないでしょうか。どのエラーの重要性が高く（たとえばホームページがダウンしている）、どのエラーの重要性が低いか（たとえばある個人サイトからのリンクにタイプミスがある）を識別する方法も用意されていませんでした。10 万件のエラーを効率的に確認する手段、たとえば並べ替えや検索、「修正済み」のマークを付ける機能も用意されていませんでした。新バージョンのクロールエラー機能では、最も重要なエラーを強調することに重点を置きました。最も重要と思われるエラー、対処する必要のあるエラーが、カテゴリごとに 1,000 件ずつ表示されます。これら上位 1,000 件のエラーは並べ替えたり検索したりでき、修正済みのマークを付けたり、詳細を表示したりすることもできるようになっています。

どの列でもエラーをフィルタリング/並べ替え可能

サイトによっては、特定のタイプのエラーが 1,000 件を超えるかもしれません。その場合でも、そのタイプのエラーの総数を確認したり、過去 90 日間の履歴データをグラフで表示したりすることは可能です。1,000 件のエラーの詳細と累計エラー数だけでは不十分という場合に備え、API を使ってプログラム的にアクセスし、すべてのエラーをダウンロードできるようにすることも検討しています。

また、robots.txt によってブロックされたページのリストも削除しました。この情報が robots.txt ファイルによる問題を診断する際に役立つこともありますが、大抵の場合はサイト運営者が「意図的に」ブロックしたものです。[クロールエラー]は緊急性の高いエラーを重点的に確認するための項目に特化させるため、robots.txt でブロックされた URL の情報は近日中に [サイト設定] の [クローラのアクセス] に移設する予定です。

詳しい情報を手に入れる
エラーリストの個々の URL をクリックすると、詳しい情報が記載されたウィンドウが表示されます。このウィンドウでは、その URL を最後にクロールしようとした日時、最初に問題が通知された日時、そのエラーの簡単な説明などを確認できます。

URL ごとのエラーの詳細

このウィンドウでは、エラーの原因になった URL のリンクをクリックすることで、実際にアクセスするとどうなるかを試すことができます。他にも、エラーに「修正済み」のマークを付けたり（後ほど詳しく説明します）、エラータイプのヘルプコンテンツを見たり、その URL を含むサイトマップを生成したり、その URL にリンクしている他のページを確認したりできます。また、Googlebot に今すぐ URL を取得させて、詳しい情報を入手したり、正しく修正できているかどうかを確認したりすることもできます。

特定の URL にリンクしているページの一覧

エラーに対処する
新バージョンのクロールエラー機能で最も注目してほしいのが、重要なエラーに重点を置いて先に修正できる点です。エラーをランク付けして、対処が可能なエラーほど優先順位リストの上位に表示されるようにしました。対処可能なエラーとは、たとえばサイト内のリンク切れの修正、サーバーソフトウェアのバグの修正、リンク切れの URL を除去するサイトマップの更新、ユーザーを実在するページに移動させる 301 リダイレクトなどです。ランク付けは、その URL がサイトマップに含まれているか、その URL へのサイト内またはサイト外からのリンクがいくつあるか、その URL への検索トラフィックが最近発生したかなど、さまざまな要因に基づいて行われます。

エラーの修正が完了したら、Googlebot にその URL を取得させることで、正しく修正できているかどうかを確認できます。フルアクセス権のあるユーザーであれば、エラーに「修正済み」のマークを付けることもできます。マークを付けると、そのエラーがリストから削除されます。修正済みのマークを付けたエラーは、URL を再クロールして同じエラーが発生しない限り、再びエラーリストの上位に表示されることはありません。

エラーを選択し、修正済みのマークを付ける

新しいクロールエラー機能にはさまざまな工夫を凝らしてあります。皆様に「これは便利」と感じていただけることを願っております。この記事に関するコメントやご意見・ご感想は、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Kurt Dresner, Webmaster Tools team
Original version: Crawl Errors: The Next Generation

ウェブマスターツールに制限付きの権限を持つ管理者を追加する機能がつきました

2012-04-13T11:00:00.000+09:00

この度、Google ウェブマスターツールに新たな機能が追加され、サイトの所有者がサイトのデータや設定へのアクセス権を制限付きで他のユーザーに与えられるようになりました。他のユーザーにフルのアクセス権を与える機能（英語）は以前からありましたが、ウェブマスターのみなさんからは度々「設定の変更はできないが、ウェブマスターツールのデータの閲覧はできるような、制限付きのアクセス権を他のユーザーに与えたい」というようリクエストをいただいていました。今回導入された新しいユーザー管理機能により、こういった設定が可能になります。

ウェブマスターツールのホームページで「サイトを管理」というドロップダウンのメニューをクリックすると、メニューのオプションが表示されます。以前は「サイト所有者を追加/削除」と表示されていたメニューが、現在は「ユーザーを追加/削除」という名前に変更されています。

この「ユーザーを追加/削除」というメニューを選ぶと、新しいユーザー管理のページが表示されます。ここでは最大 100 人のユーザーを追加または削除したり、各ユーザーに対してアクセスレベルを「フル」または「制限付き」に指定したりすることが可能です。ユーザー管理のページから追加されたユーザーは、特定のサイトに関連づけられています。もしあなたがそのサイトの所有者であると確認できなくなった場合、あなたが追加したユーザーもウェブマスターツールでのそのサイトに対するアクセス権を失います。確認済みのサイト所有者の追加や削除は、以前と変わらずウェブマスターツール内の、ユーザー管理＞サイト所有者の管理ページから行います。

フルのアクセス権を与えられたユーザーは、すべてのデータの閲覧が可能になり、さらにサイトの設定の変更やサイトリンクの順位をを下げるなど、ほとんどの操作を実行することができるようになります。制限付きのアクセス権を持つユーザーは、ほとんどのデータの閲覧と、Fetch as Googlebot を使うことやアカウントにメッセージを転送する設定など、いくつかの限られた操作のみを行うことができます。制限付きのアクセス権しか持たないユーザーにはウェブマスターツール内の多くの場所で「アクセスが制限されています」というメッセージが表示されます。

制限付きユーザーやフルの権限を持つユーザー、サイト所有者がどのような機能や操作を実行できるのかはヘルプ記事の「権限」のページをご覧ください。

今回の新しい機能では、アクセス権限を限定することでウェブマスターツールに精通していない方にも権限を付与することが可能になり、サイト運営に関わる多くの方の間でウェブマスターツールの情報を共有することができるようになりました。これによって皆様のウェブマスターツールを通じてのサイト管理がよりスムーズになればと願っています。今回の新たなユーザー管理機能について、ご意見、ご質問などございましたら、ウェブマスターヘルプフォーラムからお声をお寄せください。

Written by Jonathan Simon, Webmaster Trends Analyst
Original version: Safely share access to your site in Webmaster Tools

ソフトウェアのアップデートをおすすめする通知について

2012-04-04T11:00:00.000+09:00

本日は、ウェブマスターツールのメッセージセンターにお送りしている通知の中で、ソフトウェアのアップデートをおすすめする通知についてご紹介させて頂きます。

サイトで使用されているソフトウェアやプラグインのバージョンが古く、ハッキングされる可能性があるなど脆弱性が検知された場合や、より新しいバージョンが利用できることを Google が検知した場合、ウェブマスターツールのメッセージセンターにメッセージをお送りしているケースがあります。たとえば、Drupal のモジュールや Joomla の拡張機能のアップデートが入手できる状態であるのに、一部のサイトではアップグレードが済んでいない、ということがあるかもしれません。ウェブマスターが新しいバージョンにアップグレードしない理由はいくつか考えられますが、理由の 1 つとして、単に新しいバージョンが存在することを知らないことも考えられます。そのようなケースについては Google がお役に立てるのではないかと考え、ウェブマスターの皆様に、ウェブマスターツールを通じてメッセージを送信して、ソフトウェアの新しいバージョンについてお知らせしています。

お知らせが必要なサイトを特定するために、Google ではクロールしたウェブページのソースコードを解析するなどの方法を使用します。たとえば、WordPress や他の CMS アプリケーションには、バージョンを特定するタグが含まれています。このタグが、Google からウェブマスターの皆様に通知を行う上でバージョンの判別に非常に役立ちます。ソフトウェアデベロッパーの方が自分のソフトウェアの新しいバージョンについて Google からユーザーに通知してほしいとお考えの場合は、まずソフトウェアのバージョンを特定するタグがソースコードに含まれるよう開発することをおすすめします。プラグインやウィジェットを開発している場合も、ユーザーに提供するソースコードにバージョン番号を入れることをおすすめします。

ソースコードにバージョン番号を入れることがセキュリティ上好ましい方法なのかどうかについては、意見が分かれるかもしれません。バージョン番号を入れると、そのウェブサイトが特定の種類の攻撃に対する脆弱性を持っている可能性があることがハッカーやワーム作成者にわかってしまうからです。しかし Matt Mullenweg 氏は、「昔のワーム作成者は脆弱性の確認にインストールされているソフトウェアのバージョン番号を確認していましたが、最近ではバージョン番号は見ずにサイトの機能や動作そのものを確認しています。」と指摘しています。また、バージョン番号があることで、サイトを更新する必要があるかどうかを判別できるという利点があります。Google は、バージョン番号をソースコードに入れることは、害よりも利益の方が大きいケースが多いと考え、メッセージの送信に活用しています。

最後に、このお知らせは強制的なものではありませんので、アップグレードするかどうかについてはウェブマスターの皆様ご自身でご判断ください。

※対象ソフトウェアにつきましては、現在では WordPress や Typo3 なども追加されています。

Posted by Patrick Chapman, Search Quality Team
Original version: 'New software version' notifications for your site

サイトマップに関する新機能:よりわかりやすく直感的になりました

2012-03-27T11:00:00.000+09:00

サイトマップは、皆さんのサイトのページに関する情報を Google に提供する手段の 1 つです。ウェブマスターツールのサイトマップ機能では、皆さんから提供されたサイトマップに対して、サイトマップ内の URL のインデックス登録数や、サイトマップにエラーがないかといったフィードバックを提供しています。この度、ウェブマスターツールにおいてさらに多くの情報を提供するようになりました。1 つずつご紹介していきましょう。

※図はウェブページと動画のサイトマップが登録されているケースです。

サイトマップページでは、コンテンツのタイプ別に詳細情報を表示しています。今回、ウェブページや動画、画像、ニュースそれぞれについて、サイトマップの統計情報がひと目でわかるようになりました。これによって、各コンテンツタイプの項目の送信数（送信されたものがある場合）のほか、一部のコンテンツタイプについては、インデックス登録されている項目数もわかるようになっています。今回の機能強化に伴い、この新しいサイトマップページが [Labs] の動画サイトマップ機能に代わるものとなり、動画サイトマップ機能は廃止される予定です。

次の改善点は、サイトマップをテストする機能です。実際に送信する場合とは異なり、テスト機能ではエラーがあるかどうかのチェックだけが行われ、サイトマップは Google へ送信されません。テストでは Googlebot によってすぐにサイトマップの確認が行われ、通常は数秒で完了します。なお、このテストはあくまで初期的な診断で、細部に渡る詳しいものではなく、問題点をすべて検知できるわけではないことにご注意ください。例えば、サイトマップ内の URL がダウンロードされたときにしか確認できないようなエラーはこのテストでは発見できません。

テスト機能に加え、エラーの表示方法を改善し、サイトマップの問題点をこれまでよりも見つけやすくしました。1 つのサイトマップに対して、同じ種類のエラーを何度も繰り返し表示するのではなく、エラーや警告をグループ分けし、具体例をいくつか表示するようになりました。同様に、サイトマップのインデックスファイルについても、サイトマップインデックス配下のサイトマップのエラーや警告をまとめて表示するようにしました。これによって、配下のサイトマップを 1 つずつクリックして調べる必要がなくなります。

最後に、「削除」ボタンの挙動も変更しました。ウェブマスターツールからサイトマップを削除する際、皆さんのアカウントとサイトの他のオーナーのアカウントの両方から削除されるようになります。ただし、サイトマップはウェブマスターツールから削除しても、Google によってまだ読み込まれたり処理されたりする可能性があることにご注意ください。例えば、robots.txt ファイル内でサイトマップを参照している場合は、検索エンジンは引き続きそのサイトマップを処理しようとする場合があります。このようにサイトマップが参照されることを完全に防ぐためには、ファイルをご自分のサーバーから削除するか、robots.txt でブロックしてください。

ウェブマスターツールのサイトマップ、およびサイトマップの機能について詳しくは、ヘルプセンターの記事をご覧ください。ご質問がありましたらウェブマスターヘルプフォーラムまでお寄せください。

Written by Kamila Primke, Software Engineer, Webmaster Tools
Original version: What’s new with Sitemaps

Google Merchant Center に関するお知らせ: Google ショッピングでのパフォーマンスを詳しく分析

2012-03-21T11:30:00.001+09:00

「データは宝である」という話をショップオーナーの皆様からよく聞きます。そのデータで、商品の販売実績や顧客の購買傾向がわかる場合はなおさらです。Google ではそういった皆様からの声をもとに、Google Merchant Center の改善を図っています。第一弾として、ショップオーナーの皆様のお手元により多くのデータをお届けできる機能を追加しました。
Google ショッピングに商品フィードを送信していただくと、Google Merchant Center アカウントの [掲載結果] タブ ( 以前の [パフォーマンスレポート] タブ ) で、より詳しい商品実績データがご覧いただけるようになりました。

すべての商品についてのクリック数が表示できるだけでなく、データを掘り下げて特定の商品カテゴリ、ブランド、状態、国別のクリック数も表示できるようになりました。期間を限定して表示することもできます。さまざまなタイプの商品、ブランドなどの実績を簡単に比較できるため、現状を評価し、さらに最適化の必要がある箇所を特定することができます。

この新しい機能を使用して商品の実績をより詳しく分析できるようになったため、情報に基づいた判断が可能となり、投資収益率の向上を図ることができます。

Google では、今後も Google ショッピングおよび Google Merchant Center の機能を改善していきます。頻繁にチェックしてみてください。

Posted by 鈴木宏輔 / プロダクトマネージャー

フォームへの入力をすばやく簡単に

2012-03-13T11:00:00.000+09:00

ユーザーをコンバージョンに導くプロセスで大きなボトルネックのひとつとなるのが、オンラインフォームへの入力です。ショッピングや登録のプロセスが完了するかどうかは、フォームの出来により大きく異なります。フォームへの入力は、サイトの目標を達成する上で最も重要かつ要求の厳しいステップです。多くのユーザーにとってオンラインフォームは、ウェブ上のさまざまなサイトで自分の名前や住所などの情報を繰り返し入力しなければならないものもあるため、多くのユーザーが、この面倒な作業のために入力を途中でやめてしまいます。

Chrome の自動入力やその他のフォーム入力機能は、一般的なプロフィール情報を記憶し、フォームにその情報を事前に入力することで、こうした障壁を取り除きます。ただし現在のところ、ウェブマスターには、Chrome やその他のフォーム入力機能がサイトのフォームを正しく解析してくれるかどうかがわかりません。いくつかの規格があります（英文）が、ウェブサイトの実装に負担がかかるため、あまり利用されていないのが現状です。

そこで、Chrome ではフォームのフィールドに新しい「オートコンプリートタイプ」属性を試験的に導入いたしました。ウェブデベロッパーのみなさまはこの属性を使って、text フィールドと select フィールドに標準的なデータタイプ（「full-name」、「street-address」など）で明確にラベルを付けることができます。この属性を使用してフォームを自動入力用にマークアップすることで、ユーザーインターフェースやバックエンドに変更を加えずにサイトでのコンバージョン率を高めることができます。

実際には、input 要素に属性を追加するだけです。たとえば、メールアドレスのフィールドは、次のようになります:

<input type=”text” name=”field1” x-autocompletetype=”email” />

Google は、他の複数の自動入力対応ベンダーと共同で今回の設計を行ってきました。あらゆる初期段階の提案と同様に、ウェブ標準化コミュニティからのフィードバックに基づいてこの機能を変更、改善していく予定ですが、Google ではこの機能が、HTML5 の仕様で自動入力フォームの対応について議論するよいきっかけになると考えています。現在のところ、この新しい属性は x-autocompletetype として Chrome に実装されています。これは、webkitspeech 属性（昨年の夏にリリース（英文））と同様に、まだ実験運用属性であり、標準属性ではありません。

詳しくは、仕様案の全文（英文）をご覧ください。この記事に関するコメントやご意見・ご感想は、ウェブマスターヘルプフォーラムまでお寄せください。また、標準化の議論（英文）へのご意見もお待ちしています。

Posted by Ilya Sherman, Software Engineer
Original version: Making form-filling faster, easier and smarter

ウェブマスターヘルプフォーラムユーザーアンケート 2012

2012-03-07T11:25:00.000+09:00

ウェブマスター向け公式ヘルプフォーラムは、 3 月 6 日で開設から 3 周年を迎えました。

これもひとえに、日頃活発にディスカッションに参加してくださっているウェブマスターの皆さまのおかげです。ありがとうございます！

今年もウェブマスター向け公式ヘルプフォーラムをご利用の皆さまを対象としたアンケートを実施し、皆さまからのお声をお聞かせいただきたいと思います。

アンケートでお寄せいただいくご意見はウェブマスターヘルプフォーラムチームにとって何よりの貴重なご意見となっており、フォーラム運営の改善に活用させていただいています。例えば 2011 年のアンケートからは以下のような企画が誕生しました。

今年のアンケートでも、皆さまからのアイディア、ご提案をどんどん取り入れ、皆さまと共に、さらに役立ち、多くのウェブマスターの方々が集まるウェブマスター向け公式ヘルプフォーラムをつくっていきたいと思います。また、アンケートを回答してくださった方の中から抽選で 40 名様に Google オリジナルグッズ（写真）をプレゼントさせていただきます。

アンケートのご回答はこちらからよろしくお願いいたします。
*回答受付期間: 2012 年 3 月 7 日（水）～3 月 25 日（日）

それではご回答、お待ちしております！

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

Google の検索セキュリティを強化しました

2012-03-06T19:03:00.000+09:00

Google では、数カ月前に google.com 上でログインした状態で検索をすると、デフォルトでSSL暗号化される変更を加えましたが、今回、co.jp ドメインにおいても、同様にデフォルトで暗号化されるようになりました。

詳しい情報はこちらでご確認ください。

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

上位の検索クエリのデータが新しくなりました

2012-02-28T10:34:00.000+09:00

ウェブマスターツールの検索クエリの機能が新しくなりましたのでお知らせします。以前はあるクエリについて表示されたすべての URL の平均順位を表示していました。今後はその代わりに、最上位に表示された URL の平均順位を表示します。

例えば Nick が「ベーコン」と検索し、あなたのサイトが検索結果の 3, 6, 12 番目に表示されたとします。また、Jane も「ベーコン」と検索し、同様に検索結果の 5 番目と 9 番目に表示されたとします。以前はこれらのすべての順位を平均して 7 位と表示していました。今後はそれぞれの検索結果に表示される最も高い順位の平均（Nick の検索結果では 3 位、Jane の検索結果では 5 位になります）をとって 4 位と表示されます。

この新しい計算方法によって、表示される順位はよりウェブマスターのみなさまの実感に近いものとなるでしょう。

上位のクエリデータへの影響
この変更は今後の上位の検索クエリのデータに影響します。過去のデータは変更されません。この変更に伴い掲載順位の低い URL の平均はとらなくなるので、平均掲載順位は通常同じか高くなります。

ウェブマスターツールの「ウェブ上のサイト」セクションで新しくなった上位のクエリのデータをご確認ください。また、上位のクエリデータはプログラムを使用してダウンロードを行うこともできます（英語）。ぜひご活用ください。

今後もウェブマスターツールがあなたのサイト運営に役立てるよう改善に努めます。お気づきのことなどありましたらウェブマスターフォーラムでお知らせください。

Posted by Chris Anderson, Google Analytics team, and Susan Moskwa, Webmaster Trends Analyst
Original version: Update to Top Search Queries data

多地域向けウェブサイトの構築

2012-02-24T17:37:00.000+09:00

海外向けのビジネスを展開されているサイトでは、事業の展開に応じて、ウェブサイトの情報を様々な地域のユーザーに届けるために、サイトをローカライズ（現地化）することを考えている方は多いのではないでしょうか。そこでこの記事では、多地域向けのウェブサイトの構築に必要なことを、検索エンジンの視点から考えていきます。ではまず多地域向けのウェブサイト作成に関する大まかな準備について説明した後、サイトの構築方法について見ていきましょう。
※本記事で扱う多地域向けのウェブサイトとは、明確に複数の地域（多くの場合、国も異なります）のユーザーをターゲットにしたサイトを指し、多言語向けのウェブサイト（関連ブログ記事（英語））とは複数の言語で提供されているサイトを指します。

グローバルウェブサイトの準備

ウェブサイトを複数の地域や言語に対応させることは簡単な作業ではありません。ウェブサイトを複数のバージョンを作成するということは、バージョンの数だけその修正に手間がかかる可能性もあるということなのです。そのため、サイトの多地域・多言語化を始める前に、最初のバージョンですべてがきちんと動作することを確認してください。また、管理する URL の数が一気に増えるわけですから、ウェブサイトを支える設備もそれなりに必要になることを忘れないでください。

多地域向けウェブサイトの計画

複数の地域（通常は国）向けのサイトを計画するときは、まずそれぞれの国や地域の法的条件や行政上の規制について調べ、自分のウェブサイトに関係するものがないかどうか確認します。これらの条件によっては、たとえばその国固有のドメイン名を使えない、などその後の作業に影響が出ることがあります。

多くのウェブサイトにとって、ドメイン名は非常に重要です。Google ではドメイン名に関して、次の 2 種類を区別しています。

ccTLD（国別コードトップレベルドメイン）: このドメインは、それぞれ特定の 1 つの国に関連付けられています（たとえば、.jp は日本、.de はドイツ、.cn は中国など）。これは、ユーザーにとっても検索エンジンにとっても、そのウェブサイトがどの国向けに作られているかを示す明確なシグナルとなります。
gTLD（ジェネリックトップレベルドメイン）: このドメインは特定の国には関連付けられていません（たとえば、.com、.net、.org、.museum など）。Google では、.eu や .asia などの地域トップレベルドメイン名も gTLD とみなしています（これらのドメインは、特定の国には関連付けられないためです）。また、Google はいくつかの vanity ccTLD（.tv、.me など）も、gTLD として扱っています。というのも、これらのドメインを利用したサイトは、特定の国ではなく、より一般的な広い地域をターゲットとしていると考えるユーザーやウェブマスターが多いからです（Google が gTLD として扱う ccTLD を完全に網羅した一覧表はありません。こうした内容は、時と共に変化するからです）。gTLD を持つウェブサイトの地域ターゲティングは、 [ウェブマスターツール] の [地域ターゲット設定] を使用して設定することができます。

地域ターゲティングの判断要素

Google では通常、以下の要素を使ってウェブサイト（またはウェブサイトの各部分）の地域ターゲティングを判断します。

ccTLD の使用
これは一般に、特定の 1 つの国を指定しているため、ユーザーにとってわかりやすい指標となるでしょう。
ウェブマスターツールを使った gTLD の手動による地域ターゲティング（これはドメイン、サブドメイン、またはサブディレクトリのレベルで設定可能です）
設定方法の詳細については、ブログ記事（英語）とヘルプ記事：地域ターゲットの設定を参照してください。この方法を使用すると、地域ターゲティングからの地域タグが検索結果に表示される（英語）ため、ユーザーにとっても非常にわかりやすくなります。ただし、1 つのページが複数の国をターゲットとしている場合（ドイツ語圏のすべての国を対象としているなど）は地域ターゲティングを設定するのは適切ではないかもしれません。その場合は単にその言語を使ってページを作成し、地域ターゲティングは設定しないでください（多言語でのページ作成についてはこちらの記事をご参照ください）。
サーバーの位置（サーバーの IP アドレスにより判断）
サーバーの物理的な位置は、対象とするユーザーの近くであるはずです。しかし、ウェブサイトによっては分散 CDN（コンテンツデリバリーネットワーク）を使用している場合や、ウェブサーバーのインフラストラクチャが整備されている国でホスティングされている場合もあるため、Google ではサーバーの場所だけで判断することは避けています。
その他の要素
上記以外の要素がヒントになることもあります。たとえば、ページに記載された住所や電話番号、使われている言語や通貨、別のローカルサイトからのリンク、Google のローカルビジネスセンターの利用状況などから判断する場合もあります。

Google ではターゲット地域の特定に際し、場所を表すメタタグ（geo.position や distribution）や HTML 属性を使用していないことに気をつけてください。これらの要素は、他の点では便利なこともありますが、地域ターゲティングに使用するには信頼性に欠けることがあるからです。

URL 構造

ターゲット地域の特定に使われる上述の 3 つの要素は、使用されているサーバーや URL と密接に関係しています。地域ターゲティングをページごとに設定するのは難しいため、URL 構造を使ってウェブサイトをいくつかのセグメントに分けて地域ターゲティングを設定するほうが理解しやすいでしょう。以下に、地域ターゲティングに利用できる URL 構造の例と、それぞれの長所と短所を挙げます。

ccTLD 例: example.de, example.fr	gTLD を使用したサブドメイン例: de.site.com, fr.site.com, etc.	gTLD を使用したサブディレクトリ例: site.com/de/, site.com/fr/, etc.	URL パラメータ例: site.com?loc=de, ?country=france, etc.
長所（+） - 地域ターゲティングが明確 - サーバーの場所に依存しない - サイトの分割が簡単 - 法的要件に対応しやすい（場合による）	長所（+） - 設定が簡単 - ウェブマスターツールの地域ターゲティングを使用できる - 複数の場所にあるサーバーを使用できる - サイトの分割が簡単	長所（+） - 設定が簡単 - ウェブマスターツールの地域ターゲティングを使用できる - ホストが同じであるため管理がしやすい	長所（+）（おすすめしません）
短所（-） - 入手にコストがかかる - より多くのインフラが必要 - ccTLD 要件を満たす必要がある（場合による）	短所（-） - ユーザーが URL だけでは地域ターゲティングを認識できない場合がある（例: 「de」は言語か国か）	短所（-） - ユーザーは URL だけでは地域ターゲティングを認識できない場合がある - サーバーの場所が特定の箇所に集中する可能性がある - サイトの分割が難しい	短所（-） - URL に基づくセグメント化は難しい - ユーザーは URL だけでは地域ターゲティングを認識できない場合がある - ウェブマスターツールの地域ターゲティングを使用できない

おわかりのように、地域ターゲティングの設定は、どのサイトでも常に同じになるとは限りません。たとえ国別コードトップレベルドメイン（ccTDL）を使っているサイトであっても、内容はグローバルなものかもしれません。ですから想定とは異なる場所からサイトを訪れるユーザーのことを考えておくべきです。そのためにできることの 1 つとしては、ユーザーが地域や言語を選択するためのリンクをすべてのページに表示することが考えられます。

グローバルウェブサイトでの重複コンテンツの管理

複数の地域や言語のコンテンツを提供するウェブサイトでは、同じコンテンツや類似したコンテンツを別々の URL で提供している場合があります。違う国にいる別のユーザーがそのコンテンツを使用する限り、通常は問題ありません。もちろん各地域のユーザーグループごとに別々のコンテンツを提供することをおすすめしますが、実際には最初からすべてのページとバージョンについてユーザーグループごとに別々のコンテンツを提供するということは容易ではないでしょう。ですから、たいていの場合は、重複するコンテンツを「隠す」ために robots.txt ファイルでクロールをブロックしたり、 noindex ロボットメタタグを使用したりする必要はありません。ただし、同じコンテンツを同じユーザーグループ向けに複数の URL で提供している場合（たとえば、example.de/ と example.com/de/ の両方でドイツ語のコンテンツをドイツのユーザー向けに表示している場合）は、お好みのバージョンを 1 つ選択してそこへ適切にリダイレクトさせるか、 rel=canonical リンク要素を使用するとよいでしょう。

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

Written by John Mueller, Webmaster Trends Analyst, Google Switzerland
Original version: Working with multi-regional websites

簡単にできるウェブサイトのユーザーテストやユーザーリサーチの方法

2012-02-13T11:43:00.000+09:00

ウェブマスターチームは、数万件もの Google のウェブページを日々取り扱っています。今回は、ウェブマスターチームのこのような実地の経験に基づいたヒントやアドバイスをご紹介いたします。

もしご自身のウェブサイトにおけるユーザーの利用状況のテストや解析をまだ行ったことがないのであれば、サイトがターゲットのユーザーにとって有用なものになっているかを確認してみることをお勧めします。たとえば一例として、平均的なユーザーが下にスクロールする回数は上にスクロールする回数の 5.9 倍、つまり一度スクロールして通り過ぎたコンテンツは多くの場合「もう見られることがないも同然」であると言われています。まずはあなたのサイトの中に必要以上にスクロールさせるページがないかどうか、そしてそのページのアクセスログを解析し、直帰率の高さや滞在時間の長さなどを確認してみてはいかがでしょうか？（スクロールに関する Jakob Nielsen 氏の研究結果（英語）では、ユーザーはスクロールすることを嫌がらないけれどもそれにも限界がある、と述べられています）

まず、あなたのユーザーについて考えてみましょう

新たなウェブサイトの制作をするときは、まったく新しいサイトを構築する場合でも、既存サイトをリニューアルする場合でも、次のことについて考えてみると良いでしょう。

ユーザーはどこからサイトにアクセスするのか（自宅から、職場から、それとも外出先から）。
訪問者はどの程度技術に精通しているのか。
ウェブサイトで取り上げる内容にユーザーはどの程度馴染みがあるのか。

このような項目についての答えが、初回のサイトデザインを決めるにあたって大いに役立つことがあります。

たとえば、外出先でアクセスすることが多いユーザーは、サイトで必要な情報を見つけるための時間があまりなかったり、じっくり集中しにくい環境にあり、またデータ接続も低速であったりすることが考えられます。その場合、目的を 1 つに絞ったシンプルなレイアウトが最適でしょう。また、技術にさほど詳しくないユーザー向けにコンテンツを提供する場合、目的のコンテンツにアクセスするのが難しくなり過ぎないようにしましょう。アニメーションを使えば華やかになるかもしれませんが、それがユーザーにとって価値があり、また目的のコンテンツにアクセスするのが難しくなり過ぎない場合だけ利用するようにしましょう。

テストをしなくても、基本となるユーザープロフィール（いわゆる「ペルソナ」）を作成してみると、ユーザーにとって使いやすいデザインを作る上で役立つことがあります。プロフィールといっても、ユーザーの生い立ちや背景などを事細かに網羅する必要はなく、ユーザーの行動パターンを考えてみるだけでも足りるでしょう。

シンプルなテスト

テストは多額の費用をかけて大がかりに実施する必要はありません。友だちや家族に聞いてみるだけでも大きなヒントを得られるでしょう。ポイントとなるのは次のようなことです。

テスト対象者の人数: サイトのレイアウトやナビゲーションの問題点を見つけるには 5 人くらいに聞いてみるだけでも十分でしょう（サンプルサイズが小さくても十分である理由を述べた Jakob Nielsen 氏の記事（英語）をご覧ください）。
テスト対象者を選ぶ: さまざまな技術レベルの人を揃えた方が有用な結果につながりやすいでしょう。ただし、発生した個々の問題よりも全体の傾向を重視するようにします。たとえば、テスト対象者の半数以上に同じユーザビリティの問題が発生した場合は、本当に対処が必要な問題であると判断できるでしょう。
テストの場所: 可能であればユーザーの自宅を訪問して、サイトを利用する様子を観察してみましょう。ユーザーにとって自然な環境でリラックスした状態で普段どのようにウェブを見るのかを観察します。実際にユーザーを訪問できないときはリモートテストを行うのもよいでしょう。このような場合に Google+ ハングアウトを活用できるという報告も届いています（Google+ ハングアウトの使い方について詳しくはこちらをご覧ください）。
テスト方法: サイトの目的に応じてウェブサイトで行う簡単な操作を 4 つか 5 つ考え、ユーザーに実行してもらいましょう。テスト対象者の体験や思考をよく理解できるように、思ったことを声に出して言ってもらうとよいでしょう。
テストするべき項目: テスト用のサイトをまるごと 1 つ構築しなくても、クリックできる画像や文書のフォーマット（PDF など）または HTML などの基本的なプロトタイプを使って、基本的なインタラクションをテストすることができます。さまざまなナビゲーションやレイアウトをテストすることで、実際に実装する前にどのようにユーザーに利用されるかを確認することができます。
テストするべきではない項目: グラフィックデザイン要素よりも機能性に重点を置きましょう。デザインについては感じ方が主観的であることが多いからです。デザインについての有用なフィードバックが得られるのは、大人数（200 人以上）のユーザーを対象とした定量的なテストを行った場合に限られると言われています（ただし、たとえばサイトに使用する色によってコンテンツが判読できなくなるという場合などは、そのようなテストをしなくても有用なフィードバックが得られるでしょう）。デザインについてある程度の有用なフィードバックを得る方法としては、記述的なキーワードを 5～6 個用意して、その中からサイトに最もあてはまるものをユーザーに選んでもらうという方法などがあります。

全体として、基本的なテストはウェブサイトの機能がどのように動作しているか、つまり情報がどの程度簡単に見つけられるか、またサイトとのインタラクションがどのようなものになるかを確認する上で非常に有用です。

ユーザーテストから分かったこと

もし本当に調査とテストを行う価値があるかどうかまだ確信が持てないなら、実際に私達がユーザーに接して得ることができた事例が参考になるでしょう。いくつかの例を以下に紹介します。これらは、実際のユーザーと直接対面して Google のウェブページを利用する様子を観察しなければ、あるいは Google のウェブトラフィックを解析しなければ知り得なかったことです。

コンテンツを表示/非表示にするレイアウトを使用する場合は注意する: スクリプトを使用して長いテキストを展開したり折りたたんだりするようにしている場合、ユーザーが折りたたまれたコンテンツの存在に気づかないケースが多いことがわかりました。たとえば JavaScript で折りたたまれて非表示になるコンテンツは、ユーザーがページ内を検索（たとえば Ctrl+F キーを使うケース）しても見つかりません。

テストしたレイアウトのワイヤーフレームです。折りたたまれた

コンテンツが左下に表示されています。

最終的なページデザインです。最上部にアンカーリンクが表示され、

コンテンツはページ本文の中に配置されています。

言葉の使い方を確認する: 見出し、リンク、ボタンは、ユーザーがページをざっと見たときに最も目を引く要素です。たとえばリンクテキストには「詳細を読む...」という言葉を使わないようにしましょう。ユーザーはさらに何かを読まなければならないと感じさせるリンクをクリックすることを避けるようです。その代わりに、ユーザーがリンクをたどった後にどのようなコンテンツが表示されるのかをそのまま説明する言葉を使うように心がけましょう。リンクテキストは周りの文脈と切り離されたとしても意味が通り、簡単に理解できるようなものにしましょう（実際にユーザーがざっと見るときにはそのようにして読まれるからです）。またボタンテキストの場合には言葉の使い方を工夫して、内容がわかりやすく、ユーザーの興味を引き、クリックしてみたくなるようなものになるよう心がけましょう。
低速接続の環境でページをテストする: さまざまなネットワーク環境を使用してページをテストしてみましょう（たとえば、近所のカフェや友だちの家の Wi-Fi などを使ってブラウジングしてみましょう）。ご自分のサイトのターゲットユーザーが、たとえば職場のネットワークほど高速でない家庭用のインターネット接続でページを表示する可能性が高い場合には特にこのテストは有用です。私達のケースでは、スクリプトを使用したアニメーションをシンプルかつ高速にし、CTR （クリックスルーレート）とサイト滞在時間の数値が大幅に改善されました（低速のインターネット接続でテストできない場合は Google の Page Speed Online でパフォーマンスを確認することができます）。

終わりがないかのように思える開発のやり直しのサイクルにはまり込んでしまったときは、まず少しだけ立ち止まってユーザープロフィールの作成と基本的なテストを行うことで、サイトのレイアウトやアーキテクチャに対する適切なアプローチを選択できるようになるでしょう。

この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。
* ウェブマスターヘルプフォーラムではあなたの「簡単にできるウェブサイトのユーザーテストやユーザーリサーチの方法、コツ」を教えてください！というスレッドを開設しました。ウェブサイトのユーザテストの実践例、どのようにしたらうまく行ったか、またテストを最大限に活用するためにどのような工夫をしたか、などなど皆さまの経験から得られたコツやポイントを募集しています。ご投稿お待ちしています！

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

Îñţérñåţîöñåļîžåţîöñ （インターナショナリゼイション - サイトを国際化する際に知っておきたいこと）

2012-02-08T11:12:00.000+09:00

ビジネスを世界展開しようとしているなら、ウェブサイトもそれにあわせる必要があるでしょう。テキストを翻訳するだけの簡単なことだと思う方もいるかもしれませんが、実は気をつけることは他にもあります。Google ウェブマスターチームが作成するサイトは、40 を超える言語にローカライズ（現地語化）されることも頻繁にあります。今回はその経験を基に、ページを多言語そして多地域向けに公開するにあたっての注意点を紹介します。

（外国語のコンテンツは発信しないから関係ないと思うかもしれませんが、もしかしたら他の国の人が、Google 翻訳のようなツールを使ってあなたのページを自分の母国語で見ているかも知れません。サイトを本来の表示言語以外の言語で見ているユーザーの割合は、アナリティクスのマイレポートに表示されるトラフィックを参照することでわかります）

「言語が増える=HTML テンプレートが増える」ではない
これについてはいくら強調しても足りないくらいですが、同じテンプレートをすべての言語バージョンで再利用すること、そしてテンプレートの HTML はシンプルにしておくことを強くおすすめします。

HTML コードがどの言語でも同じであることは、メンテナンスの観点から非常に重要です。言語ごとに HTML コードに手を加えてバグを修正するのでは、拡張性に欠けます。ページのコードはできるだけシンプルなままにしておいて、スタイルについては CSS を使うのがよいでしょう。（コードをシンプルしておくもう 1 つの利点は、翻訳のしやすさです。ほとんどの翻訳ツールは HTML ドキュメントを解析して翻訳可能な文字列を抽出しますので、この作業は、HTML の構造が正しければ、非常に容易です）

文字列の長さに注意
要素のサイズを固定したときにテキストがきれいに見えるようなデザインの場合は、テキストを翻訳すると大変なことになるおそれがあります。たとえば、ページの左側に置いたナビゲーション用のテキストが、翻訳するとかなり長くなってしまうことがあります。ナビゲーション用のタイトルが 2 行にまたがってしまう可能性も考えて、全体が収まるように行の高さを決定する必要があります（ナビゲーションテキストを最初に母国語で作るときもこのことは考慮する価値があります）。

テキストの長さが変動することが特に問題となるのは、フォームのラベルやレイアウトです。たとえば、フォームのラベルを左側に、入力フィールドを右側に配置したデザインの場合は、テキストが長いと 2 行になってしまい、短いと入力フィールドとの間が空きすぎて関連がないように見えてしまいます。どちらの場合もデザインが台無しになり、フォームの可読性が損なわれます。さらに、右から左（RTL）にテキストを記述する言語のレイアウトについてもスタイルを考慮する必要があります（詳しくは後ほど）。このような理由から、Google では、ラベルをフィールドの上に置くようにフォームをデザインしています。フォームが読み取りやすくなり、さまざまな言語に翻訳したときもスタイルの維持が容易だからです。

クリックで拡大表示

また、テキストを表示する領域の高さを固定するのも避けたほうがよいでしょう。高さを揃えたいくつかのボックスを背景としてレイアウトすると、母国語のテキストはぴったり収まっても、テキストが翻訳されたときにあふれ出てしまうことがあります。デザインの中で使う UI 要素が、テキストの長さの増減によって影響を受けるかどうかも考える必要があります。たとえば、タブを横に並べるか、縦に並べるかといったことです。

右から左へ記述する言語への対応
右から左へ記述する言語のページに表示するためのコンテンツは、ほとんどの場合、純粋な RTL ではなく双方向となります。テキストによっては、左から右という方向を維持する必要があるからです（会社名の英語表記や電話番号など）。双方向 HTML のソース編集には問題が起こりがちですが、その理由は、エディタの多くが Unicode の双方向アルゴリズムをサポートしていないことです（問題と解決策に関する詳しい情報（英語））。例えば下の例のように " と > の順序を間違えてしまうということが起きえます:

<p>ابةتث <img src="foo.jpg" alt=" جحخد"< ذرزسش!</p>

双方向のテキストを適切に編集できるエディタは Coda のほか、Dreamweaver、IntelliJ IDEA、JEditX などがあります。

RTL 言語用にページをデザインするときは、必要なサポートのほとんどをコア CSS に組み込み、html 要素の dir 属性（下位互換性のため）とともに body 要素にも CSS のクラスを用意するのがよいでしょう。他の場合と同様に、すべてのスタイルを 1 つのコアスタイルシートに集めておくと、メンテナンスがしやすくなります。

スタイルに関しては、右側にフロートする要素は左側にもフロートする必要があり、その逆も同じであることに注意してください。要素の一方の側に設定されているパディングやマージン幅は反対側に置かれ、テキストの整列属性は反対向きに設定されます。

Google が通常採用しているアプローチの 1 つに、html[dir=rtl] CSS セレクタではなく body タグのクラスを使用するというものがありますが、これは古いブラウザとの互換性のためです。例えば以下のように HTML, CSS を記述します。

要素:

<body class="rtl">
<h1><a href="http://www.blogger.com/"><img alt="Google" src="http://www.google.com/images/logos/google_logo.png" /></a> 見出し</h1>

左から右への（デフォルトの）スタイル:
h1 {
height: 55px;
line-height: 2.05;
margin: 0 0 25px;
overflow: hidden;
}
h1 img {
float: left;
margin: 0 43px 0 0;
position: relative;
}

右から左へのスタイル:
body.rtl {
direction: rtl;
}
body.rtl h1 img {
float: right;
margin: 0 0 0 43px;
}

（実際の例を英語版とアラビア語版で比較できます。）

また、RTL を主とするドキュメントの中に会社名の英語表記や電話番号のような左から右のテキストがある場合に、ブラウザで正しく処理されるようにするには、インライン要素で埋め込まれたテキスト文字列を、方向を設定する属性を使って折り返します。

<h2>‫עוד ב- <span dir="ltr">Google</span>‬</h2>

dir 属性を入れる HTML コンテナがない場合（title 要素や、メッセージプロンプト用に JavaScript によって生成されたソースコードなど）は、次のようにすると同じことを実現できます。‫ と ‬‬ は、Unicode 制御文字です:

<title>&#x202B;‫הפוך את Google לדף הבית שלך‬&#x202C;</title>

JavaScript コードでの使用例:
var ffError = '\u202B' +'כדי להגדיר את Google כדף הבית שלך ב\x2DFirefox, לחץ על הקישור \x22הפוך את Google לדף הבית שלי\x22, וגרור אותו אל סמל ה\x22בית\x22 בדפדפן שלך.'+ '\u202C';

（詳細については、アラビア語やヘブライ語などの右から左へ記述する言語の HTML ページの作成と RTL 言語でのスクリプトの作成（英語）に関する W3C の記事を参照してください）

文字化け
（既に日本語文字を使用しているウェブマスターの方はあまり意識する必要はないと思いますが、）ラテン文字以外の外国語の文字セット（キリル文字、ギリシャ文字、アジアやインドのさまざまな言語の文字）をこれまでに一度も使用したことがない場合は、エディタとブラウザのどちらも、コンテンツが意図したとおりに表示されない場合があります。

エディタとブラウザのエンコードが UTF-8（推奨）に設定されていることを確認するとともに、HTML テンプレートに html 要素の lang 属性を追加することを検討してください。これによって、ブラウザがページを正しくレンダリングできるようになります。このことには、すべての Unicode 文字が正しく表示されるという利点もあります。つまり、é（é）のような HTML 実体参照を使う必要がなくなるので、貴重なバイト数を節約できます。エンコードをうまく解決できないときは、W3C の文字エンコードに関するチュートリアル（英語）を参照してください。この問題の詳しい説明があります。

標準規格に従った命名
最後に、複数の言語バージョンを作るときの命名規則に関する実務的なヒントを紹介します。ISO 639-1 言語コードなどの標準規格に従って名前を付けておくと、同じドキュメントのさまざまな言語バージョンを扱うときに便利です。

標準の命名規則が使用されていれば、ユーザーがサイトの構造を理解しやすくなることに加えて、サイトを構築するウェブマスターにとってもメンテナンスしやすくなります。また、サイトのその他の要素（ロゴ画像や PDF ドキュメントなど）に言語コードを使うと、ファイルの識別がしやすくなります。

また、ウェブマスターセントラルの記事で、URL 構造に関するヒントと、多地域向けウェブサイト（英語）や多言語ウェブサイトに関する問題について紹介していますので、参考にしてください。

ここで紹介したことについては、Google 自身も日々苦戦していますが、確かに言えることは、十分な計画を立てて適切な構造の HTML としっかりとした CSS を作成すれば、ローカライズが格段に楽になるということです。

Posted by Kathryn Cullen, Google Webmaster Team
Original version: Îñţérñåţîöñåļîžåţîöñ

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

2012-02-01T18:06:00.000+09:00

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

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

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

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

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

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

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

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

2012-01-31T11:02:00.001+09:00

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 経由でリソースをクロールする

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>

Google が yummy-sundae.html のインデックス登録を開始します。この過程で、コンテンツのよりよい理解やインスタントプレビュー生成のためにページのレンダリングが必要かどうかを判断します。
レンダリングを行う際は、yummy-sundae.html がリソース hot-fudge-info.html への XMLHttpRequest を自動的に POST で送信します（上記の $.post(...) の部分）。
POST リクエストされた URL （ hot-fudge-info.html ）とリクエストデータ本体が Googlebot のクロール待ち行列に追加されます。
Googlebot が hot-fudge-info.html をクロールするために POST リクエストを送信します。
これで Google は yummy-sundae.html の正確なインスタントプレビューを作成できるようになりました。この際、hot-fudge-info.html のコンテンツを yummy-sundae.html に組み込む場合もあります。
Google が yummy-sundae.html のインデックス登録を完了します。
ユーザーが[hot fudge sundae]を検索します。
ここで 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

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

2012-01-27T10:00:00.000+09: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

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

2012-01-16T10:37:00.000+09:00

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

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

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

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

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

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

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

Posted by Takeaki Kanaya, Search Quality Team

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

2012-01-12T10:50:00.000+09:00

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 は以下のツールを提供しています。

Safe Browsing Alerts for Network Administrators （英語）: ホスティングプロバイダ向けの情報です。
マルウェアの通知: ウェブマスターツール内にある個別のウェブサイト向けの情報です。
Safe Browsing API について: 開発者向けです。

以上のヒントが、ホスティングプロバイダとウェブマスターの皆さまが問題を見つけ出し修正するのに役立てば幸いです。ここに挙げた以外に、サービスの品質やサポートの充実度など、ホスティングの品質面についても気を配るようにしてください。

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

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

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

2011-12-27T10:58:00.001+09:00

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 年にウェブマスターのみなさまの関心を集めたブログ記事は!? 年末年始のお休み中にぜひお読みください。

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

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

2011-12-19T11:50:00.000+09:00

世界中のユーザーからのアクセスがあるようなサイトにおいて、ユーザーの言語や地域に適したコンテンツを提供する方法はいくつかあります。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 を使用するようにしてください。

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

Written by Christopher Semturs, Software Engineer, Search Infrastructure, Google Switzerland
Original version: New markup for multilingual content

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

2011-12-16T01:22:00.000+09:00

スマートフォンユーザの増加に伴い、最近ではスマートフォン用に最適化されたコンテンツを提供するサイトも増えてきました。そこで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 に関する質問専用のスレッドでその回答を公開しております。ぜひこちらも合わせてご覧下さい。

Posted by 加藤義清 / ソフトウェア・エンジニア